Team API

Обзор отчета Platform Engineering 2.0

В середине 2026 года вышел отчет Platform engineering 2.0: An evolution for the AI era от компании Weave Intelligence при поддержке Broadcom. Отчет задает ориентир развития для платформенных команд и руководителей, основанный на множестве экспертных интервью, собранных сообществом Platform Engineering, которое насчитывает более 280 000 практиков, экспертов и лидеров.

Ключевые инсайты из отчета:
  1. Platform engineering 2.0 как эволюция. Подход расширяет практики Platform as Product, Golden paths, Shift left security и Self-service IDP. Существующие инвестиции в платформу не устаревают и являются основой для того, что будет дальше;
  2. AI как движущая сила и возможность. AI вводит новый класс нагрузок, требующий выделения GPU, обслуживания моделей, Guardrails и MCP gateways, а также новый класс пользователей платформы, где агентам необходимы ограниченные права доступа;
  3. IDP превращается в Agentic Development Platform. Новая операционная модель, обеспечивающая совместную работу людей и AI агентов;
  4. Платформа не только для разработчиков. Команды Security, Data Scientists, FinOps, Business и AI агенты теперь являются полноценными пользователями, каждому из которых нужны собственные инструменты, сервисы и абстракции;
  5. Стоимость становится сигналом первого уровня. Встроенные практики FinOps переводят работу со стоимостью из отчетности в принятие решений на этапе выделения ресурсов, где каждый инженер становится практиком FinOps;
  6. Безопасность смещается в платформу. Это закрывает новые проблемы, связанные с AI, включая неконтролируемое распространение Shadow AI, Prompt injection, Model poisoning и утечки данных инференса, которые инструменты разработчиков выявить не способны;
  7. Будущее платформ: компоновка вместо выбора между Build и Buy. API-first, быстро обновляемые строительные блоки, связанные через четко определенные контракты, дают архитектурную гибкость, которую требуют AI и быстрые эксперименты;
  8. Инфраструктура делает эту эволюцию осязаемой. Каждый Golden path, каждый Self-service портал, каждый Agentic workflow в итоге сводится к выделенному ресурсу: контейнеру, инстансу GPU, хранилищу. По мере того как Platform Engineering входит в эру AI, слой инфраструктуры должен масштабироваться вместе с ним: выделяться динамически, непрерывно управляться и оптимизироваться для каждого класса нагрузки и пользователя.

Путь эволюции Platform Engineering
В начале отчета приведен путь эволюции от DevOps к Platform Engineering 2.0:

2015-2018: Эра DevOps. Эта эра заложила культурный фундамент совместной ответственности (Shared ownership), быстрой обратной связи (Fast feedback) и непрерывной поставки (Continuous delivery), которую Platform Engineering впоследствии систематизировал;

2019-2024: Platform Engineering достигает зрелости. Дисциплина сформировалась вокруг трех практик, каждая из которых была направлена на снижение когнитивной нагрузки на разработчиков:
  1. Golden paths предоставляли командам шаблоны с четко заданной структурой, заранее одобренные для типовых нагрузок и сокращали пространство принятия решений при развертываниях;
  2. Internal Developer Platforms превращали эти пути в то, что разработчики могли использовать: единый стандартный Self-service способ создания окружений, развертывания сервисов и доступа к инфраструктуре без переключения контекста между десятком инструментов;
  3. Platform as Product, практика отношения к платформе как к продукту и пользователям как к клиентам с дорожными картами, циклами обратной связи и метриками внедрения.

2024-2025: Точка перегиба. Ускорение разработки кода, обусловленное AI, регулирование суверенитета, угрозы безопасности, обусловленные AI, и проблемы в цепочках поставок оборудования оказали сильное давление на платформы, которые были ориентированы на разработчиков и рассчитаны на их темп. Архитектура начала демонстрировать структурное напряжение под новой нагрузкой.

2026 год и далее: Platform Engineering 2.0. AI-native платформы, ориентированные на разные группы пользователей, компонуемые и с расширяющейся автономией агентов. Пять столпов в этом отчете определяют практики, характеризующие эту фазу. Темп изменений сам по себе является определяющей характеристикой эры 2.0. Новые возможности моделей, паттерны для агентов, инструментарий и поверхности атак появляются намного быстрее, чем в рамках ежегодных циклов. Платформенная команда, которая ждет стабилизации этих изменений, прежде чем реагировать, будет все десятилетие догонять.

При этом практика Platform as Product остается организующим принципом, а Golden paths и Self-service IDP остаются центральными элементами. Эра 2.0 описывает направление развития. По мнению авторов — это цикл продолжительностью 3-4 года, охватывающий период до 2030 года. Организации, которые начинают эту эволюцию сейчас, будут иметь готовый фундамент к моменту, когда более поздние практики этого цикла, включая полную Agent Infrastructure, Autonomous platform operations и Vertical agentic platforms, станут операционными требованиями.

Проблемы текущих платформ
Внутренние платформы теперь должны поддерживать нагрузки, для которых они не были спроектированы. Пять следующих ограничений определяют потолок для большинства организаций:
  1. AI-Blind архитектура. Платформы строились для контейнеризированных нагрузок. В платформах отсутствует полноценная поддержка выделения GPU и TPU, обслуживания моделей, реестров моделей, MCP-шлюзов и специфичного для AI управления. Когда команде Data Scientists нужна Self-service среда с GPU или когда агенту нужна ограниченная область действия, у платформы нет встроенного решения;
  2. Фокус только на разработчиках. Текущие платформы хорошо обслуживают одну группу пользователей. В большинстве платформ команды Security, Data Engineers, ML, FinOps и Business рассматривались как пользователи второго сорта или полностью исключались. В каждой организации есть несколько групп пользователей, которые могут извлечь пользу из платформы. Платформа, обслуживающая одну группу пользователей в организации с разными группами пользователей, реализует лишь долю своей потенциальной ценности;
  3. Реактивная работа без проактивности. Платформенные команды, ориентированные только на DevEx, постоянно ощущают отставание. Платформа реагирует на проблемы вместо их предотвращения. В эпоху, когда AI создают всплески затрат за одну ночь, а угрозы безопасности непрерывно эволюционируют, реактивная позиция нежизнеспособна;
  4. Golden paths становятся Golden cages. Стандартизированные шаблоны, которые обеспечили 80% развертываний, теперь ограничивают экспериментирование и гибкость. Команды, работающие над новыми AI-архитектурами, оказываются заблокированными теми самыми Guardrails, которые были созданы, чтобы им помогать. Тот же паттерн проявляется везде, где шаблон достигает своих границ. Незначительные изменения требуют вмешательства платформенной команды. Путь, который был универсальным, становится ограничением. Платформенная команда при этом погрязает в активном сопровождении этих шаблонов;
  5. Излишняя строгость и статичность платформ. Комплаенс в платформах представляет собой снимок состояния, а не непрерывную гарантию. Платформы строились для более узкого ландшафта инструментов. Экосистема CNCF выросла примерно с 50 проектов в 2018 году до более чем 200 сегодня, резко расширив пространство выбора, которое жесткие монолитные платформы не способны вместить. Замена одного компонента другим вызывает каскадные изменения по всему стеку.

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

Изменения, требующие эволюции платформ
За последние 2 года на платформу сошлось множество изменений. Вместе они объясняют, почему эволюция больше не является опциональной.
  1. Ускорение разработки кода, обусловленное AI. Узкое место сместилось от генерации кода к поставке кода. 90% разработчиков сегодня используют AI-инструменты. Генерация кода увеличивается в 2-10 раз, что требует увеличения пропускной способности пайплайна в 2-10 раз;
  2. Agentic-будущее. Экспоненциальный рост числа AI-агентов при недостаточной поддержке. Приложения встраивают автономных AI-агентов. Платформы станут следующими. Необходимо выделение GPU/TPU, MCP-серверы, guardrails, аудиты;
  3. Момент истины FinOps. ROI бизнеса и проактивная оптимизация критически важны. 35% облачных затрат уходит впустую, непредсказуемые шоки в облачных счетах, дорогостоящая AI-инфраструктура. Ретроспективный FinOps недостаточен. В Platform Engineering 1.0 отсутствует фокус на этом вопросе;
  4. Суверенитет и комплаенс. Обусловлено регуляторными факторами, а также AI. Регуляторные требования к суверенитету и непрерывному комплаенсу;
  5. Enterprise с разными группами пользователей. Создание ценности за пределами группы пользователей разработчиков.

Пять столпов Platform Engineering 2.0
  1. AI-Native платформа (AI-Native Platform). Отвечает на ускорение разработки кода, обусловленное AI. Устраняет AI-Blind архитектуру. Опирается на Agentic Development Platform, которая является структурной эволюцией IDP для эры агентов;
  2. Опыт для разных групп пользователей (Multi-Persona Experience). Отвечает на потребности Enterprise с разными группами пользователей. Устраняет фокус только на разработчиках. Расширяет возможности платформы на шесть отдельных групп пользователей и признает, что та же Agent Infrastructure обобщается на Agentic-платформы других команд по всей организации;
  3. Встроенный FinOps (Embedded FinOps). Устраняет реактивное управление стоимостью. Переводит работу со стоимостью из надстроенной отчетности в принятие решений на этапе выделения ресурсов;
  4. Безопасность смещается в платформу (Security Shifts Down). Отвечает на давление суверенитета и комплаенса, а также на новые поверхности атак AI. Устраняет реактивную позицию и пробелы в безопасности AI. Встраивает безопасность в слои платформы и рантайма;
  5. Компонуемость, заложенная в архитектуру (Composable by Design). Отвечает на темп изменений в AI, Agentic-системах и экосистеме CNCF, насчитывающей 200+ проектов. Устраняет жесткие и статичные платформы. Обеспечивает API-first, быстро обновляемые строительные блоки, организованные в пять независимо развиваемых слоев.

Опыт для разных групп пользователей
Наиболее недооцененное ограничение Platform Engineering 1.0 заключается в покрытии групп пользователей. Большинство платформ оставляли командам Security, Data Scientists и FinOps самостоятельно выстраивать собственные наборы инструментов, что порождало теневой IT в масштабе всей организации. Платформа, которая обслуживает одну группу пользователей, раскрывает лишь долю своей потенциальной ценности. Platform Engineering 2.0 решает эту проблему на структурном уровне и выделяет шесть групп пользователей платформы:
  1. Разработчик приложений (App Developer). Разработчики приложений остаются крупнейшим потребителем платформы и командой, скорость которой напрямую определяет time to value для организации. Им нужны скорость поставки, golden paths, self-service CI/CD, а теперь и пропускная способность пайплайна и циклы валидации для безопасного поглощения работы, выполненной с помощью AI. Одновременно формируется новый подкласс agentic AI-разработчиков, которые поставляют AI-агентов, не просто код, и нуждаются в полноценной agentic-основе, включающей фреймворки оценки, MCP-шлюзы и инструментарий гибридных путей;
  2. Платформенные инженеры (Platform Engineers). Платформенные инженеры выполняют двойную роль: они одновременно создатель и пользователь платформы. Они строят и эксплуатируют платформу, от которой зависит каждая другая группа пользователей. Им нужны IaC, GitOps, observability, управление SLO и DORA-телеметрия, а также архитектурные полномочия для принятия решений о компонуемости, сохраняющих силу при масштабировании. Роль расширяется, охватывая теперь AI, Agent Infrastructure и формирующуюся поддисциплину AI Ops Engineer;
  3. Инженерные и бизнес руководители (Engineering and Business Leaders). Руководители несут ответственность за ROI, дисциплину затрат и готовность к AI, и не могут принимать эти решения на основе ежемесячных отчетов. Им нужны живые дашборды с атрибуцией затрат по командам и DORA метриками, показывающая тренды развертываний и индикаторы готовности к AI;
  4. Команды безопасности и комплаенса (Security and Compliance Teams). Команды безопасности и комплаенса работают в регуляторной среде, которую периодические аудиты не способны удовлетворить, при этом AI создает поверхности атак, которые инструменты разработчика не выявляют. Им нужен прямой доступ к управлению политиками, дашборды комплаенса в реальном времени, проактивное обнаружение, policy-as-code с автоматическим устранением нарушений и журналы аудита, охватывающие как действия людей, так и действия агентов;
  5. Специалисты по данным и ML-инженеры (Data Scientists and ML Engineers). Эта группа пользователей была наиболее стабильно недообслуживаемой в эру 1.0, несмотря на свою центральную роль в дорожной карте по AI, которую лидеры теперь требуют реализовать. Им нужны Self-service выделение GPU и TPU, версионированные реестры моделей, отслеживание экспериментов, оркестрация ML-пайплайнов, интегрированная с CI/CD, и гарантии воспроизводимости;
  6. AI-агенты (AI Agents). AI-агенты являются первой принципиально новой группой пользователей, под которую Platform Engineering потребовалось проектировать платформу за последнее десятилетие, поскольку следующее поколение создания ценности проходит через них. Они используют API и нуждаются в версионированных и хорошо документированных API, ограниченных правах доступа, идентификации, аудит-логировании, контроле бюджета и контроле исходящего трафика.

Практики FinOps
  1. Self-service FinOps, встроенный по умолчанию. Встроенная прозрачность затрат с Showback и Chargeback для каждого тенанта. Разработчики видят все варианты выделения ресурсов и их влияние на бюджет своей команды в момент выделения ресурсов, с видимостью потребления в реальном времени вместо итоговых сводок в конце месяца;
  2. Атрибуция затрат в реальном времени. Каждый ресурс автоматически помечается тегами и атрибутируется команде или проекту. Стоимость одного развертывания, стоимость одного запроса и сравнение с аналогичными командами дают разработчикам цикл обратной связи, необходимый для принятия решений с учетом затрат без потребности в экспертизе FinOps;
  3. Контроль затрат перед развертыванием. Контроль соблюдения бюджета через policy-as-code до выхода в production. Когда сервис может превысить пороговое значение, платформа блокирует развертывание и предлагает альтернативы: спотовое ценообразование, инстансы оптимального размера, on-premises варианты, в тот момент, когда решение еще можно изменить;
  4. Токеномика и атрибуция затрат в масштабе. Время GPU, использование токенов и стоимость инференса атрибутируются по каждой команде и каждой модели. Движок бюджетных политик с пороговыми значениями для команд и предложениями альтернатив делает затраты на AI-инфраструктуру такими же видимыми и управляемыми, как затраты на вычисления. Для этой категории у большинства организаций на сегодня полностью отсутствует инструментарий;
  5. Автономные агенты очистки и изменения ресурсов. Агенты, которые обнаруживают и выводят из эксплуатации зомби-инфраструктуру, приводят избыточно выделенные ресурсы к оптимальному размеру и переводят оптимизацию из реактивной в прогнозную. В экосистеме CNCF есть активные проекты, развивающиеся в этом направлении, и open-source основа для планирования с учетом затрат быстро достигает зрелости.

Безопасность смещается в платформу
Подход Shift-left пытался решить проблему безопасности, перенося ее на более ранние этапы. Разработчики получили больше инструментов и больше ответственности, но сама платформа осталась практически неизменной, и большинство уязвимостей по-прежнему выявляется в Production. Эта эволюция исправляет архитектурную ошибку. Платформа становится тем, что защищено само по себе, вместо объекта, о защите которого разработчики должны помнить.

Подход Shift-down достигает успеха там, где Shift-left терпит неудачу, поскольку обеспечивает встраивание безопасности непосредственно в слои платформы и рантайма, делая ее невидимой для разработчиков и неизменяемой по своей конструкции. Слой платформы берет на себя то, что разработчикам никогда не следует настраивать вручную.
  1. Ответственность слоя платформы (Platform layer responsibilities). Безопасность находится глубоко внутри платформы, невидимая и неизменяемая по умолчанию. Конфигурации безопасны по умолчанию, со встроенными принципом наименьших привилегий, mTLS, микросегментацией и автоматической ротацией секретов. Policy-as-code обеспечивает автоматические guardrails без настройки. Непрерывный комплаенс работает в виде аудита в реальном времени и обнаружения дрейфа вместо снимков состояния на определенный момент времени;
  2. Ответственность слоя рантайма (Runtime layer responsibilities). В рантайме применение политик продолжается и после момента развертывания. AI-обнаружение аномалий и угроз работает с прогнозной оценкой уязвимостей. Автоматическое устранение обрабатывает известные паттерны, CVE, ошибки конфигурации и нарушения политик по мере их возникновения. Контекстный RBAC адаптируется в реальном времени на основе поведенческих базовых профилей, подстраивающихся под меняющийся контекст, вместо опоры на статичные правила.

Новый фронтир безопасности AI (The new AI security frontier)
Agentic-разработка добавляет к этому слою особую проблему. AI создал совершенно новую категорию проблем безопасности, для решения которых не проектировались ни инструменты Shift-left, ни архитектуры Platform Engineering 1.0.
  1. Неконтролируемое распространение теневого AI (Shadow AI Sprawl). Несанкционированное использование моделей обходит механизмы контроля DLP и управления данными;
  2. Внедрение промптов (Prompt Injection). Новая поверхность атак: ни один инструмент SAST/DAST не обнаруживает внедрение в потоках инференса в реальном времени;
  3. Отравление моделей (Model Poisoning). Модели загружаются из реестров без проверки подписи и без проверки на отравление;
  4. Утечки данных инференса (Inference Data Leaks). Невидимы для текущих инструментов: персональные данные и интеллектуальная собственность раскрываются через ответы без журнала аудита и без механизмов контроля.

Платформа должна стать границей доверия. Четыре поверхности контроля определяют, что это означает на практике:
  1. Управление реестром моделей (Model Registry Governance). Версионированный реестр моделей с отслеживанием происхождения и этапами согласования, мониторинг дрейфа;
  2. Изоляция данных (Data Isolation). Границы данных на уровне тенанта с шифрованием в состоянии покоя и при передаче, контроль доступа. Политики DLP, встроенные в пайплайны инференса, с обнаружением и маскированием персональных данных;
  3. Безопасность промптов (Prompt Security). Guardrails на входе и выходе против рисков внедрения, утечки данных и галлюцинаций. Санитизация входных данных, фильтрация выходных данных и контроль границ контекста на уровне платформы;
  4. Аудит инференса (Inference Audit). Полный журнал аудита каждого AI-инференса с объяснимостью, отчетность по комплаенсу.

Когда безопасность смещается в платформу, каждый путь становится безопасным путем, каждое развертывание становится соответствующим требованиям комплаенса, и каждый AI-инференс становится управляемым инференсом. В этом заключается архитектурная победа встраивания безопасности на уровне платформы вместо ее надстраивания на уровне разработчика.

Пять компонуемых слоев платформ
Компонуемая архитектура платформы рассматривает каждую возможность как отдельный, независимо развертываемый, версионированный модуль с четко определенным API-контрактом. Модули можно заменять (например, Jenkins на Harness или один стек Observability на другой) без каскадных изменений в зависимых системах. Это становится возможным благодаря API-first контрактам, которые разделяют производителей и потребителей, позволяя каждому слою платформы развиваться независимо при сохранении интероперабельности.

Компонуемая платформа организуется в пять независимо развиваемых слоев:
  1. Слой опыта (Experience layer). Порталы для разработчиков и других групп пользователей, CLI-инструменты, self-service интерфейсы и многое другое. Интерфейс каждой группы пользователей развивается по собственной дорожной карте, не блокируя другие;
  2. Слой оркестрации (Orchestration layer). Движки рабочих процессов, применение политик, GitOps-пайплайны и многое другое. Логический слой, связывающий опыт с возможностями;
  3. Слой возможностей (Capabilities layer). Модульные сервисы для CI/CD, observability, безопасности, LLM и многого другого. Этот слой напрямую соответствует каноническому слою инструментов платформы: Developer Control, Integration & Delivery, Resource, Security, Observability;
  4. Слой интеграции (Integration layer). API, шины событий, service mesh. Контракты, которые разделяют производителей и потребителей;
  5. Слой инфраструктуры (Infrastructure layer). Вычисления, GPU, хранилища, сетевое взаимодействие. Основа, от которой зависят все слои.
Крайне важно понимать, что компонуемость начинается со слоя инфраструктуры. Инфраструктурный фундамент, построенный из независимо развертываемых API-first строительных блоков (вычисления, GPU, хранилища и сетевое взаимодействие), делает пять компонуемых слоев над ним действительно взаимозаменяемыми.

Четыре принципа проектирования платформ
Четыре принципа проектирования платформ превращают компонуемость из стремления в операционную дисциплину:
  1. Модульность, заложенная в архитектуру (Modular by design). Каждая возможность является отдельным версионированным модулем. Состояние хранится на уровне control plane для упрощения повторного развертывания. Вендор-независимые слои предотвращают привязку к любому отдельному компоненту. Платформенные команды строят только то, что действительно создает отличие (golden paths, governance, слой DevEx), и передают на аутсорс типовые решения;
  2. API-first контракты (API-first contracts). Стандартные интерфейсы разделяют производителей и потребителей. Люди и AI-агенты потребляют одни и те же API, поэтому MCP-шлюзы, построенные вокруг стандартных API, дают агентам ту же поверхность доступа, которую использует инструментарий для людей. Декларативная конфигурация заменяет пользовательский код интеграции. Оркестрация связывает модули за дни вместо месяцев;
  3. Plug and play. Замена реализаций без нарушения работы зависимых компонентов. Разверните GitHub Actions параллельно с Jenkins как независимый сервис и позвольте командам переходить на него в собственном темпе, ориентируясь на сравнительную DORA-телеметрию. Ускоренная интеграция при слияниях и поглощениях становится побочным эффектом качественного компонуемого проектирования: новые команды подключаются к API-контрактам через адаптеры вместо пересборки платформы;
  4. Постепенная миграция (Progressive migration). Ни одна компонуемая архитектура не требует единовременного переключения. Развертывайте новые возможности параллельно с существующими. Пусть внедрение будет естественным: команды переходят, когда новая возможность наглядно превосходит старую, и телеметрия делает это сравнение видимым.

Распределенная архитектура платформ
Такая архитектура строится на трех свойствах:
  1. Компонуемость (Composable). Обеспечивается модульным проектированием. API-first контракты на основе стандартизированных интерфейсов (MCP) разделяют производителей и потребителей. Независимость слоев позволяет заменять реализации (CI/CD, Observability) без каскадных изменений. Принцип Plug-and-play позволяет использовать CNCF-совместимые блоки для быстрой интеграции при слияниях и поглощениях и кастомизации;
  2. Неизменяемость (Immutable). Обеспечивается за счет Disposable Execution. Принцип Replace, Never Patch устраняет дрейф конфигурации за счет пересборки из версионированных образов. Декларативное состояние GitOps обеспечивает версионирование каждого компонента (инфраструктуры, политик, AI) в Git. Воспроизводимость AI/ML достигается за счет того, что версии моделей и индексы RAG рассматриваются как неизменяемые артефакты;
  3. Стратегическая ценность (Strategic Value). Заключается в фундаменте, допускающем повторное развертывание. Переход от TicketOps к поставке управляемой намерением. Масштабирование для 1000+ разработчиков со встроенными guardrails.

Основные инсайты из отчета Platform Engineering 2.0 ниже:
Если вам важно подготовить внутренние платформы и платформенные команды вашей компании к эре AI, обращайтесь к нам за помощью. Мы помогаем CTO и руководителям платформенных команд развивать внутренние платформы, расширять платформы на разные группы пользователей, встраивать управление затратами и требования безопасности в платформу, проектировать компонуемую архитектуру и развивать платформенные команды.

Не забывайте подписываться на наш Telegram канал Enabling.team Insights, чтобы оставаться в курсе технологических трендов.