Платформенные команды любят строить платформы. Это и есть ловушка. Самый частый способ провалить platform-инициативу — запереться на полтора года, спроектировать «всё сразу» и выкатить наружу монумент, которым никто не пользуется: он опоздал и решает вчерашние проблемы. Альтернатива называется thinnest viable platform (TVP) — и она требует сменить мышление с «инфраструктурного проекта» на «продукт».
Golden path — это не скаффолдер
Сначала о терминах. Golden path (он же paved road у Netflix, paved path у Thoughtworks) — это рекомендованный, поддерживаемый платформенной командой способ решить типовую задачу: создать сервис, подключить БД, настроить мониторинг. Ключевое слово — поддерживаемый. Отклонения разрешены, но команда-отклонистка несёт стоимость поддержки сама.
Здесь все спотыкаются о масштаб. Golden path — это не «scaffolder создал репозиторий». Это сквозной маршрут: код → CI → registry → деплой → мониторинг → on-call. Если ваш «золотой путь» заканчивается на сгенерированном Dockerfile, вы построили шаблон, а не путь. Настоящий путь доводит разработчика до прод-сервиса с готовыми HPA, PDB, NetworkPolicy, дашбордами, алертами на multi-burn-rate SLO и заполненным runbook — без единого решения, которое можно принять неправильно.
У зрелого golden path четыре свойства: он опционален (платформа делает правильный путь самым лёгким, а не единственным — принуждение убивает innovation), сквозной, версионирован (go-microservice-v2, -v3; старое депрекейтится, не удаляется) и owned конкретной командой внутри платформы.
TVP: начать с одного пути для одной команды
Соблазн — охватить все языки, все сценарии, все облака до первого пользователя. TVP переворачивает порядок: выбрать один golden path для одной команды, выкатить, документировать боль, расширяться от неё. Метрика успеха не «сколько фич в платформе», а простой вопрос: команда выбрала этот путь или использует его, потому что заставили? Если выбрала добровольно — путь работает. Если нет — вы построили внутреннюю бюрократию с красивым порталом.
Из этого следует, что adoption rate важнее любой технической метрики. Drift rate (сколько сервисов сошли с пути после старта) и time-to-prod — это диагностика; добровольный выбор — диагноз.
Сначала стандартизировать, потом автоматизировать
У TVP есть встроенный предохранитель, который легко проигнорировать в спешке: автоматизация сломанного процесса просто делает сбой быстрее и консистентнее. Классический кейс — пятитысячестрочный bash-скрипт провижининга AWS, который заменили на Crossplane. Сработало не «потому что автоматика», а потому что сперва формализовали корректный декларативный end-state, и только потом автоматизировали переход к нему.
Симптом нарушения распознаётся мгновенно: golden path описывает ad-hoc последовательность («сначала apply этот, потом отредактируй ConfigMap, потом рестартни…») вместо декларативного конечного состояния. Лечение — сначала зафиксировать end-state (Crossplane composition, ApplicationSet, Helm-чарт с умными дефолтами), и только потом писать automation glue.
Узкий скучный стек как противоположный полюс
Есть второй способ строить paved road, противоположный «self-service-буфету» — узкий, скучный, opinionated дефолтный стек. Внутренние команды Amazon живут по дереву решений: Lambda по умолчанию → если упёрлись в лимиты, ECS на Fargate → EC2 только для legacy; состояние — DynamoDB, клей — S3, IaC — CDK. Не «выбери любой инструмент из исчерпывающего каталога», а «вот два варианта, оба мы умеем чинить в три часа ночи».
Логика та же, что у golden path, но доведённая до предела: разрастание (sprawl) — главный враг систем, которые живут дольше, чем создавшие их команды. Несколько стандартных паттернов побеждают множество индивидуально оправданных выборов. Ограничения тут — guardrails, а не клетка: лимиты Lambda заставляют думать о chunking и идемпотентности заранее. Показательна байка из практики: Aurora-базу подняли для одного исследователя; годы спустя исследователь ушёл, база живёт. Это операционный долг, переживающий людей, — ровно то, что узкий стек предотвращает.
Что забрать с собой
Golden path — продукт, а не утилита: у него есть владелец, версии, пользователи, которых нельзя заставить, и метрика добровольного выбора. Стройте его по TVP — тонко, для одной команды, расширяя от боли, — стандартизируйте процесс прежде, чем автоматизировать, и помните, что иногда лучший золотой путь не самый гибкий, а самый скучный. Платформа, которой пользуются неохотно, дороже её отсутствия: вы платите и за инфраструктуру, и за обход, который команды всё равно построят.