[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

Extreme DevOps Automation - доклад от Revolut на QCon 2025 (Рубрика #PlatformEngineering)

Интересный доклад c QCon 2025 от Sérgio Amorim про работу их DevOps команды. Суть в том, что у ребят из Revolut практичный подход к своей платформе разработки - они плотно сидят на Google Cloud, одновременно добавляя кастомные автоматизации сверху. При таком подходе у них получается, что 15 инженеров могут поддерживать масштаб порядка 1.3к инженеров, 1.2к микросервисов и 1.1к баз данных (что ребята из платформенной команды поддерживают сами). В итоге, получается чуть меньше 1 сервиса и 1 бд на одного инженера:)

Для управления всем этим используется три столпа
- Каталог сервисов в виде внутреннего решения Tower - это главный источник истины
- Паттерны и стандарты для унификации подходов
- Автоматизации GitOps при помощи внутренней системы Rhea

А теперь давайте подробнее глянем под капот
1. Tower (каталог сервисов IDP)
Здесь существует минимальный набор параметров для сервиса: стек (Java/Python/Scala/ML), владелец, связи с БД/сервисами, окружения, критичность (tier), SLO, стоимость, "качество метаданных" и пр. В итоге, это не "статичная CMDB", а портал, откуда начинается управление и в который возвращается обратная связь (качество, аптайм, стоимость). Меньше полей - выше заполненность и точность данных → тем надёжнее автоматика.
2. Паттерны как "сужение свободы" ради скорости и соответствия
Малое число поддерживаемых стеков и шаблонов развёртывания. Это повышает повторяемость, упрощает владение и даёт выигрыш в соответствие требованиям - стандартизация автоматически реализует корпоративные и регуляторные правила
3. Автоматизация как Control Plane
Rhea «транспилирует» данные из Tower в коммиты (реализуя подход GitOps):
- генерирует пайплайны TeamCity и права на деплой для нужных команд (~10к управляемых пайплайнов)
- создаёт политики доступа к секретам (Vault) ровно по зарегистрированным связям сервис↔база (~37к политик секретов)
- создаёт ресурсы в Kubernetes/облаке
- формирует шаблонные алерты/дашборды/правила (~20к стандартных алертов и ~3к кастом‑алертов)
Всё это - без ручных действий команд

Для сервисов важен и вопрос observability - все начинается со SLO, которые тоже настраиваются в Tower, дальше автоматика генерирует стандартизованные алерты по сервисам и БД, а внутренний диспетчер шлёт единообразные сообщения в Slack командам‑владельцам. Слишком "шумные" системы признаются техдолгом: при накоплении баг‑тикетов включается стопор изменений до улучшения стабильности (этакая реализация error budget). Кстати, у сервисов всего 4 типовых уровня доступности (99.99/99.9/99.8/99.5)

Отдельно автор доклада рассказал про управление базами данных, а точнее Postgres, для которых не используются managed решения от Google, а команда DevOps сама оперирует ими, чтобы катать спокойно мажорные обновления СУБД + играть с репликами как хочется.

Если проанализировать устройство платформы, то можно отметить, что это работает из-за ряда факторов
- Минимальная платформа поверх облака - можно использовать облачную инфру провайдера, а поверх делать только необходимое
- Governance вшит прямо в happy path платформы - важные правила (SLO, алерты, секреты, права) применяются автоматически, потому что единственный удобный путь запуска системы - через каталог и паттерны. Ничего "донастраивать руками" не нужно и часто нельзя.
- Каталог систем + GitOps. Tower фактически становится "API компании" для всего инженерного ландшафта. Один набор артефактов порождает пайплайны, политики, ресурсы и мониторинг. Это снижает расхождение реальности и деклараций.
- Стандарты на масштабе ускоряют, а не тормозят. Ограничение стеков + шаблоны деплоя убирают вариативность, ускоряя онбординг и снижая операционный риск.
- SLO/алерты как механизм управления продуктом. Унифицированный шумомер и error‑budget freeze принуждают команды держать стабильность, а не "продавливаться" релизами любой ценой.
- Фокус DevOps‑платформы - не "поддержка руками", а инжиниринг инструментов и продуктовая работа над DX.

#Software #Engineering #Management #Architecture #Processes

Про Revolut (Рубрика #Business)

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

1) Куда движется Revolut (планы 2025–2027)
Компания открыла глобальный штаб в лондонском Canary Wharf и заложила инвестпрограмму на ~$13 млрд на 5 лет; целевой ориентир - 100 млн клиентов к середине 2027 года (в сентябре 2025 было 65 млн клиентов). Вектор роста: международная экспансия, продуктовые инновации, усиление B2B‑направления и партнёрства:
- Латинская Америка. В 2025 Revolut получил окончательное разрешение начать банковские операции в Мексике; в Колумбии - авторизацию на учреждение банка (первый из двух регэтапов).
- Индия. Официальный запуск в 2025 с интеграцией UPI; публичная цель - 20 млн пользователей к 2030.
- Западная Европа. Открыт региональный хаб в Париже и объявлена программа инвестиций €1,1 млрд на 3 года; подача заявки на французскую банковскую лицензию.
- Великобритания. В 2024 получили статус authorised with restrictions (стадия mobilisation); формальный запуск UK‑банка планировался в 2025.

2) Оргструктура и как устроена разработка
- Корпоративное управление. Совет директоров из 8 человек: председатель, 2 исполнительных директора и 5 независимых НЕД; работа ведётся через 4 комитета (аудит, риск/комплаенс, вознаграждения, назначения).
- Инженерия через "скводы" и "владение продуктом". Revolut работает маленькими кросс‑функциональными командами (типично 6–8 человек). Product Owner управляют командами как "локальные СЕО", что даёт end‑to‑end ответственность (в компании ~150 таких product owners)
- Масштаб ИТ. 1.3k инженеров, 1. 2k микросервисов, 1. 1k БД; платформой DevOps управляет команда ~15 инженеров благодаря высокому уровню автоматизации (централизованный каталог систем, self‑service пайплайны).
- Инженерная культура. Явная ставка на "качество в руках разработчиков": нет выделенного QA, инженеры сами пишут тесты, мониторят и эксплуатируют свои сервисы.

3) Архитектура и инфраструктура
- Размещение в облаке. Бэкенды и веб‑фронты хостятся в сертифицированных дата‑центрах Google Cloud; развертывание - Kubernetes (GKE), также используется Compute Engine. В 2025 объявлено углубление многолетнего партнёрства с Google Cloud под рост до 100 млн пользователей.
- Бекенд стек. Компания официально называет: Java 21, PostgreSQL (через jOOQ), Redis, Docker/Kubernetes, Google Cloud; архитектурные подходы - DDD, CQRS, TDD.
- Веб‑стек (2021 год). React + TypeScript, Redux, Rush (монорепо), TeamCity (CI/CD), Sentry; автоматические деплои на GKE.
- Микросервисы и события (2020 год). Широкое применение event‑driven архитектуры и собственная шина событий EventStore/EventStream

4) AI/ML: роль и приоритеты
- Клиентские и операционные ассистенты. Revolut официально сообщало о 2 gen AI‑ассистентах, а в 2024 анонсировали новый consumer‑AI‑ассистент и линейку "умных" сервисов (включая пилоты по ипотеке/банкоматам).
- Финансовая безопасность и эффективность. В годовом отчёте за 2024 - $800+ млн потенциального мошенничества предотвращено (оценка).
- Инфраструктурный AI. Расширение партнёрства с Google Cloud и использование Gemini и ML‑сервисов для фрода, персонализации
- Внутренние планы 2025. Компания исследует AI‑агентов для автоматизации продаж и поддержки, а также строит собственных агентов

Если обобщить, то ситуация примерно такая
- Revolut целенаправленно масштабируется глобально (ЛатАм, Индия, Западная Европа) с опорой на лицензирование и локальную инфраструктуру.
- ИТ‑модель - автономные продуктовые команды + небольшие платформенные команды, высокая степень стандартизации и автоматизации разработки
- Техстек - cloud‑native поверх Google Cloud Platform, на беке Java/Postgres/Redis, Kubernetes; на фронте React/TypeScript; ключевые паттерны - микросервисы, событийность, DDD/CQRS.
- AI в приоритете: от ассистентов до фрода и персонализации, с заметным влиянием на метрики безопасности и поддержки.

#Software #Engineering #Management #Architecture #Processes

[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

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

Разработка софта в 2030 году: гипотезы о (не)светлом будущем (Рубрика #AI)

В воскресенье буду выступать на конференции для студентов и выпускников ИТМО с таким докладом. Анонс от меня звучит примерно так

С 2022 года с нами технология, которая стремительно изменяет мир вокруг нас. И если раньше мы на стороне IT высутпали как драйверы изменений, цифровизируя все вокруг, то теперь и само IT трансформируется с внедрением AI. В этом докладе я хотел обсудить, а что нас ждет в будущем и как будет выглядеть разработка через пять лет. Доклад будет продолжать мысли из моих выступлений
- Интегрируем AI в процессы разработки в большой компании летом на на CTO Conf
- AI в SDLC: путь от ассистентов к агентам осенью на AI Boost Conf

После возвращения из Питера планирую как обычно записать расширенную версию этого выступления для своего канала и опубликовать его здесь:)

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[1/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)

Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes The Hard Way, который был не прост, но помог мне сдать лабы для получения шилдика CKA (Certified Kubernetes Administrator) первым в компании. Это было в те времена, когда мы с моим коллегой Стасом (гостем из первого выпуска подкаста Code of Leadership), Андреем (гостем 43 выпуска Code ...) и Антоном (гостем 17 выпуска Code ..) продумывали как будем переезжать в Kubernetes с виртуалок:)

Но если возвращаться к Келси, то он уже завершил активную карьеру в Google и теперь может философски размышлять про devops и не только. Я выделил 5 тем, что были интересны мне в этом обсуждении

1️⃣ DevOps: Эволюция или провал?
Келси критически оценивает то, во что превратился DevOps во многих компаниях.
- "Футболка вместо навыков": Многие компании просто переименовали системных администраторов в DevOps-инженеров, не изменив суть работы. "О, теперь я DevOps-инженер, дадут ли мне за это футболку?" — иронизирует Келси.
- Правильная имплементация: DevOps был задуман как "чертеж" (blueprint), предполагающий расширение компетенций. Сисадмины должны были научиться программировать, а разработчики - понимать, как работает операционная система (например, тюнить JVM под ядро Linux).
- Проблема опыта: Келси упоминает людей, у которых "20 лет опыта, состоящих из одного и того же года, повторенного 20 раз" (20 years of one-year experience). Это те, кто просто чинит серверы, не пытаясь автоматизировать или изменить подход.
- Platform Engineering: Это не что-то принципиально новое, а эволюция DevOps. Это переход от "я починю сервер, когда он сломается" к созданию продукта (платформы) для внутренних клиентов.

2️⃣ Kubernetes и «скучные» технологии
- Kubernetes - это скучно (и это хорошо): Для stateless (веб) приложений Kubernetes стал скучным еще 6-7 лет назад. Келси сравнивает инфраструктуру с полетом на самолете: "Самолеты интересны только тогда, когда они делают не то, что мы ожидаем. Если при посадке люди хлопают - значит, что-то пошло не так. Мы хотим просто выйти из самолета и не думать о полете".
- Инфраструктура не должна вызывать восторг: Если ваша инфраструктура вызывает у вас сильные эмоции, значит, вы боретесь с поломками или трением. Восторг должен вызывать продукт, который вы строите поверх неё.
- Будущее Kubernetes: Если через 20–30 лет мы всё еще будем обсуждать Kubernetes, это будет провалом индустрии. Мы должны придумать что-то лучшее. Kubernetes должен стать просто деталью реализации (как BIOS или машинный код), скрытой под более удобными абстракциями.

3️⃣ API, Silos (Колодцы) и взаимодействие команд
Келси делает контринтуитивное заявление: "Мне нравятся silos (изолированные команды)", но при наличии четкого API.
- Аналогия с авиабилетом: Когда вы летите в другую страну, вы не идете в кабину пилота обсуждать маршрут. Вы покупаете билет. Билет - это API (контракт). Вы садитесь в кресло, засыпаете и просыпаетесь в другом месте.
- API как контракт: Платформенная команда и разработчики не должны сидеть рядом и постоянно разговаривать. Они должны взаимодействовать через четкий контракт (API): "Мне нужно столько-то памяти, такой-то регион, такая-то версия".
- Когда нужно общение: Разговаривать нужно только тогда, когда вы хотите изменить API или добавить новую фичу в платформу. Для рутинного деплоя общение - это лишние накладные расходы.
Забавно, что примерно эти же моменты про взаимодествие команд мы разбирали со Стасом Халупом в первом выпуске Code of Leadership.

Оставшиеся темы про AI и важность soft skills обсудим в продолжении разбора этого крутого интервью.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

[2/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)

В продолжении разбора интервью Келси нужно упомянуть темы AI и важности soft skills

4️⃣ Искусственный интеллект (AI)
Хайтауэр скептичен к хайпу, но видит фундаментальную пользу.
- AI как новый DSL: Келси смеется над "Prompt Engineering", когда люди чекинят в git 500 markdown-файлов с промптами и версионируют их. По сути, мы изобрели еще один, очень нестабильный язык программирования.
- Недетерминированность: Всю карьеру инженеры боролись за предсказуемость (тесты, идемпотентность), а теперь мы внедряем AI, который по своей природе вероятностный ("Зачем гадать, если можно знать наверняка?").
- Главная польза AI: Он заставил вендоров и разработчиков наконец-то написать нормальные API и документацию, чтобы LLM могли с ними работать. То, что мы должны были сделать для людей (хорошие доки и интерфейсы), мы теперь делаем для роботов.
- Guardrails (Ограничения): В итоге все равно все сводится к созданию жестких рамок (guardrails), чтобы заставить AI выдавать предсказуемый, "скучный" результат.

5️⃣Развитие: Человек vs Инженер
В конце интервью фокус смещается на soft skills и личностный рост.
- Командный спорт: Келси сравнивает работу в IT с баскетболом или футболом, а не с легкой атлетикой. В беге ты побеждаешь или проигрываешь один. В IT, каким бы крутым инженером ты ни был, ты зависишь от команды.
- Эмпатия: Это не просто "быть милым". Это понимание того, что если разработчик боится деплоить в пятницу, проблема может быть не в его трусости, а в ненадежности платформы, которую вы построили.
- Профессионализм и «Ящик с инструментами»: Не будьте просто «коллекционером» инструментов. Профессионал регулярно перебирает свой ящик с инструментами (toolbox), чистит их и выбрасывает ненужные.
- Дисциплина важнее любопытства: В профессиональной среде нельзя тащить в продакшн Rust или новую технологию только потому, что вам "любопытно". Выбирайте инструменты, которые решают задачу бизнеса, а не тешают эго инженера.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

Atlassian покупает платформу DX (developer experience) за $1 млрд - причины и последствия (Рубрика #DevEx)

18 сентября 2025 года компания Atlassian официально объявила о приобретении платформы DX (Developer Experience) приблизительно за $1 млрд с оплатой наличными средствами и акциями Atlassian (крупнейшее поглощение в истории Atlassian). DX представляет собой платформу инженерной аналитики, которая позволяет организациям оценивать продуктивность команд разработки и выявлять "узкие места" в их процессах. Мне это поглощение интересно тем, что среди создателей DX есть авторы подходов DORA, SPACE, DevEx, про которые я много рассказывал.

Руководство Atlassian объясняет покупку DX стратегическим стремлением помочь своим клиентам эффективнее использовать инвестиции в ИИ и улучшить работу инженерных команд. Компания отмечает, что всё больше предприятий вкладываются в инструменты искусственного интеллекта, но сталкиваются с вопросом, приносят ли эти вложения реальную отдачу в ускорении разработки (DX недавно опубликовали методологию "Measuring AI code assistants and agents")

Дополнительным обоснованием сделки стал синергетический эффект: около 90% клиентов DX уже используют продукты Atlassian (Jira, Confluence, Bitbucket и др.), что сделало DX очевидным кандидатом для присоединения. Кэннон-Брукс, соучредитель и CEO Atlassian, отмечал, что Atlassian несколько лет пыталась создать собственный инструмент для анализа продуктивности инженеров, однако в итоге решила приобрести готовое решение (сам стартап DX был основан 5 лет назад)

Atlassian планирует глубоко интегрировать DX в свою экосистему. В октябре 2025 года CTO Atlassian представил новый комплект Atlassian Software Collection, куда DX вошла в качестве новейшего компонента: платформа DX дополняет существующие решения, объединяя качественные опросы разработчиков с количественными метриками такими, как время прохождения pull request, частота сбоев сборки и уровень использования AI-инструментов. Данные DX будут напрямую доступны в продуктах Atlassian, а также DX продолжит поддерживать интеграции и с сторонними инструментами, чтобы клиенты могли извлекать пользу из DX независимо от стека Atlassian.

В будущем пользователям Atlassian станут доступны следующие возможности благодаря интеграции DX
- Измерение продуктивности и узких мест: система автоматически собирает ключевые показатели развития софта (скорость цикла код-ревью, частоту неудачных билдов, время внедрения фич) и выявляет узкие места в процессе
- Аналитика использования ИИ: DX позволяет отслеживать, как активно и с каким эффектом разработчики применяют AI-инструменты (код-ассистентов, агентов и пр.), отсекая шум и показывая реальную отдачу от AI-внедрений.
- Оценка опыта разработчиков: Помимо технических метрик, DX регулярно собирает качественные данные об опыте инженеров (опросы удовлетворённости, индексы Developer Experience). Совмещая цифры с мнением самих разработчиков, платформа определяет, что мешает людям работать продуктивно, и где возникают точки напряжения в взаимодействии команд

В целом, покупка DX сигнализирует о появлении в линейке Atlassian нового класса функций - “инженерной аналитики” - благодаря которому разработчики и менеджеры смогут совместно измерять и улучшать продуктивность, основываясь на данных, а не интуиции. Atlassian позиционирует этот шаг как часть более широкой стратегии по созданию интегрированной платформы для управления разработкой в эпоху ИИ, где связаны воедино планирование (Jira/Confluence), выполнение (код и CI/CD) и анализ эффективности (DX) для непрерывного совершенствования процесса создания софта

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

T-Sync Conf (Рубрика #Software)

Приходите 7 февраля 2026 года на нашу большую конференцию T-Sync, точка синхронизации технологий и тех, кто их использует. Здесь будет много про практику, взаимодействие и живые системы. На этой конфе у нас будет стенд, где мы покажем результаты нашего исследования влияния AI на инженерную культуру. А вообще на конфе будет 8 технологических контуров из всех инженерных сфер: AI, Data, R&D, Security, UX/UI, Productivity, Observability, Platfrom. А вообще, эта конференция будет отличаться по формату от большинства конференций - здесь не будет скучных докладов (и не только скучных), но можно будет пообщаться и позадавать вопросы инженерам, которые реально делают те системы, которые работают у нас в проде, исследователям, что двигают нас вперед, а также техническим руководителям, которые не мешают работать остальным (а по мере своих сил стараются помогать).

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity #Conference

[3/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)

Если финализировать разбор этого отчета Гергели (начало в 1 и 2), то видны следующие ключевые тренды

1️⃣ Инструменты с искусственным интеллектом из разряда эксперимента перешли в категорию повседневных - подавляющее большинство разработчиков теперь пользуется AI-помощниками. Это означает, что продуктивность инженеров всё больше будет зависеть от интеграции AI в их рабочие процессы, а компании должны учитывать данную тенденцию при выборе инструментов.
2️⃣ Технологический стек продолжает унифицироваться вокруг лучших решений: TypeScript и React стали фактическим стандартом веб-разработки, Kubernetes – стандартом развёртывания, GitHub - стандартом хостинга кода и т. д. Популярные языки и фреймворки достигли такой зрелости, что разработчики в целом ими довольны и не испытывают острой необходимости срочно искать им замену
3️⃣ Позиции крупных экосистемных игроков остаются сильны. Так, Microsoft контролирует заметную часть инструментов разработчика (4 из 15 самых распространённых, включая VS Code, GitHub и Azure DevOps), Amazon - облачную инфраструктуру, Atlassian - управление проектами и т.д. Для индустрии это означает стабильность базового инструментария и продолжение инвестиций со стороны гигантов рынка.

Одновременно опрос показал и точки напряжения, которые можно рассматривать как ниши для инноваций.
Разработчики явно фрустрированы от "тяжеловесных" корпоративных решений – яркий пример тому JIRA, которую вынужденно используют повсеместно, но называют худшим инструментом. Запрос на более продуктивные, быстрые и удобные инструменты налицо, что подтверждается успехом конкурента Linear и других облегённых аналогов. Когда две системы (JIRA и Linear) охватывают порядка 75% всех командных процессов планирования, рынок фактически монополизирован парой игроков - и в то же время открывается возможность для новых продуктов, способных потеснить устоявшиеся, но нелюбимые решения.

Похожая ситуация складывается и в других категориях: например, появление специализированных стартапов в области oncall, фичефлагов, observability говорит о том, что существующие крупные продукты удовлетворяют не всех. Многие компании продолжают строить критически важные инструменты "in-house", и это сигнал вендорам о незакрытых потребностях. С другой стороны, столь богатый и разнообразный ландшафт инструментов - благо для инженеров, но и вызов для технологических лидеров.

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

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

[2/2] Atlassian "State of Developer Experience 2025" (Рубрика #DevEx)

Продолжим разбор отчета Atlassian выводами и рекомендациями его авторов

1️⃣ ИИ – мощный инструмент, но не "серебряная пуля"
По мнению авторов, автоматизация с помощью AI способна заметно улучшить опыт разработчиков лишь при условии, что она нацелена на реальные проблемные места процесса разработки. Если же организации концентрируются только на ускорении приятных частей работы (например, написания кода), не устраняя корневые причины трения – возникает ложное ощущение эффективности. В результате время, выигранное за счёт ИИ, тут же теряется из-за других задержек, а требования по скорости растут несправедливо относительно возможностей команды.

2️⃣ Системный подход к Developer Experience
Лучшие компании начали пересматривать подход к опыту разработчиков комплексно – выстраивая процессы вокруг прозрачности, автономности команд и высокой скорости выпуска продукта. Улучшение DevEx требует постоянной работы: авторы призывают организации целенаправленно выявлять узкие места и устранять фрикции на всех этапах жизненного цикла разработки, от планирования до деплоя. Благо, что теперь у пользователей Atlassian будет доступ к купленной платформе DX, которая позволяет системно работать над DevEx.

3️⃣ Диалог между лидерами и разработчиками
Первый шаг к улучшению – спросить самих разработчиков о том, что мешает их продуктивности. Руководителям команд рекомендуют плотно общаться с инженерами и вместе тестировать решения проблем. В одних случаях частичное решение дадут AI-инструменты, в других – даже простые меры вроде самообслуживаемых справочных материалов или шаблонов, упрощающих рутину.

4️⃣ Совместная ответственность за изменения
Авторы отчёта отмечают, что и менеджеры, и сами инженеры должны активно участвовать в улучшении процессов. Разработчикам стоит доносить до руководства свои проблемы на языке влияния на результат – показывая, как конкретные препятствия задерживают релизы или снижают качество. Такое представление превращает "жалобу" в осязаемую задачу, требующую решения. В ответ лидерам важно не отвергать сигналы, а вместе с командами искать пути улучшения. Регулярная двусторонняя связь помогает выявлять проблемы заранее, укрепляет доверие и держит всех в фокусе на приоритетных целях.

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

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops