Как оценить качество проекта? Внедряем DORA-метрики
Вы когда-нибудь сталкивались с оценкой продукта по количеству закоммиченных строк кода в месяц? Или задавались вопросом, как оценить качество продукта в целом? Если да, эта статья будет для вас актуальна. Меня зовут Арина Гончаренко, я DevOps-инженер в Lamoda Tech. Расскажу, что такое DORA-метрики и как они могут помочь оценить качество проекта.
Спойлер: в конце материала проанализируем три реальных кейса внедрения DORA-метрик в проекты Lamoda.
Немного контекста
DORA-метрики (DevOps Research and Assessment) названы в честь одноименной компании. DORA с 2013 года проводила ежегодные исследования, в котором рассматривала корреляцию между принятыми в компаниях решениями и их успехом на рынке. По результату исследования было выявлено четыре ключевых показателя качества разработки кода. Они разделяются на показатели скорости и качества.
К скорости относятся частота развертываний и время попадания кода в продакшeн.
К качеству — среднее время восстановления после аварии и процент сфейленных релизов.
В 2018 году Google выкупила Dora и продолжила исследование, выпустив в 2023 году обновленную таблицу с перфомансами компаний. Главный вывод исследования сводится к одной идее: чем выше скорость разработки кода, тем выше качество продукта.
Со всеми ежегодными отчетами можно ознакомиться на сайте dora.dev. От себя советую не придавать этим метрикам слишком большого значения. Да, они являются показателями качества и помогают увидеть картину в целом, а еще могут подсказать, что стоит улучшить в дальнейшем. Но не нужно делать из них цель.
Об этом напоминает закон Гудхарта, который гласит: если показатель становится целью, он перестает быть хорошим показателем.
Далее поделюсь нашим опытом разработки приложения по генерации DORA-метрик и визуализации самих метрик. Важно не только правильно собрать метрики, но и построить на их основе графики, по которым можно провести анализ. В GitLab (Ultimate) есть готовое решение, но для наших команд оно не подошло по двум причинам:
Потребовалось бы переделывать под GitLab внутренние процессы команд.
Потребовалось бы менять схему CI/CD с Downstream pipelines.
Также было важно иметь возможность формировать кастомные метрики под нас.
Опыт Lamoda Tech
Этап №1. Погружение в процессы команды
Первым делом мы нашли заинтересованную команду, которая хотела оценить качество своего продукта, после чего погрузились в их внутренние процессы. Здесь нужно было создать общий контекст.
Мы обозначили самые активные проекты и сошлись на том, что неудачными релизами для метрики Deployment failure rate будем считать откаты, hotfix-ветки и сфейленные джобы в GitLab. Условились, что метрику Lead time for change будем определять как среднее время от создания merge requests до попадания кода в продакшeн.
Этап №2. Разработка
В качестве языка выбрали Python, вместо GitLab REST API — GitLab GraphQL API. Это решение позволяет получать отфильтрованные данные из GitLab, что меньше нагружает систему развертываний, и может помочь нам позже, когда мы будем вводить данные приложения для каждого нового проекта. Дополнительно подготовили веб-версию, которая отдает метрики при обращении к ручке.
Далее для наглядности покажу, какие метрики мы генерируем сами.
1. Метрика скорости dora_commit_delivery_lead_avg_time_sec — среднее и полное время попадания кода в продакшeн.
2. Метрики по количеству развертываний dora_deployments_total_countс разными статусами: неуспешные, хотфикс-ветки, откаты и успешные. С их помощью считаем процент сфейленных релизов.
3. Метрики качества — здесь представлены кастомные метрики:
dora_first_deploy_prod_unixtime— время в Unix Time от первого успешного развертывания на продакшен. Объединяем эту метрику с количеством успешных развертываний (п.2) и получаем частоту развертываний за день.dora_mr_merged_total_count— количество merge requests. Она подсвечивает количество проведенных работ на проекте за определенный промежуток времени.dora_run_job_deploy_avg_time_sec— среднее время выполнения джобы раскатки кода на продакшен. Показывает, есть ли проблемы с конвейером поставки кода.dora_run_pipeline_deploy_avg_time_sec— среднее время от создания готового пайплайна до непосредственного развертывания на продакшене.
4. Метрики качества dora_time_to_recovery_avg_time_sec — среднее и полное время восстановления после аварии, с разными статусами.
Этап №3. Внедрение и визуализация
Мы развернули приложение как application в Argo CD. Используем VictoriaMetrics Operator в нашем Kubernetes-кластере, поэтому для настройки сбора метрик взяли VMServiceScrape. Для визуализации выбрали Grafana, так как формируем метрики в формате Prometheus.
Кейсы внедрения в проекты Lamoda Tech
Чтобы оценить результаты на практике, покажу три кейса полных картин по DORA-метрикам наших реальных проектов. Надеюсь, они помогут сделать выводы и станут наглядным примером для команд разработки.
Кейс №1
Рассмотрим полную картину по DORA-метрикам одного из проектов. Заметна очевидная корреляция: чем выше среднее время попадания кода в продакшeн, тем меньше развертываний в день.
Если обратиться к основной статистике за все время, то увидим, что показатели скорости ухудшились, но при этом показатели качества относятся больше к performance high или elite.
Вывод: у команды разработки этого приложения высокая экспертиза, сотрудники быстро справляются с фейлами. Здесь можно дать рекомендацию — пересмотреть процессы апрувинга кода.
Кейс №2
Здесь видим рост графиков, который показывает ухудшение важных показателей. Почему так? Присмотримся внимательнее. Частота развертываний увеличилась в 10 раз, но и процент сфейленных релизов вырос с 10% до 30%. То есть в результате получаем, что каждый третий релиз заканчивается неудачей.
Обратим внимание и на среднее время восстановления после аварии. Оно выросло почти до пяти часов, тогда как среднее время выполнения раскатки на продакшeн увеличилось до двух минут — на 57%.
Вывод: у команды разработки этого приложения низкая экспертиза, это можно понять по показателю MTTR. А также наблюдаются проблемы с конвейером поставки кода из-за возросшего среднего времени развертывания.
Кейс №3
Этот кейс можно назвать скорее успешным. Здесь мы видим хорошие показатели качества и скорости. Если посмотреть детальнее на выделенный графики скорости (Commit delivery lead time/Deployment frequency), то видно, что среднее время попадания кода в продакшeн снизилось, а частота развертывания на проекте увеличилась.
По графику «Deployment prod pipelines average duration» понятно, что среднее время от создания готового пайплайна до развертывания кода в продакшeн теперь занимает 18 часов, оно также снизилось. Но показатель MTTR слишком высокий — 7 часов.
Вывод: команде нужно обратить внимание на внутренние процессы и понять, как они принимают решение об откате. Возможно, не хватает проверок после развертывания кода в продакшене.
Заключение
Подведем итоги: в каких ситуациях DORA-метрики будут особенно полезны?
Если у вас есть проект с выстроенными процессами, но вы не понимаете, что можно улучшить, DORA-метрики покажут общую картину и помогут с анализом. Например, вы увидите влияние изменений в процессах команд на графиках и решите, оставлять их или откатываться назад.
Мы планируем собирать показатели с небольшого количества сервисов на протяжении нескольких месяцев, далее проводить бенчмаркинг наших проектов и определять их перформанс. В результате подсветим актуальные проблемы командам разработки и предоставим рекомендации по изменению внутренних процессов. После чего планируем внедрить наш продукт по генерации DORA-метрик в базовую функциональность новых сервисов.
Если у вас остались вопросы по внедрению DORA-метрик или вы хотите поделиться собственным опытом, присоединяйтесь к обсуждению в комментариях.
