В 2021 году была представлена модель зрелости Cloud Native —
Cloud Native Maturity Model, разработанная рабочей группой CNCF (
Cartografos Working Group). Модель зрелости Cloud Native Maturity Model (CNMM) предназначена для поддержки организаций на любом этапе пути к Cloud Native и помогает определить, в какие инструменты, процессы, людей или политики целесообразно инвестировать. Цель модели — предоставить структурированный и практичный фреймворк, который направляет развитие от первоначального внедрения до достижения полного уровня зрелости. Модель была разработана практиками, которые сопровождали множество организации в процессе Cloud Native трансформации.
Модель активно обновляется каждый год, текущая версия модели 4.0 была представлена в сентябре 2025 года. Новая версия расширяет охват тем, связанных с AI (Artificial Intelligence), новыми технологиями, а также организационными и культурными изменениями. Модель делает акцент на согласовании Cloud Native практик с бизнес-результатами, помогая организациям не просто внедрять технологии, но делать это осознанно и с измеримым эффектом. Bерсия 4.0 уделяет больше внимания тому, что бизнесу необходимо учитывать для полного раскрытия преимуществ Cloud Native. В рамках данной модели под бизнесом понимаются все роли за пределами команд инфраструктуры, платформенной инженерии (Platform engineering), эксплуатации (Operations) и разработки (Development). Описание каждого уровня зрелости начинается с формулирования бизнес и технологических областей. Затем рассматривается, как эти фокусные области влияют на четыре столпа: люди (People), процессы (Process), политики (Policy) и технологии (Technology).
Модель зрелости Cloud Native спроектирована для совместного использования с моделью зрелости платформ (
Platform Engineering Maturity Model), обеспечивая как взгляд сверху вниз, так и снизу вверх. Вместе эти модели формируют многослойное представление, поддерживающее стратегическое планирование и тактическую реализацию. В новую версию также включены ссылки на архитектурные документы и ресурсы от технических консультативных групп CNCF (CNCF Technical Advisory Groups, TAGs) и других рабочих групп.
Основная целевая аудитория данной модели включает следующие группы:
- Компании, которые находятся в начале цифровой трансформации;
- Компании и команды, которым необходимо сориентироваться в обширном ландшафте CNCF (CNCF Landscape) и выбрать фреймворк, пригодный для внедрения и заслуживающий доверия;
- Проекты и практики в области Open Source и Cloud Native, которые планируют использовать модель или вносить вклад в ее развитие;
- Команды руководителей, стремящиеся понять преимущества Cloud Native, масштаб усилий и уровень необходимых инвестиций;
- Технические специалисты, которые планируют начать движение в сторону Cloud Native технологий и заинтересованы в более детальном понимании предстоящего пути, а также в выявлении дополнительных областей для дальнейшего изучения.
Модель Cloud Native Maturity Model включает пять уровней зрелости:
- Build. Реализована базовая Cloud Native архитектура, системы находятся на этапе подготовки к промышленной эксплуатации (Pre-production);
- Operate. Сформирован фундамент Cloud Native, начинается переход к промышленной эксплуатации (Production);
- Scale. Компетенции продолжают развиваться, формируются процессы и практики, необходимые для масштабирования;
- Improve. Происходит развитие и усиление процессов и практик во всех окружениях;
- Adapt. Выполняется пересмотр ранее принятых решений, процессов и практик с целью адаптации и оптимизации.
Модель зрелости Cloud Native — это не только технологический путь, но и процесс, на который влияют пять ключевых областей:
- Бизнес-результаты (Business outcomes) — каких результатов бизнес ожидает достичь за счет Cloud Native? Как эти преимущества доносятся до CXO или бизнес-руководства?
- Люди (People) — как выстроена работа, какие навыки необходимы и как меняется организация по мере прохождения этого пути?
- Процессы (Process) — какие процессы необходимы, какие технологии требуются, как описываются и связываются рабочие потоки и CI/CD с использованием инфраструктуры как кода (Infrastructure as Code, IaC), и как реализуется смещение безопасности максимально влево (Shift left)?
- Политики (Policy) — какие внутренние и внешние политики необходимы для выполнения требований безопасности и комплаенса (Security and compliance)? Отражают ли эти политики операционное окружение бизнеса?
- Технологии (Technology) — какие технологии необходимы для реализации преимуществ Cloud Native и поддержки людей, процессов и политик, а также какие технологические решения требуются для CI/CD, внедрения GitOps, наблюдаемости (Observability), безопасности (Security), хранения данных (Storage), сетевых взаимодействий (Networking) и других аспектов.
Бизнес-результаты (Business outcomes)Раздел описывает, как по мере роста зрелости Cloud Native организация переходит от определения и согласования ожидаемой ценности к устойчивому достижению и оптимизации измеримых бизнес-результатов. Раздел фокусируется на формировании и использовании KPI, прозрачной коммуникации с бизнес-руководством и последовательном применении повторяемых подходов, позволяющих масштабировать эффекты Cloud Native трансформации, повышать эффективность, надежность и предсказуемость эксплуатации сервисов во всем окружении.
Уровни зрелости:
- Сформирована базовая Cloud Native реализация, окружение находится на этапе Pre-production. Завершен POC, определены первоначальные KPI и подходы к измерению успеха Cloud Native трансформации. Бизнес-результаты обсуждены и согласованы с ключевыми стейкхолдерами, заложена основа для дальнейшего развития;
- Осуществляется переход к промышленной эксплуатации (Production). Внедрены технологические стандарты, процессы и политики, команды начинают стабильную эксплуатацию решений. Основной бизнес-результат связан с миграцией приложений в Production и формированием повторяемых паттернов, упрощающих дальнейшие переносы и взаимодействие команд;
- Происходит масштабирование за счет роста компетенций команд. Формализуются процессы, повышается зрелость в области безопасности, эффективности и надежности. Бизнес начинает получать эффект от более масштабируемой и устойчивой эксплуатации сервисов;
- Фокус смещается на улучшение безопасности, политик и Governance во всех окружениях. Команды меньше времени тратят на сопровождение платформы и больше — на задачи бизнеса. Достигается устойчивое соответствие KPI и прозрачная демонстрация бизнес-результатов, что обеспечивает согласование целей с руководством;
- Достигнута стадия оптимизации. Бизнес-цели выполнены и подтверждены измеримыми результатами. Эксплуатация и развитие Cloud Native решений максимально автоматизированы, оптимизация стоимости и производительности осуществляется на постоянной основе, а цели при необходимости пересматриваются с учетом достигнутого уровня зрелости.
Люди (People)При движении от первого уровня зрелости к пятому команды начинают с базовых технических знаний. Со временем осуществляются инвестиции в обучение, формируется компетентность, а ответственность постепенно смещается в сторону команд разработки. Зрелость достигается тогда, когда DevOps и DevSecOps полностью интегрированы, а команды уверенно исследуют и применяют новые технологии. Руководство принимает Cloud Native как стратегическое направление развития и осознает его бизнес-ценность.
Уровни зрелости:
- Бизнес согласован с целями Cloud Native, а руководство понимает его преимущества. Команды только начинают работать с технологиями, но обладает базовыми техническими знаниями и релевантными квалификациями;
- Сотрудники активно обучаются и развивают навыки, формируя небольшие группы предметных экспертов (Subject Matter Experts, SMEs). Появляются практики DevOps по мере того как Cloud инженеры и группы разработчиков вносят вклад в развитие платформенных навыков. Руководство начинает брать на себя ответственность за Cloud Native инициативы;
- Компетенции расширяются в областях разработки (Dev), эксплуатации (Ops) и безопасности (Sec), формируются экспертиза, стандартизированные практики и акселераторы (accelerators). Может быть сформирована команда платформенной инженерии (Platform Engineering Team). Cloud Native интегрируется в бизнес-стратегию как базовый принцип;
- Компетенции смещаются в команды разработки, что обеспечивает формат самообслуживания для инфраструктуры (Self-service infrastructure). Руководство полностью вовлечено и последовательно продвигает Cloud Native трансформацию на уровне всей организации;
- Организация функционирует с полностью интегрированными практиками DevOps и платформенной инженерии (Platform Engineering). Команды уверенно экспериментируют с новыми технологиями и проводят испытания в изолированных окружениях (Sandbox), непрерывно внедряя инновации и адаптируясь к изменениям.
Процессы (Process)Процессы влияют на Cloud Native ландшафт, топологию и размеры кластеров. Они поддерживают зрелость CI/CD и помогают повысить способность команд быстрее поставлять приложения. На начальном этапе трансформации будет наблюдаться нехватка процессов и единообразия между реализациями. Однако со временем ситуация меняется по мере развития и документирования процессов и компетенций. Документация должна находиться рядом с кодом и, при возможности, быть машиночитаемой (Machine based). К моменту достижения зрелости формируется единый и зрелый процесс с шаблонным подходом, а стандарты регулярно пересматриваются, выявляется дрейф конфигураций (Configuration drift) и стандарты корректируются в соответствии с бизнес-требованиями. Процессы обеспечивают повторяемость. В эфемерных окружениях (Ephemeral environments) необходимо гарантировать, что внедренные процессы могут воспроизводиться между командами и кластерами. Это является основой реализации процессов.
Уровни зрелости:
- Выполняется сопоставление как функциональных (функционал приложений), так и нефункциональных (производительность, доступность) требований к приложениям, одновременно с определением того, как организация будет масштабироваться. Взаимодействие осуществляется через мессенджеры, электронную почту или по телефону, устранение проблем также выполняется вручную. Для введения повторяемости начинается определение процесса для работы с Git (Git workflow). Обновления, как правило, применяются вручную, нерегулярно или с использованием встроенных механизмов обновления дистрибутивов;
- Фокус смещается на вывод базовых приложений в промышленную эксплуатацию (Production). К этому этапу должен быть сформирован устойчивый процесс работы с Git и CI. Внедряются структурированные процессы сборки и развертывания, соответствующие принципам Cloud Native и Container Native CI/CD;
- Приоритетом становится стандартизация на уровне всей организации, что упрощает онбординг и расширяет внедрение Cloud Native. Формируется цикл обратной связи (Feedback loop) и осуществляется инвестиция в повторяемость. Ключевые аспекты включают: Обеспечение доступа к необходимым инструментам (например, Git сервисам, средствам совместной работы) для экономии времени и сокращения дублирования; Внедрение процессов измерения потребления ресурсов, включая использование контейнеров, CPU и памяти (во время выполнения и простоя); Расширение автоматизации на процессы релизов программного обеспечения и платформ; Совершенствование процессов жизненного цикла, таких как установка исправлений и обновления, особенно в части CVE и критических обновлений, за счет использования инструментов инфраструктуры как кода (Infrastructure as Code, IaC);
- Механизмы Governance полностью поддерживает DevSecOps, при этом внедряются ограничивающие рамки (Guardrails), облегчающие гибкую разработку программного обеспечения. Формируется библиотека сервисов приложений (Application services library), а также определяются политики использования контейнеров, включая автоскалирование или политики высокопроизводительных вычислений (High Performance Computing, HPC);
- Достижение зрелости процессов приводит к формированию компетенций проектирования Cloud Native решений. Также автоматизируется реакция на инциденты за счет использования данных мониторинга для перезапуска или управления проблемными и отказавшими ресурсами. Данные об использовании ресурсов играют ключевую роль в оптимизации затрат, а процессы включают предоставление бизнес-анализа затрат, обеспечивая эффективность и финансовую ответственность при эксплуатации Cloud Native окружений.
Политики (Policy)Путь внедрения политик в Cloud Native окружениях во многом повторяет кривую обучения Kubernetes и Cloud Native технологий, переходя от императивного к декларативному подходу. Вместо описания процедур это измерение фокусируется на ожидаемых результатах и эффектах. Следует учитывать, что внедрение политик носит градиентный характер, а каждая организация обладает собственным уровнем допустимого риска (Risk appetite). Политики формируются как из внутренних, так и из внешних источников и представляют собой набор правил и требований, которые техническая организация должна интерпретировать и соблюдать. В быстро меняющихся окружениях политики часто становятся предметом споров и разногласий. Осознание этих сложностей и понимание способов их смягчения является критически важным.
Источники политик, как правило, можно разделить на три категории, каждая из которых ориентирована на разные уровни организации:
- Регуляторы (Regulators, Business) — обеспечивают целостность отрасли, например в финансовом секторе, здравоохранении или коммунальных услугах.
- Юридические требования (Legal, Compliance) — обязательства, такие как GDPR и EU DORA, обеспечиваемые регуляторами.
- Технические стандарты и рекомендации (Technical, Standards & Guidelines) — фреймворки и подходы от организаций, таких как NIST и MITRE, предоставляющие технические ориентиры.
Не все политики имеют одинаковый вес, поэтому важно различать регуляторные, юридические и технические требования.
Уровни зрелости:
- Существует ограниченный набор задокументированных политик, поддерживающих сервисы, разрабатываемые в облаке. Ведется совместная работа с командами комплаенса для оценки обязательств по политикам и их возможных изменений при использовании Cloud Native технологий;
- По мере выхода сервисов в промышленную эксплуатацию формируется начальный набор согласованных политик, которые фиксируются и документируются.
- Внедряется подход политики как код (Policy as code), который интегрируется в существующие процессы;
- Определяются SLA, связанные с политиками и устранением нарушений. Подход Policy as code и механизмы обеспечения соблюдения требований (Enforcement) рассматриваются как элементы жизненного цикла разработки программного обеспечения (Software Development Lifecycle);
- На основе накопленного опыта политики уточняются и развиваются по мере достижения организацией зрелости, с использованием таких технологий, как машинное обучение (Machine learning), для улучшения обнаружения и обеспечения соблюдения требований. Контур управления политиками постоянно эволюционирует в ответ на изменяющийся ландшафт угроз Cloud Native.
Технологии (Technology)Раздел Technology в модели зрелости Cloud Native описывает технологические инструменты и платформенные решения, лежащие в основе Cloud Native приложений, платформ и инфраструктуры. Раздел показывает, как по мере роста зрелости организация проходит путь от начального экспериментирования и ограниченной автоматизации к стандартизированному, масштабируемому и полностью автоматизированному технологическому ландшафту, обеспечивающему поддержку процессов, политик и целевых бизнес-результатов.
Уровни зрелости:
- Происходит первоначальное экспериментирование и внедрение Kubernetes. Используются относительно базовые инструменты и технологии. Выполняется оценка существующего инструментального стека с точки зрения его соответствия новому ландшафту (что хорошо сочетается с Cloud Native, а что нет). Уровень автоматизации ограничен, однако он будет развиваться далее. Основной фокус — внедрение базовой технологической платформы, без выхода в промышленную эксплуатацию;
- Этот уровень знаменует первый выход в промышленную эксплуатацию (Production). Начало может быть связано с небольшими и простыми сценариями, однако выход в эксплуатацию требует проработки ряда значимых аспектов. В сервисы интегрируются мониторинг и наблюдаемость (Observability). Внедряются ключевые инструменты наблюдаемости, начинается мониторинг кластеров по базовым метрикам, таким как RAM и CPU. На этом этапе может начинаться оценка распределенной трассировки (Application tracing), однако приоритетом остается сбор базовых метрик. Фокус сосредоточен на запуске приложения в Production и наличии достаточных платформенных ресурсов, наблюдаемости и эксплуатационных возможностей внутри организации;
- Начинается масштабирование. Инструментальный стек становится более стандартизированным. Формируются решения для релизного процесса, управления секретами (Secrets management) и политик. Также появляется организационная поддержка, которая способствует дальнейшему развитию. На этом этапе используется наибольшее количество инструментов, так как происходит активная оценка, внедрение и эксплуатация решений;
- Окружения полностью контролируются, формируется уверенность за счет быстрого внедрения Cloud Native паттернов для новых приложений и платформ. Достигается организационная приверженность Cloud Native подходу, что усиливает импульс трансформации. Появляется ощущение преодоления критического разрыва (Crossed the chasm);
- Инвестиции сосредоточены на автоматизации функциональных и нефункциональных аспектов, таких как сканирование, политики, безопасность и тестирование. Используются операторы (Operators), которые берут на себя выполнение эксплуатационных задач. Окружения становятся полностью автоматизированными.
Следует учитывать, что технологии быстро развиваются, в том числе за счет развития AI. В каждом разделе рекомендуется рассматривать, каким образом AI может помочь улучшить или упростить действия. Потенциал использования AI значителен, однако, несмотря на стремление модели зрелости Cloud Native охватить эту область, экспертиза в части AI остается за сообществом внутри CNCF. Дополнительную информацию можно найти в документе
CNCF Cloud Native AI White Paper.
Модель зрелости Cloud Native представлена на схеме ниже: