Платформенная инженерия: карта трека и зачем нужна внутренняя платформа

Компания на семьдесят инженеров, двенадцать продуктовых команд. Полтора года назад собрали платформенную команду из пяти человек с понятной задачей: «сделать так, чтобы команды не занимались инфраструктурой». Появились кластер Kubernetes, общий конвейер сборки и выката, портал на Backstage с каталогом сервисов и единый service.yaml. Работы было много, работа сделана честно.

Через год кто-то догадался посчитать. Из двенадцати команд через платформу выкатываются четыре, три пользуются общим конвейером, но манифесты держат свои — «в шаблон не влезаем», пять деплоятся мимо целиком. В каталоге 96 записей, из них 31 указывает на несуществующие репозитории. У платформенной команды очередь из сорока тикетов, две трети — «выдайте доступ» и «поднимите окружение». Дальше идёт разговор, который происходит в каждой второй компании. Платформенная команда: «команды не хотят мигрировать, нужен мандат сверху». Продуктовые: «через платформу дольше, наши случаи в неё не помещаются, ответа ждём два дня». Обе стороны говорят правду и описывают одно явление: продукт, который пользователи не выбирают. Пять инженеров полтора года не писали продукт — 7,5 инженеро-лет; вопрос «окупились ли они» никто не задавал, потому что платформу считали инфраструктурой, а инфраструктуру не принято мерить принятием.

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

Что такое внутренняя платформа и чем она не является

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

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

Каждая часть определения что-то отсекает. «Без обращения к людям»: если тестовое окружение требует тикета, это команда поддержки, а не платформа, и скорость всех команд ограничена пропускной способностью одной (самообслуживание). «Всё необходимое»: не «выкатить», а полный цикл — создать сервис, получить базу, окружение, секреты, домен, дашборд, алерты, откатиться, увидеть счёт; половина пути хуже отсутствия пути, потому что команда всё равно строит свой процесс, но теперь на два стека. «Под добровольное использование»: мандат даёт 100 % принятия по определению, но убивает обратную связь — недовольство уходит в теневые обходы. «Измеряется использованием»: платформа с сорока возможностями и тремя пользователями хуже платформы с пятью и двенадцатью командами.

Техническая база платформы разбирается в треке devops: конвейеры, контейнеры, Kubernetes, GitOps, инфраструктура как код. Этот трек их не пересказывает, а отвечает на другой вопрос: как из этих кирпичей собрать продукт, которым пользуются добровольно.

Пользователь не видит ни кластера, ни модулей Terraform; он видит полосу «интерфейсы» и по ней судит о платформе целиком. Отсюда следствие: качество платформы определяется качеством самого узкого интерфейса, а не мощностью самого сложного сервиса под ним.

Пользователи: кто они и что делают, когда платформа не помогает

Разговор становится продуктовым, когда у платформы появляются персоны с разными задачами. Их как минимум пять, и путать их дорого.

Первая ошибка — считать пользователем только «разработчика», вторая — считать разработчиков одинаковыми. Что происходит без самообслуживания, видно на запросе «нужна база для сервиса».

Ключевая цифра здесь не «4,5 дня», а отношение: работы на сорок минут, ожидания на четыре дня. Оно и есть предмет платформенной инженерии. Самообслуживание не ускоряет операцию — оно убирает ожидание и переключения контекста и снимает с платформы роль живого API (задержки в системах).

Арифметика: платформенная команда не пишет продукт

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

экономия = Σ по операциям: частота_на_команду × (время_до − время_после) × число_команд
цена     = K × 1800               # штат платформы, K человек
         + N × налог_на_принятие  # обучение, миграции, разбор чужих ошибок
         + стоимость_инфраструктуры
окупаемость = экономия / цена     # меньше 1 — вы платите налог

Про второе слагаемое забывают почти всегда. Каждая миграция стоит времени продуктовым командам, каждый новый обязательный шаг — минуты на каждом выкате, каждая непонятная ошибка платформы — час чужого расследования. Это реальные часы, и они принадлежат тем, кого вы ускоряете. Считать надо по операциям, а не «в процентах продуктивности» — честная таблица для двенадцати команд (около 65 инженеров) после года работы платформы:

При 210 рабочих днях в году это 1,8 инженеро-года. Вывод неприятный и полезный: очевидные операции оправдывают примерно двух человек, а не пятерых. Остальные три обязаны окупаться эффектами второго порядка, и их придётся доказывать данными: инцидентами, которых не было (по постмортемам — сколько отказов имели причиной нестандартную конфигурацию); онбордингом (до первого выката 12 дней против 2, при найме двадцати человек в год это 200 инженеро-дней); счётом за облако (стоимость); скоростью поставки — самой заманчивой и самой скользкой величиной, потому что одновременно с платформой менялись состав команд, размер задач и приоритеты.

Одна платформенная ставка требует примерно 25 продуктовых инженеров при экономии 2 часа в неделю на человека — и примерно 50, если экономия составляет час.

Отсюда ответ на вопрос «когда платформы не нужно»: при пятнадцати-двадцати инженерах выделенная платформенная команда — чистый расход, работает другое — один человек на 20 % времени, хорошие шаблоны и управляемые сервисы облака вместо своего кластера (глава 15).

Метрики принятия: почему полнота функций — ложная цель

Продуктовая команда меряет успех использованием. Платформенная слишком часто меряет его выпуском: «сделали каталог», «добавили gRPC», «закрыли 40 тикетов». Это метрики активности. Рабочий набор выглядит иначе:

доля выкатов через платформу   = выкаты_через_платформу / все_выкаты_в_прод
доля сервисов на золотом пути  = сервисов_из_шаблона / всех_живых_сервисов
самообслуживание               = задач_без_тикета / всех_задач_к_платформе
время до первого выката (TTFD) = медиана от «создан репозиторий» до «первый прод»
доля обходов                   = сервисов_со_своим_путём / всех_живых_сервисов

Четыре замечания, без которых эти числа врут.

Знаменатель важнее числителя. «40 сервисов на платформе» ничего не значит без общего числа живых сервисов. Живой — тот, у которого был выкат за 90 дней; иначе каталог наполняется покойниками и доля растёт сама собой. Считайте по критичности, а не по штукам: двадцать вспомогательных сервисов на платформе и три ключевых мимо неё — это не 87 % принятия, это провал в самом важном сегменте.

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

Осторожнее с мандатом. Приказ «всем перейти» делает принятие равным 100 % и лишает его смысла: оно перестаёт быть сигналом. Поэтому принятие разбирается отдельно — глава 14, измерение опыта разработчика — глава 03. И полезно смотреть на команду как на объект с состоянием, а не как на строку в таблице:

Две стрелки здесь — приговор платформе: «Проба → Обход» (первый опыт хуже ручного способа) и «Золотой → Обход» (доверие сломано несогласованным изменением). Вернуть такую команду в разы дороже, чем привлечь её в первый раз.

Золотой путь: помощь, которая не должна стать забором

Золотой путь — поддерживаемый, задокументированный и самый лёгкий способ сделать типичную вещь: создать сервис, выкатить, получить окружение, подключить базу. «Самый лёгкий, но не единственный» — не оговорка, а конструкция.

Путь работает, пока по нему выгоднее идти, чем в обход. Как только выгоднее в обход, у платформы два варианта: чинить путь или ставить забор — административный запрет вроде закрытых доступов в облако или обязательного ревью на каждый манифест. Забор даёт метрики немедленно и убивает обратную связь: вы больше не знаете, где путь плох, потому что альтернативы нет. Честная позиция — забор оправдан только на узком наборе инвариантов, а не на выборе инструментов. Инварианты — то, за что компания отвечает целиком: аудит доступа в прод, отсутствие секретов в репозиториях, шифрование ПДн, идентичность сервисов, атрибуция расходов. Язык, фреймворк, структура манифеста, способ тестирования — предмет пути, а не забора.

Что делать с командой, которой золотой путь не подходит. Не уговаривать и не запрещать, а оформить съезд как договор на одну страницу:

1. Причина в одном абзаце: не «нам не нравится», а «нужен GPU-планировщик и задачи длиной 14 часов, шаблон убивает под по таймауту 2 часа».
2. Список инвариантов, которые команда берёт на себя: ротация секретов, обновление базового образа за 14 дней после CVE, метрики в общем формате, дежурство, аудит доступа. Именно он, а не сам факт съезда, защищает компанию.
3. Срок и дата пересмотра: съезд без срока превращается в вечное исключение, а через два года — в «исторически сложилось». Квартал — разумный шаг.
4. Владелец с обеих сторон и учёт: съезды считаются и публикуются, три съезда по одной причине — отсутствующая функция, а не три упрямые команды.

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

Что выносить в платформу, а что нет

Не всякая общая задача заслуживает платформенного решения. Фильтр — два вопроса: насколько часто это делают и насколько одинаково это нужно разным командам.

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

Пять способов провалить платформу

1. Обёртка над облаком, которая только мешает. Команда пишет YAML, платформа превращает его в Terraform один в один: из ста параметров провайдера доступны двадцать, зато появились свой язык ошибок, свой цикл релиза и своя очередь на добавление поля. Диагноз: доля полей вашей схемы, отображаемых в поля нижнего слоя один к одному; больше 70 % — это не абстракция, а переименование. Лечение: не абстрагировать, а курировать — модуль с хорошими значениями по умолчанию плюс разрешённый прямой доступ вниз для тех, кому не хватает.

2. Портал, которым никто не пользуется. Каталог, заполняемый вручную, устаревает за шесть недель: владельцы меняются, сервисы умирают, ссылки гниют. Диагноз: доля записей, обновляемых автоматически; доля инженеров, заходивших за 30 дней; сколько действий совершается из портала, а не только просмотров. Лечение: портал — вид на данные, а не источник; каталог наполняется из репозиториев и конвейера, а на карточке сервиса есть кнопки: выкатить, откатить, посмотреть логи, запросить доступ.

3. «Мы сделали абстракцию» поверх трёх разных потребностей. Один service.yaml на stateless API, ночной батч и stateful-сервис с диском: через год в нём 40 полей, из которых 25 игнорируются в двух случаях из трёх. Диагноз: доля полей, используемых менее чем 20 % сервисов; число веток вида «если тип = batch, то это поле означает другое». Лечение: правило трёх — абстракция строится после третьего потребителя; три шаблона честнее одного универсального, общим остаётся только действительно общее — идентичность, секреты, формат метрик.

4. Платформа — узкое горлышко. Всё идёт через тикеты, команда работает живым API: она перегружена, команды ждут, обе стороны уверены, что виноваты другие. Диагноз: доля задач, решённых без участия человека из платформы; медиана времени ответа; доля повторяющихся тикетов одного типа — это ваш бэклог самообслуживания. Лечение: каждый тип тикета, встречающийся чаще раза в неделю, становится кнопкой или командой CLI (устранение toil).

5. Платформа-налог. Команда растёт, экономия не считается, отчёт наверх состоит из числа закрытых задач; через два года восемь человек из сорока — 20 % бюджета разработки — заняты внутренним продуктом с неизвестной отдачей. Диагноз: попросите оценку сэкономленных инженеро-часов за квартал вместе с методикой — отсутствие ответа само по себе ответ. Лечение: разговор по формуле выше раз в квартал, с явным перечислением того, что вы считать не умеете.

Шестой провал не про платформу, а про моду: культ инструментов. «Нам нужен Backstage» — это не задача, а ответ без вопроса. Как выбирать инструмент под задачу — глава 09 и стратегия.

Цена владения: у каждого инструмента она есть

Ни один инструмент не хорош и не плох — у каждого есть постоянная стоимость владения, которую платит ваша команда, а не вендор. Порядок величин для организации в 50–150 инженеров:

Правило выбора: инструмент оправдан, если снимает работу, которую вы уже делаете руками и уже посчитали. Обратный порядок — «внедрим, а потом найдём применение» — и даёт платформу-налог. Смежное: безопасность в конвейере, секреты, цепочка поставки.

У платформы свои SLO

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

Определения, окна и бюджеты берутся из трека SRE как есть: SLI и SLO, бюджет ошибок, дежурство. Часто упускают, что дежурство у платформы обязано быть: её отказ парализует все команды сразу, а чинить некому — как устроить его, не выжигая пять человек, разбирает глава 13, наблюдаемость самой платформы — глава 08. Спор «конвейер сломался не по вине платформы» закрывается заранее договорённостью о классификации причин отказа сборки (код, тесты, флаки, инфраструктура), иначе метрика доступности превращается в переговорную позицию (тесты в CI).

Взгляд системного мышления: почему платформы ломаются предсказуемо

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

К этому добавляется когнитивная нагрузка из Team Topologies: задача платформенной команды — снижать нагрузку продуктовых команд, а не переносить её на себя навсегда. Отсюда же thinnest viable platform — минимальная платформа, решающая реальную боль, а не витрина возможностей.

Стадии зрелости и карта трека

Стадии проходятся по порядку: прыжок с первой сразу на третью даёт портал с каталогом мёртвых сервисов и дорожную карту, которую никто не заказывал.

Шестнадцать глав в пяти блоках: продуктовая рамка (01–03), опыт использования (04–06), платформенные сервисы (07–10), экономика и переходы (11–12), люди и реальность (13–15).

Маршруты чтения. Платформа есть, но её обходят — 14, 01, 02, 03. Только собираетесь — 15, 01, 04, дальше по порядку. Решаете, нанимать ли команду, — арифметика выше, затем 13 и 11. Инженер платформы, который хочет перестать быть тикет-машиной, — 04, 09, 07.

Что предполагается известным и не пересказывается: конвейеры и контейнеры, SLO и дежурства, границы команд, продуктовые метрики, приоритизация, исследование пользователей.

Типичные ошибки на старте

• Начали с портала. Витрина без работающих сервисов самообслуживания: инженеры заходят один раз и не возвращаются.
• Спросили «что вам нужно» и сделали список. Пользователи называют решения, а не проблемы; смотреть надо на то, что они делают — где переключаются на ручной способ, где копируют чужое, где ждут (исследование).
• Взяли инструмент до задачи. Kubernetes и Backstage появились в плане раньше цифры «сколько часов в неделю мы возвращаем каждому инженеру».
• Абстрагировали до третьего потребителя. Схема под одну команду ломается на второй и переписывается на третьей — с миграцией для всех.
• Не завели дежурство платформы. Её отказ — инцидент масштаба компании, а не «починим утром».
• Меряют выпуск, а не принятие. «Закрыли 120 задач» не отвечает, стало ли быстрее хоть у кого-нибудь; а мандат вместо продукта работает до первого срыва сроков, после чего виноватой назначают платформу.

Мини-итог

Внутренняя платформа — продукт, чьи пользователи сидят в соседней комнате и умеют писать код сами; цена ухода для них — вечер работы, а не смена поставщика. Отсюда всё остальное. Метрики принятия важнее полноты функций: неиспользуемая функция не экономит ни минуты. Золотой путь обязан оставаться путём, забор ставится только на инварианты компании, и каждый съезд — баг-репорт, а не нарушение. Платформенная команда не пишет продукт, поэтому обязана считать сэкономленное чужое время: одна ставка на 25 продуктовых инженеров при экономии двух часов в неделю и на 50 при экономии часа. Kubernetes, Backstage, service mesh имеют постоянную цену владения, которую платите вы, и оправданы, только когда снимают работу, которую вы уже делаете руками и уже посчитали. Проверить себя можно одним вопросом: сколько процентов выкатов в прод за последний месяц прошло мимо вашей платформы — и знаете ли вы, почему.

Источники

• Matthew Skelton, Manuel Pais. Team Topologies, IT Revolution, 2019 — https://teamtopologies.com/: платформенный тип команды, когнитивная нагрузка, thinnest viable platform.
• Evan Bottcher. What I Talk About When I Talk About Platforms, 2018 — https://martinfowler.com/articles/talk-about-platforms.html: платформа через добровольное использование.
• Camille Fournier, Ian Nowland. Platform Engineering: A Guide for Technical, Product, and People Leaders, O’Reilly, 2024 — организационная сторона и экономика платформенных команд.
• CNCF Platforms Working Group. Platforms White Paper — https://tag-app-delivery.cncf.io/whitepapers/platforms/ и Platform Engineering Maturity Model — https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/.
• Nicole Forsgren, Jez Humble, Gene Kim. Accelerate, IT Revolution, 2018, и отчёты DORA https://dora.dev/research/ — метрики потока доставки.
• Abi Noda et al. DevEx: What Actually Drives Productivity, ACM Queue, 2023 — https://queue.acm.org/detail.cfm?id=3595878; The SPACE of Developer Productivity, 2021 — https://queue.acm.org/detail.cfm?id=3454124.
• Internal Developer Platform — https://internaldeveloperplatform.org/; Kubernetes support policy — https://kubernetes.io/releases/patch-releases/; What is Backstage — https://backstage.io/docs/overview/what-is-backstage.

Что дальше

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