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

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

Организация растёт, 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 с каталогом сервисов, системой плагинов и custom UI, хотя реальная потребность заключается в трёх Terraform-модулях и стандартном Helm-чарте. Платформа должна расти вместе с организацией, а не опережать её.

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

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

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

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

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

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

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

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

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

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

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