Платформа — это продукт, а не вики со ссылками
Internal Developer Platform (IDP) объединяет инструменты, шаблоны и документацию в единый self-service интерфейс. Ключевое слово — продукт: у него есть владелец, пользователи — разработчики — и метрика успеха: скорость, с которой инженер доводит идею до прода. Портал, который никто не развивает как продукт, умирает за полгода — к этому я ещё вернусь.
Главная боль, которую снимает IDP, — когнитивная нагрузка. Разработчик одного микросервиса сегодня обязан держать в голове манифесты Kubernetes, Terraform, ArgoCD, политики Vault, правила Prometheus и Kyverno. Платформа прячет это за self-service: «нажми кнопку — получи окружение».
Почему именно сейчас: три драйвера
1. DevOps без структуры не масштабируется. Модель «каждая команда сама себе DevOps» работает на трёх командах и ломается на тридцати: каждая собирает свой зоопарк инструментов, и организация тонет в фрагментации. Платформа возвращает консистентность, не убивая автономию.
2. AI-код опережает governance. Агенты и Copilot пишут код быстрее, чем ручной code review успевает его валидировать. Единственный масштабируемый ответ — перенести контроль в automated guardrails: policy-as-code как admission control, а не человек-ревьюер в роли бутылочного горлышка.
3. Когнитивная нагрузка стала непосильной. Это следствие первых двух: чем больше инструментов и чем быстрее поток изменений, тем дороже держать всё в голове. IDP возвращает разработчику фокус на его сервис.
По данным CNCF, платформенная команда уже есть у 28% организаций; Gartner прогнозирует 80% крупных enterprise к концу 2026. Это не хайп — структурный ответ на сложность.
Канонический стек из шести слоёв
Рабочая платформа на Kubernetes собирается из шести слоёв. Я придерживаюсь CNCF-native defaults — не потому что они единственно верные, а потому что они дают связность: инструменты рассчитаны друг на друга.
- 1. Developer Portal — Backstage: единый UI, каталог, scaffolder.
- 2. GitOps & Deployment — ArgoCD или Flux: декларативная доставка.
- 3. Infrastructure Provisioning — Crossplane: инфраструктура как K8s-ресурсы.
- 4. Policy & Security — Kyverno и Trivy: guardrails и сканирование.
- 5. Observability — Prometheus, Grafana, OpenTelemetry.
- 6. AI / DevEx — пока emerging: ассистенты и AI-triage инцидентов.
Шесть слоёв — это минимум. Зрелые платформы добавляют homegrown admin-API сервисы и AI-assisted триаж. Но без первых шести надстройка не имеет смысла. Важная оговорка: портал без golden paths и policy engine — это каталог без содержимого. Один голый Backstage не даёт ценности; ценность — в шаблонах, которые на кнопку отдают репозиторий с CI/CD, observability и security baseline, и в политиках, которые не дают baseline деградировать.
Три кита портала
- Software Catalog — единый source of truth: сервисы, владельцы, зависимости, runbooks, ссылки на дашборды. Не ручной spreadsheet, а автоматический discovery.
- Scaffolder — golden paths в виде кода: кнопка → готовый репозиторий с пайплайном, мониторингом и security baseline.
- TechDocs — docs-as-code из репозиториев сервисов с единым поиском.
Что измерять
Платформа-как-продукт требует продуктовых метрик:
- Time-to-first-deploy — от создания репозитория до прода (цель: меньше дня).
- Self-service ratio — доля задач, решённых без обращения к платформенной команде.
- Template adoption — доля новых сервисов через scaffolder.
- Internal NPS — опрос разработчиков раз в квартал.
Если adoption растёт, а NPS падает — вы построили принуждение, а не платформу.
Четыре способа убить IDP
- Портал без owner-team — никто не развивает, умирает за полгода.
- Scaffolder без post-create automation — сгенерировал boilerplate, но не подключил CI, секреты и мониторинг; разработчик всё равно идёт к платформенной команде.
- Каталог как ручной spreadsheet — без автоматического discovery устаревает в день создания.
- Принудительное внедрение — платформа должна быть лучшим путём, а не единственным.
Вывод
IDP — это инвестиция в скорость и консистентность, которая окупается только при продуктовом подходе: владелец, метрики, путь, который выбирают добровольно. Шесть слоёв дают каркас; три драйвера объясняют, почему откладывать дорого; четыре анти-паттерна показывают, где платформы умирают. Начинать стоит не с портала, а с одного golden path, который реально экономит разработчику день. И шесть слоёв не обязаны появляться разом — достраивайте их инкрементально, по мере того как предыдущий слой начинает окупаться.