DORA-метрики допомагають знайти інсайти щодо продуктивності розробників

Оскільки DevOps являє собою суміш різноманітних передових галузевих практик, інструментаріїв і, найголовніше, культур, виникає питання: Як виміряти їхній вплив? На щастя, існує декілька наборів метрик CI/CD, які допомагають ІТ- та організаціям із розробки програмного забезпечення мати достатню видимість і отримувати практичні дані.

Один із таких наборів називається «DORA-метриками» (від англ. DevOps Research and Assessment, Дослідження та оцінювання DevOps). Спираючись на наш багатий досвід GitLab-консалтингу, ми окреслимо фундаментальні принципи DORA, дослідимо необхідні для неї вхідні параметри та надамо поради щодо оптимізації шляхів доставки.

Що таке DORA-метрики?

DORA-метрики були розроблені спеціалізованою командою Google Cloud ще у 2020 році після шести років ґрунтовних досліджень. Початкові метрики включали:

• Частоту розгортань та час виконання змін (обидва показники характеризують швидкість роботи команди).
• Частку помилок змін та час відновлення роботи сервісу (обидва показники характеризують стабільність).

Через рік команда додала п’ятий показник — надійність — у відповідь на постійні зміни у сфері DevOps.

У 2022 році світ перейшов у режим пандемії, що, за даними Міжнародного валютного фонду, в середньому на 6 відсоткових пунктів пришвидшило цифрову трансформацію у розвинених економіках. З часом метрики почали показувати перші результати. У 2023 році консалтингова компанія з «великої трійки» McKinsey запропонувала підхід до оцінки продуктивності розробки, який ґрунтувався на DORA та інших DevOps-метриках (SPACE). Для 20 фірм у сферах технологій, фінансів та фармацевтики результат був більш ніж помітним:

• Зменшення кількості проблем із дефектами, виявленими клієнтами, на 20-30%.
• Підвищення рівня задоволеності співробітників на 20%.
• Зростання задоволеності клієнтів на 60 відсоткових пунктів.

Сьогодні ми розглядаємо DORA-метрики крізь призму GitLab, універсальної платформи для всього, що стосується DevSecOps. Станом на березень 2024 року цю платформу було визнано однією з найкращих у своїй категорії авторитетним сайтом із оглядами програмного забезпечення G2.

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

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

GitLab відстежує завершені розгортання, тобто ті, що були успішно завершені (без помилок). Він фокусується на середній кількості розгортань, здійснених у продакшн-середовищах, які ідентифікуються за допомогою призначеного рівня «production tier» або назв на кшталт «production» чи «prod». Лише розгортання, що досягають цих середовищ, впливають на метрику частоти.

Цікавим питанням тут є те, як ви внутрішньо визначаєте успіх. Чи стосується він розгортань, які охоплюють лише 10% вашого трафіку, чи тих, що спрямовані на весь трафік?

Час виконання змін

Цей показник демонструє, скільки часу потрібно, щоб зміна в коді (або коміт) потрапила в продакшн. Його також використовують для постійної перевірки працездатності ваших CI/CD-пайплайнів; якщо він із часом зменшується, це означає, що ваша команда стала більш продуктивною та швидше постачає необхідні модифікації.

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

За замовчуванням моніторинг GitLab доступний для часу виконання змін у розгортаннях, які включають одну гілку з кількома етапами (наприклад, перехід із розробки до стейдж-середовища, а потім до продакшену). Якщо у вас більш складний робочий процес з окремими запитами на мердж для кожного етапу, GitLab розглядатиме їх як окремі розгортання, що може штучно завищити цю метрику.

Частка помилок змін

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

Щоб отримати частку помилок змін, GitLab ділить кількість інцидентів, що відбуваються після кожного розгортання, на їхню загальну кількість на проді. Припустимо, ви розгорнули новий код 20 разів на місяць і щотижня стикалися з інцидентами. У цьому сценарії ваша частка помилок змін становитиме 20% (4 інциденти / 20 деплойментів).

Час відновлення роботи сервісу

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

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

Як покращити свої показники за DORA-метриками: повний чеклист на 2024 рік

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

Прискорення доставки

• Порівняйте частоту розгортань між командами та проектами та знайдіть можливості для підвищення надійності.
• Розбийте великі функції на менші, більш керовані блоки, щоб скоротити час виконання змін.
• Впровадьте автоматизовані тестування та перевірку коду, щоб підвищити якість розгортань і виявити проблеми до того, як вони переростуть у фінансові втрати.
• Проаналізуйте ефективність CI/CD-пайплайнів у різних командах і проектах (дізнайтеся більше про те, чому CI/CD важливі). Зосередьте увагу на вузьких місцях і оптимізуйте їх для швидших розгортань.
• Використовуйте аналітику потоку створення вартості (GitLab Value Stream Analytics), щоб усунути неефективність і покращити загальний робочий процес.

Підвищення стабільності та відновлення

• Порівняйте час реагування команди на перебої в роботі та визначте сфери для покращення комунікації та співпраці.
• Збільшіть видимість продакшн-середовищ, щоб пришвидшити виявлення та усунення проблем (зменшивши MTTR — Mean Time To Recover, або середній час на відновлення).
• Встановіть чітко визначені робочі процеси для реагування на збої, щоб скоротити час на їхнє вирішення.

Баланс швидкості та якості

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

Про нас

Cloudfresh є партнером GitLab (Select і Professional Services). Ми можемо допомогти вам у таких сферах, як впровадження, міграція, навчання, інтеграція, консультації та підтримка.

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

• 360-градусний огляд поточного стану справ.
• Повне розуміння бізнес-цілей і того, як їх досягти.
• Визначення всіх обмежень, які вас стримують.
• Повноцінну мапу потоку створення вартості.
• Готовий до застосування аналіз співвідношення витрат і користі (де можливо).

Крім того ми можемо допомогти вам встановити необхідні бенчмарки для належного відстеження та отримання корисних даних із DORA-метрик і ширшої аналітики GitLab.