Полгода внутренней платформы: 40 команд онбордировано, время до прода сократилось с 4 дней до 6 часов

Шесть месяцев назад мы запустили внутренний developer portal в полноценном операционном режиме - не пилот, не «для избранных команд», а для всех. К концу июня в платформе работают 40 продуктовых команд, цикл от коммита до прода сократился примерно с четырёх дней до шести часов. Это хорошая новость.

Плохая новость: первые три месяца мы потратили на то, чтобы признать, что governance-модель, которую спроектировали на старте, не работает. И переделали её почти с нуля.

Что было на старте

В апреле мы описывали первые результаты - Backstage с плагинами под Gitflic и Harbor, Software Templates, сокращение онбординга нового сервиса с трёх дней до двух часов. Всё это правда. Только речь тогда шла о 8-10 командах, которые онбордились в контролируемом режиме.

Когда число команд перевалило за 15 и мы открыли регистрацию для всех - посыпалось.

Первая проблема была ожидаемой: Templates не покрывали реальное разнообразие. У нас было три шаблона (Spring, FastAPI, фронтенд), а команды приходили с Go-сервисами, с легаси на PHP, с кастомными воркерами. Кто-то начинал адаптировать ближайший Template под свои нужды - и создавал сервис, который формально существовал в portal, но реально выходил за рамки любых автоматических политик.

Вторая проблема была менее очевидной и болезненнее: мы не разграничили, кто владеет платформой как продуктом.

Провал governance-модели версии 1.0

Начальная модель выглядела разумно: есть платформенная команда (мы), есть команды-потребители. Платформенная команда пишет Templates и поддерживает portal, команды-потребители используют. Классика.

Проблема в том, что мы не договорились о нескольких вещах.

Первое - кто принимает запросы на новые Templates. Когда пришли первые пять команд с запросами «нам нужен шаблон для X» - мы взяли их в бэклог. Когда пришли ещё двадцать - бэклог превратился в очередь на полтора месяца вперёд. Команды начали делать Templates сами, без ревью, без стандартов. В portal появились шаблоны, которые создавали Kubernetes-namespace без NetworkPolicy. Один шаблон генерировал Harbor robot account с правами на весь реестр, а не на один проект.

Второе - кто отвечает за деградацию. Когда у команды не получалось что-то сделать через portal - она шла к нам. Мы разбирались, находили баг или неочевидное поведение, чинили. Но при 40 командах этот поток стал съедать треть времени платформенной команды. Без SLA, без тикетной системы, просто «в личку написали».

Третье - как обновлять платформу без поломки того, что уже работает. Мы обновили Backstage с 1.26 до 1.28 в феврале. Три плагина перестали работать, потому что сменился API. Семь команд обнаружили это в момент, когда им нужно было создать новый сервис.

Governance-модель версии 2.0

Переделка заняла март и апрель. Вот что изменилось.

Platform-as-a-product со своим бэклогом и SLA. Теперь это официально продукт внутри компании, у него есть product owner из платформенной команды, публичный бэклог и два типа запросов: «баг» (SLA 2 рабочих дня) и «новый Template» (SLA 2 спринта). Это не ускорило обработку запросов - зато убрало ожидание неизвестности и обиды «вы нас игнорируете».

Контрибьюторская модель для Templates. Команды могут писать свои Templates, но через PR в платформенный репозиторий с обязательным ревью от платформенной команды. Чеклист ревью формализован: NetworkPolicy, ресурсные лимиты, robot account с минимальными правами, catalog-info.yaml. Templates без прохождения чеклиста в portal не попадают. Да, это медленнее, чем «залить самому». Зато мы знаем, что в portal нет шаблонов, которые создают дыры в безопасности.

Changelog с уведомлениями об обновлениях. Перед любым обновлением Backstage или плагинов - тестирование на staging-инстансе portal, список потенциально затронутых команд, уведомление в Mattermost за неделю. Это очевидно, но нам понадобилось один раз поломать прод, чтобы сделать это правилом.

Откуда взялись 6 часов

Цикл commit-to-prod стал 6 часов не потому, что portal волшебным образом ускорил деплой. Он ускорился по другой причине: платформа убрала ручные ожидания из пути.

Раньше выглядело так: разработчик создаёт PR - ждёт, пока кто-то вручную настроит pipeline в CI-системе - pipeline отрабатывает - ждёт, пока DevOps-инженер проверит манифесты - деплой идёт в прод. Ожидания на ручных шагах суммировались в 2-3 дня при любой загрузке команды.

Сейчас: PR создан - platform-pipeline запускается автоматически через Templates-сгенерированную конфигурацию - GitOps-контроллер видит изменение и деплоит - прод. GitOps-подход, который мы описывали раньше, здесь является несущей конструкцией: без автоматической синхронизации состояния fleet-репозитория скорость бы не появилась.

Шесть часов - это в среднем, включая время прохождения CI (тесты, сборка образа, сканирование). Для критических фиксов с fast-track путём - 1.5-2 часа.

Где до сих пор больно

Нет смысла делать вид, что всё хорошо.

• Observability платформы - мы знаем, что portal живой, но не знаем детально, какие Templates используются чаще, где пользователи застревают, сколько попыток создания заканчивается ошибкой. Backstage не даёт это из коробки, плагин аналитики мы ещё не написали.
• Стоимость владения - поддержка portal сейчас занимает примерно 40% времени одного инженера. Это приемлемо при 40 командах, но нелинейно вырастет при 80.
• Синхронизация с реальностью - если команда сделала что-то вне portal (а такое бывает), reconciliation между реальным состоянием и тем, что видит Catalog, до сих пор частично ручной процесс.

Platform Engineering как функция не заканчивается запуском portal. Она, скорее, только начинается, когда portal запущен и к нему пришли реальные пользователи. Первые полгода - это в основном обнаружение того, что не учли при проектировании.