Измерение эффективности CI/CD с помощью метрик DevOps

Когда вы начинаете выстраивать CI/CD-пайплайн, нужно сделать очень многое: от написания автоматических тестов до организации автоматического обновления тестовых сред. Если вы хотите понять, как оптимизировать работу на этом этапе, прочитайте наше Руководство по лучшим практикам CI/CD.

Когда автоматизированный пайплайн настроен и запущен, пора подумать, как повысить его эффективность. С этого начинается цикл непрерывного улучшения, и в этом вам помогут метрики CI/CD-пайплайна.

Питер Друкер однажды сказал: «Управлять можно только тем, что можно измерить». Метрики необходимы для непрерывного улучшения. Данные помогают понять, что можно улучшить, и дают точку отсчета для оценки эффекта любых изменений.

Отслеживая важные метрики DevOps, вы выясните, что больше всего влияет на эффективность CI/CD-пайплайна, и сможете решить, стоит ли расширять покрытие тестами, улучшать пропускную способность или разбивать задачи разработки на более мелкие.

При каждой попытке оптимизировать один из этапов CI/CD-пайплайна вы усиливаете эффект от цикла обратной связи. Это помогает быстрее выпускать обновления, поддерживая высокое качество кода и минимизируя число ошибок.

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

Кроме того, отслеживание метрик — отличный способ продемонстрировать руководству и другим командам ценность вашего пайплайна для бизнеса.

Частота развертывания — это количество циклов CI/CD-пайплайна перед развертыванием в продакшн. DORA выбрала частоту развертывания в качестве показателя размера пакета: более высокая частота развертывания означает, что при каждом развертывании вносится меньше изменений.

При развертывании небольшого количества изменений снижаются связанные с релизом риски: меньше переменных — меньше вероятность непредвиденных и нежелательных последствий. Кроме того, более частое развертывание позволяет быстрее получить обратную связь.

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

Иногда низкая частота развертывания связана с объединением изменений в более крупные релизы в рамках стратегии непрерывного развертывания. Если обновления приходится объединять в крупные пакеты по соображениям бизнеса — например, таковы предпочтения пользователей — лучше измерять частоту развертывания в предпроизводственные среды.

Срок разработки (его еще называют сроком поставки или сроком вывода на рынок) — время от начала разработки функции до ее доставки пользователям. Однако такие этапы, как проработка идей, исследование рынка и прототипирование, могут занимать разное время.

Поэтому DORA измеряет время от последнего коммита кода до развертывания. Такой подход позволяет сосредоточиться на этапах, которые входят в CI/CD-пайплайн.

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

Увеличенный срок поставки часто связан с тем, что многие этапы пайплайна выполняются вручную: например, много ручных тестов или при развертывании нужно вручную обновлять среды.

Автоматизация тестов и использование CI-сервера для координации сборки, тестирования и развертывания помогут сократить время доставки ПО. Кроме того, CI-сервер позволяет собирать метрики, демонстрирующие окупаемость инвестиций в автоматизацию.

Если вы уже начали автоматизировать процесс непрерывной интеграции и развертывания, но этапы выполняются медленно или нестабильно, можно использовать метрики продолжительности сборки, чтобы определить узкие места.

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

Доля неуспешных изменений — это процент изменений, которые после развертывания в продакшн приводят к сбоям или багам и требуют отката к предыдущей версии или срочного исправления (hotfix). При этом в расчет не берутся проблемы, обнаруженные до развертывания кода.

Достоинство этой метрики в том, что она сопоставляет количество отказов после развертывания с объемом внесенных изменений. Низкий показатель неудачных развертываний говорит о том, что ваш CI/CD-пайплайн надежна и большая часть проблем успешно выявляется на ранних этапах.

Если процент сбоев высок, стоит обратить внимание на качество автоматизированного тестирования. Покрывают ли ваши тесты основные сценарии использования? Насколько они надежны? Возможно, стоит добавить автоматические тесты производительности или безопасности?

Среднее время восстановления или устранения проблемы (mean time to recovery or resolution, MTTR) означает время, необходимое для устранения сбоя в производственной среде. MTTR принимает во внимание, что в сложной системе с множеством переменных сбои в продакшене неизбежны. Вместо стремления к совершенству (что мешает частым релизам) важнее быстро реагировать на проблемы.

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

С этой метрикой связана еще одна — среднее время выявления проблем (mean time to detection, MTTD). Она измеряет, сколько времени проходит с момента развертывания изменений до того, как система мониторинга зафиксирует проблему. Сравнив MTTD и продолжительность сборки, можно понять, где стоит улучшить процесс, чтобы быстрее восстанавливать систему.

В CI/CD-пайплайне основную часть покрытия кода должны составлять автоматизированные тесты. На первом уровне автоматического тестирования следует выполнять юнит-тесты, поскольку они занимают меньше всего времени и быстрее всего дают обратную связь.

Покрытие кода — это метрика, которая показывает, какая часть кода проверена юнит-тестами. Ее рассчитывает большинство CI-серверов. Важно следить за этим показателем, чтобы поддерживать высокий охват тестирования по мере добавления нового кода. Если покрытие со временем снижается, стоит уделить внимание улучшению этой первой линии проверки.

Продолжительность сборки или время сборки — время, которое занимает выполнение различных этапов автоматического пайплайна. Анализ времени, проведенного на каждом этапе, помогает выявить проблемы и узкие места, которые могут замедлить получение результатов тестирования и развертывание в продакшн.

Доля успешных выполнений тестов — процент успешно пройденных тест-кейсов для определенной сборки. Если у вас достаточно автоматизированных тестов, этот показатель позволяет оценить качество сборки и понять, как часто изменения в коде вызывают новые ошибки.

Автотесты лучше, чем ручное тестирование или поиск багов в продакшене. Но если одни и те же тесты регулярно ломаются, стоит разобраться в причинах и устранить проблему.

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

Чем быстрее исправляются ошибки, тем эффективнее работа пайплайна. Устранять проблемы сразу после обнаружения проще, потому что вы хорошо помните, какие изменения были внесены. Быстрая реакция также помогает избежать ситуации, когда новые функции создаются поверх нестабильного кода.

Ошибки развертывания приводят к вынужденным простоям и требуют отката изменений или выпуска срочных исправлений. Количество неудачных развертываний используется для расчета коэффициента отказов при изменениях.

Отслеживая долю ошибок в общем числе развертываний, вы можете оценить выполнение соглашений о гарантированном уровне обслуживания (SLA).

Однако необходимо помнить, что цель свести количество неудачных развертываний к нулю (или очень близкому к этому значению) не всегда реалистична. Преследуя такую цель, команды могут уйти в перфекционизм, вместо того чтобы просто выпускать качественный продукт. В результате увеличится срок поставки и размер развертывания, поскольку изменения будут объединяться в крупные пакеты. Это в свою очередь только повысит вероятность ошибок в продакшене из-за увеличения числа переменных, а устранить эти ошибки будет сложнее, поскольку придется анализировать больше изменений.

В отличие от неудачных развертываний, число дефектов соответствует количеству открытых тикетов, которые помечены как баги. Эту метрику CI можно разделить на проблемы, выявленные при тестировании и в продакшене.

Отслеживать число дефектов полезно для оценки общей тенденции: если показатель растет, значит, баги выходят из-под контроля. Но помните, что, если этот показатель станет целевым, ваша команда может заняться в первую очередь классификацией тикетов, а не устранением проблем.

Размер развертывания зависит от частоты развертывания и определяется количеством сторипойнтов, которые входят в сборку или релиз. С его помощью можно отслеживать объем изменений у определенной команды.

Если размеры развертываний небольшие, значит, команда регулярно делает коммиты изменений и пользуется всеми связанными с этим преимуществами. Однако оценки сложности в разных командах будут отличаться, поэтому эту метрику не стоит использовать для определения общего размера развертывания.

Эти метрики DevOps позволяют лучше оценить эффективность CI/CD-пайплайна с точки зрения скорости развертывания и качества ПО.

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

Метрики могут быть полезными для оценки работы, но важно интерпретировать их в контексте и учитывать, какое поведение они могут стимулировать.

Не забывайте, что цель не в достижении определенных показателей, а в том, чтобы ваш пайплайн был быстрым и надежным, позволял доставлять пользователям качественный продукт и решал задачи вашей организации.