2.10 Фреймворк метрик DORA

Обзор и мотивация

Метрики DORA происходят из программы DevOps Research and Assessment, многолетнего исследовательского усилия, позже опубликованного как книга Accelerate Николь Форсгрен, Джезом Хамблом и Джином Кимом, которая опросила десятки тысяч инженерных специалистов, чтобы найти, какие практики доставки коррелируют с организационной эффективностью. Результатом стали четыре метрики, парные по две: частота развёртывания и время выполнения для изменений измеряют скорость; доля неудачных изменений и время восстановления после неудачного развёртывания, часто сокращаемое до среднего времени восстановления (MTTR), измеряют стабильность. Исследовательская находка, сделавшая фреймворк значимым, заключалась в том, что элитные исполнители были одновременно быстрыми и стабильными, опровергая предположение, что скорость и безопасность обмениваются друг на друга, и эта находка по-прежнему самый ясный разобранный пример этой книги для принципа сочетания со страховочной метрикой из темы 1.2: стимулируемая метрика скорости, сочетаемая со страховочной метрикой стабильности, это то, что фактически делают организации с наилучшей эффективностью.

Эта книга покрывает DORA последней в этой части, намеренно, а не как организующий фреймворк части. Это размещение не отрицание исследования, которое остаётся подлинно строгим и достойным использования. Оно отражает конкретное реальное ограничение: DORA измеряет, насколько быстро и насколько безопасно движется конвейер, но молчит о том, что движется через конвейер. Команда может показывать отличные показатели DORA, пока её фактический выпуск тихо дрейфовал к переделке дефектов или лишал мощности технический долг и работу над безопасностью, паттерн, который Flow Framework (темы с 2.1 по 2.4) специально построен для того, чтобы раскрывать, а DORA не может его увидеть. Используйте DORA так, как представляет её эта тема: хорошо проверенную более узкую справочную меру механики конвейера, а не полную картину здоровья доставки.

Для крупных команд оставшаяся подлинная ценность DORA это сравнимость. Метрика, последовательно вычисленная из данных конвейера и инцидентов, позволяет организации сравнивать возможность доставки по многим командам, работающим в разных областях, без проблемы сравнения несравнимого, терзающей большинство межкомандных сравнений. Корпоративные организации всё ещё используют её для приоритизации платформенных инвестиций; государственные организации всё ещё используют её, чтобы продемонстрировать с доказательствами, что программа модернизации измеримо улучшила механику доставки. Относитесь к этому как к надлежащей ограниченной работе DORA и используйте темы Flow Framework ранее в этой части для более широкого вопроса о том, доставляется ли вообще правильное.

Ключевые принципы

DORA измеряет конвейер, а не ценность, текущую через него. Тема 2.1 называет этот пробел напрямую; используйте распределение потока (тема 2.3), чтобы увидеть то, что не может DORA.
Скорость и стабильность измеряются вместе, никогда отдельно. Дашборд, информированный DORA, без обеих половин на самом деле не использует фреймворк.
Согласованность определения важнее сырого числа. Команда, движущаяся от «среднего» к «высокому» уровню эффективности по последовательно определённой метрике, это реальный сигнал; сравнение двух команд, вычисленных по-разному, не является таковым.
DORA измеряет систему, а не отдельных людей. Применение этих метрик к отдельным инженерам ломает статистическую основу фреймворка и приглашает именно то манипулирование, против которого предупреждает тема 1.2.
Все четыре метрики представители, а не цели. Они коррелируют с организационной эффективностью; погоня за самим числом, оторванным от подлинного улучшения доставки, сводит на нет цель фреймворка.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Полный фреймворк DORA, все четыре метрики в паре	Подтверждён исследованиями, сопротивляется манипулированию через сочетание, обеспечивает справедливое межкомандное сравнение	Молчит о том, какого рода ценность доставляется; нуждается в Flow Framework наряду с собой для этой картины
DORA как единственный организующий набор метрик этой части	Прост, знаком большинству инженерных лидеров	Полностью упускает вопрос смеси ценности, причину этой книги для понижения его приоритета здесь
DORA плюс Flow Framework вместе	Видны и механика конвейера, и смесь ценности	Требует поддержания двух словарей метрик вместо одного
DORA, применённая на индивидуальном уровне	Ощущается напрямую действенной для некоторых менеджеров	Ломает статистическую обоснованность фреймворка; сильная подверженность закону Гудхарта

Центральное напряжение: механическая строгость против разборчивости для бизнеса. Четыре метрики DORA точно определены и подтверждены исследованиями, что делает их отличными для сравнения эффективности конвейера между командами, но эта же точность узко ограничена самим конвейером и ничего не говорит о том, течёт ли через него правильная работа. Разрешайте это напряжение, удерживая DORA как справочный слой для здоровья конвейера, надлежащее место темы 2.10 в структуре этой книги, в то время как темы Flow Framework ранее в этой части используются для обращённого к бизнесу вопроса о смеси ценности, а не пытаясь заставить DORA отвечать на вопрос, для ответа на который она никогда не была спроектирована.

Вопросы для обсуждения в команде

Инструментируем ли мы все четыре метрики DORA из конвейера, или некоторые из них самоотчётные оценки? Фреймворк, построенный на объективном подтверждённом исследованиями измерении, теряет большую часть своей ценности в момент, когда число становится наилучшей догадкой. Проверьте фактический источник данных каждой метрики (тема 1.5).
Разделяют ли все команды, которые мы сравниваем, используя метрики DORA, одни и те же определения развёртывания, изменения и сбоя? Сравнение между командами, использующими разные определения, на самом деле не является сравнением и может производить несправедливые суждения об относительной эффективности.
Использовал ли кто-либо в нашей организации метрику DORA в индивидуальном обзоре эффективности, формально или неформально? Это самое разрушительное неправильное использование фреймворка, и оно часто происходит тихо. Спросите напрямую и будьте готовы к неудобному, но необходимому ответу.
Могут ли наши числа DORA быть отличными, пока наше распределение потока (тема 2.3) тихо дрейфовало к переделке или прочь от функций? Это именно тот пробел, который одна DORA не может увидеть. Возьмите оба набора чисел вместе и проверьте, рассказывают ли они согласованную историю.
Когда одна из наших метрик DORA сдвигается, есть ли у нас диагностика метрик потока, чтобы объяснить почему? Одно число DORA говорит вам, что что-то изменилось, но не что именно. Проверьте, могут ли ваши команды ответить «почему время выполнения выросло в этом месяце» данными, а не только спекуляцией.
Как изменились бы наши четыре числа DORA, если бы мы намеренно попытались подделать каждое из них, и заметили бы мы это? Пройдите через частоту развёртывания, время выполнения, долю неудачных изменений и время восстановления по одному, практическое применение основной дисциплины темы 1.2 к этому конкретному фреймворку.

Отраслевой взгляд

Стартап. Метрики скорости DORA обычно приходят естественно к маленькой команде, уже часто развёртывающейся; более сложная дисциплина честно инструментировать долю неудачных изменений и время восстановления, а не предполагать стабильность только потому, что ничего ещё сильно не сломалось. Сочетание DORA даже с неформальным разделением элементов потока (тема 2.2) рано избегает построения ложного ощущения здоровья доставки вокруг одной только скорости конвейера.

Малый бизнес. Большинство современных платформ CI/CD и контроля версий экспортируют данные частоты развёртывания и времени выполнения с минимальной настройкой; связывание развёртываний с инцидентами для доли неудачных изменений обычно требует больше ручных усилий. Начните с двух метрик скорости и добавьте отслеживание стабильности, как только появится неформальный журнал инцидентов, с которым можно связывать.

Корпорация. Наибольшая оставшаяся ценность DORA в этом масштабе это справедливое последовательное межкомандное сравнение для решений о платформенных инвестициях. Стандартизируйте определения по всей организации (тема 1.4), автоматизируйте инструментирование централизованно и сочетайте каждый отчёт DORA с видом распределения потока, чтобы руководство видело вместе и скорость конвейера, и смесь ценности, а не одно без другого.

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

Примеры

Корпорация. Программа модернизации платформы крупной телекоммуникационной компании последовательно инструментировала все четыре метрики DORA по сорока продуктовым командам и показала подлинное движение от band низкой эффективности к band высокой эффективности за восемнадцать месяцев, частота развёртывания выросла примерно в десять раз, время выполнения упало с недель до дней, доля неудачных изменений осталась плоской. Член совета директоров, рассматривая презентацию, задал вопрос, на который одни числа DORA не могли ответить: сколько из этой более быстрой доставки было новой клиентской ценностью против переделки. У инженерной организации не было ответа, пока она не приняла классификацию элементов потока в следующем квартале, которая показала, что функциональная работа на самом деле упала как доля общего выпуска, даже когда числа скорости DORA улучшились, находка, переформировавшая приоритеты программы на следующий год.

Государство. Офис модернизации ИТ правительства штата принял метрики DORA как условие контракта, чтобы сравнить возможность доставки нескольких конкурирующих командных поставщиков, эффективное использование сравнимости фреймворка. Высокая частота развёртывания одного поставщика, как только доля неудачных изменений была потребована наряду с ней, оказалась коррелирующей с долей сбоев почти втрое выше, чем у его коллег, информация, напрямую информировавшая решение офиса о продлении контракта. Офис позже добавил требование распределения потока к тем же контрактам после обнаружения, что поставщик с лучшими числами DORA был также тем, кто тратил наименьшую долю мощности на работу по устранению уязвимостей безопасности, которую контракт конкретно требовал.

Бизнес-кейс: мотивация, ROI и TCO

Отдача от хорошего принятия DORA, в её надлежащем охвате, защитимый обоснованный доказательствами ответ на «становится ли наш конвейер доставки быстрее и безопаснее», что остаётся одним из более решаемых вопросов в инженерии, на который можно уверенно ответить. Этот ответ обосновывает инвестиции в платформу и инструментарий реальными числами и позволяет руководству сравнивать конкурирующие инвестиции на справедливой последовательной основе, именно так, как это всегда было.

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

Антипаттерны и ловушки

Отношение к DORA как к полной картине здоровья доставки: вектор манипулирования, против которого призвано противостоять размещение этой темы. Организация может представить подлинно отличные числа DORA, быстрые частые стабильные развёртывания, пока её фактически доставленная ценность тихо сдвигалась к переделке или прочь от функций, и одни только четыре метрики DORA никогда не раскроют этот сдвиг, потому что они никогда не были спроектированы его измерять. Страховка сочетание каждого отчёта DORA с распределением потока (тема 2.3), так что быстрый стабильный конвейер, доставляющий неправильную смесь работы, виден, а не ошибочно принят за подлинное здоровье доставки.
Сообщение только половины скорости DORA: сводит на нет центральную находку фреймворка о том, что скорость и стабильность движутся вместе у высокоэффективных исполнителей.
Использование метрик DORA в индивидуальных обзорах эффективности: ломает статистическую обоснованность фреймворка и приглашает сильное манипулирование.
Сравнение команд с несогласованными определениями: производит сравнения, выглядящие справедливыми, но таковыми не являющиеся.
Самоотчётные числа DORA вместо инструментированных конвейером: вносит именно ту предвзятость, которую фреймворк был спроектирован устранить.
Отношение к DORA как к диагностике, а не сводке: оставляет команду неспособной объяснить, почему число сдвинулось, без лежащего под ним слоя метрик потока.

Модель зрелости

Уровень 1, Инициация: Метрики DORA, если вообще отслеживаются, самоотчётные, непоследовательно определены и никогда не сочетаются с данными потока.
Уровень 2, Развитие: Некоторые команды инструментируют DORA из конвейера, но определения различаются, и нет соответствия распределения потока для проверки.
Уровень 3, Стандартизация: Все четыре метрики DORA последовательно инструментированы из данных конвейера и инцидентов, с общими определениями, и регулярно показываются наряду с распределением потока.
Уровень 4, Управление: DORA и метрики потока рассматриваются вместе как стандартное сочетание на каждом уровне организации, и DORA никогда не используется для индивидуальной оценки.
Уровень 5, Оркестрация: Организация может указать на конкретные случаи, когда распределение потока поймало проблему смеси ценности, которую одни отличные числа DORA скрывали, и сознательно использует оба фреймворка для различных вопросов, на которые каждый отвечает.

Идеи для обсуждения

Где наши четыре метрики DORA сейчас честно размещают нас на спектре уровней эффективности?
Могли бы наши числа DORA выглядеть отлично, пока наше распределение потока тихо дрейфовало? Проверяли ли мы это когда-либо?
Использовал ли кто-либо когда-либо число DORA, чтобы судить отдельного человека, даже неформально?
Если бы конкурент опубликовал свои числа DORA, сравнивались бы наши благоприятно, и действительно ли это сравнение сказало бы нам, кто доставляет больше реальной ценности?

Основные выводы

Четыре метрики DORA, частота развёртывания, время выполнения, доля неудачных изменений и время восстановления, сочетают скорость со стабильностью по замыслу и остаются подлинно подтверждёнными исследованиями.
Эта книга размещает DORA последней в этой части, потому что она измеряет конвейер, а не ценность, текущую через него; сочетайте её с распределением потока (тема 2.3) для более полной картины.
Центральный вектор манипулирования этой темы ошибочное принятие отличных чисел DORA за полное здоровье доставки; страховка всегда сообщать DORA наряду с распределением потока.
Никогда не используйте метрики DORA в индивидуальных обзорах эффективности; обоснованность фреймворка зависит от измерения на уровне системы, а не индивида.
Используйте метрики потока как диагностический слой под сводными числами DORA, когда одно из них сдвигается.

Источники и дальнейшее чтение

Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
Google Cloud. Программа DevOps Research and Assessment. dora.dev.
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013.
Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook. IT Revolution Press, 2016.
Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.

2.10 Фреймворк метрик DORA

Обзор и мотивация

Ключевые принципы

Рекомендации

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

Инструментируйте время выполнения для изменений от первого коммита до продакшена

Определите долю неудачных изменений письменно, прежде чем сравнивать между командами

Измеряйте время восстановления от обнаружения, а не от события развёртывания

Используйте метрики потока, а не DORA, чтобы диагностировать, почему число сдвинулось