DevOps Research and Assessment — программа исследований поставки ПО

Зачем вам DORA

DORA — сокращение от DevOps Research and Assessment, «исследование и оценка DevOps». Так называется программа, которую ведёт команда Google Cloud: с 2014 года она каждый год опрашивает инженеров по всему миру и считает, чем быстрые команды поставки отличаются от медленных. В отчёте 2021 года сведены данные семи лет и больше 32 000 специалистов со всего мира10. Весь материал открыт по лицензии CC BY 4.0 — пользоваться и переделывать можно, указав авторство1.

Метрики DORA — то, во что этот ответ упакован: пять показателей, по которым видно, как у команды устроена доставка изменений до пользователя3. Ниже они с определениями.

И сразу поправка, ради которой стоит дочитать: метрик пять, а не четыре. Пятую добавили в 2024 году, а одну из прежних до этого переименовали и переопределили2. Формулировка «четыре ключевые метрики» без оговорки «до 2024 года» сегодня неверна.

Нужен, если вы хотите измерять поставку ПО и не изобретать метрики самостоятельно.

Нужен, если спорите с бизнесом о скорости: с 2015 года исследование показывает, что скорость и стабильность растут вместе, а не одна за счёт другой2.

Нужен, если ищете, за какие способности взяться, чтобы сдвинуть показатели: у программы есть каталог с разбором каждой.

Не нужен как оценка людей. Метрики измеряют поток поставки одного приложения, а не производительность разработчика.

Годовой отчёт бесплатен, но выдаётся после заполнения формы на площадке владельца7, и здесь его нет. Ниже — что программа меряет, какие пороги в ней считались хорошими, как она менялась и где её применяют неправильно.

Пять метрик, а не четыре

Метрики считают не по компании и не по отделу, а по одному приложению или сервису3. Три слова, без которых список ниже не читается. Коммит — момент, когда разработчик отправил свой код в общее хранилище с историей изменений, в репозиторий. Развёртывание (деплой) — выкладка новой версии в ту среду, где ею пользуются. Продуктивная среда (продакшен, «прод») — рабочая среда, в которой система живёт для пользователей.

Владелец свода, Google Cloud, сводит пять показателей в две группы — сам он называет их факторами3.

Пропускная способность поставки — насколько быстро изменение доходит до пользователя.

• Время прохождения изменения (change lead time) — сколько времени проходит от коммита до момента, когда этот код работает в продуктивной среде.
• Частота развёртываний (deployment frequency) — сколько развёртываний команда делает за период или сколько времени проходит между ними.
• Время восстановления после неудачного развёртывания (failed deployment recovery time) — сколько уходит на то, чтобы вернуть сервису работоспособность после развёртывания, последствия которого пришлось устранять срочно.

Нестабильность поставки — как часто быстрая поставка оборачивается сбоями и внеплановой работой.

• Доля неудачных изменений (change fail rate) — какая часть развёртываний потребовала немедленного вмешательства: отката или срочной заплатки.
• Доля переделок при развёртывании (deployment rework rate) — какая часть развёртываний внеплановая, то есть сделана ради починки того, что сломалось в продуктивной среде.

Почему меряют именно это. Частота развёртываний интересна не сама по себе: исследователям нужен был размер партии изменений — чем мельче порция, тем быстрее обратная связь, — а в разработке ПО его трудно измерить напрямую, и частота оказалась ближайшей заменой. Время прохождения считают от коммита, а не от замысла: у отрезка «от идеи до кода» начало размытое и разброс огромный, у отрезка «от кода до пользователя» — нет11.

Что изменилось в 2023 году. Метрика «среднее время восстановления» (mean time to recover, MTTR) переименована и переопределена: теперь это время восстановления после неудачного развёртывания. Причина названа прямо: прежние определения не отличали сбой, вызванный изменением кода, от сбоя из-за внешних причин вроде отказа центра обработки данных2.

Что изменилось в 2024 году. Появилась пятая метрика — доля переделок при развёртывании. Исследователи заметили: доля неудачных изменений говорит не столько об отказах, сколько о том, что команде приходится переделывать уже сделанное. Новая метрика считает это прямее — какая доля развёртываний оказалась внеплановой починкой23.

Ловушка при цитировании

В материалах владельца остались три несогласованности, и все три разошлись по пересказам.

Адрес страницы с описанием метрик у владельца до сих пор содержит слово «four-keys», хотя в её тексте речь о пяти3. В разделе вопросов и ответов и в интерактивной модели DORA Core осталась прежняя формулировка про четыре ключевые метрики, да и показаны в модели четыре412. Наконец, «пятой метрикой» в отчёте 2021 года назвали надёжность — и владелец сам это исправил: она описывает работу сервиса, а не поставку изменений2.

Ориентироваться стоит на статью об истории метрик2: только в ней владелец прямо говорит, что и когда менялось. Её обновляли 2 января 2026 года.

Группы эффективности и пороги

Команды в исследовании не расставляют по единой шкале. Программа сравнивает ответы и собирает похожие в группы, а сколько групп выйдет, заранее не задаёт: владелец пишет, что число кластеров он никогда не назначал, оно проступает из самих данных4. Потому и менялось. До 2018 года групп выходило три: низкая, средняя и высокая. С 2018 по 2021 их было четыре, тогда и появилась элитная группа. В 2022 году снова три, а в отчётах 2023 и 2024 годов опять четыре4.

Пороги — границы, по которым команду относят к той или иной группе, — тоже не постоянны, и это главное, что стоит знать до того, как цитировать любое число. Вот таблица из отчёта DORA за 2019 год по русскому изданию9. Названия метрик в ней прежние: «срок реализации изменений» здесь то же самое, что теперь зовётся временем прохождения изменения, а «время восстановления сервиса» — предшественник времени восстановления после неудачного развёртывания.

Через два года часть границ сместилась. У элитных команд время прохождения изменения стало меньше часа, а не меньше дня. Границу высокой группы по частоте развёртываний сдвинули до «от раза в неделю до раза в месяц». А доля неудачных изменений у высокой, средней и низкой групп получила один общий диапазон — 16–30 %10. Поэтому число, взятое из чужой статьи без года отчёта, описывает не ту планку, о которой думает читатель.

Насколько далеко расходятся группы, видно по крайним. В 2019 году элитные команды развёртывали в 208 раз чаще низких. Изменение доходило до пользователя в 106 раз быстрее, восстановление после сбоя — в 2 604 раза. А доля неудачных изменений у них была в 7 раз ниже9.

Порогов за 2022–2025 годы здесь нет намеренно: они опубликованы в отчётах, которые владелец отдаёт после заполнения формы, а пересказы поставщиков инструментов вместо первоисточника мы не берём. Прикинуть, где вы относительно остальных, можно быстрой самопроверкой на сайте владельца: она сравнивает ваши ответы с данными исследования 2025 года4.

Что такое DORA Core

Модель, в которую сведены самые устойчивые выводы программы: способности, метрики и результаты, которые исследование подтверждало из года в год4. Устроена она как цепочка из трёх звеньев12.

Способности — то, что команда умеет делать; их три группы. Климат для обучения: культура, качество внутренней документации, право команды выбирать инструменты. Быстрый поток: непрерывная поставка, автоматизация развёртывания, работа малыми партиями, контроль версий. Быстрая обратная связь: мониторинг и наблюдаемость, инженерия надёжности, сквозная безопасность, автотесты.

Эффективность — то, что из способностей получается, и меряют её двумя разными измерителями: поставку ПО — пятью метриками, надёжность — целями уровня услугУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation (SLOЦель уровня обслуживанияЧисло, которым задают требуемую надёжность услуги: какая доля обращений должна отрабатывать успешно и достаточно быстро.Google. Site Reliability Engineering, глава о целях уровня обслуживания).

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

Надёжность в модели стоит рядом с поставкой, а не внутри неё. Отсюда и путаница с «пятой метрикой»: у надёжности свой измеритель — цели уровня услуг, а не один из пяти показателей212.

Отсюда же правило работы с моделью. Улучшать метрику напрямую бессмысленно — она следствие. Работать надо со способностями, а метрику держать как измеритель.

Каталог способностей

У программы есть открытый каталог способностей с разбором каждой: что это, как измерять, какие ошибки типичны. Проверено 21.08.2026 — в каталоге около сорока карточек, часть помечена как основные5. В книге «Ускоряйся! Наука DevOps» Николь Форсгрен, Джеза Хамбла и Джина Кима, подводившей итог первым четырём отчётам, способностей было 2411: каталог растёт вслед за исследованиями.

Что там есть по темам5:

• непрерывная поставка и интеграция, автоматизация развёртывания;
• управление изменениями баз данных;
• качество внутренней документации;
• гибкая инфраструктура, наблюдаемость и оповещение;
• сквозная безопасность и упрощение согласования изменений;
• автоматизация тестирования и управление тестовыми данными;
• работа малыми партиями, ограничение незавершённой работыНезавершённая работаВсё, что начато и не закончено. Ограничение её объёма — главный рычаг Kanban.Kanban University. The Official Guide to The Kanban Method;
• культура обучения, самочувствие и удовлетворённость людей.

Свежее наблюдение. В каталоге появился отдельный раздел про искусственный интеллект. В нём пять способностей: внутренние данные доступны моделям; у организации есть понятная и объявленная позиция по ИИ; данные здоровы; налажена платформенная инженерия; работа идёт от пользователя5. Это прямое продолжение отчёта 2025 года, где вывод сформулирован так: ИИ работает усилителем — увеличивает и сильные, и слабые стороны организации7.

Что покрывает — и чего не покрывает

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

Важная оговорка о характере покрытия. Программа не описывает практикуПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 целиком — она называет способность и показывает, как та влияет на поставку. Это разбор одной грани, а не руководство по процессу: за устройством работы всё равно идут к сводам практик.

Чего нет совсем: денег, поставщиков, каталога услуг, управления активами, соглашений об уровне услуг. Программа смотрит на один участок пути — от коммита до пользователя.

Как менялась

Двенадцать годовых исследований подряд, с 2014 по 2025 год; отчёта за 2026 год у владельца пока нет6. Пять зарубок, которые объясняют сегодняшний вид программы:

• 2014 — первый отчёт те же трое авторов делали вместе с командой компании Puppet, и в этом партнёрстве вышли ещё четыре выпуска11. Начинали с четырёх переменных, но статистика первого года показала, что доля неудачных изменений не складывается с остальными в один показатель, и определение опиралось на три метрики2.
• 2015 — метрики разошлись на два фактора, пропускную способность и стабильность. Тогда же рухнул расхожий довод, что за скорость платят стабильностью: лучшие команды сильны в обоих2.
• 2018 — к метрикам поставки добавили доступность как меру работы сервиса, «ИТ-эффективность» сменилась на «эффективность поставки и эксплуатации», и появился верхний кластер, тот самый «элитный»26.
• 2021–2023 — доступность выросла до надёжности, в которую вошли ещё задержки, производительность и масштабируемость; MTTR стал временем восстановления после неудачного развёртывания2.
• 2024–2025 — пятая метрика, а в фокусе исследования платформенная инженерия, ориентация на пользователя и влияние ИИ6.

Чем отличается от соседей

От SRE. Инженерия надёжности сервисов отвечает, как удерживать работающий сервис; DORA — как измерить поток поставки. Пересечение одно: восстановление после сбоя.

От DevOps. У самого подхода нет ни владельца, ни измерителя. DORA и есть тот измеритель, которым чаще всего проверяют, случился ли переход на DevOps на самом деле.

От моделей зрелости. Модель зрелости присваивает уровень; здесь уровня нет — есть группы, посчитанные по данным опроса, и сравнение с ними. Авторы объясняли выбор так: уровень — отметка, поставленная однажды, а планка отрасли двигается, и вчерашняя высокая эффективность через год оказывается средней; поэтому работают со способностями, которые можно наращивать дальше11.

Сколько стоит

Ничего. Сайт программы открыт целиком, лицензия — CC BY 4.0: пользоваться и переделывать можно, указав авторство1. Быстрая самопроверка на сайте бесплатна.

Полный годовой отчёт тоже бесплатен, но выдаётся после заполнения формы с именем и рабочей почтой7. Это не то же самое, что свободное скачивание.

В России

ГОСТ-аналога нет. Поиск по базе Росстандарта по слову DORA даёт три документа, и все три — совпадения по подстроке внутри латинских названий эфирных масел8. К поставке ПО они отношения не имеют.

По-русски отчёты выходили: у выпуска 2019 года есть официальный перевод, по нему приведена таблица порогов выше9. У отчёта 2025 года сокращённые версии сделаны только на японском и корейском7.

Где ломается применение

Складывают метрики по всей компании. Владелец прямо предупреждает: смешивание показателей разных команд и тем более всей организации создаёт проблемыПроблемаПричина одного или нескольких инцидентов.ITIL3. Метрики считают по одному приложению или сервису.

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

Гонятся за элитным кластером. Кластер — описание распределения, а не цель. Целью остаётся ваш собственный результат для пользователя.

Улучшают метрику вместо способности. Метрика — следствие4. Работают со способностями из каталога, метрику держат как измеритель.

Цитируют «четыре метрики». С 2024 года их пять2.

Считают надёжность пятой метрикой. Надёжность относится к работе сервиса, её меряют целями уровня услуг, и в пятёрку метрик поставки она не входит212.

Берут пороги без года. Границы групп переезжают от отчёта к отчёту: то, что в 2019 году называлось высокой частотой развёртываний, в 2021-м описывало уже другую группу910.

С чего начать

1. Выберите одно приложение и посчитайте по нему две метрики пропускной способности за последний квартал. Не по всей компании — по одному.
2. Пройдите быструю самопроверку на сайте программы. Она даёт общий балл от 0 до 10, каждую из пяти метрик по отдельности, отдельно пропускную способность и стабильность — и сравнивает результат с данными исследования 2025 года4.
3. Возьмите из каталога одну способность, которая ближе всего к вашему узкому месту, и работайте с ней. Метрику перемеряйте через квартал.

Что читать дальше

Рядом три свода: SRE — инженерия надёжности работающих сервисов; DevOps — сам подход к совместной работе разработки и эксплуатации; ISO/IEC/IEEE 32675 — стандарт, который этот подход нормирует.