50-минутный доклад Макса Кёрбахера на InfoQ Dev Summit Munich сводится к неприятной, но полезной мысли: platform engineering проваливается не из-за неправильного кластера, а из-за неправильной логики сборки. Если внутренняя платформа начинается с Kubernetes, портала и списка модных инструментов, а не с нужд команд, она быстро превращается в дорогую декорацию для IT-отдела.
Как пишет InfoQ, Кёрбахер, основатель и технологический советник Liquid Reply, CNCF Ambassador и автор книги Platform Engineering for Architects, разбирает типичный сценарий неудачи внутренней платформы. Компания стартует не с продукта, а с витрины: ставит developer portal, чаще всего с оглядкой на Backstage, потому что «это же Spotify». Дальше выясняется скучная часть: сам по себе портал пуст, первая полезная интеграция требует нескольких инженеров и месяцев настройки, а обещанная польза все еще где-то в будущем. Отсюда знакомый набор симптомов: слабое внедрение, завышенные ожидания менеджмента, промах мимо реальных потребностей разработчиков и ощущение, что денег сожгли больше, чем проблем решили.
Главный тезис доклада бьет по старой привычке инфраструктурных команд мыслить снизу вверх. Кёрбахер называет это infrastructure-first thinking: сначала архитектурные решения, потом стек, потом инструменты, а пользователь как-нибудь приложится. Формально все выглядит разумно. На практике команда собирает платформу, которая нравится инженерам, любящим инфраструктуру ради инфраструктуры, но не тем, кто потом будет через нее выпускать сервисы, чинить инциденты или проходить комплаенс. Отсюда и его довольно едкое наблюдение: platform engineering часто делают бывшие DevOps-команды, просто с новым шильдиком. Сердце по-прежнему тянется к железу, GitOps и облачным схемам, а не к исследованию того, как люди реально работают.
На этом фоне он довольно жестко проходится по корпоративному «сдвигу влево». Когда на разработчика заодно перекладывают CI/CD, observability, tracing, security и compliance, это продают как зрелость инженерной культуры. По факту нередко выходит просто новый способ размазать операционные задачи по всем командам. В средних и крупных компаниях проблема усиливается организационной турбулентностью: одна волна ведет к унификации, следующая реорганизация снова разносит ландшафт по разным углам, а затем приходит очередной хайп. Десять лет назад им был IoT, потом тотальная контейнеризация, теперь AI. Каждая такая волна тащит в платформу новые инструменты и новые «обязательные» практики, даже если у бизнеса и команд на них нет внятного запроса. В итоге растут дублирование, patchwork-архитектура и теневой IT, когда команды оплачивают внешние сервисы корпоративной картой просто потому, что внутри быстрее не получается.
Противоядие, по Кёрбахеру, довольно приземленное и потому редко любимое технарями: относиться к платформе как к продукту. Не как к проекту с дедлайном, после которого можно торжественно разрезать ленточку и уйти, а как к продукту с пользователями, сценариями, стоимостью владения и постоянной обратной связью. У платформы должна быть не только миссия в духе «ускорим delivery», но и конкретная цель: для кого она строится, какую проблему убирает, почему этой проблемой вообще стоит заниматься. В докладе он отдельно подчеркивает, что пользователи платформы — это не только разработчики. Туда же попадают безопасность, комплаенс, продакты, а иногда и бизнес-руководители, если через платформу они получают отчеты о деплоях, использовании сервисов и состоянии инженерного ландшафта. Логика простая: если платформой никто не хочет пользоваться добровольно, это не продукт, а просто инфраструктура. А инфраструктура без принятия со стороны команд редко становится любимым корпоративным сервисом.
Отдельный сильный блок доклада посвящен метрикам, и здесь Кёрбахер заходит с позиции, которая многим CTO и head of engineering может не понравиться. Он прямо говорит, что компании слишком поздно начинают измерять эффект платформы: сначала запускают ее, а потом пытаются придумать, как доказать успех. Так это не работает. Сравнивать нужно с состоянием «до», иначе в руках останется только настроение команды и пара красивых графиков. В качестве сигналов полезности платформы он предлагает смотреть на использование документации, сервис-каталогов, внутреннего time-to-market и, что особенно показательно, на снижение shadow IT. В одном из приведенных им кейсов у крупного телеком-заказчика расходы на внешние IT-сервисы заметно сократились уже после того, как платформа закрыла всего одну-две понятные боли. Для измерения качества platform engineering он осторожно относится к DORA: метрики полезные, но в руках менеджмента легко превращаются в дубинку «пишите быстрее и ошибайтесь меньше». Ему ближе SPACE и DevEx-подход: оценка удовлетворенности, потока работы, коммуникации, эффективности и когнитивной нагрузки. И да, без разговоров с людьми у кофемашины это не взлетает. Числа могут врать, пользователь, который в третий раз за день переключается между пятью инструментами и тремя встречами, обычно нет.
Не менее важная часть — техдолг и правила утилизации платформенных решений. Кёрбахер напоминает вещь, которую компании любят игнорировать: платформа — живой продукт, а не бетонная плита, на которую можно бесконечно докладывать новый слой. Если инструмент устарел, сообщество вокруг него исчезло, интерфейс бесит пользователей или миграция на него съедает больше времени, чем экономит, его надо уметь выбрасывать. Не через пять лет бухгалтерских мучений, а тогда, когда вред стал выше пользы. Поэтому alongside purpose и KPI он советует заранее определять критерии «списания» платформенных компонентов. Для российской IT-аудитории здесь сигнал вполне прикладной: пока многие компании строят внутренние платформы на фоне дефицита кадров, роста требований к безопасности и очередной AI-гонки, соблазн собрать все сразу особенно велик. Но platform engineering редко ломается из-за того, что команда выбрала не тот GitOps-инструмент. Гораздо чаще оно ломается, когда никто заранее не ответил на три вопроса: кому это нужно, как это войдет в повседневную работу и по каким признакам через год станет ясно, что платформу надо не расширять, а переделывать.
Самая неприятная мысль в этом докладе как раз самая полезная: зрелость platform engineering начинается в момент, когда команда перестает хвастаться стеком и начинает заниматься исследованием пользователей, сообществом вокруг платформы и неудобными продуктовыми решениями. Похоже, рынок внутренних платформ взрослеет ровно там, где инженеры соглашаются на не слишком героическую роль: не строить «идеальную платформу», а годами доводить до ума ту, которой люди действительно хотят пользоваться.