У платформенной команды было больше 99 DevOps-команд, Kubernetes под рукой и правильная, казалось бы, идея: дать разработчикам максимум свободы. На практике это привело к перегрузке, дублированию решений и медленному онбордингу. Для русскоязычной аудитории, которая строит внутренние платформы и пытается не утонуть в DevOps-ручной работе, это хороший кейс о том, почему платформенная инженерия заканчивается не на выдаче namespace.
Об этом сообщает InfoQ по мотивам выступления Jerry van Hulst и Marcel Kerker на KubeCon & CloudNativeCon Europe. Их история проста и потому неприятно узнаваема: в 2017 году команда начала с небольшого proof of concept на OpenShift и сделала ставку на полную автономию разработчиков. Платформа есть, доступ выдан, дальше команды сами отвечают за весь жизненный цикл. Для первых пользователей, которым нравилось копаться в инфраструктуре, модель работала. Но когда в 2019 году платформу попытались масштабировать на более широкий круг команд, начались проблемы роста.
Главная из них - слишком высокая когнитивная нагрузка. Ранние адепты контейнеров и Kubernetes готовы мириться со сложностью ради гибкости, а обычные продуктовые команды нет. Новые пользователи, по словам van Hulst, быстро упирались в слишком крутую кривую обучения и начинали платить так называемый Kubernetes tax: вместо кода они занимались платформой. Внутренний сервис, который должен ускорять доставку, превращался в отдельную профессию. Для бизнеса это особенно неприятный сбой: компания вкладывается в платформу ради скорости и предсказуемости, а получает еще один слой инженерной бюрократии, только уже в YAML.
Вторая проблема оказалась не менее типичной для зрелой платформенной инженерии: фрагментация знаний и решений. Командам почти не навязывали стандарты, и они независимо друг от друга решали одни и те же задачи - логирование, ingress, CI/CD, доступы, шаблоны развертывания. В итоге даже внутри одного кластера возникал тот самый Wild West, о котором говорил van Hulst. Для платформенной команды это означает дорогое сопровождение, для разработчиков - случайную архитектуру, где соседняя команда уже решила вашу проблему, но совсем другим способом. Снаружи это выглядит как свобода, а внутри - как налог на повторное изобретение колеса.
От платформы как сервиса к платформе как маршруту без ловушек
Вывод, к которому пришла команда, выглядит почти банально, но на практике его многие принимают слишком поздно: полная свобода не ускоряет, а тормозит. Поэтому вместо модели support-first они перешли к enablement-first. Идея не в том, чтобы отвечать на бесконечные тикеты и быть внутренним хелпдеском по Kubernetes, а в том, чтобы сделать команды самодостаточными. Не просто помочь один раз, а снизить трение так, чтобы правильный путь был самым легким.
На уровне платформы это выразилось в подходе automation first. Один из ключевых инструментов - оператор Project-as-a-Service, через который команда может поднять свое окружение одним простым YAML-файлом. Внутри уже есть базовый набор того, что обычно съедает часы и дни на старте: namespaces, RBAC, resource quota и другие стартовые настройки. Это важная деталь: речь не о красивой декларации "мы автоматизировали онбординг", а о конкретном переносе рутины в стандартный механизм. Если разработчику не нужно три дня настраивать ingress, права и пайплайны, платформа наконец начинает выполнять свою работу.
Но одних операторов и шаблонов мало. Kerker отдельно подчеркивает, что их стратегия строится не вокруг документации ради документации, а вокруг плотной совместной работы с командами. При масштабе более 99 DevOps-команд знания нельзя передавать только через wiki и ожидать, что все magically синхронизируются. Поэтому они запустили Communities of Practice, регулярную Container User Group для демонстрации новых возможностей платформы и более крупные Containerization Days с внешними спикерами и обзором новых технологий. Отдельный слой - прикладные, самостоятельные воркшопы по Tekton, ArgoCD, Identity Access Management, RightSizing и Kustomize.
Самой эффективной инициативой Kerker называет Accelerator Hackathon. Формат предельно приземленный: платформенные инженеры садятся рядом с продуктовой командой на целый день и вместе доводят первое приложение до запуска на платформе. Не "вот вам ссылка на гайд", а совместная сборка результата руками. Для российских и вообще восточноевропейских IT-команд здесь есть важный управленческий вывод: enablement работает не тогда, когда вы написали 40 страниц внутренней документации, а когда сократили путь до первого рабочего деплоя. Люди охотнее принимают стандарт, если он экономит им неделю, а не если он просто красиво описан.
Что это значит для разработчиков и внутренних платформ
История van Hulst и Kerker хорошо ложится на более широкий тренд в platform engineering. Еще несколько лет назад компании часто продавали внутренние платформы как "облако для разработчиков": вот доступ, вот кластер, дальше разберетесь. Теперь маятник явно ушел в сторону paved road и golden path - заранее подготовленного маршрута, где типовые решения уже собраны, автоматизированы и поддерживаются платформенной командой. Это не про удушение свободы, а про честный обмен: меньше вариативности в сантехнике, больше времени на продукт.
Следующий шаг у команды тоже показателен. Они собираются глубже интегрироваться с Backstage, расширять CI/CD starters и использовать ИИ для автоматических ответов в ChatOps и тикетах поддержки. Важно, что ИИ здесь подается не как самостоятельная магия, а как способ убрать повторяющиеся вопросы и освободить платформенных инженеров для более дорогой работы - обучения, стандартизации и развития платформы. Такой сценарий куда реалистичнее модных обещаний про "автономного AI DevOps", который якобы сам все настроит и никого не потревожит.
Для тех, кто строит платформенные команды, здесь остается неудобный, но полезный вопрос. Если вашим разработчикам все еще нужно вручную собирать базовую инфраструктурную обвязку, значит ли это, что у вас действительно есть внутренняя платформа, или пока только аккуратно упакованный доступ к Kubernetes? История с Project-as-a-Service показывает, что зрелая платформенная инженерия начинается в тот момент, когда команда перестает гордиться свободой как таковой и начинает мерить успех тем, насколько быстро и предсказуемо код доезжает до продакшена.