Платформа как продукт: зачем IDP и кто её пользователи

Хронометраж: занятие 60 минут — теория 30 минут, практика 30 минут. Домашняя работа: 1–2 часа.

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

---

1. Что изучаем

• понимать, что такое IDP и какую проблему (когнитивную нагрузку) она решает;
• видеть «поверхность разработчика» — сколько областей и инструментов трогает один сервис;
• относиться к платформе как к продукту: у неё есть пользователи, а участие добровольное;
• отличать платформенную команду от классической эксплуатации;
• знать роль golden path, self-service и каталога как частей платформы.

2. Зачем это нужно и где применяется

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

Это первый урок блока 19. Дальше — конкретные части платформы: golden path и шаблоны (19.02), self-service окружения (19.03), каталог сервисов (19.04), документация как код (19.05), метрики опыта разработчика (19.06), общие модули (19.07). Здесь — зачем всё это вместе и как об этом думать.

3. Теория (30 минут)

Проблема: когнитивная нагрузка разработчика. Чтобы отгрузить один сервис в прод, разработчик проходит десяток областей, и в каждой — свои инструменты и артефакты. Посчитано на стенде по областям самого курса (блоки 06–18): 12 областей, 41 инструмент/артефакт, 39 типовых шагов настройки — код и зависимости, контейнеризация, CI, тесты, секреты, развёртывание, конфигурация, сеть и доступ, наблюдаемость, надёжность, безопасность, инфраструктура. Всё это — на разработчике, если платформы нет. Такая нагрузка либо тормозит доставку (каждый сервис настраивают с нуля), либо приводит к тому, что часть областей делают плохо или пропускают (нет проб, нет сканирования, секреты в коде). Именно эту нагрузку и снимает платформа.

IDP — то, что склеивает области в один путь. Определение (internaldeveloperplatform.org): «An Internal Developer Platform (IDP) is built by a platform team to build golden paths and enable developer self-service.» Ключевое — не «ещё один инструмент», а склейка: «An IDP consists of many different techs and tools, glued together in a way that lowers cognitive load on developers without abstracting away context and underlying technologies.» Обратите внимание на оговорку «without abstracting away … underlying technologies»: платформа не прячет Kubernetes и Terraform так, чтобы разработчик перестал их понимать, — она даёт удобный путь поверх, оставляя доступ к деталям. Проверено на стенде: те же 12 областей через golden path сворачиваются для разработчика в один шаг скаффолдинга (19.02), а всё остальное настроено по стандарту платформой.

Платформа — это продукт, а не проект. Главный сдвиг мышления: у платформы есть пользователи (разработчики продуктовых команд), и её успех измеряется тем, пользуются ли они ей. Отсюда продуктовый подход: изучать потребности пользователей, а не навязывать «правильное»; делать удобным, а не обязательным; собирать обратную связь и улучшать (19.06). Признак провала — платформа, которой команды избегают, обходя её «в тайне», потому что своими скриптами быстрее. Признак успеха — команды выбирают платформу, потому что через неё проще, чем без неё.

Золотой путь — проложенная дорога, а не забор. Центральная идея: golden path (он же paved road) — рекомендованный, хорошо поддержанный способ делать типовое: создать сервис, выкатить, получить окружение. По нему быстро и правильно из коробки. Но это дорога, а не забор: платформа делает правильный путь самым лёгким, но не запрещает съехать с него, если команде нужно нестандартное. Разница принципиальна: забор (жёсткое «только так») команды обходят и саботируют; проложенная дорога (удобное «так проще всего») — выбирают добровольно. Это продолжение мысли из безопасности (18.07): мутация-умолчания и secure-by-default работают лучше запретов, потому что помогают, а не мешают.

Кто пользователи и что им нужно. У платформы не один тип пользователя. Продуктовый разработчик хочет отгрузить фичу, не изучая 12 областей, — ему нужен golden path и self-service. Тимлид хочет, чтобы его команда двигалась быстро и безопасно, — ему нужны стандарты по умолчанию и видимость. Служба безопасности и SRE хотят, чтобы правила (сканирование, пробы, политики) применялись сами, — платформа встраивает их в golden path (это и есть DevSecOps из 18.01, но на уровне платформы). Хорошая платформа сводит эти интересы: разработчику удобно, а стандарты применяются автоматически, потому что встроены в удобный путь.

Платформенная команда — не переименованная эксплуатация. Классическая эксплуатация принимает заявки и выполняет их для команд (тикет «создайте мне окружение»). Платформенная команда вместо этого строит продукт для самообслуживания: команды создают окружения сами, без тикета (19.03). Team Topologies называет это platform team, чья задача — снижать когнитивную нагрузку stream-aligned (продуктовых) команд, предоставляя self-service. Разница в модели: эксплуатация — узкое место (все заявки через неё), платформа — множитель (команды обслуживают себя сами по проложенному пути). Если платформенная команда снова стала очередью заявок, продуктового подхода не получилось.

Платформа не для всех и не сразу. IDP оправдан там, где много команд и сервисов и повторяющаяся сложность; для одного маленького сервиса платформа — избыточность. Строят её постепенно: не «сначала полгода строим платформу», а найти самую больную повторяющуюся боль (обычно создание сервиса или окружения) и проложить первый golden path, затем следующий. Платформа растёт по потребности пользователей, как продукт, а не по большому плану сразу.

Тончайшая жизнеспособная платформа. Team Topologies вводит понятие thinnest viable platform — минимум, который уже снижает нагрузку, а не «полный IDP сразу». Иногда тончайшая платформа — это просто хорошая вики со ссылками и пара шаблонов; иногда — набор общих модулей. Начинать с большого портала — частая и дорогая ошибка: полгода строят инфраструктуру платформы, пока продуктовые команды продолжают страдать от той же боли. Правильнее спросить: что самое тонкое, что уже поможет? — и дать это, а наращивать по мере спроса. Платформа, как продукт, растёт итеративно от реальной потребности, а не разворачивается целиком по плану.

Собрать самим, купить или взять готовое. Платформу редко пишут с нуля — её собирают. Три пути: из открытых кирпичей (cookiecutter/шаблоны, Backstage как каталог 19.04, Argo CD как доставка 14.10, Terraform-модули 19.07 — всё уже пройдено в курсе, платформа их склеивает); купить готовый IDP (Humanitec, Port и подобные — портал и оркестрация как сервис); облачные готовые пути (managed-сервисы провайдера). Выбор зависит от масштаба и наличия своей платформенной команды: маленьким хватает шаблонов и модулей, крупным окупается портал. Важно, что почти всё, из чего собирают платформу, вы уже знаете по блокам 07–18 — новизна не в кирпичах, а в том, чтобы склеить их в удобный путь.

Платформа — критичная зависимость, и у неё свой SLO. Как только команды перешли на платформу, она становится общей точкой отказа: если платформа лежит, никто не может создать сервис, получить окружение или выкатиться. Поэтому к платформе применяют всё из блока 17: у неё есть свой SLO и бюджет ошибок (17.02), дежурство (17.03), наблюдаемость (14). Платформенная команда несёт ответственность за надёжность своего продукта так же, как продуктовая — за свой сервис. Обратная сторона удобства self-service — что платформа обязана быть надёжной, иначе она из множителя снова превращается в узкое место, только теперь техническое.

Успех платформы измеряют, а не декларируют. Продукт без метрик успеха — это вера, а не управление. Успех платформы меряют принятием (сколько команд и сервисов реально на ней, а не обязаны быть), опытом разработчика (19.06: время до первого выката нового сервиса, частота обращений за помощью, опросы удовлетворённости) и влиянием на доставку (метрики DORA: сократилось ли время доставки, выросла ли частота выкатов). Растущее принятие и улучшающийся DX — сигнал, что платформа полезна; команды, обходящие её, — сигнал, что что-то не так с продуктом. Это замыкает продуктовый цикл: измерили, узнали у пользователей, улучшили (19.06).

Платформенная инженерия не отменяет DevOps и SRE. Частый вопрос: платформенная инженерия — это замена DevOps? Нет, это его продолжение. DevOps соединил разработку и эксплуатацию (блок 01); проблема в том, что «you build it, you run it» на масштабе означает, что каждая команда несёт всю сложность сама. Платформенная инженерия снимает эту сложность, не возвращая старое разделение: команды по-прежнему владеют своими сервисами (19.04), но по проложенному пути, а не в одиночку с нуля. SRE даёт надёжность (блок 17), и платформа встраивает практики SRE в golden path по умолчанию (пробы, SLO, наблюдаемость). То есть платформенная инженерия — это способ применить накопленное DevOps и SRE на масштабе многих команд, а не отказ от них.

3.1. Примеры и варианты реализации

Платформа — это подход; различается, из чего её собирают.

Масштаб	Как выглядит платформа	Из чего
Небольшая команда	шаблоны + скрипты + документация	cookiecutter, общие модули (19.02, 19.07)
Средняя организация	self-service + каталог + golden paths	шаблоны, CI, Backstage-каталог (19.03–19.04)
Крупная / облачная	полноценный IDP с порталом	внутренний портал, оркестрация, управляемые сервисы

Небольшая команда. Платформа начинается не с портала, а с шаблонов и общих модулей: один способ создать сервис (19.02), общие Terraform-модули и чарты (19.07), написанная документация (19.05). Этого уже достаточно, чтобы снять львиную долю нагрузки.

Средняя организация. Добавляются self-service окружения (19.03) и каталог сервисов с владением (19.04), golden paths на несколько типов сервисов.

Крупная / облачная. Полноценный IDP: портал разработчика, оркестрация ресурсов, интеграция с управляемыми сервисами. Замером в этом уроке не проверялось — здесь речь о подходе.

Что выбрать. Начинать с малого: шаблон создания сервиса и общие модули снимают больше всего нагрузки при наименьших затратах. Портал и полный IDP — когда команд и сервисов много и повторяющаяся боль это оправдывает. Главное — продуктовый подход и golden path как дорога, а не забор.

4. Практика на занятии (30 минут)

Курс проходят самостоятельно, поэтому каждый шаг говорит, что ввести или сделать, зачем, что должно получиться и что делать при неудаче. Стенд не нужен — только python3 на хозяине. Опыты — в 19.01-platform-as-product/, инвентаризация — platform-surface.py.

Шаг 1 (10 минут). Посчитать поверхность разработчика.

• Что ввести:

cd blocks/19-platform-engineering/examples/19.01-platform-as-product
python3 platform-surface.py

• Зачем: увидеть числом, а не на словах, сколько разных областей и инструментов должен пройти разработчик, чтобы отгрузить один сервис без платформы, — это и есть когнитивная нагрузка из §3.
• Ожидаемый результат: построчный список 12 областей с инструментами (от «Код и зависимости — 3 инстр.» до «Наблюдаемость — 5 инстр.») и строка «ИТОГО областей: 12, инструментов/артефактов: 41, типовых шагов настройки: 39».
• Если не так: если скрипт не запускается («No such file or directory») — проверьте, что вы в каталоге examples/19.01-platform-as-product (pwd); если python3 не найден — проверьте python3 --version.
• Ответьте: какая из 12 областей у вас в реальной практике отнимает больше всего времени — совпадает ли она с той, где в скрипте больше всего инструментов (Наблюдаемость, 5)?

Шаг 2 (10 минут). Посмотреть golden path.

• Что ввести:

python3 platform-surface.py --golden

• Зачем: увидеть на числах разницу между «без платформы» и «с golden path» — те же 12 областей остаются, но у разработчика теперь один шаг вместо 39.
• Ожидаемый результат: строки «шагов у разработчика: 1 (остальное — ответственность платформы)» и «когнитивная нагрузка: знать бизнес-логику сервиса, а не 12 областей».
• Если не так: если вывод совпадает с выводом шага 1 — проверьте, что флаг передан именно как --golden, а не -golden или golden без дефисов.
• Ответьте: платформа убрала эти 12 областей или переложила ответственность за них на себя? (Подсказка — оговорка IDP «without abstracting away ... underlying technologies» в §3.)

Шаг 3 (10 минут). Соотнести области со своей практикой.

• Что сделать: возьмите 12 областей из шага 1 и против каждой запишите номер блока курса, где вы её уже проходили (§2 перечисляет их по блокам 06–18). Затем против каждой области отметьте, настроена ли она у вас (в рабочем или учебном проекте) по единому стандарту для всех сервисов или каждый разработчик делает её по-своему.
• Зачем: убедиться, что golden path не придумывает ничего нового, а склеивает уже изученное, и увидеть у себя долю областей без стандарта — это и есть измеримая когнитивная нагрузка, которую можно снять первой.
• Ожидаемый результат: список или таблица на 12 строк с номером блока и пометкой «есть стандарт» / «нет стандарта» у каждой области; хотя бы одна область без стандарта — кандидат в первый golden path.
• Если не так: если стандарт есть у всех 12 областей сразу — кандидатом на golden path становится не отдельная область, а весь путь целиком (одна команда вместо 12 отдельно настроенных шагов).
• Ответьте: какая область без стандарта повторяется у вас чаще всего между сервисами — она и есть первый кандидат на golden path (проверьте вывод в домашней работе).

Проверка результата. Вы можете назвать проблему, которую решает IDP (когнитивная нагрузка), объяснить golden path как дорогу-не-забор и почему платформу строят как продукт.

5. Домашняя работа (1–2 часа)

Задание. Оценить «поверхность разработчика» в своей (или учебной) среде и описать первый golden path.

Критерии приёмки.

• перечислены области и инструменты, которые проходит один сервис от кода до прода (поверхность);
• оценена когнитивная нагрузка: что из этого сейчас на разработчике, а что стандартизовано;
• выбрана самая больная повторяющаяся область (обычно создание сервиса/окружения) как первый golden path;
• golden path описан как дорога, а не забор: что даёт по умолчанию и как с него можно съехать;
• названы пользователи платформы (разработчик, тимлид, безопасность/SRE) и что нужно каждому;
• объяснено, чем платформенный (self-service) подход отличается от очереди заявок эксплуатации.

Файлы для работы: blocks/19-platform-engineering/examples/19.01-platform-as-product/

6. Частые ошибки и подводные камни

• Платформа как проект, а не продукт. Симптом: построили, никто не пользуется. Причина: не изучали пользователей. Что делать: продуктовый подход, обратная связь (19.06).
• Забор вместо дороги. Симптом: команды обходят платформу. Причина: жёсткое «только так». Что делать: golden path как самый лёгкий путь, съезд возможен.
• Абстрагировали до потери понимания. Симптом: разработчики не понимают, что под капотом, и беспомощны при сбое. Причина: спрятали технологии. Что делать: удобный путь поверх, доступ к деталям сохранён.
• Переименованная эксплуатация. Симптом: платформа — очередь тикетов. Причина: нет self-service. Что делать: команды обслуживают себя сами (19.03).
• Платформа раньше потребности. Симптом: полгода строили, боли не сняли. Причина: строили по плану, не по боли. Что делать: начать с самой больной повторяющейся области.
• Платформа для одного сервиса. Симптом: overhead больше пользы. Причина: масштаб не тот. Что делать: IDP оправдан при многих командах/сервисах.
• Стандарты навязаны, а не встроены. Симптом: безопасность/пробы игнорируют. Причина: требуют вручную. Что делать: встроить в golden path по умолчанию (18.01).

7. Проверка усвоения

1. Что такое IDP и какую проблему он решает?
2. Что такое «поверхность разработчика» и почему она — проблема?
3. Почему платформу строят как продукт, а не как проект?
4. Что такое golden path и почему это дорога, а не забор?
5. Кто пользователи платформы и что нужно каждому?
6. Чем платформенная команда отличается от классической эксплуатации?
7. Почему платформа не должна абстрагировать технологии до потери понимания?
8. Когда IDP оправдан, а когда избыточен?

8. Материалы

Минимум два варианта на выбор: официальная документация плюс книга/статья/видео.

• internaldeveloperplatform.org — internaldeveloperplatform.org. Что такое IDP, golden paths, self-service, когнитивная нагрузка.
• Team Topologies (platform team) — teamtopologies.com. Платформенная команда как способ снизить когнитивную нагрузку продуктовых команд.
• CNCF Platforms White Paper — tag-app-delivery.cncf.io/whitepapers/platforms/. Платформы как продукт, их пользователи и возможности.

---

← Предыдущий: 18.10. Аудит, логи безопасности и требования регуляторов · Блок 19 · Следующий: 19.02. Golden path и шаблоны: типовой путь нового сервиса →