Golden Paths и self-service

Проблема фрагментации

В любой растущей организации через два-три года после старта микросервисной архитектуры вы обнаружите одну и ту же картину: 15 сервисов на Java с тремя разными фреймворками, 8 сервисов на Python с разными подходами к тестированию, CI-пайплайны, которые каждая команда копировала из соседнего репозитория и дорабатывала по-своему, и четыре способа деплоить в Kubernetes. Каждый из этих способов когда-то был оправдан, но в совокупности они создают проблему, которую Spotify описал в своём блоге: фрагментация экосистемы.

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

Что такое golden path

Golden path — это рекомендуемый, поддерживаемый и документированный способ выполнить типовую задачу. Создать новый сервис. Настроить CI/CD. Подключить базу данных. Настроить мониторинг. Для каждой такой задачи платформенная команда определяет один путь, который работает, соответствует стандартам безопасности и обеспечен поддержкой.

Spotify ввёл термин golden path. Netflix использует термин paved road. Red Hat пишет о golden paths в контексте platform engineering. Названия разные, суть одна: вы прокладываете дорожку, по которой идти легко и безопасно, и предлагаете командам по ней пройти.

Ключевое слово — «предлагаете». Golden path — это рекомендация, а не требование. Команда может сойти с golden path, если у неё есть техническая причина: специфические требования к производительности, нестандартная технология, уникальный use case. Но сойти — значит взять на себя ответственность за поддержку нестандартного решения. И об этом стоит сказать вслух.

Guardrails vs gates

В индустрии есть два подхода к тому, как обеспечить следование стандартам, и The New Stack хорошо описал разницу.

Gates (шлагбаумы) — жёсткие ограничения. CI не пропустит деплой без определённых тегов. Политика запрещает использовать базовые Docker-образы, кроме одобренных. Нельзя создать сервис без SLO. Gates работают через запреты: вы не пройдёте, пока не выполните условие.

Guardrails (ограждения) — мягкие подсказки. CI покажет предупреждение, что вы используете необычный базовый образ. Скорекард в Backstage покажет, что у вашего сервиса нет runbook-а. Линтер подсветит, что ваш Terraform-код не следует модулям компании. Guardrails информируют, но не блокируют.

Зрелые платформы комбинируют оба подхода. Gates — для требований безопасности и compliance, где нет места для исключений: нельзя деплоить с known critical vulnerabilities, нельзя хранить секреты в коде, нельзя открыть порт в интернет без WAF. Guardrails — для всего остального: рекомендуемые версии языков, структура проекта, подходы к тестированию. Если вы поставите gates на всё, разработчики будут ненавидеть платформу. Если ограничитесь guardrails для безопасности — рано или поздно получите инцидент.

Как проектировать golden paths

Хороший golden path отвечает четырём критериям.

Покрывает реальную потребность

Начните с того, что разработчики делают часто и что занимает у них много времени. Проведите интервью с пятью-шестью командами и спросите: «Какую задачу, связанную с инфраструктурой, вы выполняли в последний месяц?» Посчитайте частоту. Самые частые задачи — кандидаты для golden paths.

Работает из коробки

Разработчик проходит по golden path и получает работающий результат за минуты. Шаблон нового сервиса создаёт репозиторий с CI-пайплайном, который проходит, а не падает на первом же запуске. Self-service для базы данных выдаёт connection string, который работает в dev-окружении. Если после прохождения golden path нужно ещё два часа ручной настройки, разработчики перестанут им пользоваться.

Обновляется

Golden path — это продукт, а не разовый скрипт — именно поэтому подход Platform as a Product так важен для их успеха. Когда команда безопасности добавляет новое требование, golden path обновляется. Когда выходит новая LTS-версия Node.js, шаблон обновляется. Когда CI-провайдер меняет формат конфигурации, шаблон обновляется. Если golden path устаревает, разработчики перестанут ему доверять и вернутся к копированию конфигов из соседнего репозитория.

Прозрачен

Разработчик может посмотреть, что golden path делает внутри. Шаблон — это не чёрный ящик, а набор файлов с комментариями. Если разработчику нужно отклониться от golden path, он видит, какую часть конфигурации менять и какие последствия это имеет.

Примеры golden paths

Создание нового сервиса. Разработчик заходит в Backstage, выбирает шаблон «Java Spring Boot Service», указывает имя и команду-владельца. Scaffolder создаёт репозиторий в GitHub с Gradle-конфигурацией, Dockerfile на основе одобренного базового образа, GitHub Actions-пайплайном, Helm-чартом для деплоя, заготовкой для документации и записью в каталоге. Первый пайплайн запускается автоматически и деплоит сервис в dev-окружение.

Добавление базы данных. Разработчик в портале выбирает «Добавить PostgreSQL», указывает сервис-потребитель и окружение. Платформа создаёт инстанс через Terraform, прописывает connection string в секреты Kubernetes, обновляет граф зависимостей в каталоге.

Промоция в production. Разработчик нажимает «Promote to prod» в портале. Платформа запускает pre-production тесты, проверяет compliance-требования (gates), создаёт change request, и после ручного одобрения выполняет canary-деплой с автоматическим откатом при деградации метрик.

Метрики golden paths

Вы построили golden paths — как понять, что они работают? Три метрики.

Adoption rate — какой процент новых сервисов создаётся через golden path. Если 90% команд используют шаблоны, golden path удался. Если 30% — вы построили то, чем неудобно пользоваться, или не донесли ценность до команд.

Time to first deploy — сколько времени проходит от решения «нам нужен новый сервис» до первого деплоя в dev. Хороший golden path сокращает это время с дней до минут.

Deviation rate — как часто команды отклоняются от golden path и по каким причинам. Высокий deviation rate в конкретной области означает, что golden path не покрывает реальную потребность и его нужно расширить.