DevOps в SAFe: модель CALMR

Во фреймворке SAFe модель CALMR является одним из центральных элементов DevOps-подхода. Она определяет мышление и практики, позволяющие организациям выстраивать эффективную DevOps‑среду и обеспечивать непрерывную доставку ценности.

В статье рассматриваются основные элементы CALMR и их роль в построении устойчивого конвейера непрерывной доставки.

Что такое CALMR в SAFe?

CALMR – это пять ключевых областей знаний DevOps, которые направляют Релизный Поезд (Agile Release Train, ART) на достижение непрерывной доставки ценности через развитие: культуры, автоматизации, бережливого потока, измерений и восстановления.

Основная задача DevOps – объединить всех участников потока создания ценности вокруг общей цели: быстрого и безопасного вывода продуктов и изменений в промышленную среду. В SAFe модель CALMR покрывает все, что нужно для этого в организации.

Когда все участники потока создания ценности – команды разработки, эксплуатации, информационной безопасности и бизнеса – работают в логике непрерывной доставки, организация получает измеримые бизнес-результаты:

• увеличивается частота и качество продуктовых инноваций;
• повышается уровень безопасности решений;
• снижаются риски развёртывания благодаря более коротким циклам обучения;
• сокращается время вывода продукта на рынок (time-to-market);
• повышается качество решений и сокращается время устранения дефектов;
• уменьшается частота и серьёзность дефектов и сбоев;
• сокращается среднее время восстановления после инцидентов в промышленной эксплуатации (метрика «Mean Time to Recover», MTTR).

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

Эволюция модели: от CALMS к CALMR

DevOps-сообщество более десяти лет развивало модель CALMS – Сulture, Automation, Lean flow, Measurement, Sharing (культура, автоматизация, бережливый поток, измерения и обмен знаниями).

SAFe сохраняет эту концепцию, но делает важное уточнение: обмен знаниями рассматривается как естественная часть организационной культуры. Поэтому в модели SAFe вместо элемента «S» («Sharing», обмен знаниями) выделяется отдельный элемент – «R» («Recovery», восстановление).

Так формируется подход SAFe к DevOps – модель CALMR (рисунок 1).

Рисунок 1. Подход SAFe к DevOps – модель CALMR

CALMR включает пять взаимосвязанных областей развития DevOps:

• Culture – культура
• Automation – автоматизация (всего)
• Lean Flow – бережливый поток
• Measurement – измерения (и телеметрия)
• Recovery – восстановление

Эти элементы формируют единый управленческий и технологический подход к организации непрерывной доставки ценности.

Culture – культура DevOps в SAFe

В SAFe DevOps опирается на Lean‑Agile культуру, формируемую ценностями, принципами и практиками фреймворка. Все принципы SAFe – от принципа №1 «Принять экономическую точку зрения» до принципа №10 «Организоваться вокруг ценности» – напрямую применимы к DevOps.

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

Культура DevOps в SAFe строится на нескольких ключевых принципах:

Клиентоцентричность

Ценность определяется способностью организации понимать потребности клиентов и быстро реагировать на них. Поэтому все участники потока создания ценности должны иметь единое пониманием потребностей клиентов и бизнес-целей.

Сотрудничество

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

Толерантность к риску

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

Обмен знаниями

Распространение практик, инструментов, идей и опыта между командами, Поездами (ART) и всей организацией ускоряет развитие компетенций и способствует смещению контроля качества на более ранние этапы разработки («сдвиг влево» по шкале времени).

Automation – автоматизация Конвейера Непрерывной Доставки в DevOps

DevOps рассматривает ручные процессы как один из ключевых барьеров на пути к быстрой и надёжной доставке ценности. Ручные операции увеличивают вероятность ошибок в конвейере доставки, особенно при масштабировании. Ошибки приводят к доработкам и задержкам.

Поэтому одной из главных задач становится автоматизация Конвейера Непрерывной Доставки (Continuous Delivery Pipeline, CDP).

Интегрированная цепочка инструментов DevOps (рисунок 2) позволяет ускорить обработку изменений и сократить циклы обратной связи. Такая обратная связь поступает от клиентов и пользователей, заинтересованных лиц, поддержки инфраструктуры и самих систем и помогает объективно оценивать создаваемую ценность.

Рисунок 2. Концептуальная цепочка инструментов CDP

Типовая DevOps-цепочка инструментов в Конвейере Непрерывной Доставки включает следующие категории:

Управление потоком создания ценности (Value Stream Management, VSM)

Инструменты управления потоком создания ценности обеспечивают сквозную прозрачность конвейера и позволяют отслеживать его эффективность в режиме реального времени.

Системы управления версиями (VC)

Используются для хранения и управления изменениями исходного кода и конфигураций системы.

Инфраструктура как код (Infrastructure as Code, IaC)

Подход, при котором инфраструктура описывается в виде кода и может автоматически создаваться, изменяться и удаляться.

Автоматизация тестирования

Применяется для ускорения проверки качества на различных уровнях: модульном, компонентном, интеграционном, регрессионном, нагрузочном, приёмочном и других.

Инструменты поиска уязвимостей

Позволяют выявлять проблемы безопасности в коде, инфраструктуре и сетях.

CI/CD – инструменты

Автоматизируют процессы сборки, интеграции, тестирования, проверки соответствия регуляторным требованиям и развёртывания решений.

Мониторинг и аналитика

Собирают данные о производительности и использовании системы и позволяют оценивать качество решения и эффективность конвейера доставки.

Дополнительные инструменты

Перечисленные выше инструменты используются практически повсеместно, однако существуют и другие инструменты, поддерживающие DevOps и зависящие от конкретной реализации. К ним относятся плагины для интегрированных сред разработки (IDE), микросервисы, репозитории артефактов, инструменты управления облачной инфраструктурой и решения для «хаос инжиниринга».

Lean Flow – Бережливый поток доставки ценности

Agile‑команды и Релизные Поезда (ART) стремятся обеспечить непрерывный поток – от идеи до получения бизнес-результата. Этот подход отражён в Принципе SAFe №6 — «Обеспечить непрерывный поток ценности».

Для ускорения потока SAFe предлагает восемь ускорителей потока. Они применяются на всех уровнях фреймворка – от команды до портфеля.

Примечание: В отдельных статьях SAFe рассматривается применение этих ускорителей для каждого уровня потока: Поток Команды, Поток Поезда (ART), Поток Крупного Решения (Поезда Решения) и Поток Портфеля.

Для оптимизации конвейера непрерывной доставки особенно важны три из них.

Рисунок 3. Канбан система поезда (ART Kanban) помогает визуализировать и ограничивать количество незавершённой работы (НЗР, WIP)

Визуализация и ограничение незавершённой работы (НЗР, WIP)

Канбан-система Поезда (рисунок 3) позволяет сделать поток работы прозрачным и выявлять узкие места. Ограничение НЗР помогает балансировать загрузку команд разработки и эксплуатации.

Работа малыми партиями

Небольшие партии изменений проходят систему быстрее и с меньшими рисками. Это увеличивает частоту релизов, ускоряет обучение и получение обратной связи от пользователей. Сокращение размера партий обычно требует особого внимания и инвестиций в инфраструктуру и автоматизацию, которые позволяют снизить транзакционные издержки для каждой партии.

Сокращение очередей

Размер очередей напрямую влияет на скорость доставки изменений. Чем меньше очередь, тем быстрее функциональность достигает пользователей.

Measurement – измерения в DevOps

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

Такой подход напрямую соответствует принципам SAFe:

• Принцип №1 «Принять экономическую точку зрения»
• Принцип №5 «Основывать вехи на объективной оценке реально работающих систем»

На практике возникает ключевой вопрос: какие именно метрики следует отслеживать и из каких источников получать данные? Несмотря на то, что каждая организация и каждый конвейер доставки имеют свои особенности, в DevOps сформировались общие подходы к измерению эффективности процессов разработки и эксплуатации.

Как правило, метрики DevOps можно разделить на три основные группы: метрики потока, метрики качества и метрики бизнес-ценности решения.

1. Метрики потока: измерение эффективности конвейера доставки

Эффективность Конвейера Непрерывной Доставки во многом определяют результативность всей системы разработки и эксплуатации. Разработческий Поток Ценности (Development Value Stream) должен постепенно эволюционировать в полноценный конвейер непрерывной доставки, обеспечивающий гибкость бизнеса и быстрое внедрение изменений.

Метрики потока, описанные в статье «Метрики в SAFe», позволяют оценить, насколько эффективно изменения проходят путь от идеи до получения экономического результата.
Они отражают пропускную способность системы и время прохождения работы через все этапы – от запроса клиента до доставки функциональности пользователю.

Такие показатели формируются на основе совокупной работы людей, процессов и инструментов, задействованных в проектировании дизайна, разработке, тестировании, развёртывании и выпуске решений.

В современной практике DevOps используется несколько широко известных моделей измерения потока.

Например, Мик Керстен, создатель фреймворка «Поток» (Flow Framework), в книге «От проекта к продукту» («Project to Product») выделяет четыре ключевые метрики потока:

• пропускная способность (скорость) потока – объём работы, проходящей через систему за определённый период;
• эффективность потока – доля времени, когда работа действительно выполняется, по отношению к общему времени прохождения;
• время потока – общее время от начала работы до её завершения;
• загрузка потока – объём текущей работы в системе.

Кроме того, Фреймворк «Поток» анализирует структуру потока работа, включая распределение между различными типами работ: новым функционалом (фичами), дефектами, рисками и техническим долгом.

Другим широко используемым источником практик DevOps являются исследования Google (DORA). В них выделяются ключевые показатели эффективности доставки программного обеспечения, среди которых:

• сквозное время выполнения изменений (lead time for changes);
• частота развёртывания (deployment frequency).

Эти показатели позволяют оценить скорость и стабильность доставки изменений в промышленную среду.

2. Метрики качества решения

DevOps-подход предполагает перенос контроля качества на более ранние этапы жизненного цикла разработки – подход, известный как «сдвиг влево». Это позволяет закладывать качество непосредственно в процессе разработки, а не обнаруживать проблемы уже после выпуска продукта.

Метрики качества отражают соответствие решения функциональным и нефункциональным требованиям, требованиям безопасности и соответствия регуляторным требованиям.

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

В практиках DevOps используется несколько показателей, позволяющих оценивать стабильность и надёжность изменений.

Например:

• Фреймворк «Поток» относит показатели дефектов и технического долга к метрикам качества потока.
• Исследования Google выделяют метрику «частота отказов из-за изменений» («change failure rate») – долю изменений, приводящих к сбоям или требующих срочного исправления после развёртывания.

Такие метрики позволяют оценивать устойчивость процессов разработки и качество поставляемых изменений.

3. Метрики бизнес-ценности решения

Даже идеально оптимизированный конвейер доставки не создаёт реальной ценности, если он лишь ускоряет выпуск продуктов, не востребованных рынком. Поэтому важнейшей задачей DevOps становится измерение бизнес‑ценности решений, доставляемых через конвейер.

Метрики этой категории позволяют оценить экономические результаты внедряемых изменений и уровень удовлетворённости клиентов или конечных пользователей. Они сопоставляются с ожидаемыми результатами, сформулированными в исходной бизнес‑гипотезе.

Источниками данных для таких метрик могут быть:

• телеметрия и операционные данные системы,
• аналитика использования продукта,
• финансовые показатели,
• обратная связь от пользователей и заинтересованных лиц.

В рамках фреймворка «Поток» такие показатели рассматриваются как бизнес‑результаты и включают метрики, отражающие создаваемую ценность, уровень затрат и удовлетворённость клиентов.

Исследования Google (DORA) также выделяют дополнительный показатель – время восстановления системы после сбоя (time to restore service). Эта метрика соответствует широко используемому показателю времени восстановления после инцидентов (Mean Time to Recover, MTTR) и отражает способность системы быстро возвращаться к нормальной работе после инцидентов. Высокий MTTR может существенно снижать ценность внедрённых изменений.

Recovery – восстановление после сбоев

В модели CALMR отдельное внимание уделяется способности системы быстро восстанавливаться после операционных сбоев. Высокая частота релизов возможна только при условии, что конвейер непрерывной доставки обеспечивает как безопасное развёртывание изменений, так и быстрое восстановление системы при возникновении проблем.

Поэтому Конвейер Непрерывной Доставки должен проектироваться таким образом, чтобы каждое развёртывание было низкорисковым, а процессы восстановления были быстрыми и предсказуемыми. В статье «Выпуск по Требованию» описаны дополнительные техники для обеспечения более гибкого процесса выпуска.

К числу ключевых практик восстановления относятся следующие:

Подход «остановить линию» (андон / stop‑the‑line)

Если возникает проблема, которая может повлиять на ценность решения, команда временно приостанавливает текущую работу и сосредотачивается на устранении причины проблемы. Такой подход позволяет быстро локализовать источник сбоя и предотвратить его дальнейшее распространение.

Полученные уроки затем превращаются в постоянные улучшения процессов, архитектуры или инженерных практик.

Планирование и отработка сбоев

Даже при развитой DevOps‑культуре неудачные развёртывания полностью исключить невозможно. Поэтому команды должны заранее разрабатывать планы восстановления и регулярно отрабатывать сценарии сбоев.

Для этого используются среды, максимально приближённые к промышленной эксплуатации, а также практики «хаос инжиниринга» – например, инструменты наподобие «Хаоса обезьянок» (Chaos Monkey), позволяющие моделировать отказ компонентов системы.

Быстрое исправление «вперёд» (fix forward) и откат «назад» (roll-back)

Поскольку сбои в производственной среде неизбежны, команды должны обладать возможностью быстро выпускать и сразу устанавливать исправления (fix forward) либо оперативно возвращаться к известной стабильной версии системы.

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

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

Практическое применение CALMR в организациях

Модель SAFe CALMR может использоваться как практическая рамка для DevOps-трансформации и развития Конвейера Непрерывной Доставки. Многие организации применяют её при модернизации технологических платформ и переходе к более быстрым и устойчивым моделям разработки цифровых продуктов.

На практике внедрение CALMR, как правило, охватывает пять взаимосвязанных направлений: развитие культуры, автоматизацию, управление потоком, систему измерений и способности к восстановлению.

Формирование DevOps‑культуры

Одним из первых направлений изменений становится развитие культуры совместной ответственности за весь жизненный цикл решения. Организации постепенно переходят от функционально разделённых команд разработки, эксплуатации, тестирования и информационной безопасности к более тесной кросс-функциональной кооперации и совместной ответственности за весь жизненный цикл продукта.

На практике формирование DevOps-культуры может включать:

• создание кросс‑функциональных команд;
• внедрение практик SRE и DevSecOps;
• развитие культуры экспериментов и обучения на ошибках;
• регулярные ретроспективы и обмен знаниями между командами.

Такие изменения позволяют сократить барьеры между функциями, повысить скорость принятия решений и усилить ориентацию команд на конечный результат.

Повышение автоматизации и улучшение конвейера доставки

Следующим важным направлением является развитие Конвейера Непрерывной Доставки (CDP) и максимальная автоматизация всех этапов жизненного цикла разработки.

Как правило, компании инвестируют в автоматизацию следующих процессов:

• ускорение разработки кода с помощью ИИ;
• автоматизированная сборка и интеграция кода;
• автоматизированное тестирование;
• автоматическое развёртывание инфраструктуры (Инфраструктура как код, IaC);
• мониторинг и сбор телеметрии в реальном времени.

Развитие автоматизации позволяет снизить зависимость от ручных операций, сократить вероятность ошибок, ускорить прохождение изменений через конвейер и повысить устойчивость систем.

Управление потоками создания ценности

Практическое применение CALMR также предполагает внедрение практик Бережливого Потока (Lean Flow) и Управления Потоками Ценности (Value Stream Management) для повышения прозрачности и управляемости потоками работ.

В организациях это может выражаться в следующих практиках:

• визуализация потоков работ с помощью Канбан;
• ограничение незавершённой работы (НЗР, WIP);
• выявление и анализ узких мест в конвейере доставки;
• сокращение времени ожидания между этапами и уменьшение размеров партий изменений.

Такие практики помогают организациям не только ускорять доставку изменений, но и повышать предсказуемость работы конвейера непрерывной доставки.

Развитие системы измерений и управление на основе данных

Отдельным направлением внедрения CALMR является развитие системы измерений, позволяющей объективно оценивать эффективность Конвейера Непрерывной Доставки, качество доставляемых изменений (инкрементов) и создаваемую бизнес‑ценность.

На практике это означает переход от набора разрозненных технических показателей к согласованной системе метрик, которая используется для принятия решений на уровне команд, Поездов (ART) и потока создания ценности.

Это направление может включать:

• определение единого набора метрик потока, качества и бизнес‑ценности;
• автоматизацию сбора данных из систем разработки, тестирования, развёртывания, мониторинга и эксплуатации;
• формирование сквозной отчётности и дашбордов для разных уровней управления;
• регулярный анализ показателей для выявления узких мест и оценки эффекта изменений;
• создание массивов данных для предиктовной аналитики и обучения ИИ.

Развитие системы измерений позволяет сделать DevOps‑трансформацию более прозрачной, снизить зависимость от субъективных оценок и обеспечить управление на основе фактических данных.

Развитие восстанавливаемости (устойчивости) и операционной надёжности

Ещё одним важным направлением становится развитие способности систем быстро восстанавливаться после сбоев и обеспечивать устойчивую работу цифровых сервисов в условиях постоянных изменений.

На практике организации здесь внедряют такие подходы, как:

• хаос инжиниринг;
• автоматизированное восстановление инфраструктуры;
• сценарии аварийного восстановления;
• мониторинг, управление инцидентами и пост-инцидентный анализ.

Такие практики позволяют сократить время восстановления после сбоев, повысить надёжность сервисов и снизить операционные риски при частых релизах.

В совокупности все приведённые выше 5 направлений формируют практическую модель внедрения DevOps в логике SAFe CALMR. Исследования показывают, что организации, последовательно развивающие перечисленные выше практики, достигают более высоких показателей эффективности доставки программного обеспечения, включая более высокую частоту развёртываний, более короткое время выполнения изменений и меньшее время восстановления после инцидентов.

Заключение

Модель SAFe CALMR описывает базовые области знаний и определяет системный подход к внедрению DevOps и развитию Конвейера Непрерывной Доставки. Она объединяет организационные, технологические и управленческие аспекты трансформации, позволяя компаниям ускорять вывод продуктов на рынок и одновременно повышать их качество и надёжность.

Культура сотрудничества, автоматизация процессов разработки и эксплуатации, управление потоком создания ценности, использование объективных метрик и развитие устойчивости систем формируют основу современной DevOps‑практики.

Для крупных организаций CALMR служит не просто набором технических практик, а управленческой моделью развития потоков продуктовой разработки и поддержки. Именно сочетание этих элементов позволяет компаниям обеспечить устойчивую непрерывную доставку ценности и быстрее адаптироваться к изменениям рынка.

Часто задаваемые вопросы о CALMR

Что означает CALMR в SAFe?

CALMR – это модель DevOps в Scaled Agile Framework, которая объединяет пять областей знаний, одновременно являющимися направлениями развития: Culture (культура), Automation (автоматизация), Lean Flow (бережливый поток), Measurement (измерения) и Recovery (восстановление).

Она помогает организациям выстраивать устойчивую систему непрерывной доставки ценности, не упуская её важных элементов.

Чем CALMR отличается от модели CALMS?

Модель CALMS включает элементы Culture (Культура), Automation (Автоматизация), Lean Flow (Бережливый Поток), Measurement (Измерения) и Sharing (Обмен Знаниями).

В SAFe обмен знаниями рассматривается как часть организационной культуры, поэтому вместо «Sharing» (Обмен) выделяется отдельный элемент – «Recovery» (Восстановление), отражающий способность системы быстро восстанавливаться после сбоев.

Как CALMR связан с DevOps?

CALMR описывает знания и формирует практическую модель внедрения DevOps в рамках SAFe. Модель помогает организациям выстраивать процессы разработки, эксплуатации и доставки продуктов, и особенно программного обеспечения, в виде единого потока создания ценности.

Какие метрики DevOps используются в SAFe?

В SAFe используются несколько видов метрик, все из них могут быть DevOps метриками:

• метрики потока
• метрики качества
• метрики бизнес‑ценности

К ключевым показателям обычно относят время вывода продукта на рынок (lead time), частоту развёртываний (deployment frequency), частоту отказов из-за изменений (change failure rate: доля изменений, приводящих к сбоям или требующих срочного исправления после развёртывания) и MTTR (способность системы быстро возвращаться к нормальной работе после инцидентов).

Почему способность к восстановлению важна для DevOps?

Частые релизы неизбежно повышают вероятность операционных сбоев. Поэтому способность системы быстро восстанавливаться после инцидентов является критически важной для устойчивой работы конвейера непрерывной доставки. При этом, без возможности производить частые релизы компания существенно теряет рыночные позиции как в инновационности, так и в адаптивности, а значит и в целом в устойчивости бизнеса.

Оригинал: Scaled Agile, Inc. (вендор), статья «CALMR». Материал не является официальным переводом.

Перевод и адаптация: Алексей Ионов, Lean-Agile коуч организаций, Advanced SPC, Ионов и Партнеры. В подготовке статьи использованы дополнительные материалы и опыт практического использования CALMR в организациях. Основано на версии статьи вендора от 14.03.2023.

Почитать дополнительно:

DevOps и DevSecOps: как доставить ценность быстро и безопасно
Управление Потоком Ценности
Как обеспечить непрерывный поток ценности?
Ускорение Потока с помощью SAFe
Конвейер Непрерывной Доставки (CDP)
Выпуск по требованию — управление релизами в SAFe
Метрики SAFe (метрики потока)

© «Ионов и Партнеры» (ИП Ионов Алексей Константинович), 2018-2025. Все права защищены. Цитирование материалов и размещение ссылок на материалы для формирования сторонних баз знаний, рубрикаторов или агрегаторов допускается только с письменного согласия «Ионов и Партнеры».

SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.