Каждая команда, которая решает «построить внутреннюю платформу разработчика», начинает одинаково: кто-то закрепляет скриншот Backstage в чате, слово «Spotify» упоминается дважды, и создаётся рабочая группа. Через полгода у платформы есть каталог сервисов, который никто не обновляет, шаблон «золотого пути», которым пользуется только сама платформенная команда, и растущая очередь заявок с просьбой «просто создайте репозиторий за меня». Платформа превратилась во вторую команду эксплуатации с дополнительными шагами.
В этом и заключается основное недоразумение. Платформенная инженерия — это не портал, который вы устанавливаете. Это продукт, заказчиками которого являются ваши собственные инженеры, а портал — лишь его витрина. Ниже объясняется, как на самом деле работает механизм, приводится реальный пример и указываются места, где он ломается.
Зачем вообще нужна IDP — механизм, а не лозунг
Разработчику нужно выпустить сервис. Без платформы это означает: запросить облачный аккаунт, дождаться IAM, вручную написать Dockerfile, скопировать конфигурацию CI из репозитория двухлетней давности, угадать подход к управлению секретами и подать заявку на базу данных. Каждый шаг мал; вместе они складываются в дни ожидания и груду решений, которые каждая команда принимает по-своему.
IDP сводит это к контракту: на входе — одно декларативное описание сервиса, на выходе — работающий, наблюдаемый, защищённый сервис. Разработчик пишет короткий манифест — имя, владелец, язык, нужна ли база данных — а платформа делает остальное. Ценность не в удобстве; ценность в том, что теперь каждый сервис имеет одинаковую форму, поэтому проверка безопасности, атрибуция затрат и дежурства перестают быть археологией.
Именно поэтому инструменты делятся на слои: каталог сервисов (Backstage, Port) хранит истину о том, что существует и кому принадлежит; оркестрация инфраструктуры (Crossplane, Terraform) превращает манифест в реальные облачные ресурсы; слой CI/CD и окружений даёт каждой ветке среду предварительного просмотра; наблюдаемость и управление секретами подключаются по умолчанию, а не прикручиваются потом.
Один пример: разработчику нужен сервис с базой данных
Представьте инженерную организацию из 40 человек. Бэкенд-разработчику нужен новый сервис с базой данных Postgres и средой для тестирования.
Без платформы: запрос облачного аккаунта (1–3 дня), ручное копирование Terraform, база данных, созданная вручную с учётными данными, вставленными в хранилище секретов, которое никто не документировал, файл CI, адаптированный из другого репозитория, и URL среды тестирования, который живёт в электронной таблице. Реалистично — от одной до двух недель календарного времени, большая часть которого — ожидание.
С работающей IDP: разработчик заполняет форму в каталоге — имя сервиса, команда-владелец, язык, «нужен Postgres: да». Каталог создаёт репозиторий из шаблона «золотого пути», регистрирует сервис с его владельцем и запускает Crossplane, который преобразует заявку в управляемую базу данных плюс секрет подключения. Конвейер собирает, развёртывает в среду предварительного просмотра и привязывает панель мониторинга и инструкцию обратно к записи в каталоге. Время до работающего сервиса в среде тестирования: менее часа, большая часть которого — первая сборка.
Порядок имеет значение. Команды, которые начинают с портала, получают красивый каталог сервисов, за которым всё ещё требуется ручная работа. Команды, которые начинают с оркестрации и «золотого пути», получают работающие сервисы, а затем добавляют портал как представление сверху. Если вы поменяете порядок, вы построите каталог ссылок и назовёте это платформой.
Где ломается сам механизм
1. Платформа превращается в очередь заявок. «Золотой путь» покрывает 60% случаев; остальные 40% подают заявки. Платформенная команда становится командой эксплуатации с более удобным интерфейсом, и очередь растёт быстрее каталога. Ранний сигнал: соотношение заявок к действиям самообслуживания растёт месяц за месяцем. Решение: измеряйте долю обходных путей — какую часть запросов обходит «золотой путь» — и рассматривайте каждый обход как недостающую функцию, а не как ошибку пользователя.
2. Каталогом никто не владеет. Каталог хорош настолько, насколько он свеж. Сервисы переименовываются, команды распадаются, владельцы уходят. Через полгода половина записей устарела, инженеры перестают доверять каталогу, и это убивает внедрение быстрее, чем любая недостающая функция. Ранний сигнал: результаты поиска указывают на удалённые репозитории. Решение: генерируйте записи каталога из самого репозитория (файл catalog-info.yaml в репозитории), чтобы источник истины находился там, где живёт код.
3. Платформа строится для платформенной команды. Команда строит то, что интересно — красивый слой абстракции — а не то, что нужно разработчикам. Внедрение застревает, потому что путь не соответствует тому, как люди на самом деле работают. Ранний сигнал: только сервисы самой платформенной команды используют «золотой путь». Решение: относитесь к внутренним разработчикам как к заказчикам с обратной связью и выпускайте скучную вещь (работающее развёртывание) раньше умной.
4. Затраты и радиус поражения появляются поздно. Платформа самообслуживания делает создание ресурсов — включая дорогие — тривиально простым. Без квот и атрибуции затрат, настроенных с первого дня, вы получите неожиданный счёт за облако и не сможете проследить его до команды. Ранний сигнал: ресурсы без меток в счёте. Решение: FinOps — это функция платформы, а не ежеквартальный отчёт — помечайте сервис и владельца во время создания.
Какой путь вам подходит
Честный компромисс: построение IDP — это реальная инвестиция — платформенная команда из двух-четырёх инженеров, от шести до двенадцати месяцев до окупаемости, и она окупается только при достаточном количестве сервисов и команд для амортизации. Примерно до десяти команд хороший набор шаблонов и документированный процесс обычно лучше платформы.
| Путь | Время и стоимость | Что вы получаете |
|---|---|---|
| Самостоятельное изучение по документации | Дёшево, медленно, неравномерно | Знание инструментов, без обратной связи по архитектурным решениям |
| Структурированный курс | Недели, умеренная стоимость | Полная цепочка от каталога до FinOps, с конфигурациями для сравнения |
| Собственная разработка | Месяцы, команда | Платформа, адаптированная к вашей организации — и счёт за поддержку |
Самостоятельное изучение упирается в конкретную стену: инструменты документированы по отдельности, но решения между ними — Backstage против Port, Crossplane против Terraform, когда среда предварительного просмотра стоит своих затрат — именно там никто не говорит вам, что ломается. Этот пробел закрывает структурированный путь, и здесь подходит курс Платформенная инженерия — внутренние платформы разработчика: он проходит полную цепочку от архитектуры до метрик с готовыми конфигурациями, чтобы вы сравнивали свой дизайн с работающим, а не гадали.
Этот путь подходит инженерам, переходящим из DevOps в платформенную работу, и командам, которые собираются строить свою первую IDP. Он не подходит тем, кто надеется обойти организационные изменения — платформа это продукт, а продуктам нужны заказчики, которые им доверяют.
Начните с наименьшего работающего пути: один шаблон «золотого пути», один согласовываемый ресурс, одна запись каталога, сгенерированная из репозитория. Если это выживет месяц реального использования, у вас есть платформа; если нет — у вас очень дорогой скриншот.