Вчера CNCF выпустили подробный разбор своей модели зрелости платформы (Platform Engineering Maturity Model). Они выделяют четыре уровня взаимодействия. Кратко рассмотрим каждый из них и разберем, почему большинство команд намертво застревают на втором.
Дискуссии о платформенной инженерии обычно делят компании на два лагеря.
В первом — какой‑то сформировавшейся DEV-платформы вообще нет. Балом правят разрозненные скрипты и отрывочные знания в духе: «Попроси Дашу, она умеет поднимать базу».
Во втором DEV-платформу уже внедрили — есть и портал разработчика, и согласованные инструменты, и «лучшие практики». Однако даже и платформенная команда по‑прежнему обрабатывает нестандартные запросы руками и недоумевает: «Почему нагрузка не снижается?»
Проблема обеих групп идентична. Дело не в наличии платформы, а в зрелости интерфейсов. Именно они определяют, как именно разработчики взаимодействуют с инфраструктурой.
1. Кастомные процессы
На этом уровне живет большинство команд без формализованной DEV-платформы. Единого интерфейса нет, ресурсы выделяются по запросам вручную, знания передаются устно.
Чтобы выбраться, не надо пытаться сразу построить портал разработчика — это инструмент третьего уровня. Начать нужно с инвентаризации: найти самый частый и болезненный процесс (например, создание кластера PostgreSQL) и превратить его в единственный правильный путь — работающий, стандартизованный и задокументированный.
2. Ловушка стандартных инструментов
Итак, шаблоны и документация появились. Метрики вроде бы растут, онбординг ускоряется. Однако по‑прежнему все, что выходит «за рамки», требует вмешательства живого человека. На этом уровне развитие часто останавливается из‑за четырех проблем:
- очередь исключений — в крупных компаниях треть задач попадает в пограничные случаи, которые не укладываются в стандартные пути и заваливают бэклог платформенной команды;
- иллюзия универсальности — платформенные инженеры не могут быть экспертами во всех областях, а специализированные команды перестают доверять DEV-платформе и начинают (или продолжают) строить свои «велосипеды»;
- бремя поддержки — выпустить пару‑тройку десятков инструментов несложно, а вот организовать стандартизированную эксплуатацию, актуализировать версии компонентов при каждом обновлении Kubernetes, оперативно отрабатывать CVE — тяжелый труд, и компания начинает нанимать людей просто для поддержки старого кода;
- ригидность — технологии меняются, и довольно быстро, а глубоко зашитые «золотые пути» остаются, превращаясь из ускорителя в тормоз.
3. Настоящая автономность команд
На этом уровне разработчики получают настоящую автономию. Главный признак перехода — изменение поведения: продуктовые команды перестают заводить тикеты на рутину.
По данным CNCF, на этом этапе количество запросов на исключения падает вдвое.
Чтобы продвинуться дальше необходимо:
- параметризировать кажущиеся оптимальными способы — заменить жесткие ограничения на политики с валидацией, при этом дав разработчикам возможности для кастомизации;
- анализировать перед автоматизацией — найти 20% паттернов, генерирующих 80% запросов, и начать именно с них;
- относиться к интерфейсу как к продукту — управлять контрактами и схемами валидации, а не собирать каждый Helm-чарт вручную.
4. Ненавязчивость интегрированных сервисов
Итак, DEV-платформа становится незаметной. Инструменты прозрачно встроены в привычный пайплайн — неважно, Git это, IDE или CI/CD. Мониторинг, логирование и безопасность накручиваются на новые сервисы автоматически благодаря продуманным настройкам.
Метрика успеха на четвертом уровне — разработчики вообще не вспоминают об инфраструктуре, а код новичка попадает в продакшен за пару дней и без единого вопроса.
Архитектура большинства платформенных интерфейсов сегодня спроектирована для человека. Однако правила игры меняются, и ИИ-агенты уже начинают запрашивать ресурсы. Они не читают документацию, а работают с API так быстро, что никакой привычный ручной способ к этому попросту не готов. Разрыв между UI для людей и машиночитаемыми интерфейсами — это следующий вызов платформенной инженерии.
Комментарий эксперта
Полагаю, что всем без исключения регулярно приходится наблюдать «ловушку второго уровня». Если любой шаг в сторону от «единственного пути» требует ручного ревью и согласования, это не автономия, а просто автоматизированная бюрократия.
Согласен и с тезисом о необходимости параметризации. Задача платформенной команды — устанавливать безопасные границы, внутри которых продуктовые разработчики могут собирать нужную им конфигурацию, не дергая инженеров эксплуатации.
Дополню еще один важный аспект — финансовый. При разработке и развитии любой внутренней платформы команда должна понимать что преследует не только технологические цели, но и бизнес-экономику проекта. Компании строят DEV-платформы не ради самой автоматизации: основная цель — добиться эффекта масштаба и снизить совокупную стоимость эксплуатации инфраструктуры.
Когда вместо тысяч уникальных конфигураций компания получает стандартизированный набор управляемых сервисов — например, кластеров PostgreSQL, — становится возможным централизовать эксплуатацию, автоматизировать типовые операции и эффективнее использовать ресурсы. Именно в этом случае платформа превращается из «удобного инструмента для разработчиков» в полноценный бизнес-инструмент.
Что касается ИИ-агентов — это уже не футурология, а наступающая реальность. Если единственным интерфейсом внутренней платформы остается портал для людей, а API сделан по остаточному принципу, то шагнуть на четвертый, по терминологии CNCF, уровень зрелости не выйдет.
Будущее, возможно, действительно за API-first архитектурой: инфраструктура должна быть изначально готова к высокочастотным запросам от автоматизированных пайплайнов и нейросетей, которым нужны не инструкции в Confluence, а строгие контракты и предсказуемая валидация.
