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

Поскольку DevOps представляет собой смесь различных передовых отраслевых практик, инструментариев и, самое главное, культур, возникает вопрос: Как измерить их влияние? К счастью, существует несколько наборов метрик CI/CD, которые помогают IT- и организациям по разработке программного обеспечения обладать достаточной видимостью и получать практические данные.

Один из таких наборов называется «DORA-метриками» (c англ. 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.