Розуміння рівня невдалих змін

Алексій Чірцей, генеральний директор і співзасновник Waydev.

Change Failure Rate (CFR) – це показник, який вимірює частоту помилок або проблем, які виникають у клієнтів після розгортання робочої версії. Швидкість безуспішного впровадження змін називається частотою невдалих змін. Частота невдалих змін, як і інші показники DORA, є показником рівня розвитку та якості організації чи команди. Рівень успіху переходу є предметом цієї статті. Завдяки цій статистиці легше зрозуміти час, витрачений на вирішення проблем. Ви можете отримати розуміння його методів квантування та ослаблення.

Що таке показники DORA?

Метрики DORA визначають чотири показники, тісно пов’язані з успіхом, і ці показники служать мірилом, за яким організації DevOps можуть оцінювати свою продуктивність. Швидкість розгортання, частота помилок змін, час відновлення та середній час – це чотири показники, які слід відстежувати. Відгуки 31 000 експертів з усього світу, які взяли участь у шестирічному опитуванні, допомогли визначити ці тенденції.

Для кожного показника команда DORA також встановила критерії ефективності, що описують якості «Елітних», «Високоефективних», «Середньоефективних» і «Низькоефективних» команд.

Який відсоток невдалих змін?

Якщо взяти кількість інцидентів і розділити її на загальну кількість розгортань, ви отримаєте відсоток невдалих змін, тобто відсоток розгортань, які не вдались у виробництві. У результаті супроводжувачі можуть бачити, скільки часу витрачається на виправлення помилок у надісланому коді. Команди DevOps зазвичай можуть досягти рівня невдалих змін від 0% до 15%.

Помилки будуть завжди, оскільки нові функції та виправлення постійно надсилаються на живі сервери. Ці несправності іноді можуть бути досить тривіальними або спричиняти катастрофічні збої. Важливо пам’ятати, що це не привід звинувачувати будь-яку особу чи групу, але інженерні менеджери повинні стежити за тим, як часто такі речі трапляються.

Як високий CFR впливає на бізнес і як його можна мінімізувати?

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

Ви можете знизити свій CFR, виконавши кілька різних кроків. Деякі з них можна реалізувати під час розробки; вони зосереджені на тестуванні та автоматизації. Етап розгортання також включає додаткові показники, такі як інфраструктура, як-от код, методи доставки та показники функціональності.

Покращити тестування.

При покращенні якості коду ймовірність виникнення збоїв менша. Якщо вам потрібен код кращої якості, краще тестування є обов’язковим. Для цього потрібен комплексний набір тестів для коду програми. Модульне тестування є основним типом тестування, і його мета полягає в тому, щоб переконатися, що конкретні процедури або частини більшої загальної функції відповідають очікуванням.

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

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

Автоматизувати тестування.

Автоматизація тестування або...