Как незаметно DORA метрик стало не четыре, а пять (Рубрика #Productivity)
Долгие году у DevOps Research & Assesment или попросту DORA было 4 метрики, на которых строилась кластеризация команд по разным уровням элитности. Эти метрики были про скорость поставки и стабильность
- Скорость поставки: deployment frequency и lead time for changes
- Стабильнсоть: MTTR / time to restore service и change fail rate
Подробнее эту историю можно прочитать в моем разборе книги "Accelerate")
С января 2026 года у DORA стало 5 software delivery performance metrics, которые на их сайте тоже разбиты на две категории
1️⃣ Throughput - пропускная способность системы
- Change lead time - время от коммита до успешного деплоя в прод
- Deployment frequency - как часто вы выкатываете изменения
- Failed deployment recovery time - как быстро вы восстанавливаетесь именно после неудачного деплоя
2️⃣ Instability
- Change fail rate - доля деплоев, требующих немедленного вмешательства
- Deployment rework rate - доля незапланированных деплоев, которые пришлось делать из-за прод-инцидента / дефекта
Возникает вопрос, а что именно изменилось по сравнению со старой моделью и зачем это было сделано?
Вообще, измений было два и оба они важные
1) Старый MTTR / time to restore service в 2023 был уточнен и переопределен как failed deployment recovery time. DORA прямо объясняет это тем, что старое определение смешивало проблемы, вызванные изменением в коде, и внешние инциденты вроде outage в датацентре. Новая формулировка лучше статистически "сцепляется" именно с delivery-метриками.
2) В 2024 DORA добавила новую пятую метрику - deployment rework rate. Их логика была такой: change fail rate хорошо ловит немедленные проблемы после релиза, но плохо отражает объем последующей незапланированной переделки. Поэтому DORA решила отдельно измерять rework как самостоятельную часть instability.
Если же говорить про использование метрик, то возникает вопрос: а теперь классификация будет идти по 5 метрикам?
И тут по сути ответ "да", но есть нюансы ... ребята из DORA отдельно подчеркивают, что число кластеров не фиксировано и не задается вручную. В FAQ они пишут, что кластеры у них emergent from the data: до 2018 обычно было 3, с 2018 по 2021 - 4, в 2022 снова 3, а в 2023 и 2024 - опять 4. То есть фиксированного "всегда 4 класса команд" больше воспринимать не стоит.
Если подумать, а что это значит для обычных технических руководителей (кто не упарывается по методолгии и метрикам)?
Кажется, что DORA стала лучше различать два разных вида проблем:
- Немедленный фейл после релиза → change fail rate
- Отложенная незапланированная переделка из-за продовых проблем → deployment rework rate
Это полезно, потому что команда может выглядеть "нормально" по rollback/hotfix сразу после релиза, но при этом системно тонуть в незапланированном rework через день-два. В старой 4-метричной модели это было видно хуже; в новой - видно лучше. Это и есть главное содержательное обновление модели.
Отдельно стоит сказать, что 5 метрик бывало в DORA и раньше, а именно в 2021/2022 годах, когда была операционная метрика reliability, но она была не про software delivery performance, а вот текущая великолепная пятерка - это уже именно delivery metrics.
P.S.
В чате @ai4sdlc вчера обсуждали метрики и было предложение просто использовать DORA. В итоге, я решил написать этот пост, чтобы показать, что даже DORA не просто так посчитать, а еще само понимание метрик дрифтит со временем:)
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership
Долгие году у DevOps Research & Assesment или попросту DORA было 4 метрики, на которых строилась кластеризация команд по разным уровням элитности. Эти метрики были про скорость поставки и стабильность
- Скорость поставки: deployment frequency и lead time for changes
- Стабильнсоть: MTTR / time to restore service и change fail rate
Подробнее эту историю можно прочитать в моем разборе книги "Accelerate")
С января 2026 года у DORA стало 5 software delivery performance metrics, которые на их сайте тоже разбиты на две категории
1️⃣ Throughput - пропускная способность системы
- Change lead time - время от коммита до успешного деплоя в прод
- Deployment frequency - как часто вы выкатываете изменения
- Failed deployment recovery time - как быстро вы восстанавливаетесь именно после неудачного деплоя
2️⃣ Instability
- Change fail rate - доля деплоев, требующих немедленного вмешательства
- Deployment rework rate - доля незапланированных деплоев, которые пришлось делать из-за прод-инцидента / дефекта
Возникает вопрос, а что именно изменилось по сравнению со старой моделью и зачем это было сделано?
Вообще, измений было два и оба они важные
1) Старый MTTR / time to restore service в 2023 был уточнен и переопределен как failed deployment recovery time. DORA прямо объясняет это тем, что старое определение смешивало проблемы, вызванные изменением в коде, и внешние инциденты вроде outage в датацентре. Новая формулировка лучше статистически "сцепляется" именно с delivery-метриками.
2) В 2024 DORA добавила новую пятую метрику - deployment rework rate. Их логика была такой: change fail rate хорошо ловит немедленные проблемы после релиза, но плохо отражает объем последующей незапланированной переделки. Поэтому DORA решила отдельно измерять rework как самостоятельную часть instability.
Если же говорить про использование метрик, то возникает вопрос: а теперь классификация будет идти по 5 метрикам?
И тут по сути ответ "да", но есть нюансы ... ребята из DORA отдельно подчеркивают, что число кластеров не фиксировано и не задается вручную. В FAQ они пишут, что кластеры у них emergent from the data: до 2018 обычно было 3, с 2018 по 2021 - 4, в 2022 снова 3, а в 2023 и 2024 - опять 4. То есть фиксированного "всегда 4 класса команд" больше воспринимать не стоит.
Если подумать, а что это значит для обычных технических руководителей (кто не упарывается по методолгии и метрикам)?
Кажется, что DORA стала лучше различать два разных вида проблем:
- Немедленный фейл после релиза → change fail rate
- Отложенная незапланированная переделка из-за продовых проблем → deployment rework rate
Это полезно, потому что команда может выглядеть "нормально" по rollback/hotfix сразу после релиза, но при этом системно тонуть в незапланированном rework через день-два. В старой 4-метричной модели это было видно хуже; в новой - видно лучше. Это и есть главное содержательное обновление модели.
Отдельно стоит сказать, что 5 метрик бывало в DORA и раньше, а именно в 2021/2022 годах, когда была операционная метрика reliability, но она была не про software delivery performance, а вот текущая великолепная пятерка - это уже именно delivery metrics.
P.S.
В чате @ai4sdlc вчера обсуждали метрики и было предложение просто использовать DORA. В итоге, я решил написать этот пост, чтобы показать, что даже DORA не просто так посчитать, а еще само понимание метрик дрифтит со временем:)
#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership