28 записей с тегом "dora-metrics"

Swarmia это самый «чистый» Git-driven инструмент инженерной аналитики на рынке. Достаёт коммиты, PR и деплои, считает DORA, показывает cycle time на уровне команды и не лезет в процесс. Большинство команд, которые её покупают, остаются довольны на год-два. Потом всплывает вопрос, на который инструмент изначально не рассчитан (обычно про деньги, on-prem или то, что реально происходит вне PR), и начинается поиск.

Если в 2026 году вы вбиваете «swarmia альтернатива», эту задачу мы и разбираем.

В среднем post-mortem пишется 4 часа и порождает ноль action items, которые команда закрывает в течение 30 дней. Мы посмотрели на 120 post-mortem документов у трёх наших on-prem клиентов перед тем, как собрать этот шаблон. 83% action items оставались в статусе "open" через полгода. Это не разбор инцидента — это кладбище документов.

Post-mortem имеет смысл писать только если он что-то меняет. Всё остальное — прикрытие.

Согласно отчёту McKinsey о продуктивности разработчиков (2023), инженеры тратят лишь 25–30% времени на написание кода. Остальное исчезает в митингах, ожидании и процессном оверхеде. DORA-метрики существуют, чтобы сделать эту невидимую трату видимой — и исправимой.

Если вы CTO, VP of Engineering или Engineering Manager, который ещё не внедрил DORA — вы управляете по интуиции в эпоху, которая требует доказательств. Это руководство охватывает всё: что измеряет каждая метрика, как сравнить свою команду с бенчмарками, как внедрить отслеживание и какие ошибки превращают данные DORA в бесполезный мусор.

Исследование Stripe «Developer Coefficient» (2018) оценило, что $300 миллиардов ежегодно теряется глобально из-за неэффективности разработчиков. Значительная доля этих потерь скрыта внутри одной метрики: Lead Time. Lead Time в 5 дней не говорит вам ничего. Это 4 дня кодинга и 1 день ревью? Или 1 день кодинга и 4 дня ожидания, пока кто-то откроет ваш merge request? Решение для каждого сценария совершенно разное — и если вы воспринимаете Lead Time как одно число, вы решаете не ту проблему.

Accelerate State of DevOps Report (2023) показал, что элитные команды деплоят по запросу, несколько раз в день — и при этом у них меньше инцидентов в продакшене, чем у команд с ежемесячным циклом. За десять лет исследований и 36 000+ опрошенных данные однозначны: более частый деплой не означает больше поломок. Тем не менее большинство команд застряли в ежемесячных релизных циклах, воспринимая частоту как риск вместо митигации риска. Вот практический план, как это изменить.

Когда VP of Engineering говорит мне, что их Change Failure Rate — 0%, я не поздравляю. Я спрашиваю, что они не учитывают. Исследование Stripe «Developer Coefficient» (2018) оценило, что $300 миллиардов ежегодно теряется глобально из-за плохого кода и неэффективных процессов — и значительная часть этих потерь скрывается за нереалистичными метриками качества. 0% CFR почти всегда означает, что команда либо деплоит так редко, что каждый релиз тестируется до состояния паралича, либо — что чаще — определение «сбоя» настолько узкое, что реальные инциденты в него не попадают.

Книга Google Site Reliability Engineering (2016) популяризировала контринтуитивный принцип: примите неизбежность сбоев и инвестируйте в скорость восстановления. Исследования DORA подтвердили это данными — разница между элитными и отстающими командами не в том, что у элитных меньше инцидентов, а в том, что они восстанавливаются менее чем за час вместо недели. Каждая инженерная организация инвестирует в предотвращение сбоев. Немногие инвестируют в быстрое восстановление после них. Данные говорят, что приоритеты расставлены наоборот.

Stack Overflow Developer Survey (2023) показал, что удовлетворённость разработчиков напрямую предсказывает удержание и качество результата. Одновременно DORA-метрики предсказывают эффективность организации. Тем не менее многие инженерные лидеры рассматривают эти подходы как конкурирующие, а не как взаимодополняющие линзы. В 2026 году проблема не в нехватке фреймворков — а в выборе правильной комбинации. DORA, SPACE и DevEx — каждый заявляет, что измеряет «продуктивность разработчиков». Ни один из них не измеряет одно и то же.

Вот как разобраться в этом шуме.

Большинство попыток внедрения DORA проваливаются не из-за инструментов или данных — а потому что превращаются в 6-месячные проекты, умирающие в комитетах. Исследование Accelerate (Forsgren, Humble, Kim, 2018) показало, что организации с видимыми метриками доставки улучшаются быстрее. Ключевое слово — видимыми: дашборд, на который никто не смотрит, хуже, чем отсутствие дашборда, потому что создаёт иллюзию измерения. Вот пошаговый план: от нуля до рабочих DORA-дашбордов за две недели — достаточно быстро, чтобы инерция не рассеялась.

Регуляция — не враг скорости; отсутствие измерений — вот настоящий враг. State of DevOps Report (2023) показывает, что финансовые организации из верхнего квартиля деплоят ежедневно, поддерживая при этом более строгий контроль изменений, чем их медленные коллеги. Когда аудитор спрашивает «как вы обеспечиваете контролируемость и надёжность процесса деплоя?», нужен ответ лучше, чем «у нас есть код-ревью». DORA-метрики дают такой ответ — с количественными доказательствами, которые аудиторы и комитеты по рискам могут реально проверить.