Представьте типичную продуктовую команду. У них все просто и понятно: вот бэклог, вот новые фичи, вот спринты, а в конце довольный бизнес считает прибыль. Метрики эффективности прозрачны: выпустили фичу вовремя, и если за ней не последовал шлейф багов, все молодцы.
А теперь представьте команду внутренней Платформы. Они не создают продукт для внешних заказчиков. Их клиенты — это соседние отделы разработки. И когда платформа работает идеально, ее никто не замечает. Но если нет, разработчики фич тихо страдают.
Команда Платформы и ее продукт
Меня зовут Станислав Решетнев, я руковожу отделом разработки в Sape (направление Link Building). Внутри нашей структуры есть та самая команда Платформы, которая упрощает жизнь продуктовым командам.
Чтобы понять особенности их работы, давайте посмотрим на цели команд:
Основным продуктом команды Платформы является IDP (Internal Developer Platform) — набор инструментов разного уровня, обобщенных лучших практик, сервисов и т.п. Его главная цель — упростить и ускорить процесс создания, тестирования и запуска программного обеспечения. IDP можно понимать достаточно широко, и меня всегда радует, что здесь есть простор для творчества.
Задачи у Платформенной команды бывают разные, разделим их условно на четыре типа.
1. Поиск универсальных решений для рутины, которая раздражает разработчиков
Например:
быстрое разворачивание микросервиса;
написание OpenAPI-спецификаций через ИИ-агента;
автоматизированная отправка технических метрик и т.п.
2. Поиск точечных решений проблемы продуктовой команды
Например:
сделать ИИ-бота, оставляющего комментарий с решением бага на основе решений из предыдущих тикетов;
создать нейро-ревьюера.
3. Ускорение цикла разработки SDLC через аналитику
Если процесс разработки прозрачен и хорошо отслеживается (логируется время, отмечаются переходы статусов тикета «В работу», «В ревью»), можно ускорять цикл разработки SDLC, приглядевшись к аналитике. Причем платформизация (сама система IDP) уже делает процессы более универсальными и ускоряет этапы разработки.
4. Обеспечение актуальности техстека
С одной стороны, это может показаться задачей DevOps. Но что, если речь идет не о переходе на новую мажорную версию базы данных, а о ее замене на другую? Это уже не просто обновление, а пересборка архитектуры.
А что, если у команд возникла потребность в чем-то принципиально новом, например, в автомасштабируемой базе данных, чтобы не беспокоиться об объемах хранения? В таком случае команда Платформы берет на себя всё:
провести исследование;
создать рабочий прототип;
качественно запустить новую БД;
провести обучение;
написать документацию;
передать мониторинг админам;
отдать SRE-отделу алгоритм диагностики проблем и реагирования.
Постановка целей на год по OKR
Наша компания уже некоторое время работает по методологии OKR (Objectives and Key Results), и мне было интересно продумать, как команда Платформы может не отставать от других отделов и тоже ставить перед собой амбициозные цели. У разработчиков всегда много идей, а текучка способна поглотить любое количество ресурсов. Хотелось сделать так, чтобы команда Платформы вносила свой вклад в достижение общей цели компании так же, как это делают продуктовые команды.
Подойти к планированию я решил через риск-менеджмент. Поскольку Платформа должна помогать разработке не только ускоряться, но и не останавливаться из-за внезапно реализовавшихся рисков, важно заранее понять, с какими вызовами мы можем столкнуться в следующем году. При этом риск может быть не только в 0-day баге, который неожиданно требует срочного внимания, но и, например, им может оказаться устаревшая архитектура, из-за которой мы не сможем реализовать ожидаемые фичи.
В риск-менеджменте распространен подход оформлять такие вызовы в виде таблицы. В ней фиксируется сам риск, его вероятность, потенциальное влияние на систему и варианты действий в случае возникновения (митигация). У нас получилось примерно так:
Может показаться, что к нам заглянул Капитан Очевидность, но ценность такого подхода в системности: заранее осмыслить возможные проблемы, увидеть наиболее востребованные решения и сфокусироваться на них. Причем такой анализ не обязательно каждый раз запускать с нуля. Его можно обновлять при очередном планировании по OKR.
С учетом этих рисков был составлен черновик дерева OKR команды Платформы (привожу его здесь в общем виде, без деталей):
Основными целями стали:
O: снять блокеры и риски технологического характера
KR1: отсутствуют репорты по критическим уязвимостям из техстека в пределах Платформы
KR2: количество технологических блокеров сокращено минимум на 1
O: сократить расход времени на обслуживание в Links
KR1: снижено время на решение bugs
KR2: снижено время на решение service requests
O: ускорить процесс разработки в Sape (пользователи Платформы)
KR1: типовой этап разработки ускорен в среднем на 30%
KR2: скорость доставки на prod увеличена на 30%
На первый квартал по каждой цели были выбраны подцели, которые наиболее заметно влияют на результат (на схеме они отмечены зеленым):
O: своевременно обновлять технологический стек
KR1: техстек полностью описан
KR2: есть общедоступный roadmap обновлений, который поддерживается и доводится до команд, использующих продукты Платформы
KR3: 80% приложений Платформы обновляются по SLA
O: ускорить решение багов за счет улучшения наблюдаемости через Data Platform
KR1: появился инструментарий для 3 наиболее проблемных участков
KR2: время решения багов в legacy-бэкенде сокращено на 30%
O: ускорить создание прототипов приложений (research, early MVP)
KR1: половина прототипов создается с помощью универсального инструмента
KR2: запущен один early MVP при помощи универсального инструмента
Кстати, на этапе черновика удобно формулировать KR тезисно, в общем виде, а уже после принятия цели можно переводить их вместе с командой в конкретные технические метрики.
Как видно, цели напрямую связаны с рисками из таблицы выше. Интересно, что на основе этого дерева и инициатив (на схеме они отмечены желтым и заботливо заблюрены) были отобраны технологии.
Оказалось, что часть технологий работает сразу на несколько целей, а значит, мы можем таким образом определить приоритетность их внедрения. Например, n8n оказалась полезной и как инструмент для упрощения запуска MVP, и как средство автоматизации сбора метрик для OKR и других управленческих задач.
Хотя n8n в Sape используется давно, стало очевидно, что нам он нужен в масштабируемом варианте. А значит, пора переходить на кластерную версию и проводить полноценную внутреннюю раскатку: обучать, документировать и помогать с первыми внедрениями разработчикам и менеджерам.
С целями определились, но дальше возникает следующий вопрос: как их оцифровать?
Метрики Платформы
Поделюсь тем, как мы измеряли не самые очевидные платформенные метрики.
Одна из них — «Показатель платформизации». Он отражает степень переиспользования компонентов IDP. Например, для нас важно, чтобы по всей компании использовался единый шаблон микросервиса, а от самодельных решений команды постепенно отказывались. Подобные метрики, скорее всего, придется периодически собирать вручную. Но программисты не были бы программистами, если бы не задались вопросом: а что из этого можно оцифровать и автоматизировать?
Возьмем в качестве примера метрику «Актуальность техстека». Она относится к следующей цели:
O: своевременно обновлять технологический стек
KR2: по всем компонентам техстека обновления происходят в общесистемном порядке до окончания срока поддержки ПО
Мы выстроили процесс, в котором ведем список компонентов техстека и для каждого задаем SLO на обновление — предельный срок после появления версии LTS, к которому компонент должен быть обновлен. После завершения обновления сразу планируется следующее — пусть даже с ориентировочной датой, которую позже можно уточнить.
В результате сформировалось инфополе, на основе которого мы рассчитали общий процент обновления компонентов по SLA и вывели его на верхнеуровневый дашборд:
Еще одна метрика — «Критические уязвимости». Она описывает следующий KR:
O: знаем о критических уязвимостях нашего техстека
KR2: автоматически собираются оповещения о критических проблемах по техстеку
Это бинарный KR, который подразумевает создание системы сбора уведомлений о найденных проблемах в используемых нами компонентах. Здесь мы полагаемся на базу уязвимостей National Vulnerability Database (NVD) и регулярно отслеживаем появление новых тикетов.
На инфополе выводится количество найденных уязвимостей за последний месяц:
Кстати, это и другие инфополя и метрики мы собираем с помощью n8n. Подробнее об этом я рассказывал в статье «Как быстро построить метрики для измерения эффективности разработчиков: готовое решение».
В заключение
В IT крайне важно системно ставить цели, задавать критерии успеха и наблюдать за прогрессом через измеримые показатели. Надеюсь, наш опыт поможет вам выстроить собственную платформенную команду со своими уникальными задачами, подходами и целями.
А какие платформенные решения используете вы? И как измеряете результаты платформенной разработки?