CALMS (ex-CAMS) — основа DevOps

Фреймворк CALMS (Culture, Automation, Lean, Measurement, Sharing) выглядит абстрактным, поэтому разберемся в его практической части.

CALMS — фреймворк для оценки готовности к переходу в DevOps, равно как модель выявления мест для улучшений. В первоначальной модели не было Lean (было CAMS). Его позже добавил Jez Humble.

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

Culture, Collaboration (Культура)

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

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

Второй пример — готовность идти на риск в изменениях. Если люди запуганы последствиями от прошлых неудач, то ничего не выйдет. Неудачи — неотъемлемая часть развития. К ним стоит относиться как источнику новых знаний, делиться этим знанием. Здесь еще один очень важный аспект в изменении мышления: к любому изменению (в продукте, в процессе) следует относиться как к эксперименту. Само понятие эксперимента подразумевает, что он может пройти либо успешно, либо нет, что авторизует право на неудачу. Конечно, своими неудачами мы не хотим загубить бизнес, поэтому договариваемся (Culture) о возможных последствиях и принимаем меры по снижению риска: применяем низкорисковые стратегии поставки (Automation), следим за метриками (Measurement), фокусируемся на клиенте и потоке (Lean), выносим уроки из неудач и делимся результатами (Sharing).

Automation (Автоматизация)

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

Из очевидного автоматизируется:

• Большинство видов тестов
• Сборка билда
• Статический анализ
• Создание бинарного пакета
• Развертывание инфраструктуры
• Настройка инфраструктуры
• Развертывание приложений
• Мониторинг
• Уведомления об ошибках
• Развертывание базы данных

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

Lean (Бережливость)

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

В создании визуального представления потока создания ценности принимают участие все без исключения участники процесса (Culture), об ограничениях WIP договариваются так же совместно. Измерения (Measurement) обращают внимание на те части потока, которые требуют улучшения или автоматизация (Automation), улучшения же неразрывно связаны с выявлением и устранением потерь, а устранение потерь на одном этапе может потребовать изменений в подходе к работе на других этапах. Сам по себе поток создание ценности уже показывает какие этапы проходит работа, какие возникают препятствия и на каких этапах накапливается работа (Sharing).

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

Measurement (Измерения)

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

Если цель — максимально ограничить негативное влияние дефектов небольшой группой клиентов с целевым состоянием «в 95% случаев дефект влияет максимум на 1000 клиентов», то общение будет строится вокруг метрики «Количество пользователей, затронутых дефектом». Исходя из анализа будут приниматься решения о смелых экспериментах:

• Попробовать Canary Releases или Blue/Green Deployment
• Начать использовать Feature Toggles
• Автоматизировать откатку изменений на основе immune system
• Перейти от монолитной архитектуры на архитектуру с независимыми сервисами для изоляции сбоев одним доменом
• Выстроить процесс Chaos Engineering для проактивного выявления ошибок

И все это должно быть автоматизировано (Automation), учитывать интересы всех заинтересованных лиц (Culture), а знания о том, как этим пользоваться должны быть доступны тем, кому это нужно в тот момент, когда потребуется (Sharing), без избыточности (Lean). То есть снова все пять частей CALMS работают сообща.

Sharing (Распространение знаний)

Этот пункт не только о распространении знаний, но и о принятии решений, обладая полнотой знаний. Отличный пример реализации этого пункта — War Room от Тойоты:

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

С точки зрения DevOps в комнате могут быть: цели, доска со всеми текущими работами, архитектурная и инфраструктурная схемы, метрики прогресса, эксплуатации и продукта (Measurement, Automation), схемы распределения трафика и так далее.

Другая, более детальная информация, может храниться в wiki в форме, понятной тем, кто будет пользоваться этой информацией (Culture).

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

Keep CALMS and Embrace Devops!