Spotify → Backstage: от внутреннего инструмента к стандарту индустрии
Как Spotify построил developer portal для 2700 инженеров и превратил его в CNCF-проект с двумя миллионами пользователей
Контекст: автономия, которая перестала помогать
В 2016 году в Spotify было больше 200 инженерных команд. Каждый «сквод» выбирал инструменты, процессы и способ документирования на своё усмотрение. Скорость старта это давало, но порождало проблему, которую внутри окрестили rumour-driven development: о существовании сервисов, API и внутренних инструментов узнавали от коллег за обедом или в корпоративном чате. Документация лежала в десятках систем. Каталога сервисов не существовало. Новый инженер тратил недели, чтобы разобраться, что есть и кто за это отвечает.
К 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 перенёс документацию из вики и облачных документов к коду. Инженеры писали 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 вырос из обычного каталога сервисов. «Единый портал для всего» в первый день никто не строил. Каталог дал ценность сразу — сервисы и владельцы находились, а не угадывались. Templates и TechDocs пришли позже, когда каталог доказал полезность.
Автономия и стандартизация совместимы. Свободу выбора инструментов у сквадов не отбирали. Backstage создал golden paths — шаблоны, которые инженеры использовали добровольно, потому что они экономили время. Принуждение не понадобилось.
Платформенная команда обязательна. Как и любой IDP, Backstage требует людей: настройка, поддержка, обновления, плагины. Spotify выделил отдельную команду и со временем дорастил её до целого подразделения. Организация, которая ставит Backstage с расчётом «само заработает», разочаруется через полгода.