IDP: правильный путь — самый лёгкий

Михаил просит переформулировать вопрос: не «зачем такая платформа нужна», а с чего она вообще появилась. Инфраструктура, особенно облачная, усложнялась, и большие компании принялись пилить собственные маленькие платформы задолго до того, как появился термин IDP: у Google это был Borg — ещё до Docker. Потом Borg переписали в Omega, а когда появился Docker и его понадобилось оркестрировать, принципы ранней платформы перенесли на контейнеры — так вырос Kubernetes. Александр комментирует: похоже, сработал синдром второй системы — Omega не полетела, зато про неё вышел white paper, следом про Borg, а потом уже про Kubernetes. В открытый Kubernetes сознательно не занесли часть внутренних возможностей Borg: с ними решение вышло бы слишком сложным и другие компании не смогли бы им пользоваться. Оба сходятся, что до появления публичного термина такие платформы оставались уделом бигтеха, где без слоя абстракции нормально доставлять фичи просто не получалось.

Массовой темой платформы сделали микросервисы: сначала бэкенд, недавно и фронтенд. Александр вспоминает Сэма Ньюмана с «Building Microservices» и «Monolith to Microservices», где тот уже уточнял, что дробить нужно не всё, — но джинн был выпущен. Сложность ушла из модулей внутри приложения на уровень operations: сеть, задержки, обработка ошибок, консистентность, shared nothing, — и оттуда же выросла observability. Михаил добавляет: продукт вроде один, а под капотом сто, двести, триста сервисов, каждый со своей гибкостью, и на масштабе это выстреливает неконсистентным опытом, который платформа собирает обратно. Отдельно участники отмечают декларативное описание приложения и control loops в Kubernetes — руками такое состояние не удержать. Название одной из первых открытых систем этого класса Михаил сходу не вспоминает, и Александр подсказывает: Backstage от Spotify, каталог сервисов и портал для разработчиков. Ещё одна опора — книга Accelerate: ложная дихотомия «быстро или надёжно» исчезла, но инженерным практикам нужен инструментарий, и он оказался внутри платформ.

В базе платформа, по Михаилу, — это one button click: одним кликом разворачивается сервис со всей инфраструктурой, а вместе с ним накладываются стандартные паттерны. Дальше инструмент растёт, и компании, которые строят IDP только под проблемы разработки, без бизнеса, по его мнению, проигрывают: для бизнеса «инженерная культура» звучит как куча денег непонятно куда, а платформа переводит вложения в человеко-часы и метрики. Александр рассказывает свою историю: полноценная платформа началась в начале 2020 года, когда Игорь Маслов пришёл руководить управлением базовых сервисов и собрал разрозненные куски и людей в одну концепцию — хранение и доставка кода, целевой рантайм, базы, очереди, надёжность; недавно у команды был пятилетний юбилей. Пока платформы нет, каждая продуктовая команда платит налог на собственную мини-платформу: свой GitLab или Bitbucket, свой мониторинг, свои базы и очереди — и это 20–25% инженерного времени, вложенных в кучу так себе решений.

Объединение даёт эффект масштаба: вместо россыпи команд со своими базами — три хорошо сделанных варианта, которые выдаются по кнопке, а не по заявке. Сначала просадка, потом резкий буст, потому что улучшение фреймворка сразу влияет на все команды. Михаил добавляет: если настроить продуктовый цикл, платформа начинает насаждать культуру — правильные вещи делать легко, неправильные тяжело; у них к этому шли полтора-два года, и это немалая инвестиция. Дальше говорят про измерение: DORA — частота и скорость выкладки, доля поломок, скорость откатов, — а с выхода Accelerate, прикидывает Александр, прошло лет восемь и появились DevEx и SPACE. Буквы SPACE разбирают с примерами: активность вроде коммитов и merge request бессмысленна на индивидуальном уровне, но «ускорили тесты с 20 до 18 минут» в масштабе компании превращается в сэкономленные часы; в коммуникации — код-ревью и онбординг, который у Google резко просел в ковид; в efficiency and flow — переключения контекста, шумные логи и менеджерские встречи каждые два часа.

Дашборды не спускаются до отдельного инженера, но позволяют сравнивать команды: мобильные разработчики вышли вперёд по ощущению, что делают важные вещи, — вероятно, потому что сидят на последней миле и видят результат. Бизнес, считают собеседники, покупает борды зрелости: разом видно, что каждая команда подключила и как соблюдает договорённости, а метрики стоит брать по своей боли — под мобильную версию написали скрипт, проверяющий, у каких команд интерфейс адаптирован. Из базового Михаил называет поиск ответственных: платформа как минимум показывает сервисы без владельца, а услуги заведены так, что видно дежурную команду, гарантии и кривую эскалации. Трассировки доводят до инфраструктуры, но их adoption ниже, чем у логов и метрик, — кто-то до сих пор ищет концы по correlation ID в логах, где причинно-следственная связь не видна. У Александра рядом сервис с SLA по уровням критичности и отчётами: в антилидерборде быть никто не хочет, и задачи приоритизируются сами.

Платформенная команда проваливается, когда замыкается на инструменте: Александр вспоминает команду, которая объявила себя гуру Kubernetes на голом железе и ждала, что к ней придут; её забрали под общее руководство, подход переделали и мигрировали на целевой рантайм. Рецепт Михаила прост: продуктовые подходы — регулярные синки с демо и сбор обратной связи; клиент здесь разработчик, а платформа не босс. Александр добавляет: платформе мало развивать продукт, она должна евангелить свои возможности — не только показывать фичи, но и вести воркшопы, как собрать из её кубиков типовое решение. У них платформенная команда числится продуктовой и защищает фичи наравне с остальными, а продакты выросли из тимлидов и техлидов: технических продактов на рынке почти нет. Глубже DORA участники предлагают идти через джобы разработчика и сравнение реального пути с golden path: код-ревью, где вместо «открыл, посмотрел, написал комментарии» уходит два часа на развернуть, почитать документацию и найти эксперта. Из свежего — ассистенты: по скриншотам генерируются тест-кейсы, время на ручные тесты сократилось в разы. Финальный совет: чем позже начнёшь, тем дороже выйдет платформа.