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

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

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

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

Backstage как ответ

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

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

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

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

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

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

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

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

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