[3/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Сквозная обработка пользовательских запросов (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1 и 2). Мы поговорим про обработку пользовательских запросов, которая спроектирована end-to-end для достижения нужного уровня качества (latency, scalability, reliability, ...) и стоимости.

Глобальная сеть и точки присутствия (PoP)
Чтобы минимизировать задержки, Meta динамически направляет запросы пользователя к ближайшему своему узлу. Когда пользователь открывает, например, facebook.com, DNS Meta возвращает IP ближайшего point of presence (PoP) - небольшого edge датацентра, который завершает входящее соединение от пользователя и проксирует трафик в основные регионы датацентров Meta по заранее установленным долгоживущим соединениям (внутри своей WAN сети). Это позволяет сократить время установления соединения и сбалансировать нагрузку между регионами

CDN и кеширование статичного контента
Если пользовательский запрос касается статического контента, то ответ может быть дан напрямую на уровне PoP, если там содержится свежий кеш. Meta также размещает кеш-серверы внутри сетей интернет-провайдеров при большом объёме трафика.

Маршрутизация динамических запросов
Если запрос не относится к статическому контенту (то есть требует генерации ответа на лету), PoP перенаправляет его во внутреннюю сеть Meta. Специальный балансировщик нагрузки в выбранном регионе ЦОД принимает входящий поток и распределяет запросы по фронтенд-серверам. В Meta фронтенд реализован как масштабируемый serverless слой: каждый пользовательский запрос обрабатывается отдельной фронтенд-функцией, которая может вызывать множество бэкенд-сервисов для составления ответа. Здесь появляется второй инсайт от автора статьи

Insight 2 : Meta’s global infrastructure consists of CDN sites, edge datacenters, and main datacenters. Because of the high volume of our internal cross-datacenter traffic, we have built a private WAN to connect our datacenters, rather than relying on the public Internet.

Асинхронная обработка и офлайн-вычисления
Для задач, не критичных к мгновенному ответу, широко применяется асинхронная обработка. Фронтенд-функции могут ставить события в очередь, которые будут обработаны отдельно специальными фоновыми функциями без блокировки ответа пользователю. Такие event-driven функции запускаются параллельно, их выполнение оптимизировано под пропускную способность (throughput), а не задержки (latency), и они не влияют на время ответа основного запроса. В то же время всё, что происходит при обработке запросов, генерирует огромные объёмы данных, которые непрерывно сбрасываются в хранилище данных (data warehouse). Дальше офлайн-системы Meta используют накопленные данные для пакетных и стриминговых вычислений, которые потом используются онлайн-сервисами при обработке новых пользовательских запросов. Здесь появляется третий инсайт от автора статьи

Insight 3 : Using a data warehouse as an intermediate layer to decouple online and offline processing simplifies the architecture and enables independent optimizations.

Это является ключевым принципом устойчивости и эффективности при гипермасштабе.

Топология и масштаб инфраструктуры
Масштаб инфраструктуры примерно следующий
- Регионов в компании десятки, в каждом регионе множество датацентров, в каждом из которых сотни тысяч серверов
- PoPs сотни, в каждом из них от сотен до тысяч серверов
- CDN site тысячи, в каждом из них типично десятки серверов, но иногда бывают и сотни
- MSB (main switchboards) - штука для секционирования питания внутри датацентров, их дюжины в датацентрах, типично MSB обслуживает десятки тысяч серверов

В следующем посте мы поговорим про подходы, что обеспечивают продуктивность инженеров Meta.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[4/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Повышение продуктивности разработки (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2 и 3). Мы поговорим про то, какие аспекты позволяют быть разработчикам внутри Meta более продуктивными.

Continuous deployment и автоматизация
Одной из главных целей общей инфраструктуры Meta является ускорение работы разработчиков. В компании довели до экстрима подходы CI/CD, добившись практически полного автоматического выпуска обновлений. 97% сервисов Meta разворачиваются без ручного участия инженеров - изменения поставляются через автоматические пайплайны деплоя (более 30к пайплайнов следят за обновлениями). Около 55% сервисов используют реально непрерывный деплой, остальные ~42% - развёртываются роботами по расписанию (как правило, ежедневно или еженедельно). Например, фронтенд-платформа Meta (serverless-функции, обслуживающие пользовательские запросы) релизится каждые три часа, а она работает на 500к+ серверов и ее код ежедневно меняют 10к+ разработчиков.

Конфигурация как код и мгновенные изменения
В Meta разграничение между “кодом” и “настройками” практически стёрто - конфигурационные изменения обрабатываются теми же конвейерами, что и программный код. Каждый день более 100к изменений конфигураций автоматически применяется на продакшене с помощью внутренней системы управления настройками. Они затрагивают порядка 10к различных сервисов и 1M+ запущенных процессов по всему миру (настройки параметров балансировки нагрузки, включение feature flags, настройки A/B тестов, ...). Практически каждый инженер Meta, пишущий код, также вносит правки в “живые” конфиги:
- Они хранятся в репе как код
- Проходят peer-review
- Раскатываются через CD pipelines
- Агенты по принципу publish-subscribe раскатывают изменения на сервисы
- Приложения применяют новые параметры на лету, без перезапуска процессов
Из этого следует четвертый инсайт статьи

Insight 4 : Even for a large organization with O(10,000) services, it is feasible to adopt continuous deployment at extreme scales and speeds. Specifically, 97% of our services adopt fully automated deployments without manual intervention, and 55% deploy every code change instantly.

Инструменты для качества и быстрого отката
Стремление “выпускать сразу” неизбежно повышает риски сбоев, поэтому в Meta разработаны многоуровневые средства для безопасного развертывания. Перед полным выкатом новый код проходит автоматические тесты и канареечные прогоны. В случае обнаружения проблем хорошо отлажены механизмы мгновенного отката до предыдущей стабильной версии.

Serverless functions как основа разработки
Более 10 000 разработчиков Meta используют FaaS ежедневно, а это устраняет необходимость в управлении инфраструктурой: код автоматически масштабируется и разворачивается и оптимально использует инфру. Использование FaaS интегрировано в IDE (облегчен доступ к социальному графу и бэкенд‑системам). FaaS - это stateless архитектура, которая опирается на внешние кэш‑системы и базы данных, что обеспечивает предсказуемое поведение и простоту горизонтального масштабирования.У Meta есть две FaaS платформы:
- FrontFaaS для обработки пользовательских запросов (PHP, Python, Erlang, Haskell) с low latency
- XFaaS для обработки асинхронных, событийных функций с резкими пиковыми нагрузками. Они оптимизируются через глобальный балансировщик, отложенное выполнение и квот‑троттлинг, чтобы избежать оверпровижининга.
Эту часть обобщает пятый инсайт

Insight 5 : Serverless functions have become the primary coding paradigm for product development at Meta. More than 10,000 Meta engineers write code for serverless functions, exceeding the number of engineers writing regular service code by 50%.

В следующем посте мы поговорим про то, как Meta уменьшает свои затраты на инфраструктуру.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[5/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Снижение затрат на оборудование (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3 и 4) и обсудим снижение затрат на инфру.

All global datacenters as a computer
Подход Meta к восприятию своей инфры отлично описывается очередным инсайтом

Insight 6 : Meta is evolving from the practice of “the datacenter as a computer” to the vision of “all global datacenters as a computer.” In this model, the infrastructure autonomously determines and migrates deployments across global datacenters in response to workload changes, eliminating the need for user involvement. We have successfully demonstrated this approach for databases, ML systems, and diverse services operating at the scale of O(100,000) servers and O(100,000) GPUs.

Hardware and software co-design
Но при этому появляется потребность в совместном проектировании софта и железа для него
- Graceful degradation: эффективная инфраструктура должна уметь адаптивно деградировать при экстремальных ситуациях, чтобы не держать постоянный избыточный запас мощности про запас. В Meta система Defcon умеет отключать функциональность по уровням приоритетности, освобождая ресурсы для ключевых сервисов
- Экономия на proxy в service mesh: в индустрии распространена архитектура service mesh с sidecar proxy per service, который перехватывает и маршрутизирует запросы. Meta разработала свою систему ServiceRouter (~1% RPC-запросов проходят через proxy, а 99% - маршрутизируются напрямую с помощью встроенной в каждый сервис библиотеки). Это экономит 100k+ серверов
- Многоуровневое хранение данных: чтобы оптимизировать расходы на хранение, данные разделяются на категории по частоте доступа и допустимой задержке
-- Горячие данные (соцграф, ленты, кеши) хранятся в высокопроизводительных системах (RAM + SSD)
-- Тёплые данные (фото/видео пользователей, кликстрим) хранятся в распределенной файловой системе Tectonic на обычных HDD-дисках (1 server ~36 HDD + 2SSD для metadata)
-- Холодные данные (оригинальные видео высокого качества) архивируются на ультраплотных storage-серверах с большим числом медленных дисков (1 server ~216 HDD)
- Локальные SSD вместо сетевых хранилищ: в индустрии облачных сервисов считается хорошей практикой выносить хранение отдельно на блочное устройство для простоты миграций и балансировки нагрузки. Но в Meta ради экономии и низкой latency предпочитают локальные SSD даже для stateful-сервисов, где это возможно. От этого возникают сложности, которые Meta решает централизованно через систему управления шардированием (Shard Manager), которая абстрагирует размещение фрагментов данных и обеспечивает автоматический ребаланс
- Дешёвое оборудование с надёжностью через софт: в публичных облаках оборудование часто дублируется, потому что приложения клиентов могут быть не готовы к сбоям. Meta выбрала противоположный подход - использовать более простое и дешёвое железо, но заставить всё ПО быть устойчивым к отказам. В итоге, очередной инсайт звучит так

Insight 7 : To reduce hardware costs, we use software solutions to overcome the limitations of lower-cost hardware. Although this approach adds complexity to the software stack, we consider the trade-off worthwhile due to the significant cost savings.

In-house hardware design
Для всего описанного выше Meta сама разрабатывает конструкции ЦОДов (Open Compute датацентры), а также значительную часть оборудования. Контроль над дизайном позволяет убирать всё лишнее и повышать эффективность (особенно эффективность использования электроэнергии, что сейчас является бутылочным горлышком для ДЦ)

Insight 8 : To reduce hardware costs and power consumption, Meta designs its own datacenters, servers, racks, and network switches, and shares these designs through open source.

В следующем посте мы поговорим про то, как инженеры в Meta проектируют свои системы.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[6/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Проектирование масштабируемых систем (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4 и 5) и обсудим как ребята подходят к проектированию масштабируемых приложений.

Централизация vs децентрализация
Инфраструктура планетарного масштаба исторически ассоциируется с децентрализованными архитектурами (BGP, BitTorrent, и т.п.). Они хорошо масштабируются без SPOF (single point of failure). Однако опыт Meta показал, что в пределах датацентра, где ресурсы относительно надёжны и управляются одной организацией, централизованные контроллеры зачастую упрощают систему и при этом обеспечивают достаточную масштабируемость. А часто это еще позволяет принимать более глобально оптимальные решения, чем множество локальных агентов. Поэтому Meta сознательно отошла от многих изначально распределённых дизайнов в сторону управляемых централизованно. Например,
- Внутренняя сеть ЦОД (Fabric) по-прежнему использует протокол BGP для совместимости, но маршрутизацией управляет центральный контроллер, который при перегрузках или обрыве линков переоптимизирует пути трафика взамен медленной сходящейся динамики BGP
- В магистральной глобальной сети (WAN) Meta изначально применяла децентрализованный протокол резервирования полосы (RSVP-TE), но затем перешла на центральный контроллер, рассчитывающий оптимальные пути для потоков между датацентрами и заранее прокладывающий резервные каналы на случай типовых отказов. Это позволило значительно эффективнее использовать пропускную способность каналов и упростило управление сетью.

В общем случае подход Meta можно сформулировать таким инсайтом

Insight 9 : In a datacenter environment, we prefer centralized controllers over decentralized ones due to their simplicity and ability to make higher-quality decisions. In many cases, a hybrid approach - a centralized control plane combined with a decentralized data plane-provides the best of both worlds.

В качестве примера подробнее разбирается гибридный service mesh под названием ServiceRouter (попытка получить “лучшее из двух миров”). ServiceRouter обслуживает миллиарды вызовов в секунду между микросервисами, распределёнными по миллионам программных маршрутизаторов уровня L7. В традиционных решениях service mesh (например, Istio) каждое приложение сопровождается локальным прокси, через который проходят все исходящие и входящие вызовы. В ServiceRouter Meta от этой схемы отказались (как упоминалось, ~99% запросов идут без sidecar-прокси). Вместо этого
- Control plane централизован - он агрегирует всю информацию о сервисах и глобальных метриках сети, вычисляет оптимальные правила маршрутизации и сохраняет их в RIB (outing Information Base), построенной поверх распределенной базы данных Delos с Paxos протоколом (то есть она распределена и отказоустойчива). Таким образом, центральные контроллеры ServiceRouter ответственны только за вычисление глобальных решений, а непосредическая работа по маршрутизации лежит на data plane.
- Data plane в виде отдельных L7 routers децентрализован - они автоматически подтягивают из RIB нужные им сведения (кэшируют небольшой необходимый поднабор) и работают автономно, без постоянного участия центрального координатора

Благодаря такому дизайну достигаются
- Простота управления - центрально видна вся картина
- Масштабируемость - нет узкого места, через которое прошёл бы весь трафик
В итоге, удаётся обеспечить полный функционал сервис-меша (балансировка, retries, discovery, мониторинг) при минимальном расходе ресурсов и с возможностью глобального оптимального распределения нагрузки.

В последнем посте из серии мы поговорим про будущие направления развития инфраструктуры и архитектуры Meta (это одна из самых интересных частей)

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[7/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Будущие направления развития (Рубрика #Infrastructure)

Этот пост финальный в рассмотрении крутой обзорной статьи от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4, 5 и 6). Здесь мы обсудим как автор видит дальнейшее развитие инфраструктуры, архитектуры и проникновение AI в системы компании. Отмечу, что эта часть была мне очень интересна - сложить пазл о том, как развивалась история это одно, а сделать качественное предсказание - это уже задачка со звездочкой.

AI и новая архитектура дата-центров
AI-нагрузки уже стали главным потребителем ресурсов Meta: к концу десятилетия они займут более половины мощностей ЦОД. В отличие от классических веб-сервисов, обучение моделей требует сотен терабайт данных, мощных GPU и сверхбыстрых сетей. Это ведёт к смене парадигмы — от scale-out (много дешёвых узлов) к scale-up, когда создаются крупные AI-кластеры, напоминающие суперкомпьютеры. Meta выстраивает полный стек под AI: от PyTorch и моделей до собственных чипов (MTIA), сетевых решений, хранилищ и систем охлаждения. Всё проектируется комплексно, чтобы работать синхронно. В будущем датацентры наполовину станут «машинами для обучения ИИ» - это изменит всю их архитектуру.

Эра специализированного железа
После эпохи унификации серверов начинается обратный процесс: расцвет кастомных ASIC и ускорителей. Гиперскейлеры могут позволить себе проектировать собственные чипы для AI-тренинга, компрессии, шифрования, видео-кодирования, In-Network-/In-Storage-Processing и т.д. Meta ожидает, что ЦОДы превратятся в гетерогенные кластеры из множества типов оборудования. Главный вызов - научить софт эффективно использовать столь разнородные ресурсы. Для этого потребуются новые уровни абстракций и оркестрации. Но выигрыш в энергоэффективности и стоимости на миллионах серверов окупит усилия.

Краевые датацентры и метавселенная
Meta прогнозирует бурный рост инфраструктуры на «краю» сети — мини-ЦОД, близких к пользователям. Это нужно для AR/VR, облачного гейминга и IoT, где критична задержка <25 мс. Компания строит модель Global Data-center-as-a-Computer: приложения будут автоматически выполняться там, где ближе пользователь, без участия разработчика. Архитектура станет многоуровневой - крупные регионы + сеть микро-ЦОД, объединённых общей системой оркестрации.

Прорыв в средствах разработки
Meta ожидает качественного скачка продуктивности инженеров за счет двух факторов
1. Массовое внедрение AI-ассистентов (Copilot, GPT-4 и др.), которые автоматизируют генерацию кода, поиск багов и рефакторинг и так далее
2. Появление вертикально интегрированных платформ, где разработчик описывает только бизнес-логику, а инфраструктура скрыта под капотом.
Пример - внутренний проект FrontFaaS, ускоряющий создание веб-интерфейсов. Похожие фреймворки появятся и в других доменах, радикально повышая индивидуальную продуктивность.

Совместное развитие
Автор подчёркивает: за 20 лет гиперскейлеры задали темп всей индустрии, и ИИ лишь ускорит этот процесс. Чтобы инновации распространялись быстрее, нужно делиться опытом. Meta призывает публиковать открытые проекты и исследования — как она делает сама. Статья служит именно этой цели: показать, из каких «кирпичиков» строится инфраструктура Meta и какие принципы могут вдохновить инженеров по всему миру.

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

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[2/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Вызовы на сети в эру AI (Рубрика #Infrastructure)

Продолжая рассказ про эволюцию сетей Google, стоит сказать, что сейчас они видят новый поворотный момент - взрывное развитие искусственного интеллекта, что предъявляет к сети беспрецедентные требования (например, обучение больших моделей резко меняют профиль нагрузки на сеть). На самом деле там есть целых четыре отдельных вызова, что приводят к изменению дизайн-принципов развертывания сетей

1. WAN как новая LAN
Обучение современных foundation models требует объединения тысяч TPU/GPU. И то, что раньше размещалось в пределах одного датацентра, теперь распределено географически (континент как датацентр - примерно тот же посыл у запрещенной в России Meta). Сеть должна масштабироваться на порядок больше прежнего, чтобы связать удалённые кластеры так, словно они в одном локальном сегменте. При этом трафик от распределённого обучения идёт всплесками, которые нужно эффективно обнаруживать и маршрутизировать без потери производительности.

2. Нулевая терпимость к сбоям
Процессы обучения моделей ИИ и крупномасштабный inference очень чувствительны к перебоям. Остановка обучения из-за сетевого сбоя - неприемлема из-за простев дорого железа. От сети теперь ожидают практически 100% доступности, без ощутимых перерывов, а значит сеть должна быть спроектирована так, чтобы любые отказоустойчивые механизмы срабатывали мгновенно и вообще не влияли на долгий процесс обучения.

3. Повышенные требования безопасности и контроля
Данные, на которых обучаются модели, и сами модели - ценный и чувствительный ресурс. Их нужно защищать как от утечек, так и от несанкционированных изменений. Кроме того, по мере распространения ИИ растут требования к соблюдению региональных регуляторных норм и к контролю данных "на лету" (в транзите). Сеть должна обеспечивать изоляцию, шифрование, соответствие политикам разных стран и компаний, чтобы ИИ-сервисы оставались надёжными и законопослушными.

4. Операционное совершенство при возросшей сложности
Масштаб, растущий на порядок, не может управляться по-старому. Google применяет лучшие практики SRE и уже использует машинное обучение для управления сетью, но теперь ставится цель минимизировать человеческий фактор. Сеть должна работать с минимумом ручного вмешательства, потому что линейное наращивание инфраструктуры иначе приведёт к неуправляемому росту сложности и затрат. Новые подходы требуются для автоматизации, быстрого выявления и устранения проблем, оптимизации емкости.

Отсюда появляются новые дизайн принципы сетей, которые мы обсудим в следующий раз.

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

[3/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Новые принципы дизайна сетей (Рубрика #Infrastructure)

Продолжая рассказ про эволюцию сетей Google, стоит рассказать про то как новые подходы к архитектуре сетей решает вызовы, озвученные в прошлом посте

1. Экспоненциальная масштабируемость
Сеть должна гибко выдерживать лавинообразный рост трафика и данных, особенно в регионах, где сосредоточены ИИ-вычисления. Принцип "WAN - это новая LAN" реализуется через отказ от монолитна в пользу горизонтального масштабирования (архитектура multi-shard network). Шарды независимы - у каждого свой набор контроллеров и каналов. Это позволяет параллельно наращивать пропускную способность - с 2020 по 2025 год пропускная способность глобального WAN Google увеличилась в 7 раз. Кроме того, такая сегментация упрощает управление: каждая «шардинговая» подсеть более контролируема по размеру.

2. Надёжность выше традиционных “пяти девяток”.
В индустрии обычно говорят о 99.9% или 99.99% доступности, но для критичных AI нагрузок выжны long tail выбросы (нужен детерминизм и бесперебойная работа сети). На практике сеть должна локализовать проблемы и автоматически их обходить до того, как пользователи или процессы заметят сбой. Для этого
- Шарды изолированы друг от друга (сбои не кореллируют)
- Дополнительно введена изоляция по регионам, чтобы локальные неполадки не каскадировались глобально
- Создана технология Protective ReRoute для быстрого обнаружения потерь связи и перенаправления трафика за секунды
После включения Protective ReRoute суммарное время простоев по инцидентам сократилось на до 93%.

3. Программируемость, управляемая намерениями (Intent-driven programmability)
Сеть Google обслуживает миллиарды пользователей и множество корпоративных клиентов с разными требованиями, например
- Кому-то критична задержка
- Кому-то важно шифрование
- А кто-то должен географически раскидывать данные (с учетом регуляторики)

Для удовлетворения таких разных требований ребята сделали сеть полностью программируемой (SDN) на основе высокоуровневых политик (intent), то есть созданы
- Единые модели представления сети (например, модель MALT - Multi-Abstraction-Layer Topology)
- Открытые API для управления
- Централизованные SDN-контроллеры, которые могут трактовать намерения операторов или приложений и применять их к сети.
Такая гибкость позволяет задать политики для конкретных приложений или данных (например, чтобы определённый тип трафика шёл только через узлы в заданной стране для соблюдения суверенитета данных, или чтобы критичные сервисы всегда имели резервные каналы). А высокоуровневое управление не требует ручного конфигурирования (как в SQL достаточно указать что нужно, а умная сеть подстроится под запрос)

4. Автономная сеть
Сети уже прошли путь вида: ручное управление -> автоматизированное (скрипты) -> автоматическое (по жестким правилам). Новая цель в том, чтобы сделать сеть самоуправляемой при помощи машинного обучения и "цифрового двойника", где модели постоянно обучаются на телеметрии.Так сеть сможет симулировать и предвидеть сбои, быстро локализовать причину неполадок и даже оптимизировать планирование ёмкости каналов на будущее.
После внедрения этих инструментов время реакции на сбой сократилось с часов до минут, что существенно повысило эффективность и устойчивость работы сети без участия человека.

Следуя этим четырём принципам, Google внедрила целый ряд технологических новшеств в своей следующей генерации сети. Всё это превращает её глобальную сеть в платформу, способную удовлетворять потребности ИИ без ущерба для опыта пользователей. В финале статьи подчёркивается, что такая сеть открывает возможности не только для Google, но и для клиентов облака (немного нативной рекламы не повредит)

В последнем посте мы сравним эту стать/ про инфру от Google и статью от запрещенной в России Meta.

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

Сравнение подходов Google и Meta к построению сетей и инфры (Рубрика #Architecture)

В этом посте я решил сравнить подходы Google запрещенной в России Meta к своей сетевой архитектуре. Суть в том, что обе эти компании в 2025 году написали статьи на тему того, как инфра меняется с учетом вызовов эры AI и я до этого разобрал обе
- Meta’s Hyperscale Infrastructure: Overview and Insights
- Google's AI‑powered next‑generation global network: Built for the Gemini era

Если обобщать, то обе компании сходятся во взгляде, что их глобальная инфраструктура должна работать как единый организм. У них похожи даже девизы
- Google: WAN – это новая LAN, континент стал датацентром
- Meta: все глобальные датацентры – это один компьютер

Но при реализация акценты у Google и Meta различаются:

1. Масштаб сети и для кого она
И Google, и Meta построили собственные глобальные сети на оптоволокне, связывающие датацентры напрямую, вместо зависимости от публичного интернета. Оба стремятся разместить узлы ближе к пользователям (кэши, PoP) для низких задержек. Но Google делает для себя и клиентов Google Cloud, а Meta только для себя и своих продуктов

2. Архитектура масштабирования
Подходы компаний к масштабируемости сети WAN очень схожи по концепции, хотя реализованы своими методами
- На уровне LAN внутри ДЦ все похоже и oversubscription нет - обе компании используют масштабируемые фабричные топологии (Clos/fat-tree) и добавляют коммутаторы на верхних уровнях
- На уровне WAN у Google шарды, у Meta отдельные planes, но у Google на уровне WAN нет oversubscription, а у Meta есть (а это влияет на возможность/невозможность распределенного обучени foundation models)

3. Надёжность и обновления
У обеих компаний сеть спроектирована с идеей локализации проблем и быстрого самовосстановления, но
- Google говорит об автономной сети - автоматическом реагировании самой сети на проблемы. Задача в том, чтобы сделать ультра-высокую надежность (beyond 9s) и для этого нужна автономная система, что обладает selfhealing возможностями
- Meta говорит об автоматизациях сетевой конфигурации - возможности быстро менять конфигурацию и софт без ущерба работе. То есть здесь закрыт уровень автоматизации, но изменения должен инициировать человек

4. Интеграция с AI-нагрузками
Оба гиганта осознают, что искусственный интеллект диктует новые требования к инфраструктуре. Однако подходы проявляются по-разному.
- У Google сеть позволяет делать распределенные тренировки и они могут горизонтально масштабироваться
- У Meta сеть позволяет распределенно гонять все нагрузки, кроме тренировок больших моделей. Там ребята ориентируютсяй на масштабирование через scale-up внутри ДЦ. Дальше они планируют допилить сеть для возможностей распределенных тренировок

5. Программируемость решений
Оба игрока применяют принципы software-defined networking и автоматизации управления. Но есть и разница
- У Google много разных клиентов (с учетом Google Cloud), поэтому им нужно было удобное централизованное управление политиками сети для разных задач (будь то обслуживание cloud-клиентов или внутренних сервисов)
- У Meta также центральные контроллеры для управления сетью - они постоянно оптимизируют распределение трафика от пользователей (PoP) к датацентрам с учётом загрузки и задержек, а в самих датацентрах контроллер может изменять маршруты при перегрузках или сбоях.

Итого, Google и Meta идут параллельными курсами: они решают схожие задачи гипер-масштабной сети, иногда разными методами, но общая цель одинакова - сеть, способная связать весь мир в единый “компьютер” для своих услуг и будущих AI-приложений. Но вот подход компаний к публикации результатов сильно отличается
- Google публикует научные статьи и продает коммерческие сервивсы, но не публикует код инструментов или дизайн железа
- Meta активно делится дизайнами аппаратного обеспечения через сообщество Open Compute Project, а также публикует многие свои наработки: фреймворки, базы данных

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

[1/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)

Когда я изучал как устроена инженерия в Uber, я наткнулся на отличную статью с разбором эволюции ML/AI платформы Michelangelo. Мне показалось интересным отдельно рассказать про все три этапа эволюции платформы, какие у них были предпосылки, что получилось в итоге, а также что можно почерпнуть себе, если вы тоже делаете платформы в своих компаниях.

Ну и начать стоит с того, что в Uber машинное обучение (ML) уже много лет играет ключевую роль практически во всех аспектах бизнеса - от прогнозирования времени прибытия (ETA) и подбора водителя до ранжирования ресторанов в Uber Eats и выявления мошенничества. Для поддержки такого широкого применения ML Uber в 2016 году создала централизованную платформу Michelangelo (вот рассказ от 2017 года об этом), охватывающую весь жизненный цикл ML-моделей - от подготовки данных и обучения до деплоя и онлайн-инференса. Дальше платформа росла и развивалась, пройдя следующих три этапа эволюции

1️⃣ Predictive ML-платформа (2016–2019)
Фокус: табличные данные, модели типа XGBoost, классические predictive задачи: ETA, ценообразование, риск, антифрод.
Запуск Michelangelo 1.0 как централизованной ML-платформы:
- Единый Feature Store для повторного использования фичей,
- Стандартизованные пайплайны обучения/деплоя,
- Инструменты для мониторинга и дебага моделей.
Цель: перестать собирать ML-инфру в каждой команде как с нуля

2️⃣ Deep Learning & Michelangelo 2.0 (2019–2023)
Первая версия была хорошо, но требовалось порешать новые проблемы
- Deep learing начал давать выигрыш по качеству в high‑impact задачах, а платформа его плохо поддерживала
- Моделей и команд много, инструменты фрагментированы.
- Нет единого взгляда на качество моделей и приоритеты.
Ключевые изменения:
- Michelangelo 2.0: единый продукт вместо зоопарка тулов.
- Встроенная поддержка deep learning (GPU, distributed training, PyTorch/TensorFlow и т.д.).
- Добавлены следующие возможности
-- Model Excellence Score - сквозная метрика качества модели (от обучения до продакшена),
-- Tiering (Tier‑1…Tier‑4) для приоритизации ML-проектов по бизнес‑ценности.
-- Canvas / "model iteration as code": monorepo для ML, шаблоны ML-приложений, CI/CD для моделей, нормальные code review и reproducibility.

3️⃣ Generative AI и LLMOps (2023+)
После появления LLM надо было добавить в Michelangelo слой для generative AI:
- GenAI Platform / GenAI Gateway:
- Единый интерфейс к внешним и внутренним LLM (OpenAI, Llama2 и др.),
- Централизованный контроль доступа, логирование, cost‑контроль, безопасная работа с данными.

Michelangelo решили расширить до end‑to‑end LLMOps:
- Хранение и версионирование LLM,
- Репозиторий и version control для prompt’ов,
- Инструменты оценки качества и A/B-тестов LLM.

Технологический стек был выбран следующий: Hugging Face, DeepSpeed (model parallelism), Ray для распределённых вычислений и масштабирования GPU.

В следующем посте расскажу об уроках, что можно извлечь из этой истории об опыте Uber.

#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign

[2/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)

Продолжая рассказ про ML-платформу Michelangelo хочется поделиться уроками, что можно извлечь из рассказа про 8 лет ее эволюции и развития внутри Uber. Вдруг вы тоже планируете делать свою платформу:)

1. Централизованная ML-платформа
Для средних и больших компаний централизация значительно повышает эффективность разработки ML-моделей, избавляя от дублирования и позволяя внедрять стандарты повсеместно. В Uber оргструктура выглядела так: сильная центральная ML Platform team + встраивание ML-инженеров и data scientist’ов в продуктовые команды. Это позволило совместить экспертизу платформы с глубоким знанием домена продукта

2. Единый и гибкий UX
Кто-то любит интерфейсы “point-and-click”, а другие предпочитают всё делать кодом. Но для платформы важно предоставить обе возможности в рамках единого платформенного опыта: UI-инструменты для визуализации и быстрого прототипирования, а также возможность полноценно работать через код (API, конфигурации, Git). В Uber эта дуальность была критичной для принятия платформы разными командами. Причем разные режимы существуют совместно и платформа синхронизирует изменения, будь то через UI или код, обеспечивая согласованность и version control

3. Высокоуровневые шаблоны + доступ к низкоуровневым компонентам
Платформа обеспечивает эффективность за счет предоставления high-level абстракций (шаблоны типовых ML-пайплайнов, авто-настройки, готовые интеграции) для большинства пользователей. Но для продвинутых команд нужно обеспечить доступ к низкоуровневым компонентам для кастомизации. Именно так сделано в Michelangelo 2.0: большинство используют готовые workflow templates и стандартные конфигурации, а power users при необходимости "спускаются" на уровень кастомных pipelines, встроенных в общую систему.

4. Модульная архитектура и открытость
Модульность позволяет компонентам платформы развиваться и масштабироваться независимо друг от друга. Plug-and-play дизайн позволяет быстро внедрять state-of-the-art технологии из open-source или сторонних сервисов по мере их появления. Uber держит фокус на основном пользовательском опыте, но технически может подключать лучшие решения для оркестрации, хранения данных, вычислений и т.д., не ломая общий продукт. Uber предпочитает открытые решения там, где это возможно, но использует и облачные модели, внимательно оценивая косты

5. Осознанное применение Deep Learning
Продвинутые методы вроде DL способны решать очень сложные задачи, но требуют огромных ресурсов и инфраструктуры, что должно быть оправдано бизнес-ценностью. Поэтому архитектура поддерживает разные типы моделей, а выбор делается прагматично. Для команд, планирующих внедрять DL, важно заранее обеспечить поддержку масштабируемого обучения (GPU/TPU, distributed training) и продумать мониторинг продуктивности моделей, так как обслуживание DL в продакшене сложнее и дороже обычных моделей.

6. Приоритизация ML-проектов
Не все модели равны - какие-то напрямую влияют на ключевые метрики бизнеса, другие играют вспомогательную роль. Вводите систему приоритетов (tiers) для ML-проектов, чтобы рационально распределять ресурсы и требования к надежности. Опыт Uber показывает эффективность четкого разделения
- Критичные (tier-1) модели получают максимальный уровень поддержки, мониторинга, строгие процессы деплоя
- Низкоприоритетные экспы (tier-4) могут обслуживаться по упрощенной схеме, предоставляя командам свободу творить, но без расходования чрезмерных ресурсов.

Итого, кажется, что Michelangelo показал путь эволюции платформы для успешного масштабирования AI в крупной компании. Секрет успеха - в постоянном улучшении опыта разработчиков, стандартизации процессов и гибкой архитектуре, готовой к новым технологическим веяниям.

#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign

Modern Architecture 101 for New Engineers & Forgetful Experts - NDC Copenhagen 2025 (Рубрика #Architecture)

Отличное выступление Jerry Nixon, product manager из команд SQL Server и Data API Builder, в котором он говорит, что архитектура - это не про "best practices", а про контекстные решения и смелость говорить "нет". Фактически, Никсон разрушает мифы и дальше показывает как строить архитектуру под любой масштаб с учетом вашего контекста. А начинает он с провокации, говоря, что термин "best practice" используют как оправдание отсутствия аргументов. Единственная настоящая best practice - не использовать SQL injection. Все остальное зависит от:
- Политики и бюджета компании
- Уровня команды (джуниоры vs эксперты)
- Наследия систем и ограничений от объединения разных систем
- Возможности "платить за ошибки" (Twitter может себе позволить глупости, а вы - нет)
Дальше он показывает "годовые кольца" технологий: spaghetti code 90-х, трехуровневые приложения 2000-х и микросервисы 2010-х, а дальше заключает, что все это работает до сих пор. В итоге, architecture shaming - это просто неуважение к контексту, в котором были приняты прошлые архитектурные решения.

По Никсону роль архитектора быть хранителем простоты. Ведь архитектор отвечает за самые дорогие решения, которые нельзя отложить. Это не тот, кто рисует схемы в начале проекта, а тот, кто постоянно решает, что оставить за бортом. Главная задача - не добавлять компоненты, а защищать систему от лишнего - это очень похоже на тезис Антуана де Сент-Экзюпери

Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать

После этого спикер начинает показывать как можно начинать проектировать решение с базы и постепенно наращивать сложность по мере появления доп требований
- Client → Database
- Client → API → Database (добавили интерфейс)
- Write API → Primary DB (синхронизация через логи) и Read API → Read replica. Логика в том, что вы масштабируете запись и чтение независимо за счет простого изменения connection string, а также за счет eventual consistency (и вам сразу становитсья важно понимать модели консистентности)
- Дальше появляется API Manager (APIM) / Gateway для управления API, версионирования, балансировки нагрузки, постепенной раскатки и a/b тестов
- Дальше появляется история про мониторинг (Никсон советует OpenTelemetry), кеши и service bus
- Ну и вообще асинхронность - это способ работы на масштабе: CQRS (Command Query Responsibility Segregation), Queue для работы со спайками нагрузки
- И так далее

В общем, выступление очень интересное. Основные мысли примерно такие
- Все компромиссы исходят из реальности, а не идеологии
- Архитектор - это тот, кого винят. Ваши решения будут судить через 5 лет, когда вы уже покинете компанию
- Сложность должна оправдываться. Каждый добавленный компонент (service bus, cache, gateway) - это еще одна система, за которую вы отвечаете.

Ну и напоследок тезис от автора, что меня сначала повеселил, а потом заставил задуматься

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

#Architecture #DistributedSystems #Management #Software #Leadership #Patterns #SystemDesign

Meta looks to power trading supports its AI energy needs (Рубрика #AI)

В ноябре 2025 года стало известно о нетривиальном шаге запрещенной в России компании Meta, которая получила разрешение американских регуляторов на торговлю электроэнергией на оптовом рынке. Такой шаг призван удовлетворить стремительно растущий спрос ее центров обработки данных (ЦОД) на электричество для решений искусственного интеллекта (AI). По сути, Meta создает собственное направление энерготрейдинга, чтобы напрямую закупать электроэнергию, заключать долгосрочные контракты с электростанциями и при необходимости перепродавать излишки мощности на рынке. Интересно, что в документе "Meta’s Hyperscale Infrastructure: Overview and Insights", что я разбирал раньше, было рассказано как раз о энергии, как о главном лимитирующем факторе для датацентров и инфры (условно, железо можно и обновить, а вот новые мощности по питанию обеспечить сложнее)

Тезисы тут примерно такие
- Сейчас мы наблюдаем взрывной рост потребности в энергии для AI, которые требуют огромных вычислительных ресурсов
- Существующая энергосистема с трудом справляется с такими темпами роста нагрузки, что уже вызвало в отдельных регионах США рекордный рост цен на мощность на оптовых аукционах
- Традиционных подходов к закупке энергии недостаточно - разработчики новых электростанций нуждаются в “якорных” покупателях, готовых брать на себя долгосрочные обязательства по закупке энергии. Например, Meta для своего нового ДЦ в Луизиане потребовалось вкладываться в строительство трех газовых станций, чтобы запитать ДЦ (они закоммитились только на это потратить 1.6 млрд $)
- А закупая электричество оптом можно не только снижать издержки за счет оптовых закупок, но и получать прибыль в периоды избытка продавая её обратно в сеть по пиковым ценам

В итоге, Meta создала дочернюю компанию Atem Energy LLC и получила разрешение на торговлю электроэнергией оптом от федеральной комиссии по регулированию энергетики США (FERC). Компания планирует изначально сотрудничать с опытными партнёрами-трейдерами и сконцентрироваться на работе на рынке США

Интересно, что Meta пошла по стопам других корпораций, получавших аналогичные лицензии. На оптовом рынке уже есть Google Energy, Apple Energy, Energy LLC, Amazon Energy. В общем, Meta не прокладывает абсолютно новый путь, но масштаб её усилий в энергетике - один из крупнейших на сегодня в Big Tech.

Если подумать, то для инфраструктуры ЦОДов это может значить следующее
- Снятие энергетических ограничений на рост ИИ - раньше именно энергия была лимитирующим фактором
- Увеличение капитальных затрат на дата-центры - теперь при планировании новых центров обработки данных компаний уровня Meta или Google необходимо учитывать и строительство параллельной энергоструктуры (это приведет к росту стоимости ЦОД проектов)
- Дизайн будущих дата-центров - появляется стимул размещать их ближе к источникам энергии: например, строить кампусы рядом с зонами богатых ВИЭ-ресурсов (ветер, солнце) или возле действующих крупных электростанций, чтобы минимизировать нагрузку на сети.
- Новые стандарты надежности и устойчивости - включение дата-центров в активное управление энергопотреблением (через торги, регулирование нагрузки) повышает устойчивость энергосистем, но и задаёт новые стандарты самим ЦОД. Например, Google уже заключает demand response-контракты с энергокомпаниями, согласившись переносить часть вычислений на непиковое время во избежание перегрузок сети

В сумме, инициатива Meta сигнализирует всему ИИ-сектору: эры дешёвого и гарантированного электричества больше нет, и дальнейший прогресс ML/AI тесно увязан с энергетической инфраструктурой. Те, кто сумеют интегрироваться с энергосистемой (через инвестиции или партнерства), получат фору в гонке ИИ, а те, кто проигнорируют - рискуют столкнуться с энергетическим дефицитом, замедляющим их инновации.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #AI #Economics

[2/2] Communication Patterns: A Guide for Developers and Architects (Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов) (Рубрика #Management)

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

3️⃣ Передача знаний (Communicating Knowledge) - как управлять знаниями в команде и организации.
- Глава 10. Принципы управления знаниями (Knowledge Management Principles). Разница между данными, информацией и знаниями. Почему wiki-системы превращаются в свалку и как этого избежать.
- Глава 11. Знания и люди (Knowledge and People). Как люди усваивают информацию и почему "шаринг знаний" часто не работает. Психология обучения взрослых применительно к инженерным командам.
- Глава 12. Эффективные практики (Effective Practices). Конкретные инструменты: от ведения ADR (Architectural Decision Records) до проведения воркшопов и сессий совместного моделирования.

4️⃣ Удаленная работа (Remote Communication) - специфика общения в распределенных командах.
- Глава 13. Фактор времени при удаленной работе (Remote Time). Паттерны для асинхронной коммуникации и работы в разных часовых поясах. Как сохранить контекст и темп работы, когда команда разбросана по миру.
- Глава 14. Принципы дистанционного общения (Remote Principles). Здесь речь про создание четких коммуникационных каналов, протоколов, а также про адаптацию стиля общения в зависимости от нужд команды. На эту тему есть хорошая книга "Remote Team Interactions Workbook" (о которой я уже рассказывал) от авторов книги "Team Topologoies".
- Глава 15. Методы дистанционного общения (Remote Channels). Здесь автор рассказывает про установление культуры открытой и честной обратной связи, а также использование технологий для улучшения коммуникации и поддержания связи между членами команды. Кстати, про открытую и честную обратную связь можно почитать в книге "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity", о которой я уже рассказывал.

#Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking

AI-инженерия. Построение приложений с использованием базовых моделей (AI Engineering) (Рубрика #AI)

Книгу "AI Engineering" уже перевели и скоро выпустят в издательстве Питер. А я эту книгу прочитал на английском еще в начале года и она мне супер зашла (мы ее вместе с Женей Сергеевым из Flo почти целиком разобрали за три серии подкаста: 1, 2 и 3). Собственно, книга отлична подходит инженерам, что строят GenAI‑продукт прямо сейчас, например, чат‑бот, copilot, RAG, ...

Книгу написала Chip Huyen, которая
- Преподавала Machine Learning Systems Design в Stanford (CS329S), а значит умеет объяснять системно и доступно
- Написала книгу "Designing Machine Learning Systems" (O’Reilly), которую многие считают must‑read для инженеров из ML/Platform команд
- Работала на стыке AI + инфраструктуры (NVIDIA, Snorkel AI), сейчас - Voltron Data (GPU‑ускорение аналитики)

Есть несколько факторов почему "AI Engineering" стала бестселлером
1. Попала в боль 2024–2025: команды массово интегрируют базовые модели, и нужен инженерный фреймворк, а не очередной набор промптов
2. Большой фокус был на evaluation: не “vibe check”, а измеримые метрики, регрессионные наборы, LLM‑as‑a‑judge, тестирование на деградации
3. Закрывает прод‑реальность: стоимость и латентность инференса, мониторинг, качество данных/фидбек‑лупы, безопасность и риск‑менеджмент
4. Даёт карту паттернов (prompting, RAG, fine‑tuning, tools/function calling, agents) и отвечает на главный вопрос: когда что выбирать
5. У книги есть публичные материалы/ресурсы (репо на 12.5к звездочек), поэтому вокруг неё быстро выросла “экосистема” практик

Вот чем может быть полезна эта книга инженерам, которые уже пилят GenAI
- Превращает "демку на фреймворке" в проект: требования → архитектура → eval harness → релиз → наблюдаемость
- Помогает говорить на одном языке с Product/Platform: какие SLO/SLI у LLM‑фичи, что логируем, где делаем гейтинг качества, как считаем cost‑per‑request
- Хороша для техлидов: много про компромиссы (качество vs цена, контекст vs retrieval, детерминизм vs креативность) и про то, где чаще всего “ломается” система

Мини‑чеклист из книги, который можно использовать хоть завтра:
- Golden кейсы + негативные кейсы (и регулярные регрессионные eval’ы)
- Версионирование промптов/моделей/ретривера + логирование контекста
- Метрика "стоимость ответа" + бюджет на фичу
- Eval гейты в CI перед деплоем (как unit/integration, только для LLM)

В общем, книга определенно заслуживает прочтения. Кстати: пока книга еще в предзаказе на нее действует скидка в 35% при использовании промокода "Предзаказ"

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

RepoSwarm - Giving AI Agents Architecture Context Across All Your Repos (Рубрика #Architecture)

Интересный доклад про восстановление архитектурного контекста при помощи AI агентов от Roy Osherove, Chief AI Architect в Verbit AI (компания с ~90 разработчиками, 12 командами и 400+ репозиториями). Интересно, что Roy написал три книги: The Art of Unit Testing, Elastic Leadership, Pipeline Driven (пока в разработке, но про его доклад с таким названием я уже рассказывал). У Роя есть и интересный блог robotpaper.ai, где он документирует AI-паттерны для разработчиков. Из интересного - его книги попали в обучающие датасеты LLM, поэтому промпт "review my tests in Roy Osherove style" работает из коробки в Cursor:)

Если же говорить про основные тезисы доклада изложены ниже

Документация в enterprise - проигрышная битва
В компаниях с 400+ репозиториями реальность такова
- 90% README-файлов устаревшие или неполные
- Архитектурные диаграммы существуют как кот Шредингера (пока не посмотришь не знаешь они еще живы или уже нет)
- Критические вопросы требуют недель ручного анализа: "что за инструменты мониторинга используются", "где хранятся определенные данные", "кто пользуется устаревшими API "

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

Автор доклада в качестве решения создал RepoSwarm, живой архитектурный репозиторий, который доступен в виде open source. Он работает примерно следующим образом
1. Ежедневно сканирует GitHub-репозитории (приватные/публичные) с коммитами за последние 12 месяцев (это настраивается)
2. Генерирует markdown-документацию (один repo.md на репозиторий) через Claude Code SDK
3. Сохраняет в централизованный Architecture Hub — Git-репозиторий с полной историей изменений
4. Никогда не устаревает: при новом прогоне файлы полностью перезатираются (нет никакой backward compatibility)

Ключевое отличие от статической документации в том, что документы сделаны AI-readable (markdown) и у нас есть git-история

Если говорить про то, что автор решил добавить в repo.md, то это такой список инфомрации
- Базовая информация - High-level overview, Dependencies (package.json/requirements.txt), Security checks (top 10 OWASP), Monitoring tools
- Данные и API - Database schemas, API versioning, Events/messaging (pub/sub), Data mapping (GDPR/HIPAA flows)
- Инфраструктура - CI/CD deployment, Authentication/Authorization, Feature flags, ML/LLM usage (Gemini/Claude endpoints)
- Специализированные - Prompt security (injection checks), Mobile UI patterns (для repo_type: mobile), IaC analysis (для Terraform/K8s)

В каких реальных кейсах этот инструмент использовался автором

1. Cross-repo анализ - ответы на вопрос вида "какие monitoring tools используются?"
2. Large-scale migrations - обновление Python, консолидация API gateways (переход на Kong), deprecation внутреннего сервиса (поиск всех зависимостей)
3. Архитектурная история - генерация ретроспективно ADR с ответом на вопросы вида "why we moved to serverless in Q2 2024"
4. AI-агентам как контекст - использование Architecture Hub в Cursor → автоконтекст для features/bugs

Что использование значит для разработки
1. Смещение роли архитектора - от ручной работы к построению и использованию таких инструментов
2. Новый workflow для compliance - проще выстроить соответствие внешним требованиям
3. Эволюция AI-агентов - улучшениие AI-assisted разработки за счет интеграции архитектурной информации в контекст агентов
4. Следование философии "живой документации" - генерация ее из кода и гарантированный freshness

#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software #SystemDesign

Developer Experience in the Age of AI Coding Agents (Рубрика #Agents)

Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)

Основные тезисы доклада такие

1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.

🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign