Платформенные команды: когда создавать и как не облажаться

Платформа, которую никто не хотел

Компания растёт. Stream-aligned команд становится десять, потом двадцать, каждая решает одни и те же инфраструктурные задачи: настраивает CI/CD, пишет Terraform-модули, разбирается с секретами и мониторингом. Руководство видит дублирование и собирает платформенную команду. Через год команда превращается в очередь заявок, разработчики ждут неделю, чтобы получить namespace в Kubernetes, и времена «каждый делал сам» вспоминаются с ностальгией. История повторяется в сотнях компаний. Корень почти всегда один — платформу собрали раньше времени, без понимания, зачем она нужна и кому служит.

Эван Ботчер сформулировал определение, которое стоит повесить на стене в каждом инженерном офисе: «Цифровая платформа: фундамент из self-service API, инструментов, сервисов, знаний и поддержки, организованных как привлекательный внутренний продукт». Self-service — разработчики получают нужное без ожидания и согласований. Привлекательный — команды выбирают платформу добровольно.

Тонкая платформа vs толстая

Скелтон и Пайс в Team Topologies ввели понятие Thinnest Viable Platform (TVP) — минимальная платформа, которая решает реальные проблемы команд. В маленькой компании TVP вполне может выглядеть как страница в корпоративной вики с описанием «используем AWS, вот эти сервисы, вот так их конфигурируем». Никакого кода, никакого портала. Документ и набор договорённостей.

По мере роста организации платформа утолщается: появляются шаблоны для создания сервисов, shared-библиотеки, внутренний developer portal, golden paths для типовых сценариев. В крупной компании толстая платформа разрастается до экосистемы из нескольких платформенных команд, каждая владеет своим слоем — compute, data, observability, security.

Типичная ошибка — перепрыгивать этапы. Компания на 50 разработчиков строит портал уровня Backstage с каталогом сервисов, системой плагинов и кастомным UI, хотя реальная потребность — три Terraform-модуля и стандартный Helm-чарт. Платформа должна расти вместе с организацией, а не опережать её.

Платформа как редуктор когнитивной нагрузки

Главная метрика успеха платформенной команды — снижение когнитивной нагрузки на stream-aligned команды. Точнее, снижение extraneous load, той части нагрузки, которую создаёт инфраструктурная возня.

Когда разработчик из продуктовой команды тратит два дня на настройку Datadog для нового сервиса, это extraneous load в чистом виде. Платформенная команда делает эту работу один раз, заворачивает в self-service (один YAML-файл в репозитории сервиса — мониторинг готов), и сорок продуктовых команд получают эти два дня обратно.

Платформа как продукт подразумевает, что платформенная команда исследует потребности пользователей, собирает обратную связь, приоритизирует фичи и измеряет adoption. Команда, которая строит платформу в вакууме без разговоров с разработчиками, собирает инструмент, которым никто не пользуется.

Четыре антипаттерна платформенных команд

Очередь заявок. Команда принимает запросы и выполняет их руками. Разработчики ждут, когнитивная нагрузка перераспределяется, но никуда не девается. Запрос, который повторяется больше трёх раз, должен быть автоматизирован.

Обязательная платформа. Руководство приказывает использовать платформу, даже если она хуже того, что команды собирали сами. Разработчики находят обходные пути, доверие падает. Платформа должна конкурировать качеством, а не административным ресурсом.

Когнитивная перегрузка самой платформенной команды. Три инженера отвечают за CI/CD, Kubernetes, мониторинг, секреты, сети и базы. Они тонут в extraneous load и не успевают строить self-service. Выход — сузить скоуп или вырастить платформу в группу специализированных команд.

Платформа ради платформы. Команда строит красивый портал и стройные абстракции, которые никому не нужны. Каждая фича платформы обязана отвечать на вопрос: какую проблему какой команды это решает.

Когда создавать платформенную команду

Универсального правила нет, но есть набор сигналов. Несколько stream-aligned команд тратят заметную долю времени на одни и те же инфраструктурные задачи. Онбординг новых разработчиков занимает недели из-за сложности инфраструктуры. Команды делают одно и то же по-разному, и это бьёт по безопасности или надёжности. Разработчики жалуются на когнитивную перегрузку от инфраструктурных задач.