Метрики DORA и состояние CI/CD

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

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

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

• Частота развёртывания (DF)
• Время выполнения изменений (LTFC)
• Среднее время восстановления (MTTR)
• Частота сбоев изменений (CFR)

Рассмотрим каждую из них!

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

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

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

• Пример: если Ваша команда выполняет 15 развёртываний за неделю, DF равна 15 в неделю.
• Цель: увеличивать это число. Лидирующие команды выполняют развёртывание несколько раз в день.

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

Эта метрика показывает эффективность процесса разработки, включая написание кода, тестирование, проверку и развёртывание.

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

• Пример: если функция зафиксирована утром в понедельник и доступна в рабочей среде к вечеру вторника, LTFC составляет примерно 36 часов.
• Цель: сокращать это время. Меньшее время выполнения означает более быструю поставку и ускоренную доработку.

Среднее время восстановления (MTTR) показывает, сколько времени требуется для восстановления службы после инцидента или сбоя в производственной среде. Оно отражает способность команды реагировать на проблемы и устранять их последствия.

Низкое значение MTTR указывает на высокую операционную устойчивость и эффективные процедуры реагирования на инциденты.

MTTR рассчитывается от момента обнаружения инцидента до полного восстановления службы. Обычно его измеряют в минутах или часах.

• Пример: если сбой приложения занимает 2 часа на обнаружение, диагностику и исправление, MTTR для этого инцидента составляет 2 часа.
• Цель: сокращать это время. Быстрое восстановление уменьшает влияние на пользователей и сбои в работе бизнеса.

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

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

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

• Пример: если из 100 развёртываний 5 приводят к инциденту в производственной среде, CFR равна 5%.
• Цель: поддерживать это число на минимально возможном уровне. У ведущих команд CFR часто составляет менее 15%.

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

Поздравляем! Вы изучили четыре метрики DORA:

• Частота развёртываний: как часто вы выпускаете изменения.
• Время выполнения изменений: как быстро код попадает в рабочую среду.
• Среднее время восстановления: насколько быстро вы устраняете проблемы.
• Частота неудачных изменений: как часто развёртывания приводят к проблемам.

Отслеживая эти метрики, вы получаете глубокое представление о состоянии CI/CD и можете постоянно совершенствовать свои процессы DevOps.