Spotify → Backstage: от внутреннего инструмента к стандарту индустрии

Контекст: автономия, которая перестала помогать

В 2016 году Spotify насчитывал больше 200 инженерных команд. Каждый «сквод» выбирал инструменты, процессы и способы документирования на своё усмотрение. Модель давала скорость старта, но породила проблему, которую внутри компании окрестили rumour-driven development: люди узнавали о существовании сервисов, API и внутренних инструментов от коллег за обедом или в Slack-каналах. Документация лежала в десятках систем. Каталога сервисов не существовало. Новый инженер тратил недели, чтобы разобраться, какие сервисы есть и кто за них отвечает.

К 2020 году масштаб разросся до 2000+ бэкенд-сервисов, 300+ веб-сайтов, 4000+ дата-пайплайнов и 200+ мобильных фич. Инженер, который хотел создать новый сервис, открывал несколько инструментов для CI, отдельную систему для мониторинга, третью для документации, четвёртую для управления инфраструктурой. Переключение контекста между инструментами съедало часы каждый день.

Проблема: фрагментация убивает продуктивность

Spotify измерял разработческий опыт через внутренние опросы и количественные метрики. Вот что они увидели. Онбординг нового инженера до момента десятого пулл-реквеста занимал больше 60 дней. Инженеры тратили значительную часть времени на поиск информации: кто владелец сервиса, где документация, какой пайплайн отвечает за деплой. Создание нового сервиса по стандартам компании требовало ручной работы и копирования бойлерплейта из чужих репозиториев.

Фрагментация росла пропорционально числу команд. Каждая новая команда приносила свои инструменты и свои подходы, и разрыв между «знаю, как работает мой сервис» и «знаю, как работает инфраструктура Spotify» увеличивался.

Решение: один портал для всего

Команда платформенных инженеров Spotify начала строить Backstage как единую точку входа для инженерной экосистемы. Три базовых компонента определили архитектуру.

Software Catalog стал центром. Каждый сервис, библиотека, API, дата-пайплайн получил файл catalog-info.yaml в репозитории. Backstage читал эти файлы и строил граф: кто владелец, какие зависимости, где CI-пайплайн, где алерты. Инженер открывал страницу сервиса и видел всё на одном экране.

Software Templates (Scaffolder) закрыли проблему создания новых компонентов. Платформенная команда описывала шаблоны: «Backend Service на Java», «Data Pipeline на Spark», «React-приложение». Инженер заходил в /create, выбирал шаблон, заполнял форму, нажимал кнопку. Через минуту у него был репозиторий с CI-пайплайном, мониторингом и записью в каталоге. Все стандарты компании заложены в шаблон, и разработчику не нужно думать о бойлерплейте.

TechDocs перенёс документацию из Confluence и Google Docs к коду. Инженеры писали Markdown рядом с исходниками, а Backstage генерировал страницы и показывал их в портале.

Результаты: цифры из Spotify

Spotify опубликовал метрики Backstage-пользователей в сравнении с теми, кто порталом не пользовался.

Инженеры, которые работали через Backstage, были в 2.3 раза активнее на GitHub. Они создавали в 2 раза больше code changes при 17% меньшем cycle time. Они деплоили софт в 2 раза чаще, и их деплойменты работали в 3 раза дольше (то есть реже откатывались).

Онбординг ускорился радикально: время до десятого пулл-реквеста сократилось с 60+ дней до 20. Снижение на 55%.

К 2025 году 2700 инженеров Spotify используют Backstage каждый день для работы с 14 000+ программных компонентов.

Open source и CNCF

В марте 2020 года Spotify выложил Backstage в open source. В сентябре того же года CNCF принял проект в sandbox, в 2022-м перевёл в incubation. К пятилетнему юбилею в 2025 году Backstage вырос до 2 миллионов разработчиков в 3400+ организациях: Airbnb, LinkedIn, American Airlines, Twilio, LEGO, Booking.com. В 2023 году проект набрал больше коммитов, чем любой другой CNCF-проект.

Spotify запустил Spotify for Backstage как коммерческое предложение: хостинг, дополнительные плагины, enterprise-поддержка. Компания превратила внутренний инструмент в бизнес.

Уроки

Измеряйте до и после. Spotify сравнивал поведение инженеров через Backstage с контрольной группой. Без таких данных сложно доказать ценность портала руководству и обосновать инвестиции в платформенную команду.

Начинайте с каталога. Backstage вырос из простого каталога сервисов. Spotify не пытался построить «единый портал для всего» в первый день. Каталог дал ценность сразу: инженеры находили сервисы и владельцев, а не гадали. Templates и TechDocs появились позже, когда каталог доказал свою полезность.

Автономия команд и стандартизация совместимы. Spotify не отобрал у сквадов свободу выбора инструментов. Backstage создал «мощёные дорожки» (golden paths): шаблоны, которые инженеры хотели использовать, потому что те экономили время. Принуждение не потребовалось.

Платформенная команда обязательна. Как и любой IDP, Backstage требует людей для настройки, поддержки, обновлений, написания плагинов. Spotify выделил отдельную команду, и со временем вырастил её до целого подразделения. Организация, которая ставит Backstage и ожидает, что он заработает сам, разочаруется через полгода.