Golden Paths

Отличить типовой путь (golden path) от мандата можно одним вопросом: что происходит с командой, которая пошла другой дорогой. Если ничего, кроме потери поддержки, — это golden path. Если ревью, эскалация или блокировка выката — это регламент, и называть его золотым путём я считаю подменой понятий. Разница не косметическая. Регламент можно навязать один раз и дальше не трогать, а типовой путь приходится постоянно держать лучше альтернатив, иначе им просто перестанут пользоваться — тихо, без объявления войны, каждая команда по отдельности.

Golden path — собранный, версионируемый и поддерживаемый способ пройти частый сценарий целиком: от намерения до результата, который работает в проде. Отличие от CI/CD и Infrastructure as Code в единице: там компоненты и правила их устройства, здесь собранный маршрут поверх них. От Platform as a Product — в масштабе решения: там границы и состав платформы целиком, здесь один конкретный путь и его содержание.

Что должен уметь

Главный навык на уровне L5 — держать портфель путей в состоянии, где каждый из них дешевле обходить, чем использовать. Самый недооценённый навык на уровне L4 — спроектировать выход: путь, из которого нельзя аккуратно уйти, через год становится ловушкой, и команды начинают обходить его заранее, ещё до того, как он им помешает.

Проходит существующий golden path по своему сценарию и понимает, что именно он сгенерировал: репозиторий, конвейер, манифесты, права, точки мониторинга.
Отличает то, что путь гарантирует, от того, что остаётся ответственностью команды.
Сообщает о поломке пути как о дефекте продукта, а не обходит её молча своим скриптом.

Собирает путь для повторяющегося сценария: шаблон, параметры, проверки, документация и работающий результат в конце, а не набор заготовок.
Версионирует путь и тестирует его в CI так же, как обычный код: путь, который не собирается на чистом окружении, сломан независимо от того, что написано в документации.
Проектирует осознанное отклонение: где путь разрешает заменить компонент, что теряется вместе с заменой и как об этом узнает владелец.
Отвечает на вопрос про расхождение: что происходит с сервисами, созданными по старой версии шаблона.

Ведёт портфель путей: какие сценарии покрыты, какие намеренно не покрыты, какие пути пора объединить или закрыть.
Считает, какую часть сценария путь реально закрывает и где он обрывается. Обрыв в середине хуже отсутствия пути: команда всё равно доделывает руками, но уже поверх чужих решений.
Разделяет обновление шаблона и миграцию существующих сервисов; для второго нужен отдельный план и владелец.
Удерживает путь тонким. Каждый новый обязательный шаг в нём оплачивается временем всех команд, которые по нему идут.

L6+

Задаёт правило, при котором путь становится обязательным: как правило, это требования безопасности или вывод старого решения из эксплуатации, и в обоих случаях у обязательности есть срок и миграционный путь.
Не допускает превращения набора путей в единственную разрешённую архитектуру: у организации должен остаться способ делать по-другому и признанная цена такого выбора.
Связывает решение о новом пути со спросом, а не с наличием шаблона: путь для сценария, который случается дважды в год, почти всегда дороже, чем разовая помощь.

Материалы

Статьи и документация

Spotify Engineering — How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (август 2020). Первоисточник самого термина в его нынешнем значении: «opinionated and supported» путь сделать типовую вещь. Читать целиком, там же описано, как путь сочетается с автономией команд.
Philip Fisher-Ogden, Greg Burrell, Dianne Marsh — Full Cycle Developers at Netflix (май 2018). Та же идея под именем paved road и на два года раньше. Ценна честностью про пределы: авторы прямо пишут, что идеал «каждая команда использует каждую возможность каждого инструмента» недостижим.
CNCF TAG App Delivery — Platform Engineering Maturity Model. Аспект Interfaces — про то, как пользователи потребляют возможности платформы. Полезен, чтобы не свести разговор о путях к одному лишь шаблону репозитория.
Backstage Software Templates (документация). Механика генератора: заготовка кода, подстановка переменных, публикация в GitHub или GitLab. Отмечу, что сама документация слов golden path не использует — это инструмент под путь, а не путь.

Книги

Matthew Skelton, Manuel Pais — Team Topologies (IT Revolution, 1-е изд. 2019, 2-е изд. 2025). Ради идеи самой тонкой из работающих платформ (thinnest viable platform): авторы предупреждают, что внутренние платформы чаще раздуваются и начинают замедлять команды. Для путей это прямое правило — каждый обязательный шаг оплачивается всеми.

Инструменты

Scaffolder (Backstage Software Templates, cookiecutter, copier) — генерация стартовой точки. По моим наблюдениям, здесь чаще всего и останавливаются, а это самая дешёвая часть пути: сгенерировать репозиторий легко, довести сервис до прода — нет.
Обновляемые шаблоны — copier и подобные умеют переносить изменения шаблона в уже созданные проекты. Я вижу, что об этом вспоминают на втором году жизни пути, когда расхождение уже накопилось; закладывать стоит сразу.
CI-проверка самого пути — регулярный прогон, который создаёт из шаблона рабочий сервис на чистом окружении. Самый недооценённый инструмент: без него путь тихо ломается на очередном обновлении зависимостей и обнаруживается новичком в худший момент.

Best practices

Два самых известных публичных примера пришли к одному правилу независимо. Netflix в 2018 описал paved road как набор инструментов и практик, который централизованные команды поддерживают, но не навязывают: на него переходят потому, что с ним заметно лучше, чем без него. Spotify в 2020 сформулировал то же про golden paths — сойти с пути можно, но тогда не будет той же поддержки, а «blessed» инструменты видны в Backstage, то есть выбор остаётся видимым и осознанным. Обе компании могли сделать путь обязательным. Не сделали. Я считаю это главным аргументом в спорах, где обязательность предлагают как способ ускорить адаптацию.

Дальше три правила, на которых я не готов торговаться. Путь — это код: версия, тесты, ревью, changelog. Шаблон, который никто не собирает на чистом окружении, сломан по умолчанию, и узнают об этом не авторы, а первый новичок, которому не повезло. Выход проектируется вместе со входом — что можно заменить, что теряется вместе с заменой, кто об этом узнает. И обрыв в середине хуже, чем отсутствие пути вовсе: либо доводим до работающего результата, либо честно рисуем границу, где путь заканчивается и начинается своя работа.

На путь переходят из-за разницы в удобстве, а не по мандату. Если по пути идут только потому, что иначе не согласуют выкат, обратная связь исчезает: жаловаться некому и незачем. Дальше путь деградирует незаметно, потому что единственный сигнал о его качестве — добровольный выбор команд — выключен. Я регулярно вижу, как обязательность вводят ради быстрых цифр внедрения и через год получают путь, которым все пользуются и все недовольны.

Главная незакрытая проблема путей — расхождение поколений. Сгенерировать сто сервисов из шаблона легко. Вопрос в том, что происходит, когда шаблон изменился, а сто сервисов остались на старой версии. Обновление шаблона и миграция созданного — две разные работы с разной стоимостью, и вторую почти всегда недооценивают. По моим наблюдениям, именно здесь пути и умирают: не от плохого дизайна, а от того, что через два года «типовых» сервисов пять разных поколений и ни одно не типовое.

Про границу применимости. Путь окупается там, где сценарий повторяется достаточно часто, чтобы стоимость сопровождения делилась на много команд. Для сценария, который случается пару раз в год, дешевле помочь руками и записать, как сделали. Team Topologies формулирует общее правило жёстче: платформа остаётся тонкой, потому что каждый лишний обязательный шаг оплачивают все, кто по ней идёт.

Связанные листья

Platform as a Product — путь живёт по продуктовым правилам: у него есть пользователи, владелец и условие вывода из эксплуатации.
CI/CD — конвейер как обязательная часть пути; заодно место, где сам путь проверяется на собираемость.
Infrastructure as Code — модули и манифесты, из которых путь собирается; версионирование шаблона наследует те же практики.
Toil Automation — источник сценариев для путей: повторяющийся ручной запрос и есть кандидат.
Service Ownership — сгенерированный сервис получает владельца в момент создания, иначе путь производит бесхозные сервисы быстрее, чем раньше их создавали руками.

Открытые вопросы

Как честно измерять, что путь остаётся выгоднее альтернатив, когда альтернативы никто не пробует? Доля прошедших по пути этого не показывает.
Чем должно заканчиваться расхождение поколений шаблона: принудительной миграцией, длинной поддержкой нескольких версий или признанием, что старые сервисы сходят с пути навсегда. У меня нет ответа, который бы не упирался в стоимость.
Нужен ли отдельный лист про шаблоны и генерацию заготовок как технику, или это часть этого листа.