Комментарии 2
Большое спасибо за интересную статью!
Есть несколько вопросов - поделитесь опытом, пожалуйста:
Про поддержку.
По пути к светлому будущему у вас наверняка было 2 больших направления - разработка нового решения и поддержка старого зоопарка. Как с этим справлялись? Какие подходы? Это делала одна команда - и поддержку, и развитие платформы? Или разные?
Про ресурсоемкость
Из статьи вижу порядка 2000 сервисов, срок прихода к светлому будущему - 2 года. Полагаю, что языки разработки/флоу - тоже имеют небольшую вариативность.
А какой размер команды это все делал (платформу и поддержку)? Хотя бы ориентир - 2-3, 5-7, 10+ ?
Про backstage - а чем обсуловлен выбор собственного решения? Так исторически сложилось или есть какие то грабли/нюансы с backstage?
Судя по тому, что вы там храните - возможно backstage не покрывал ваши запросы?
Я тоже стою перед backstage и думаю с какой стороны к нему подступится.
Про метрики - тоже инетересно. В конце указано TTM, и это вполне логично (субъективно), что автоматизации и быстрый CI/CD явно быстрее ручных вариантов, но как замерялось влияние именно инфраструктуры на TTM (объективно)? Создание нового сервиса - да, померить можно - вначале ручками через кучу заявков создавали 3 дня, а через автоматику за 5 минут. Но замерлся ли остальной процесс - linter/unit/тесты, доставки кода по контурам, автоматические релизы? Именно в контексте метрики TTM. Если да - было бы круто узнать чуть больше деталей.
Про поддержку: делала одна команда, для переезда мы делали автоматические скрипты, которые большинство рутинных задач переезда покрывали. Далее нужно было овнеру сервиса провалидировать, пройти тесты и перейти на новые рельсы.
Про ресурсоемкость: в разное время было разное количество, на старте было всего несколько инженеров, далее уже команда росла до десятков инженеров.
Backstage был на раннем этапе развития, совсем не популярен, поэтому тогда даже не рассматривали. Плюс мы недавно ресерчили его возможности и применимость: к сожалению всё еще очень базовый фреймворк, который сильного ускорения, на наш взгляд, не даёт. Что важно: не закладывает каких-то явных ограничений на построение платформы, скорее общий layout и component ownership система с возможностью писать свои плагины-экраны, вместе с этим еще решая проблемы производительности (пробовали туда наш набор сущностей загрузить).
Про метрики: по прокси метрикам: количеству релизов, времени на все фазы, которые идут вне машины разработчика. Базовые DORA метрики. Плюс смотрели, например, TTM подключения базы и подобных "выколотых" кейсов, где мы видели проблемы (например, неделя на настройку). Далее это просто масштабировали на компанию и value как метрика adoption.
Построение платформенного продукта в Авито