Вимірюйте систему доставки

Почніть із рішення, яке потрібно ухвалити

Команда хоче знати, чи ШІ поліпшує доставку. Підрахунок згенерованих рядків відповідає на інше питання. Визначте корисний результат і умови якості до вибору метрики.

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

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

Використовуйте актуальні визначення

Поточна модель доставки DORA містить п’ять метрик. Вони охоплюють результативність доставки, а не цінність кожної функції чи внесок окремої людини. Визначення метрик DORA.

Панель може використовувати інше визначення. Прочитайте його до тлумачення результату. Поточна документація Taiga щодо розгортань описує чотири звітні метрики, отримані із записів розгортань постачальника. Її показник відновлення використовує наступне успішне розгортання. Це не повний запис кожного інциденту в продуктивному середовищі. Визначення Taiga.

Дослідіть вигадану послідовність змін

Припустімо, сервіс виконує дванадцять розгортань за місяць. Вісім доставляють заплановані зміни. Чотири виправляють проблеми попередніх випусків. Кількість — дванадцять, але склад має значення.

Наступного місяця команда виконує десять розгортань: дев’ять запланованих змін і одне виправлення. Менша кількість розгортань може поєднуватися з більшою кількістю корисної роботи. Ці числа ілюструють тлумачення; вони не є орієнтиром результативності.

Також дослідіть розподіл. Одне тривале очікування перегляду може зникнути в середньому значенні. Показник відновлення з однієї відмови — слабкий доказ майбутньої надійності. Повідомляйте кількість спостережень і суттєві винятки.

Поєднуйте потік із наслідками

Використовуйте сигнали сервісу, щоб перевірити, чи зміни доставки впливають на користувачів. Швидшого pipeline недостатньо, якщо експорт частіше завершується невдало. Використовуйте відповідний SLO або інший чітко визначений показник результату. Рекомендації щодо SLO.

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

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

Зберігайте корисність вимірювання

Уникайте індивідуальних рейтингів на основі кількості PR або згенерованого коду. Ці показники можуть заохочувати штучний поділ роботи, уникнення складного обслуговування або перекладання зусиль на перегляд на колег.

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

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

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

Цей окремий вигаданий набір даних записує десять запланованих змін. Увесь час подано в UTC для зазначеної дати. Порожнє поле виправлення означає, що в цьому наборі даних виправлення не записано.

Порівняйте час від готовності коду до початку перегляду, потім від прийняття до випуску. Визначте найдовше видиме очікування. Дослідіть його причину, перш ніж називати його уникненним. Ці позначки часу не вимірюють активних зусиль і не визначають початку інциденту. Сам випуск виправлення не встановлює часу відновлення після невдалого розгортання.

Завантажити вигаданий набір даних (CSV)