Портал №1 по управлению цифровыми
и информационными технологиями

DevOps в динамике – 2. Метрики

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

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

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

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

Назначения процессов широко известны, поэтому шаги 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

Варианты метрик

Time to market

Lead Time

Percentage of changes timely implemented

Process Time

Process Time / Average Implementation Time

Timely Processing Index

Backlog size

Number of changes in queue

Time for implementing all changes in queue

Standardization level

Standard Change Rate

First-Time Implementation

First-Time Implementation Rate

Change capability

% changes successfully implemented

%C/A (percent complete and accurate)

PIR

PIR Coverage Index

Release rate

 

Mean time between release implementation

Deploys per day

Change risk

Percentage of Changes Without Recurring incidents

Total time of Major incidents caused by Releases

Number of defects per release

Release size

Average number of release units / functionality points per release

Emergency changes

Emergency Change Rate

Changes logged

Percentage of Changes Registered

 

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

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

  1. 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 для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

Комментариев: 2

  • Тимур

    Очень интересно!

  • Nargiza Suleymanova

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


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM