Продолжение заметки "DevOps в динамике".

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

Коллеги Дмитрий Исайченко и Роман Журавлев в книге «ITSM. Руководство по измерению» в части разработки процессных метрик предлагают следующий подход:

1. Установить назначение процесса
2. Разработать метрики соответствия назначению
3. Установить ключевые практики
4. Разработать метрики ключевых практик
5. …

Назначения процессов широко известны, поэтому шаги 1-2 обычно не вызывают трудностей – что должны показывать метрики понятно, вопрос только в выборе правильной математики. А вот с шагами 3-4 приходится сложнее. Установить комплекс практик, необходимых для реализации назначения процесса, оказывается не так просто. Конечно, можно подсмотреть в CSF в ITIL или Key Practices в COBIT5, но те из вас, кто выполнял такое упражнение, могли убедиться, что трудности на этом не заканчиваются. Кроме того, и после выполнения шагов 3-4 могут оставаться вопросы к полноте метрик.

В прошлой заметке про DevOps я привел возможный вариант CLD (Causal Loop Diagram) – диаграммы, которая связывает ключевые факторы системы управления в контексте DevOps и отражает их взаимное влияние друг на друга. Вот, что получилось:

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

Из книги нам известны следующие ключевые практики, которые без труда можно найти на диаграмме.

• Обеспечение полноты регистрации изменений (Changes Logged)
• Реализация изменений с первого раза, без потерь на доработки (First-Time Implementation Rate)
• Применение PIR для оценки и совершенствования процесса (PIR)
• Минимизация количества аварийных изменений (Emergency changes)
• Стандартизация изменений для сокращения рисков и оптимизации ресурсов (Standartization/Automation)

Анализируя остальные факторы, с помощью CLD список ключевых практик можно дополнить:

• Контроль хода изменений (Change Control Level)
• Обеспечение частых и небольших внедрений (Release Rate)
• Управление бэклогом (или сокращение среднего времени на старт работ по изменению) (Backlog size / Queue Time)
• …

Из книжек и других доступных примеров мне известны следующие примеры DevOps-метрик, которые также неплохо укладываются на CLD:

• Lead Time (Time to Market)
• Process Time (Process Time)
• Deploys per day (Release Rate)
• % changes successfully implemented (Change Capability)
• %C/A – percent complete and accurate (Change Capability)

Продолжая такое упражнение, можно построить таблицу, которая связывает элемент CLD и метрики, попутно корректируя и расширяя набор по необходимости:

Помимо помощи в поиске ответа на вопрос «Достаточно ли текущих метрик, чтобы определить состояния объекта управления?» CLD может помочь в следующем:

1. CLD помогает проанализировать, какой вклад достижения по тому или иному показателю делают в общий результат, а также определить относительную важность разных показателей. По итогам можно принять решение, стоит ли тратить силы на измерение с учетом важности метрики и сложности измерений.
2. CLD дает возможность косвенно оценить то, что мы не умеем мерить напрямую. Например, прямой метрикой Cost per change / release может быть стоимость привлекаемых ресурсов на единицу работ, что может быть затруднительно установить. Однако из диаграммы видно, что ресурсы используются тем эффективнее, чем больше изменений стандартизированы / автоматизированы и насколько много внедрений проходят с первого раза (без затрат на доработку) – метрики, связанные с этими элементами, могут помочь оценить фактор затрат косвенно.

3. CLD показывает возможный способ агрегирования показателей. Например, если мы хотим контролировать следующие ключевые области, связанные с проведением изменений: 1) своевременность реализации (Time to Market); 2) затраты (Сost per change) и 3) негативное влияние от проведения изменений (Change Risk), то CLD подскажет нам метрики, характеризующие каждую область. Например, для Change Risk:

Причем, у нас есть как метрики, связанные с элементом Change Risk непосредственно (Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases) – они являются отложенными показателями (trailing indicators) и характеризуют уже случившиеся успехи или неудачи в этом направлении. Но также у нас есть метрики, связанные с элементами, влияющими на Change Risk (Release size, Emergency change rate, …), которые могут быть использованы в качестве опережающих показателей (leading indicators) – они помогут прогнозировать наши успехи или неудачи в данном направлении.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом