Spotify: Backstage и измерение DX

Проблема, которую все чувствовали, но никто не называл

В 2016 году Spotify нанимал инженеров пачками. Компания росла, количество микросервисов перевалило за тысячу, и каждая автономная команда («сквад» в терминологии Spotify) строила свои инструменты под себя. Один сквад заводил сервис через Terraform, другой писал скрипты на Bash, третий поднимал инфраструктуру через внутреннюю CLI-тулу, про которую знали три человека. Новый инженер приходил в компанию и тратил первые недели на один вопрос: «Где что лежит и кому это принадлежит?».

Тайлер Мелтон, один из ранних участников проекта, рассказывал, как команда Platform Experience начала с аудита: подсчитали, сколько внутренних инструментов инженеры используют ежедневно. Число оказалось шокирующим. Десятки разрозненных UI, документация в пяти разных системах, CI-пайплайны в трёх разных тулах. Автономия, которой Spotify славился, обернулась фрагментацией. Каждый сквад работал быстро внутри своего контекста, но любое межкомандное взаимодействие превращалось в археологию.

Backstage как ответ

Команда Platform Experience решила строить внутренний портал разработчика — IDP. В основу легли четыре принципа, описанные в инженерном блоге: единая точка входа для всей инфраструктуры, плагинная архитектура (команды могут добавлять свои инструменты без разрешения центральной команды), каталог сервисов как ядро системы и golden paths для типовых сценариев.

Каталог сервисов стал фундаментом. Каждый компонент в Spotify получил запись в каталоге с владельцем, документацией, CI-статусом, зависимостями и API-спецификацией. Чтобы узнать, кто отвечает за конкретный сервис, инженер открывал Backstage вместо того, чтобы писать в пять чатов мессенджера.

Плагинная архитектура позволила масштабировать портал без бутылочного горлышка в виде одной центральной команды. По данным Spotify, более 200 инженеров внутри компании написали фичи для Backstage, 50+ команд создали 120+ плагинов, 80% кода пришло от людей за пределами ядровой команды Backstage. Здесь критическая точка: портал выжил и расцвёл, потому что команда Backstage отдала контроль.

Метрики и результаты внутри Spotify

После внедрения Backstage время онбординга новых инженеров сократилось вдвое. Около 50% всех сотрудников компании (не только инженеров) используют Backstage ежемесячно, большинство инженеров заходят туда каждый день.

Команда Backstage отслеживает adoption через несколько сигналов: частоту создания новых компонентов через golden paths, процент сервисов в каталоге с заполненной документацией, количество поисковых запросов через каталог и NPS внутренних пользователей. От привязки Backstage к метрикам вроде DORA Lead Time сознательно отказались: слишком много факторов влияют на скорость доставки, чтобы выделить вклад одного инструмента. Фокус на proxy-метриках: сколько времени инженер тратит на поиск информации, как часто обращаются к каталогу вместо чата и сколько новых сервисов создают через стандартные шаблоны.

Open source и масштаб

16 марта 2020 года Spotify опубликовал Backstage как open source проект. За пять лет платформу приняли более 3400 организаций, включая Airbnb, LinkedIn, Twilio и American Airlines. Проект собрал более 2200 контрибьюторов. CNCF назвал Backstage одним из пяти самых активных проектов по velocity.

Adoption в open source оказался сложнее, чем внутри Spotify. Вице-президент по инженерии Spotify отмечал: во многих организациях реальное использование Backstage застревает ниже 10%, даже если компания формально «приняла» инструмент. Backstage требует серьёзных инвестиций в плагины и интеграции, без них портал превращается в пустую оболочку, куда никто не заходит.

Уроки и trade-offs

Внутренний портал разработчика работает, когда его строят как продукт для инженеров, а не как административную панель для менеджмента. Команда Backstage наняла продуктовых менеджеров, дизайнеров, проводила user research с внутренними пользователями. К инженерам относились как к клиентам, а не как к пользователям, обязанным использовать инструмент.

Главный trade-off: плагинная архитектура даёт гибкость, но создаёт проблему качества. Когда 50 команд пишут плагины, уровень документации и поддержки неизбежно неравномерен. Spotify закрывает это внутренними стандартами и ревью, в open source экосистеме проблема стоит острее.