Обзор State of Platform Engineering Report 2025

В конце 2025 года вышел новый отчет по исследованию состояния платформ и платформенных команд State of Platform Engineering Report (Volume 4). Данные для четвертого отчета были собраны в рамках сообщества Platform Engineering. В опросе приняли участие 518 респондентов из различных отраслей с разными должностями и уровнями. Вопросы охватывали как индивидуальный уровень — должность, опыт, зарплату и фокус, — так и организационный уровень, включая зрелость платформ, финансирование и ROI. Как и в методологии предыдущего отчета, в данном анализе использовалась модель зрелости Platform Engineering от CNCF. Эта модель задала структуру вопросов, сфокусированных на ключевых аспектах платформ: Investment, Adoption, Interfaces, Operations, Measurement. По сравнению с результатами прошлого года данные демонстрируют устойчивый и постепенный прогресс организаций по всем аспектам модели зрелости.

В начале отчета авторы приводят основные тренды Platform Engineering на конец 2025 года:

1. Индустрия переходит от подхода Shift Left к подходу Shift Down, при котором платформа берет на себя ответственность за надежность, качество и безопасность, снижая нагрузку на разработчиков;
2. AI стал определяющим трендом, платформенным командам теперь необходимо одновременно поставлять платформы с поддержкой AI (AI-powered platforms) и создавать Platforms for AI, формируя специализированные экосистемы для AI/ML;
3. Область Platform Engineering значительно расширилась за пределы классической инфраструктуры и управления контейнерами. Платформенные команды все чаще обеспечивают работу новых доменов, таких как: AI, Data, Observability, Security, FinOps;
4. Появляются новые специализированные платформенные роли и команды;
5. Завершается эпоха ремесленной модели разработки, поскольку платформы берут на себя автоматизацию и стандартные решения, снижая зависимость от индивидуальной экспертизы.

В отчете приводится список новых специализированных ролей:

• Head of Platform Engineering (HOPE). Руководитель, отвечающий за всю функцию Platform Engineering, определяющий стратегическое направление, обеспечивающий согласование с бизнес целями и координацию команд. Роль требует широких компетенций в архитектуре, разработке, безопасности и эксплуатации;
• Platform Product Manager (PPM). Выступает связующим звеном между Platform Engineering и организацией, структурируя работу и приоритизируя функционал. PPM сочетает техническое понимание с потребностями пользователей для максимизации ценности платформы;
• Infrastructure Platform Engineer (IPE). Определяет конфигурации ресурсов и поддерживает базовую инфраструктуру, включая серверы, сети и базы данных. Обеспечивает масштабируемость, надежность и эффективность платформы;
• DevEx Platform Engineer (DPE). Улучшает Developer Experience за счет оптимизации рабочих процессов и снижения трения. Создает инструменты, шаблоны и документацию, делая платформу интуитивной и эффективной, а также расширяя возможности разработчиков;
• Security Platform Engineer (SPE). Реализует и управляет политиками безопасности в конвейере разработки, встраивая guardrails и поддерживая устойчивые меры безопасности по всей платформе;
• Observability Platform Engineer (OPE). Эволюция роли SRE, отвечает за стандарты надежности и наблюдаемости, оптимизацию ресурсов и надзор за мониторингом. Играет ключевую роль в настройке ресурсов продуктивной среды;
• Data and AI platform engineer. Интеграция AI привела к появлению новых специализации в платформенных командах, включая AI инженеров, Data инженеров и специалистов по MLOps. Сформировалась специализированная роль, которая обеспечивает взаимодействие с командами Data Science.

Также в отчете подводятся итоги работы сообщества Platform Engineering:

• Сообщество приблизилось к отметке в 270 000 участников. Рост сопровождался расширением инициатив, включая образовательную экосистему (Platform Engineering University), программу амбассадоров (Community Ambassadors), работу с Enterprise компаниями и конференцию PlatformCon;
• Конференция PlatformCon 2025 собрала более 255 докладов, 30 виртуальных воркшопов и свыше 20 сессий в формате live day — в сумме более 160 часов контента по Platform Engineering;
• Обновление эталонной архитектуры (Reference architecture for IDP). Версия 2.0 развивает исходную модель IDP на основе двух лет практического применения, роста отраслевой зрелости и появления AI в SDLC. Наиболее существенным изменением стало признание мультиплатформенности;
• Переосмысление ландшафта платформенных инструментов (Platform tooling landscape). Ландшафт теперь структурирован в соответствии с архитектурными плоскостями (planes), что позволяет более четко соотносить инструменты с их функциональной ролью внутри платформы. Этот подход упрощает навигацию по экосистеме, снижает фрагментацию и помогает командам осознанно выбирать инструменты в соответствии с целевой архитектурой и уровнем зрелости.

Что интересного мы отметили по результатам опроса:

1. Мотивы создания платформенных команд. Основные мотивы сосредоточены на улучшении Developer Experience и оптимизации конвейера поставки. Наиболее часто упоминаемым мотивом является стандартизация конфигураций поставки, за которой следуют снижение когнитивной нагрузки разработчиков и внедрение формата самообслуживания с целью ухода от модели TicketOps;
2. Основной фокус платформенных команд. Данные показывают, что платформенные команды по-прежнему сосредоточены на базовых возможностях платформы. Наивысшими приоритетами являются стандартизация предоставления инфраструктуры через Internal Developer Platform (28%) и улучшение Developer Experience и Developer Productivity (26%). Развитие практики Infrastructure as Code (IaC) (20%) также остается одним из ключевых фокусов;
3. Метрика Time to deliver value. Распределение времени до получения измеримой ценности от инициатив Platform Engineering показывает, что ранний успех возможен, однако в большинстве случаев достижение ценности требует большего времени. Около трети команд (35%) начинают демонстрировать измеримую ценность в течение первых шести месяцев. При этом 41% команд не способны продемонстрировать измеримую ценность в течение первых двенадцати месяцев, а 18% сообщают об отсутствии каких-либо измеримых результатов;
4. Инвестиции (Investment). Как организованы платформенные команды и их финансирование. Большинство организаций все еще находятся на ранних этапах зрелости Platform Engineering. У 45% организаций есть выделенная платформенная команда с бюджетом, но ее работа по-прежнему носит реактивный характер и не является стратегической. Еще 13% организаций полагаются на добровольные или временные команды без финансирования. Более высокий уровень зрелости наблюдается у 28% организаций, которые рассматривают платформу как продукт и принимают решения на основе данных. Лишь 13% сообщают о наличии платформенной экосистемы;
5. Принятие (Adoption). Как пользователи используют и переходят на платформенные сервисы. Данные показывают, что внедрение платформ заметно различается по уровню зрелости. 37% организаций переводят команды на платформы за счет внешнего давления (Extrinsic push), а 17% сталкиваются с нерегулярным внедрением без четкой стратегии. Более позитивные паттерны наблюдаются у 28% организаций, которые внедряют платформы за счет их реальной ценности и внутреннего спроса (Intrinsic value). Еще 18% сообщают о совместном развитии и внедрении платформ, при котором пользователи платформ также вносят вклад в их развитие;
6. Интерфейсы (Interfaces). Как пользователи взаимодействуют с платформенными сервисами. Данные показывают, что большинство команд опираются на знакомые и относительно консистентные интерфейсы. Стандартные инструменты (Standard tooling) являются наиболее распространенным подходом и используются в 43% организаций. Еще 32% предоставляют Self-service решения, обеспечивающие пользователям высокий уровень автономии. При этом часть команд (15%) по-прежнему зависит от ручных и ad hoc процессов взаимодействия;
7. Развитие (Operations). Как планируются, приоритизируются, разрабатываются и поддерживаются платформенные сервисы. 36% организаций централизованно развивают платформенные сервисы с фокусом на потребностях пользователей. Еще 32% ведут единый учет и координацию платформенных сервисов. По запросу и в ad hoc режиме платформы развивают 19% организаций;
8. Измерение (Measurement). Как платформенные команды работают с метриками и обратной связью. Наибольшая доля (35%) опирается на ad hoc и непоследовательную обратную связь, что ограничивает возможности для непрерывного улучшения. Еще 20% собирают обратную связь на регулярной основе, но применяют ограниченный анализ. Более зрелые практики наблюдаются у 26% организаций, которые используют инструменты инженерной аналитики и получают инсайты для принятия решений;
9. Платформенные метрики. Данные о том, как команды измеряют успех платформенных инициатив, выявляют резкий разрыв между организациями, использующими устоявшиеся метрики, и теми, у кого практики измерения отсутствуют вовсе. Метрики DORA остаются наиболее широко используемым подходом и упоминаются наибольшей долей организаций. Далее следуют Time to market и, в меньшей степени, фреймворк SPACE для оценки продуктивности разработчиков. При этом около 30% организаций вообще не измеряют платформенные инициативы, что существенно ограничивает возможности улучшения платформ и платформенных сервисов;
10. Влияние платформ на организационные метрики. Данные демонстрируют в целом позитивный тренд, однако также показывают, что многие команды все еще находятся на ранних этапах своего развития. Большинство организаций сообщает об улучшении метрик, при этом наибольшая доля фиксирует незначительные улучшения. Только 14% организаций сообщают об отсутствии заметных изменений, а почти четверть указывает, что не знает, улучшились ли метрики вообще. Это указывает на пробелы в измерениях, прозрачности или коммуникации. Лишь очень небольшая доля организаций сообщает об ухудшении метрик;
11. Применение подхода платформа как продукт (Platform as a Product). Данные показывают, что осознанность этого подхода растет, однако подлинное продуктовое мышление по-прежнему остается вызовом для многих команд. Наибольшая группа, 38%, сообщает об отсутствии выделенных Platform Product Manager, при этом инженеры работают с продуктовым мышлением. Еще 25% указывают, что продуктовые подходы в их организациях не применяются, что подчеркивает существенный барьер на пути к достижению зрелости платформы. Более структурированный подход наблюдается у 22% организаций, имеющих выделенных Platform Product Manager;
12. Способы сбора обратной связи о работе платформ. Данные показывают, что организации преимущественно полагаются на неформальные способы сбора обратной связи. Наиболее распространенным подходом являются неформальные обсуждения, за которыми следуют сессии обратной связи и office hours, что указывает на то, что обсуждения по-прежнему остаются основным источником инсайтов. Регулярные опросы добавляют определенную структуру, однако используются заметно реже. Почти 10% организаций вообще не собирают обратную связь, что выявляет существенный разрыв в понимании эффективности платформы;
13. Структуры подчинения. Данные показывают, что платформенные команды чаще всего подчиняются Head of Platform Engineering. Далее по распространенности следуют подчинение Director или VP of Engineering, а также CTO, что указывает на тесную связь Platform Engineering с ключевыми инженерными приоритетами во многих организациях;
14. Годовой бюджет Platform Engineering инициатив. Большинство таких инициатив по-прежнему работают с очень ограниченным финансированием. Почти половина организаций располагается в диапазоне от 0 до 1 млн $, что подчеркивает: от многих команд ожидают значительного организационного эффекта при весьма скромных ресурсах. Еще одна значительная доля находится в диапазоне от 1 до 5 млн $, в то время как лишь небольшое меньшинство сообщает о бюджетах выше 10 млн $. Это распределение показывает, что уровень инвестиций пока не соответствует масштабу задач и ожиданий, и большинство инициатив остаются недофинансированными;
15. Количество внутренних платформ в организациях. Большинство организаций сегодня эксплуатируют более одной платформы, что является заметным сдвигом по сравнению с ранними предположениями индустрии, согласно которым наличие нескольких платформ рассматривалось как признак фрагментации или низкой зрелости. 56% организаций сообщают о наличии более одной платформы, что делает все более очевидным: мультиплатформенность часто отражает осознанный архитектурный выбор;
16. Основные вызовы для платформенных команд. Данные показывают, что культурные и организационные барьеры по-прежнему превосходят технические. Наиболее значимым вызовом остается принятие и использование платформ со стороны разработчиков, за которым следует формирование общего видения и продуктового мышления. Еще одним крупным препятствием является сложность существующих систем. Многие команды также сталкиваются с ограниченной продуктовой экспертизой, недостаточным финансированием и трудностями в получении поддержки со стороны руководства, что замедляет прогресс и снижает долгосрочный эффект. Такие задачи, как расчет ROI и масштабирование Minimum Viable Platform (MVP), дополняют перечень ключевых вызовов.

В конце отчета авторы подводят итоги и отмечают, что результаты 2025 года показывают: дисциплина Platform Engineering активно развивается и вышла за пределы прежнего этапа ажиотажа. В то же время результаты выявляют и пробелы, наиболее значимыми из которых остаются платформенные метрики и обратная связь. Для решения этих проблем и успешного развития Platform Engineering в организациях авторы дают рекомендации:

• применять подход платформа как продукт (Platform as a Product);
• начинать с Minimum Viable Platform (MVP);
• инвестировать в обучение команд;
• улучшать опыт использования платформ.

Основные инсайты и графики из отчета State of Platform Engineering Report 2025: