DORA Metrics in Plain English: How to Discuss Deployment Frequency and MTTR (англійською)

Метрики DORA — розроблені командою DevOps Research and Assessment — є найпоширенішою структурою для вимірювання продуктивності доставки програмного забезпечення. Якщо ви працюєте в сучасній інженерній команді, ви зустрінетеся з цими показниками на зустрічах команди, переглядах керівництва і співбесідах з наймом. У цьому довіднику пояснюється кожна метрика простою англійською мовою і надано словник, який допоможе вам обговорювати їх з впевненістю.

4 метричні точки DORA пояснені

Частота розгортання

** Що вимірює: ** Як часто ваша команда розгортає код до виробничого стану.

** Просте пояснення англійською: ** “Частота розгортання говорить нам, як часто ми фактично випускаємо програмне забезпечення для реальних користувачів. Команда, яка розгортається кілька разів на день, може експериментувати швидко і швидко вирішувати проблеми. Команда, яка розгортає один раз на місяць, несе набагато більше ризику в кожному випуску і навчається набагато повільніше»

** Рівень продуктивності DORA: **

• Еліта: декілька розгортань на день
• Висока: раз на день до раз на тиждень
• Середня: раз на тиждень до раз на місяць
• Низька: менше одного разу на місяць

Фрази для обговорення:

• «Наша частота розгортання поліпшилась з тижневої до щоденної, оскільки ми ввели постійне розгортання»
• «Ми зараз знаходимося в «середньому» діапазоні DORA для частоти розгортання; наша мета для Q3 - досягти «високого»»

Час зміни

** Що вимірює: ** Час від моменту перенесення коду до моменту його запуску у виробничому середовищі.

** Просте пояснення англійською: ** « Час виконання говорить нам, наскільки швидко ідея може стати реальним продуктом. Короткий час виконання означає, що команда може швидко реагувати на відгуки клієнтів і бізнес-потреби. Довгий час виконання означає, що зміни чекають в чергах — в перегляді, в тестуванні або очікують на вікно розгортання»

Словник:

• ** Час циклу ** — час від початку роботи до її завершення (перетинається з, але не є ідентичним до, часу виконання).
• ** Вікно розгортання ** — запланований період, протягом якого дозволено розгортання; це є причиною довгого часу розгортання у менш досвідчених командах.

Фрази для обговорення:

• «Наш час для змін зменшився з двох тижнів до трьох днів, оскільки ми автоматизували інтеграційний тестовий набір»
• «Головним чинником, що сприяє нашому довгому часу виконання, є вручну перегляд безпеки — ми досліджуємо способи змінити це вліво»

Змінити рівень невдач

** Що вимірює: ** Відсоток розгортань, які спричиняють збої у виробництві, що вимагають повернення, перенесення або виправлення.

** Просте пояснення англійською: ** « Частота помилок зміни говорить нам, як часто наші розгортання зазнають невдачі. Висока частота означає, що наші випуски є ризикованими, і наші тести не вловлюють проблеми до того, як вони дістануться користувачам. Елітні команди мають рівень невдач змін 0-5%; багато команд тримаються близько 10-15%. ”

Фрази для обговорення:

• «Наш рівень невдач змін був 18% в останньому кварталі — значно вище високоефективного еталону DORA 5-10%. Ми ставимо пріоритет на тестування покриття в нашому основному потоці оплати, щоб знизити його»
• «Пік в зміні неефективності в березні корелює безпосередньо з двома великими випусками, які ми відштовхнули без достатнього тестування стадій»

Середній час відновлення (MTTR)

** Що він вимірює: ** Середній час відновлення роботи після виробничого інциденту.

** Просте пояснення англійською: ** “MTTR говорить нам, як швидко ми можемо виправити щось, коли щось не так. Жодна система не є досконало надійною, тому MTTR так само важливий, як і спроби запобігти аваріям. Елітна команда відновлюється менше ніж за годину. Команда, що бореться, може витратити декілька днів»

** Ключова відмінність: ** MTTR не є тим самим, що і середній час між помилками (MTBF), який вимірює надійність. MTTR вимірює швидкість відновлення.

Фрази для обговорення:

• «Наш MTTR поліпшився з 4 годин до 45 хвилин після того, як ми вклали в інструменти спостережливості і автоматизацію runbook»
• «Інцидент минулого тижня мав MTTR 6 годин — значно вище нашої мети. Після смерті було встановлено, що затримка виявлення становила 90 хвилин; у нас не було попередження про конкретну метрику бази даних, яка була кореневою причиною. “

Як показано на рисунку

При представленні показників DORA команді або керівництву, скоріше використовуйте мову трендів, ніж значення в певний момент часу. Тенденції розповідають історію; окремі значення не розповідають.

** Мова позитивного тренду: **

• Частота розгортання постійно покращувалася протягом останнього кварталу, з одного разу на тиждень до трьох разів на тиждень
• «MTTR має тенденцію до зниження, оскільки ми представили нову бібліотеку runbook — ми бачимо постійне поліпшення місяць за місяцем»
• «Наш рівень невдач змін впав з 15% в Q1 до 8% в Q2, що ми приписуємо введенню функціональних прапорів»

Негативна тенденція або занепокоєння:

• «Ми бачимо тривожний ріст рівня невдач змін за останні шість тижнів, що заслуговує на розслідування»
• «Відпускний час зафіксувався — він перестав покращуватися в квітні, і ми вважаємо, що вузький кут зараз знаходиться на стадії перегляду коду, а не на етапі розгортання»

Що робити, якщо метеорити не зникли?

Бути чесним щодо поганих показників, одночасно представляючи переконливий план поліпшення, будує більше довіри, ніж мінімізація проблеми.

** Конструктивное оформление плохих результатов: **

• «Наш MTTR 4,5 години не там, де він повинен бути. Основною причиною є наша відсутність спостережливості в платіжній службі; у нас є конкретний план, щоб вирішити це в наступному спринті»
• «Я хочу бути прозорим: наша частота розгортання знаходиться в «низькій» діапазоні DORA. Це структурна проблема — у нас є довготривалі гілки функцій і повільний набір тестів. Ось наш план, щоб розв’язати обидва питання»
• «Дані про рівень невдач змін є незручним, але цінним — це говорить нам точно, де наш процес якості розбивається»

Приклади командних зустрічей

1. «Глядачи на показники DORA минулого місяця: частота розгортання залишалася постійною на щоденній основі, час виконання незначно поліпшився з 4 днів до 3,5 днів, але рівень невдач змінився до 12% — нам потрібно зрозуміти, що це викликало»

2. «6-годинний MTTR на вівторковий інцидент був нашим найгіршим кварталом; після смерті було виявлено два фактори: 2-годинний затримка виявлення і відсутність runbook для цього режиму несправності. Обидва вони адресовані»

3. «Наша мета для Q3 — перейти від «середнього» діапазону DORA до «високого» на частоті розгортання — це означає перехід від щотижневих до щоденних розгортань, що вимагає від нас розбити наш поточний монолітний процес випуску»

4. «Я хочу попередити, що час виконання був рівним протягом восьми тижнів; ми вилучили вузьке місце в конвеєрі, що означає, що обмеження тепер знаходиться деінде — ймовірно, в черзі перегляду коду, яка в середньому становить 2 дні на PR»

5. «Повнішня оцінка MTTR з 3 годин до 35 хвилин за квартал є найбільш обнадійливим сигналом в цих даних — це показує, що робота з попереднього кварталу за рахунок роботи з попереднього кварталу виплачується»

Розширення вашого словника: точність в технічних дискусіях

Ми описали основні поняття метрик DORA - Частота розгортання, Час виконання змін, Частота невдач змін і Середній час відновлення (MTTR) - і як підходити до їх обговорення. Але важливим елементом, який часто ігнорується, особливо для розробників, які не знають професійної англійської мови, є * точна * мова, необхідна для ефективного вираження цих ідей. Це не просто про те, щоб вказати числа; це про передачу розуміння, пропозиції покращень і сприяння спільному вирішенню проблем. Давайте розглянемо деякі конкретні фрази і сценарії, які допоможуть вам збільшити впевненість у своїх технічних обговореннях.

Однією з найпоширеніших проблем є формування зворотнього зв’язку під час перегляду коду. Замість того, щоб просто сказати «Це забирає занадто багато часу», що може відчуватися обвинувачуючим, розгляньте щось на зразок: «Я помітив, що час для цієї зміни довший, ніж наша ціль. Можемо ми розглянути способи, щоб упорядкувати процес тестування? Можливо, додавання тут тесту на одиницю скоротить загальний час?» Аналогічно, коли ви обговорюєте MTTR з колегою після переривання роботи, уникайте нечітких тверджень. Замість цього, ви можете сказати: “MTTR був значно вищим, ніж очікувалося під час цього інциденту. Давайте проаналізуємо основну причину і визначимо кроки, які ми можемо зробити, щоб поліпшити часи реагування – можливо, документуючи більш чіткі шляхи ескалації або автоматизуючи деякі початкові шляхи усунення несправностей”. Використання таких термінів, як «оптимізація», «аналіз основної причини» і «шляхи ескалації» демонструє глибше розуміння операційних процесів.

Інша ключова область — це опис тенденцій у ваших описах PR. Замість того, щоб просто сказати «Збільшена частота розгортання», спробуйте щось більш конкретне: «Частота розгортання збільшилася на 15% за останній квартал, в основному завдяки прийняттю нашого нового конвеєра CI / CD. Це дає можливість ще більше оптимізувати наш процес випуску і, можливо, скоротити час виконання. “Фрази, такі як “прийняття”, “оптимізація” і “потенціал” додають шар складності, який демонструє, що ви не просто повідомляєте дані, але критично думаєте про їх наслідки. Пам’ятайте, чітке спілкування - це більше, ніж просто передавання інформації; це будівництво довіри і спільного розуміння в межах вашої команди.

Нарешті, при представленні показників DORA зацікавленим сторонам - можливо, під час ретроспективи спринту - уникати жаргону. Замість « Частота помилок зміни підвищена » ви можете сказати: « Ми спостерігали збільшення кількості розгортань, які потребують переробки. Це свідчить про те, що нам слід зосередитись на поліпшенні наших процесів тестування і перевірки. » Використання простішої мови, у поєднанні з візуальними засобами, наприклад, діаграмами, що показують тенденції, забезпечить, що кожен зрозуміє ситуацію і зможе зробити значний внесок у пошук рішень. Сфокусування на впливі – «зменшення переробки» – часто переконливіше, ніж просто заява про технічну метрику.