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

Оригінал: 13 DevOps Metrics for Increased Productivity
Автор: Sara Miteva

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

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

Оскільки в основі DevOps лежить безперервна і швидка доставка коду, дуже важливо діяти також швидко, без серйозних помилок. Тому так важливо відстежувати DevOps метрики, які можуть допомогти вам у цьому.

Щоб досягти успіху в DevOps,команди використовують безліч різних інструментів. Саме тому різні показники DevOps є важливими для різних команд розробників.

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

Ось критичні метрики DevOps, які вважаються важливими для більшості команд:

Частота розгортання (Deployment Frequency)

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

Метою має бути якнайчастіше розгортання невеликих систем. Дрібні зміни набагато зручніші для тестування та розгортання програмного забезпечення.

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

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

Час розгортання (Deployment Time)

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

Відсоток успішно пройдених автоматичних тестів (Percentage of Automated Tests Pass)

Рекомендується, щоб команда ефективно використовувала модульне та end-to-end тестування для максимального збільшення швидкості. Оскільки DevOps залежить від автоматизації, корисна метрика DevOps - це вимір того, наскільки добре працюють автоматизовані тести. Корисно знати, скільки коригування коду призводить до збою тестів.

Коміти коду (Code Commits)

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

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

Швидкість усунення дефектів (Defect Escape Rate)

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

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

Вартість (Costs)

Хоча хмарні рішення чудово підходять для скорочення витрат на інфраструктуру, деякі незаплановані помилки та події можуть призвести до дуже високих витрат. Ось чому слід зосередитись на визначенні зайвих витрат та їх скороченні. Візуалізація джерел ваших витрат може відіграти велику роль у розумінні того, за які дії ви платите найдорожче.

Невдалі розгортання та здоров'я оточень (Failed Deployments and Environment Health)

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

Час до виявлення проблем (Time to Detection)

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

Незапланована робота (Unplanned Work)

Кількість часу, який ви витратили на завдання, яких не було в початковому плані. У стандартних проектах коефіцієнт незапланованих робіт (UWR) не повинен перевищувати 25%. Високе значення UWR може виявити витрачені зусилля на непередбачені помилки, які, очевидно, не були помічені на початку робочого процесу. Разом із частотою переробок (RWR), яка стосується спроби виправити проблеми, викладені в заявках, UWR також є важливим показником.

Середній час до відмови (Mean Time to Failure - MTTF)

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

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

Продуктивність застосунків (Application Performance)

Перед виконанням розгортання необхідно перевірити межі продуктивності. Після релізу було б добре відстежувати значні зміни у використанні певних запитів SQL, викликів веб-сервісів та інших нефункціональних вимог до рішення. Щоб виявити їх, можна використовувати інструменти моніторингу, які точно покажуть вам зміни.

Середній час до виявлення (Mean Time to Detection - MTTD)

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

Середній час відновлення (Mean Time to Recovery - MTTR)

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

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

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

Час на реалізацію (Lead Time)

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

Agile-методології, пов'язані з DevOps, можуть забезпечити швидкий період обробки покращень інфраструктури, дозволяючи бізнесу задовольняти потреби споживачів та зосередитись на зміні тенденцій. Ви можете використовувати такі інструменти, як Jira та Trello, щоб ефективно відстежувати час виконання завдань.

Обсяг змін (Change Volume)

Оскільки DevOps - це часті зміни, необхідно виміряти рівень змін між розгортаннями. Кінцева мета повинна полягати в тому, щоб сконцентруватися на значних поліпшеннях, які завдають менше незручностей і призводять до більш плавної взаємодії. Для кожного розгортання моніторинг обсягу змін дозволяє більш точно описати розвиток. Ви можете отримати цю інформацію з таких інструментів, як GitHub, Bitbucket та Jira.

Клієнтські запити (Customer Tickets)

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

Висновок

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

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