DORA Metrics in Plain English: Deployment Frequency, Lead Time, and More (англійською)

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

4 метричні точки ДОРА

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

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

** Категорії: **

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

** Простою англійською: ** Частота розгортання говорить вам, наскільки швидко користувачі отримують цінність. Високочастотне розгортання пов’язане з нижчим ризиком на розгортання (меншими змінами) і швидшими петлями зворотного зв’язку.

** Фрази для командних зустрічей: **

• “Ми зараз розгортаємо двічі на тиждень — наша мета досягти щоденних розгортань до Q3.”
• “Частота розгортання впала в минулому кварталі, тому що ми були в середині міграції — вона повинна відновитися, як тільки новий конвеєр стабільний.”

2-й. Час зміни

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

** Також виражається як: ** час затвердження розгортання, час циклу

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

** Фрази для командних зустрічей: **

• “Наша середня тривалість виконання на даний момент становить чотири дні — головним в’язким місцем є інтеграційний тестовий набір, який запускається за три години.”
• “Зменшення часу виконання є пріоритетом в цій половині, тому що це безпосередньо впливає на те, наскільки швидко ми можемо реагувати на проблеми виробництва.”

3-й. Змінити рівень невдач

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

** Формула: ** (Кількість невдалих розгортань ÷ Всього розгортань) × 100

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

** Фрази для командних зустрічей: **

• • “Наша частка невдалих змін минулого місяця склала 22%, що перевищує наш цільовий показник. Ми переглядаємо контрольний список перед розгортанням, щоб визначити прогалини». *
• “Розмах у кількості помилок змін збігся з вилученням інтеграційних тестів — їх відновлення є пріоритетом.”

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

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

** Також виражається як: ** середній час відновлення, час відновлення

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

** Фрази для командних зустрічей: **

• “Наш MTTR для інцидентів P1 на даний момент становить 45 хвилин — ми хочемо зменшити його до 30 хвилин, поліпшивши наші runbooks.”
• • “Ми повинні інвестувати в кращу спостережливість, перш ніж MTTR стане проблемою при нашому поточному темпі зростання.” *

Розглядаючи DORA метрики в звітах

Під час написання про показники DORA у технічних звітах або стратегічних документах, використовуйте точну мову:

Instead of	Use
”We deploy a lot"	"Our deployment frequency is 8.3 deployments per week on average"
"We’re getting faster"	"Lead time for changes improved from 6 days to 2.5 days over the last quarter"
"We had some failures"	"Change failure rate was 18% in March, compared to our target of below 10%"
"We recovered quickly"	"Median MTTR for P1 incidents was 28 minutes in Q1”

Приклади висловлювань

1. «Наша частота розгортання зросла з тижневої до щоденної після того, як ми перейшли до розробки на основі ствола і впровадили автоматизовані тести диму»
2. «Відпускний час для змін на даний момент становить три дні — найдовший етап — черга перегляду коду, яка в середньому триває 36 годин»
3. «Після трьох послідовних інцидентів високої важкості, рівень невдач змін досяг 30% в лютому, що призвело до тимчасового заморожування розгортання»
4. «MTTR значно поліпшився після того, як ми централізували наші runbooks і додали автоматичне попередження для найбільш поширених режимів невдачі»
5. «В нашій оцінці DORA, ми класифікували як «високий виконавець» на частоті розгортання і MTTR, але «середній» на часі виконання — це наша фокусна область для цієї половини»

Поняття мови: лексика та контекст

Будьмо чесними - розмови про “час виконання” або “частота розгортання” можуть здатися трохи… стерильні. Легко зануритися в числа, не розуміючи * чому * ці показники важливі і як вони перетворюються на реальні поліпшення для вашої команди. Для не-рідних носіїв англійської мови це особливо важливо. Точне формулювання, яке використовується при обговоренні продуктивності розробки програмного забезпечення, може значно відрізнятися в різних культурах, і нерозуміння може легко виникнути, якщо ви не знайомі з поширеними ідіомами і прийнятими стилями спілкування. Просте твердження на кшталт « нам потрібно скоротити час виконання» може бути інтерпретовано буквально – як наказ зменшити процес! – а не як запрошення дослідити вузли і оптимізувати робочий процес.

Також важливо розуміти, що технічні дискусії рідко проводяться на досконалому формальному мові. Хоча ясність є найважливішою, ви часто почуєте такі фрази, як «давайте ітерувати на цьому» або «ми повинні швидше досягти виробництва», які використовуються випадково. Це не просто модні слова; вони представляють зобов’язання щодо постійного вдосконалення і реагування на потреби користувачів. Аналогічно, розуміння різниці між «прохідністю» (швидкість, з якою робота завершується) і «швидкістю» (швидкість, з якою команда забезпечує цінність) може бути складним - швидкість часто включає фактори, що виходять за рамки простого часу кодування, такі як тестування і документація. Вміння сформулювати * чому * один показник вищий за інший вимагає більше, ніж просто знати визначення; це вимагає розуміння основних процесів. Не вагайтеся попросити про пояснення, якщо ви не впевнені щодо фрази або терміну - запитання “Чи можете ви пояснити, що ви маєте на увазі під “зменшенням часу циклу” в цьому контексті?” є цілком прийнятним і демонструє бажання навчатися.

Розглянемо ситуацію, коли старший інженер, Сара, переглядає запит на завантаження. Вона може залишити коментар на описі PR, сказавши: “В цілому це виглядає добре, але давайте зосередимося на збільшенні частоти розгортання. Ми могли б розглянути автоматизацію деяких з цих кроків, щоб зменшити вручну вкладені зусилля. “Це не тільки про швидкість; це про * ефективність * і зменшення ризику, пов’ язаного з рідкісними розгортаннями. Це тонкий спосіб запропонувати, що частіші випуски - навіть невеликі - можуть призвести до швидших петель зворотнього зв’язку і швидшого надання цінності.

Нарешті, давайте поглянемо, як ви можете описати результати роботи вашої команди в каналі Slack після успішного спринту: «Всі чудово попрацювали! Ми досягли нашої мети частоти розгортання цього тижня, а час розробки функції X значно скоротився завдяки вдосконаленню автоматизації, яке ми впровадили. ” Це демонструє не тільки * досягнення *, але і активні кроки, які були зроблені для досягнення цього результату.

# Example using `git` for analyzing commit history (illustrative)
git log --author="John Doe" --since="1 week" --pretty=format:"%h - %an, %s" | head -n 5

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