Spirit: внутренняя платформа как продукт

Александр представляет гостя: Дима Гаевский давно работает в компании и сейчас исполняет роль архитектора и технического продакта всей платформы для разработчиков Spirit; сам Дима добавляет, что Spirit — часть большего подразделения, отвечающего за базу инженерной практики. Свой путь Дима начинал у подрядчика, работавшего с компанией: примерно в середине 2017 года его нанимали в команду привлечения, которой тогда руководил сам Александр. Первая инженерная работа была негероической — он приводил в порядок монолит, обслуживавший большую часть неавторизованной зоны, много писал SQL и, по его словам, познал много печали. В январе 2018 года переехал из Петербурга в Москву и включился в распил этого монолита на микросервисы одновременно с переносом нагрузок в Google Kubernetes Engine. К концу 2019-го решил уйти в платформу, которой тогда ещё не существовало, и два года руководил её PaaS-частью — консолью и core-сервисами, работающими клеем. Потом команду пересобрали: по рассказу Александра, один Станислав ушёл, а второй вместе с Димой поделили техническую и продуктовую половины развития платформы. Александр советует посмотреть первый выпуск подкаста с тем самым Станиславом — там много говорили про топологию команд.

Отдел у Димы смешанный, не чисто продуктовый: системные аналитики, открытые позиции технических продактов, которые займутся пользовательскими историями и продуктовым дискавери, редакция, отвечающая за редакторский процесс и всю пользовательскую документацию платформы, и команда поддержки из нескольких человек — она разбирается с пользователями, когда что-то работает не так или просто непонятно. На вопрос Александра, есть ли в редакции функция пропаганды, Дима отвечает, что это скорее информирование: ежемесячные встречи с рассказом про фичи и канал с анонсами, на которые можно подписаться. Технический продакт в компании, объясняет он, — это в первую очередь инженер или бывший инженер с широким кругозором, ушедший в продукт: кандидат проходит и систем-дизайн, и продуктовую секцию. Дима признаётся, что считал такого человека единорогом, — и оказался неправ: желающих нашлось немало, включая довольно хардкорных инженеров.

Портфель Дима разбирает по схеме подразделения, оговариваясь, что Spirit давно не одна большая штука, а система: команда отвечает за компоненты, которые участвуют в SDLC и дальше в эксплуатации. Домен develop и build сейчас держится на развёрнутой у себя community-редакции GitLab — там лежит весь код, разработчик создаёт приложение из шаблона или пустой репозиторий, проходит ревью, туда же интегрированы инструменты безопасности, а сборки идут на GitLab CI; сам GitLab постепенно хотят заменить собственным инхаус-решением, а сборочную часть — со временем развить во что-то другое. Ниже блок delivery и rollout: продукт deploy — централизованная поставка приложений и управление релизами, замысел которого появился давно, а делают его недавно, — и свой container registry, который должен вырасти в реестр контейнеров и пакетов. Рядом лежат ресурсы для рантайма, которые пишут команды IT-инфраструктуры внутреннего облака, а также надёжность на базе Kubernetes, управление доступами и квотами и движок, отслеживающий во всех репозиториях изменения определённых типов манифестов.

Отдельный сюжет — контрибуция чужих команд: по такой модели, например, живут управляемые базы данных. Идеология разработки экосистемы формализована, а гайд для контрибьюторов местами мог бы уместиться в небольшую книгу, но Дима подчёркивает, что не закрывается ни документацией, ни тикетами: запрос всё равно приходит к нему. Дальше обсуждают, укладывается ли он в продуктовую стратегию, под какие сценарии и профиль нагрузки подходит новая база, насколько развиты её инструменты и как выбор ложится на целевой технический радар — потому что новая опция для пользователя бывает и вредной, если плохо поддержана. Помогают команды компонентов (сейчас это россыпь маленьких микросервисов с API, в будущем возможны операторные решения, сводящие всё к контроллерам в Kubernetes), интерфейсные команды и фронтенд, а с внешними командами Дима проводит event storming, чтобы смоделировать и сразу зачелленджить целевой сценарий вместе со всеми стейкхолдерами.

Продакт нужен не в каждом блоке платформы: на deploy с его движущимися частями, сценариями и хотелками — да, а рантайм-инфраструктуру ведёт инженер, который сам понимает домен и его ограничения; сейчас у Димы открыты две позиции. Основное время уходит на дизайн фич и ревью вместе с командами Spirit и инфраструктуры, продуктовые исследования — например регулярное исследование ландшафта приложений компании, — сквозные проекты, встречи с пользователями и стратегические сессии; около 20% занимает проектирование, потому что продукт технический. Идеальная картина другая: человек, формирующий vision, должен иметь кругозор и заниматься стратегией, а не дизайнить почти каждую фичу; но это, оговаривается Дима, пока гипотеза, которую надо проверить, набрав помощников. Роли, добавляет он, размыты, особенно в России: архитектор в двух компаниях может означать кардинально разное.

Александр приносит свою боль: вечером решаешь задачку, тест зеленеет — и ты сразу молодец, а RFC про изменение работы команд имплементируют полгода и ещё полгода собирают обратную связь. Дима отвечает, что нужна концептуальная модель, которая говорит, что ты делаешь хорошие вещи, и продуктовые практики, возвращающие сигнал раньше: метрики, исследования и процесс adoption, когда сырую фичу сначала отдают инноваторам, готовым страдать вместе с командой. Его взгляд на RFC изменился: неправильно применённые, они удлиняют путь к результату, а каскад тикетов и эпиков теряет контекст на каждой передаче, поэтому впереди процессов он ставит коммуникацию. Отсюда и разница между внутренней и публичной платформой: публичную меряют проданными ресурсами и подобными метриками, а внутренняя отвечает за то, что получится у разработчиков и как выбор ляжет на технический радар компании. В финале Дима советует не книги, а принципы: чаще челленджить свои решения, рационально относиться к компромиссам, учиться не только по конференциям, но и в разговорах с друзьями из зарубежных компаний и в open source, и знать своего клиента даже когда просто пишешь библиотеку.