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 — рекомендация, а не требование. Команда может сойти с пути, если есть техническая причина: специфические требования к производительности, нестандартная технология, уникальный 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 так важен для их успеха. Команда безопасности добавила требование — обновляется шаблон. Вышла новая LTS-версия Node.js — обновляется шаблон. CI-провайдер сменил формат конфигурации — обновляется шаблон. Если 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 не покрывает реальную потребность и его пора расширять.