DORA Metrics

Я регулярно вижу команды, которые «внедрили DORA», нарисовали дашборд с четырьмя цифрами и больше к ним не возвращаются. Это не DORA, это украшение Confluence. Четыре метрики — deployment frequency, lead time for changes, change failure rate, MTTR — нужны как материал для регулярного разговора: почему лид-тайм растёт, что не так с pipeline, где сжимается фидбэк. Без разговора цифры превращаются в vanity-метрики, по которым отчитываются перед менеджментом. С разговором они становятся самым дешёвым SRE-сигналом, который у команды вообще есть: данные уже лежат в git и CI, считать почти ничего не надо. Лист — про то, что делает измерение работающим, и где Goodhart’a ловит чаще всего.

DORA — это не «теперь у нас 4 KPI вместо двух». Это эмпирическое исследование (Forsgren, Humble, Kim), которое показало корреляцию между delivery-производительностью и бизнес-результатами. Метрики — индикаторы профиля команды, а не цель. Граница со SLO / Budget Review важная: SLO меряет, как сервис ведёт себя для пользователя; DORA — как команда доставляет изменения. Команда может иметь идеальный SLO и при этом катастрофический lead time (release раз в квартал, всё стабильно потому что ничего не двигается) — это не «всё хорошо», это противоположный профиль команды.

Что должен уметь

Главный навык на уровне L5 — читать четыре метрики как систему, а не каждую отдельно. Высокая deployment frequency при растущем change failure rate — команда катит быстро и ломает; низкий lead time при стабильном MTTR — pipeline быстрый и команда умеет восстанавливаться; высокий lead time при низком change failure rate — heavy review gates с риском теряемых возможностей. Каждая комбинация требует разных решений. Я регулярно вижу попытки «улучшить одну метрику» — это путь к манипуляции данными, не к улучшению потока.

Понимает, что такое каждая из четырёх метрик и как она считается из git/CI-данных (commit → merge → deploy → first incident).
Читает дашборд DORA своей команды и понимает, какие тренды что означают.

Настраивает сбор четырёх метрик для своего сервиса из CI-логов / git-истории; различает «deploy в staging» и «deploy в prod» в подсчёте deployment frequency.
Считает change failure rate из связи deploy ↔ incident: какие инциденты считаются failure (rollback, hotfix, customer-facing degradation), какие — нет.

Фасилитирует регулярный разговор по DORA в команде: тренды за квартал, что изменилось в pipeline / процессе, какие решения принимаем на следующий период.
Различает vanity-улучшение (deployment frequency через micro-commits без бизнес-значения) от реального улучшения потока; не позволяет оптимизировать одну метрику за счёт остальных.
Связывает DORA с org-level решениями: систематически плохой lead time → инвестиция в pipeline или progressive delivery; растущий change failure rate → инвестиция в pre-deploy testing / canary.

L6+

Внедряет DORA как стандарт измерения в нескольких командах / org-wide; согласует определения (что такое «deploy», «failure»), чтобы цифры разных команд были сопоставимы.
Защищает DORA от превращения в KPI с премиями: «команда A elite, команда B low» по DORA-классификации — это путь к манипуляции данными в течение квартала.

Материалы

Книги

Nicole Forsgren, Jez Humble, Gene Kim — Accelerate (IT Revolution, 2018). Главный источник, эмпирическая база. Объясняет, почему именно эти четыре метрики и как они коррелируют с бизнес-результатами. Если читать одну книгу про DORA — эту. Главы 2–4 — основа; остальное — методология исследования.
Gene Kim, Patrick Debois, John Willis, Jez Humble — The DevOps Handbook (IT Revolution, 2-е изд., 2021). DORA в более широком контексте Three Ways. Не заменяет Accelerate, но даёт операционную обвязку — как встроить измерение в практику.

Статьи и доклады

DORA — State of DevOps Report. Ежегодный отчёт с 2014 года; с 2018 — под Google после поглощения. Главный публичный кейс DORA в живом времени: видно, как сами метрики уточняются (Reliability добавили в 2021, Documentation в 2023, AI Adoption в 2024).
DORA — Quick Check. Короткий опрос, где команда оценивает себя по 4 метрикам и попадает в один из профилей (Low / Medium / High / Elite). Я использую не как «приговор», а как стартовую точку разговора — что мешает двигаться выше.
DORA — Capabilities catalog. 27 practices, которые DORA-исследование выделяет как драйверы улучшения метрик. Полезно как чек-лист «что попробовать», когда тренд застрял.
Charity Majors — The Engineer-Manager Pendulum. Не про DORA напрямую, но раскрывает, почему DORA как KPI с премией — путь к манипуляции и плохим решениям.

Инструменты

Four Keys (Google open source, архивен с 2023) — reference-имплементация сбора 4 метрик из GitHub / GitLab / Cloud Build. По моим наблюдениям, чаще берут как архитектурный референс, чем как production-решение: репо архивен, поддержка не гарантирована. Полезно посмотреть, как они определили source-of-truth для каждой метрики.
LinearB, Sleuth, Faros AI — коммерческие платформы. По моему опыту, оправданы в организациях от 50+ инженеров, где нужно сравнение между командами и unified definitions. В команде до 10 человек — overengineering.
Self-hosted из git/CI-логов. Самый частый рабочий вариант для команды среднего размера: SQL-запрос по deploy-таблице из CI + связка с инцидентами из PagerDuty / Opsgenie. Я регулярно вижу команды, у которых это просто Grafana-дашборд поверх Postgres. Стартовая точка — формула из Four Keys, реализованная на своих данных.
DIY Spreadsheet. Для команды 3–5 человек на старте — нормально. Не строить дашборд раньше, чем понятен ответ на вопрос «что мы будем делать с этим числом».

Best practices

Самый часто цитируемый публичный кейс — само DORA-исследование. За 10 лет State of DevOps Report показал, что элитные команды по 4 метрикам имеют выше операционную производительность и удовлетворённость сотрудников. Это не «4 метрики делают команду elite», это «эти 4 метрики коррелируют с тем, что команда умеет работать хорошо». Подмена «индикатор → цель» — главная ошибка, которую я наблюдаю при внедрении.

Короткие правила:

DORA — материал для разговора, не дашборд для менеджмента. Антипаттерн: «у нас есть DORA-дашборд, в красном квадрате — change failure rate». Без регулярного ритуала анализа (раз в месяц / квартал, в зависимости от cadence изменений) дашборд устаревает и его перестают открывать. Правильно — регулярная встреча, где команда смотрит на тренды и принимает решения по pipeline / процессу.
Считайте метрики из реальных данных, не из опроса. Антипаттерн: оценка по DORA Quick Check как единственный источник — «мы думаем, что мы High». Правильно — сбор из git/CI/incident-таблиц. Self-assessment полезен как стартовая точка, но цифры из логов спорить с ощущениями.
Единое определение «deploy» и «failure» на команду. «У нас deployment frequency 50/день» в команде, где deploy в staging считается за deploy, не сопоставимо с командой, где считается только prod. То же с change failure rate: считается только rollback или любой hotfix в течение 24 часов? Без явного определения сравнения бессмысленны.

Подробнее:

Goodhart’s Law — главная ловушка DORA. Закон Goodhart’a гласит: «when a measure becomes a target, it ceases to be a good measure». Я регулярно вижу команды, которые решили «улучшить deployment frequency» и начали дробить коммиты на микро-изменения без бизнес-смысла, чтобы их сосчитал pipeline. Через квартал deployment frequency вырос вдвое, lead time для значимого изменения остался прежним, а команда устала от ритуала. То же с MTTR: если он становится KPI, инциденты закрываются как resolved до реальной mitigation, чтобы укладываться в SLA метрики. DORA-метрики работают как диагностический индикатор, не как target: если число изменилось — спрашиваем, почему, и работаем с причиной. Если работаем с самим числом — это уже не измерение, это театр.

Четыре метрики — система, не четыре независимых KPI. Высокий deployment frequency при низком change failure rate — норма для зрелого pipeline с canary и feature flags; высокий deployment frequency при высоком change failure rate — катят слишком быстро без safety nets. Низкий lead time при низкой deployment frequency — pipeline быстрый, но что-то блокирует release decision (heavy approval gates? страх release? отсутствие feature flags?). По моему опыту, оптимизировать одну метрику изолированно — это либо случайно улучшить остальные (счастливый случай), либо повредить им (типичный случай). Разговор всегда про профиль четырёх чисел, а не про «насколько хорошо» каждое из них.

Команда — не индивидуум. DORA-метрики осмысленны для delivery team — группы, которая владеет сервисом end-to-end. Считать DORA для отдельного инженера или для всей engineering-организации одинаково бессмысленно. Для инженера это превращает работу в гонку коммитов; для org-wide значения теряют сигнал, потому что усредняются между командами с разной природой работы (платформенная команда vs продуктовая vs research). Правильный масштаб — service team из 5–10 инженеров, владеющих общим code base.

Elite / High / Medium / Low — категории для разговора, не для премии. DORA-классификация полезна как точка отсчёта: «мы где-то в medium по deployment frequency и high по change failure rate, значит у нас pipeline-issue, не quality-issue». Превращение этой категории в KPI с премией («перейти из medium в high до конца года») — путь к манипуляции цифрами и потере сигнала. Я считаю, что командам стоит знать свою категорию и тренд, но не привязывать её к compensation. Из всех плохих способов использовать DORA это, по моим наблюдениям, самый разрушительный.

Связанные листья

SLO / Budget Review — две оси измерения, не одна. SLO про сервис для пользователя, DORA про команду доставляет изменения. Зрелая команда смотрит и туда и туда.
Toil Tracking — toil ratio дополняет DORA третьей осью: что внутри команды занимает время. Команда с elite DORA и 60% toil — sustainability-проблема, которой DORA не видит.
Progressive Delivery — один из самых сильных рычагов улучшения сразу нескольких DORA-метрик: deployment frequency растёт (мелкие release-ы безопаснее), MTTR падает (быстрый rollback / kill switch), change failure rate падает (canary ловит до broad rollout).
CI/CD — инженерная основа deployment frequency и lead time; без работающего CI/CD говорить о DORA преждевременно.
Change Governance — heavy change approval boards проявляются как растущий lead time; DORA — самый прямой способ показать стоимость bureaucratic gate.
Postmortem Culture — change failure rate и MTTR — суммарный сигнал того, что выходит из постмортемов; ритуал ревью DORA — место, где этот сигнал превращается в приоритеты.
Dev Team Partnership — DORA-разговор с участием dev-команды — основной канал, где shared accountability за delivery proявляется в работе с общими цифрами.
Stakeholder Management — DORA-числа — один из лучших источников business-переводимых метрик для non-engineering audience; deployment frequency / lead time понимаются executive легче, чем p99 latency.

Открытые вопросы

Cadence DORA-ревью (раз в неделю / месяц / квартал) зависит от deployment frequency и размера команды. Универсального ответа я не нашёл; чаще встречаю месячный.
Reliability как пятая метрика (введена DORA в 2021) — пока сосуществует со SLO. Я не уверен, что это полезное добавление: реляйбилити-сигнал, по моему опыту, лучше живёт в SLO-дашборде, а не в DORA. Если у вас есть рабочая практика — расскажите через PR.
Я не уверен, что DORA-метрики осмысленны в командах с очень редким release-циклом (mainframe, embedded, regulated firmware), где deployment frequency измеряется месяцами и lead time — кварталами. В Accelerate такие команды не покрыты.