IT-инфраструктура *

Как-то раз внутри корпорации Google появилась идея раздавать интернет с помощью воздушных шаров, парящих в стратосфере, — так родился Project Loon. Проект должен был обеспечить доступ к сети в отдаленных и труднодоступных точках, но после нескольких лет испытаний, триумфов и неудач его, к сожалению, закрыли. Правда, не совсем — некоторые наработки были реализованы уже в другом проекте под названием Taara. Об этом сегодня и поговорим.

Недавно, скучая после безумно скучного учебного дня и бездумно листая главную страницу моего любимого видеохостинга в поисках чего-нибудь интересного, мне попалось одно любопытное видео, сподвигшее к созданию невероятного.

Как можно видеть с самого видео, человек, нажимая на кнопку в Майнкрафте, включает у себя лампу в реальной жизни. Круто! Но как это работает?

«Папа, ну почему Солнце каждый день всходит на Востоке, а садится на Западе?» — «Главное — ничего не трогай!». Все вполне логично. Зачем менять технологию, инструмент, подход, если он и так хорошо работает. А инициатива, как известно, наказуема — рядового сотрудника за успешное внедрение чего-то нового максимум похвалят, а вот выпроводить за неудачу могут легко. Поэтому и существуют отделы RnD. Их задача — вовремя найти, оценить и предложить бизнесу то, что в будущем может принести деньги. Или же вовремя понять бесперспективность технологии. 

Привет, Хабр! Меня зовут Александр Сапронов, я руковожу лабораторией ИТ-инфраструктуры в центре компетенций RnD МТС. Мы с коллегами щупаем, перегружаем, перегреваем и всячески издеваемся над разным компьютерным «железом» (например, опускаем в бочку со специальной жидкостью), чтобы через пару лет не пришлось менять его во всех продуктах, потому что оно не соответствует требованиям или превратилось в кирпич. В этом цикле постов я расскажу, как в крупных компаниях внедряют новые технологии, на какие этапы делят их жизненный цикл и почему в современном мире без RnD нельзя. 

А начну с обзора работы RnD в крупных организациях: как они встроены в структуру, что делают, с какими проблемами сталкиваются и зачем вообще нужны. Все подробности — дальше.

Краткое введение в графы: их устройство, основные типы и способы хранения в программе. Всё изложено просто и по делу — для тех, кто хочет быстро разобраться в теме.

Вы наверняка сталкивались с системами хранения данных семейства TATLIN или серверами VEGMAN, хотя можете об этом даже не подозревать. Например, делая заказ в интернет-магазине или пользуясь другими популярными онлайн-сервисами — в глубине ИТ-инфраструктуры для них можно обнаружить продукты YADRO. 

Всем привет, меня зовут Александр Чуриков, я технический эксперт отдела сервисного дизайна YADRO. Мы служим мостиком между сервисом и нашим R&D, который разрабатывает продукты — изучаем все боли сервиса, которые возникают при обслуживании, в том числе при обновлении и замене компонентов, и транслируем их в R&D. Предлагаю подробно разобраться в процессе обновления СХД TATLIN.UNIFIED: от операционной системы и до прошивок аппаратных компонентов.

В Островке мы строим экосистему вокруг данных — от хранилищ и пайплайнов до систем мониторинга и каталогов. Но когда всё только начиналось, под часть наших процессов просто не существовало готовых решений. Так появился наш собственный дата-каталог DataPortal — лёгкий, быстрый и идеально подходящий для небольшой компании.

Со временем всё изменилось: объём данных вырос в десятки раз, появились новые команды, и вместе с этим начали звучать вопросы вроде «где лежат данные для этого дашборда?», «кому писать, если он упал?» и «можно ли этим данным доверять?». Так мы поняли, что пора взрослеть — и искать инструмент, который поможет масштабировать не только инфраструктуру, но и дата-культуру.

Мы выбрали DataHub — open-source каталог, обещавший прозрачность, автоматизацию и гибкость. Развернули, подключили источники, построили lineage, и даже порадовались, что всё заработало с первого раза. А потом стало ясно: DataHub не заменил наш DataPortal. Более того, оба инструмента отлично дополнили друг друга — инженерное ядро и удобное окно в данные для бизнеса.

Почему два дата-каталога оказались лучше одного, как это повлияло на культуру работы с данными и что нам дал DataHub помимо красивых графов lineage — рассказываем под катом.

Hello! Bonjour! Hola! Nǐ hǎo! Здравствуйте!

Сегодня поговорим о наболевшем – совместимости западного оборудования с отечественным. У нас уже есть опыт построения фабрики ЦОДов на российских коммутаторах Eltex. И мы даже проверили ее работоспособность под нагрузкой. Вывод – работает.  Бери и делай – построить фабрику с нуля на едином вендоре проблем не составляет. 

Но что, если нам нужно расширить существующую фабрику ЦОДов или заменить только один, вышедший из строя, коммутатор?

Можем ли мы использовать оборудование Eltex в комбинации с другими вендорами? Давайте проверим. А проверять мы будем на всем привычном оборудовании Cisco (Hello!) и Huawei (Nǐ hǎo!).

Команды разработки и DevOps начинают совместную работу с энтузиазма и взаимного уважения. Но со временем отношения превращаются в холодную войну. В ней нет победителей — только выгоревшие. Разработчики не понимают инфраструктуру, тестировщики хотят странного, безопасники закручивают гайки, DevOps окапываются в обороне, процессы тормозят работу, а CTO хватается за голову. Все стараются, но становится только хуже. Но есть способы это изменить и превратить  конфликты в полезное сотрудничество.

DevOps-команды сегодня — это внутренние поставщики сервисов: от пайплайнов и окружений до документации и архитектурных решений. В этой статье поговорим о том, как выстроить эту работу так, чтобы было удобно и разработчикам, и самим девопсам. Как выйти из роли «пожарной команды», навести порядок в ожиданиях и инструментах, построить платформу и не сгореть.

Чтобы разобраться, где вообще рождаются платформенные практики и кто их использует, давайте посмотрим на разные типы компаний и что конкретно происходит на поле боя.

Всем привет! Меня зовут Василий Иванов, я ведущий разработчик в команде Data Storage в MWS Cloud Platform, занимаюсь тем, чтобы диски наших виртуальных машин были надёжные и быстрые.

В этой статье я расскажу, как данные попадают из виртуальной машины в хранилище. Рассмотрим, как мы используем SPDK, зачем мы вообще взялись за этот низкоуровневый фреймворк, а также почему просто «заиспользовать» не получилось и пришлось копать, как всё устроено в самой глубине. Также мы увидим, как high performance фреймворка при нашем количестве устройств не хватало и какие доработки пришлось сделать.

Эта статья выходит по следам моего доклада на летнем Highload 2025 года.

Наш ЦОД «Медведково», о котором мы уже рассказывали, в 2024 году стал кластером, так как рядом был построен еще один дата-центр — «Медведково-2». В этой статье мы покажем, как устроен новый ЦОД.

Здание «Медведково-2» возвели за год, параллельно проводили интеграцию инженерных систем. К 2024 году ЦОД полностью подготовили для проведения аудита и сертификации. Дата-центр успешно прошел испытания Uptime Facility и получил сертификат Tier III.

Привет! Меня зовут Михаил Шпаков, я разрабатываю Statuser — платформу для мониторинга доступности сайтов, приложений и серверов. Делаю всё один, по вечерам, без команды.

В этой статье я расскажу, как появилась функциональность, которая была в планах с самого начала — публичные страницы статуса. Эта идея зрела давно, и запросы от первых клиентов только ускорили её появление.

Объясню, как всё устроено внутри, с какими техническими решениями пришлось столкнуться и почему статус-пейджи — это логичное продолжение любого хорошего мониторинга.

Всем привет! Долгое время считалось, что виртуальные продукты не способны сравниться по производительности с аппаратными аналогами. Особенно остро эта проблема проявляется в сегменте NGFW, где высокий трафик и глубокий анализ требуют значительных ресурсов. Но так ли это на самом деле? Действительно ли виртуальный межсетевой экран не способен обеспечить производительность в 5 Гбит/с и более, необходимую для современных корпоративных сетей и высоконагруженных систем?

Данная статья призвана ответить на этот вопрос. На примере PT NGFW мы не только продемонстрируем потенциал виртуальных межсетевых экранов, но и дадим практические рекомендации по настройке виртуальной инфраструктуры, а также подсветим важные нюансы, которые стоит учесть при использовании NGFW в виртуальной среде.

Мы все чаще сталкиваемся с парадоксом: с одной стороны, растут требования к скорости вывода продукта на рынок, с другой — увеличивается сложность приложений. При этом, разработчики тратят большое количество времени на рутинные задачи, такие как интеграция с API и написание boilerplate-кода. Именно здесь на помощь приходит автоматизация рутинных задач во фронтенде на основе OpenAPI-спецификаций и она может очень сильно упростить нам, фронтендерам, жизнь!

Привет, Хабр!

Сегодня рассказываем об одном любопытном кейсе в крупном заказчике, который столкнулся со странным поведением при построении свой сети с NSX-T от VMware. Проблема была связана с реализацией Bridge между сегментом GENEVE и физической сетью. В целом, это известный и востребованный механизм, а также он помогает закрыть часть вопросов, когда нужно «подружить» Overlay и физическую сеть без роутинга. До решения докопались – об этом читайте ниже во всех подробностях.

Всем привет! Меня зовут Алексей Мерсон, я несколько лет работал Developer Advocate в Sage, платформе наблюдаемости Т-Банка. Эта платформа сама по себе очень немаленькая, со сложной архитектурой. Но если посмотреть на ландшафт экосистемы в целом, то Sage — всего лишь одна из платформ в Т-Банке, необходимых, чтобы наши услуги были надежными. А платформы, в свою очередь, — это тоже только часть более общей картины. 

В этой статье хочу поговорить о том, какие инструменты и практики мы используем для надежности в Т-Банке. Уделим внимание работе с инцидентами. И отдельно сфокусируемся на клиентском опыте: мне кажется, мы, инженеры, часто забываем, что технологии делаются не ради технологий, а ради решения задач бизнеса и его клиентов. Если они будут довольны, то и у нас будет больше возможностей заниматься интересными нам вещами.

Большинство серьезных сбоев в системах хранения данных происходят не из-за глобальных катастроф, а из-за незаметных повторяющихся отказов, на которые никто не рассчитывал: перегруженный контроллер, зависание диска, сбой питания в неподходящий момент. Такие ошибки не поймать быстрыми и однократными тестами. В целом, надежность системы хранения данных невозможно проверить абстрактно — только вживую, на реальном железе, часами, с полным погружением в нагрузку и нестабильность.

Я Наталья Грязнова, ведущий инженер по разработке ПО в YADRO. Моя задача — не просто проверить, что СХД работает, а воспроизвести реальные риски отказа системы и проверить ее на устойчивость: высокая нагрузка, внезапные отказы компонентов системы, нестабильные внешние условия, например перебои в сети. В этом тексте расскажу, как мы тестируем отказоустойчивость СХД TATLIN.UNIFIED: какие сбои моделируем, как устроены автотесты и почему короткие прогоны не справляются с поиском критичных багов.

Привет! Продолжаем понемногу рассказывать о том, как мы строим собственные ЦОД. Под катом — коротко о том, что мы сделали за минувший месяц.

ChatGPT стоит дорого, требует постоянного интернета и может внезапно отключиться. Альтернативой становятся компактные Edge-устройства, способные работать автономно. Но действительно ли локальное железо может конкурировать с облачными гигантами?

Антон Мальцев знает ответ на этот вопрос. ML Lead в ArtSign и основатель RemiBrain, он с 2014 года развертывает решения компьютерного зрения и ИИ на тысячах Edge-устройств — от городских камер до промышленного оборудования. За десять лет накопил уникальный опыт сравнения облачных и локальных решений в реальных проектах.

С начала 2025 года мы выпустили четыре крупных обновления DVP, внедрили более 72 изменений и добавили более 32 новых фич и улучшений. В этом дайджесте — самые важные изменения: живая миграция без простоев, расширенные политики безопасности, новый аудит, автоматизация работы с ВМ и многое другое.

Привет, Хабр!

В этой статье разберём важнейший механизм защиты от перегрузок и DoS-атак в NGINX — лимиты.