Измерение и мониторинг эффективности CI/CD
Непрерывное совершенствование — один из краеугольных камней философии DevOps.
Это касается всех аспектов разработки ПО — от создаваемого продукта или услуги до корпоративной культуры организации и используемых рабочих процессов.
Непрерывное совершенствование основано на сборе и анализе обратной связи о готовых продуктах и услугах, а также о вашей работе. Это помогает понять, что делается хорошо, а что можно улучшить. После внесения необходимых изменений вы снова собираете отклики, чтобы понять, дало ли это нужный результат, и дальше продолжаете действовать аналогично.
CI/CD-пайплайн играет главную роль в непрерывном улучшении разрабатываемого ПО. Сокращая время цикла от разработки до развертывания, вы чаще выпускаете обновления и получаете от пользователей отклики, которые помогают определить, на чем нужно сосредоточиться дальше. Точно так же благодаря быстрой обратной связи на каждом этапе автоматического тестирования становится проще исправлять ошибки и поддерживать качество программного обеспечения.
Однако этим непрерывное совершенствование не ограничивается. Используя те же методы для анализа самого CI/CD-пайплайна, можно улучшить процессы сборки, тестирования и выпуска ПО, дополнив циклы обратной связи, используемой для улучшения продукта.
Общая информация о метриках пайплайна
Известный принцип гласит: «Невозможно управлять тем, что не можешь измерить».
Метрики — важнейший инструмент повышения эффективности системы. Они помогают понять, что можно улучшить, и дают точку отсчета для оценки эффекта любых улучшений.
Эффективность CI/CD подразумевает как скорость, так и качество. Мы не должны идти на компромисс между быстрым развертыванием изменений и созданием надежного продукта: высокопроизводительный CI/CD-пайплайн позволяет решить обе задачи одновременно.
Измерение и мониторинг скорости работы, качества ПО и уровня автоматизации помогают выявить сферы, где необходимы улучшения, а затем убедиться, что внесенные изменения действительно дали требуемый результат.
Метрики верхнего уровня для оценки эффективности DevOps
Компания DevOps Research and Assessment (DORA) выделила четыре метрики верхнего уровня, которые дают точное представление об эффективности организации с точки зрения разработки ПО.
You can learn more about the research that informed these choices in the book Accelerate.
Срок поставки
Срок поставки (его также называют сроком доставки, временем вывода на рынок и т. д.) можно определить как время от момента появления идеи функции до момента ее доставки пользователями. Однако время обдумывания, изучения рынка и создания прототипа может очень сильно различаться от случая к случаю.
Поэтому DORA предлагает другой подход к определению срока поставки: это время от коммита кода до развертывания. Таким образом, оно охватывает этапы, входящие в CI/CD-пайплайн.
Долгий срок поставки означает, что вы не доставляете пользователям обновленный продукт достаточно регулярно, а следовательно, не можете пользоваться преимуществами быстрой обратной связи для его дальнейшего улучшения. Это может быть связано с рядом факторов.
Если в пайплайне выпуска продукта есть этапы, выполняемые вручную, например, большое количество ручных тестов, оценка рисков или утверждение вносимых изменений, это может занимать целые дни и даже недели, сводя на нет преимущества частых релизов.
Вложения в автоматизацию тестирования помогут справиться с первой из перечисленных проблем, но решение остальных требует участия всех заинтересованных сторон: они должны понять, что для удовлетворения их требований можно действовать эффективнее. В то же время, если автоматизированные этапы дают медленный или ненадежный результат, метрики продолжительности сборки позволяют понять, что именно занимает много времени.
Частота развертывания
Частота развертывания — это количество циклов CI/CD-пайплайна перед развертыванием в производственную среду. DORA выбрала частоту развертывания в качестве показателя размера пакета: более высокая частота развертывания означает, что при каждом развертывании вносится меньше изменений.
При частом развертывании небольшого количества изменений снижаются связанные с релизом риски: меньше переменных — меньше вероятность непредвиденных и нежелательных последствий. Кроме того, это позволяет быстрее получить обратную связь.
Низкая частота развертывания может означать, что коммиты недостаточно регулярно поступают в пайплайн, например, из-за того, что задачи не разделены на отдельные отрезки. С другой стороны это может означать, что обновления объединяются в крупные релизы.
Иногда обновления необходимо объединять в крупные пакеты по соображениям бизнеса — например, таковы предпочтения пользователей. В этом случае можно измерять частоту развертывания в предпроизводственные среды. Это поможет отслеживать размер пакетов и понять, получаете ли вы выгоду от работы короткими циклами.
Доля неуспешных изменений
Доля неуспешных изменений обозначает процент изменений, развернутых в производственной среде, которые привели к проблемам в работе продукта — например, к сбою или ошибке, которая потребовала возврата к предыдущей версии или выпуска срочного исправления. Достоинство этой метрики в том, что она сопоставляет количество отказов после развертывания с объемом внесенных изменений.
Низкий уровень отказа изменений дает уверенность в качестве пайплайна и указывает, что предыдущие этапы работают эффективно, выявляя основную часть дефектов до развертывания в производственную среду.
Среднее время восстановления
Среднее время восстановления или устранения проблемы (mean time to recovery or resolution, MTTR) означает время, необходимое для устранения сбоя в производственной среде. MTTR принимает во внимание, что в сложной системе с большим числом переменных периодические сбои в производственной среде неизбежны. Вместо того, чтобы пытаться добиться идеальной работы и в результате задерживать релизы, отказываясь от преимуществ коротких циклов, гораздо важнее быстро реагировать на проблемы.
Низкий показатель MTTR означает, во-первых, что вы постоянно отслеживаете состояние производственной системы и быстро выявляете возникающие проблемы, а во-вторых, что вы можете либо быстро вернуться к предыдущей версии, либо быстро развернуть через пайплайн необходимое исправление.
С этой метрикой связана еще одна: среднее время выявления проблем (mean time to detection, MTTD). Она означает время от развертывания обновления до момента, когда система мониторинга обнаруживает проблему, вызванную этим обновлением. Сравнив MTTD и продолжительность сборки, можно понять, удастся ли усовершенствовать какую-либо из этих сфер за счет инвестиций в сокращение MTTR.
Непрерывная интеграция и операционные метрики
Помимо метрик верхнего уровня, существует ряд операционных метрик, которые помогают лучше понять, как работает пайплайн, и определить те сферы, где рабочий процесс можно улучшить.
Покрытие кода
В CI/CD-пайплайне покрытие тестами должно обеспечиваться в основном за счет автоматических тестов. Благодаря этому QA-инженеры могут сосредоточиться на исследовательском тестировании и разработке новых тест-кейсов. На первом уровне автоматического тестирования следует выполнять юнит-тесты, поскольку они занимают меньше всего времени и быстрее всего дают обратную связь.
Метрику покрытия кода обеспечивает большинство CI-серверов путем расчета доли кода, покрытой юнит-тестами. Ее стоит отслеживать, чтобы по мере увеличения объемов кода тестами по-прежнему была покрыта достаточная доля кода. Если покрытие кода со временем снижается, нужно уделить ему дополнительное внимание, чтобы получать необходимую обратную связь на этом первом этапе.
Продолжительность сборки
Продолжительность сборки или время сборки — время, которое занимает выполнение различных этапов автоматического пайплайна. Отслеживать время, потраченное на каждом этапе рабочего процесса, очень полезно для выявления проблемных мест, этапов, которые тормозят работу в целом и увеличивают время получения обратной связи после тестирования или развертывания в производственную среду.
Доля успешных выполнений тестов
Доля успешных выполнений тестов — процент успешно пройденных тест-кейсов для определенной сборки. При условии разумного уровня автоматического тестирования это дает хорошее представление о качестве каждой сборки. Эта метрика помогает понять, как часто изменения в коде приводят к неуспешному выполнению тестов.
Безусловно, лучше находить ошибки с помощью автоматических тестов, чем проводить ручное тестирование или обнаруживать проблемы после развертывания в производственную среду. Однако, если определенный набор автоматических тестов регулярно завершается неуспешно, возможно, стоит поискать первопричину ошибок.
Время устранения ошибок при тестировании
Время устранения ошибок при тестировании — промежуток времени от получения отрицательного результата теста сборки до успешного прохождения этого теста следующей сборкой. Эта метрика показывает, насколько быстро вы устраняете проблемы, обнаруженные в пайплайне.
Малое время устранения ошибок показывает, что вы максимально эффективно используете пайплайн. Решая проблемы сразу после их выявления, вы повышаете общую эффективность работы, поскольку еще хорошо помните, в чем заключались сделанные изменения, и не надстраиваете новые функции на базе нестабильного кода.
Ошибки развертывания
Ошибки развертывания приводят к вынужденным простоям и требуют возврата к предыдущей версии или срочного выпуска исправления. Количество ошибок развертывания используется для расчета уровня отказа изменений (об этой метрике мы говорили выше).
Отслеживая долю ошибок в общем числе развертываний, вы можете оценить выполнение соглашений о гарантированном уровне обслуживания (SLA).
Однако необходимо помнить, что целевой показатель в ноль (или даже просто очень низкое количество) ошибок при развертывании не всегда достижим. Стремясь к нему, команды могут уйти в перфекционизм. В результате увеличится срок поставки и размер развертывания, поскольку изменения будут объединяться в крупные пакеты. Это в свою очередь только повысит вероятность ошибок в производственной среде из-за увеличения числа переменных, а устранить эти ошибки будет сложнее, поскольку придется анализировать больше изменений.
Число дефектов
В отличие от ошибок, число дефектов означает количество открытых тикетов, относящихся к багам. Его можно разделить на проблемы, выявленные при тестировании и в производственной среде.
Как и в случае с покрытием кода, отслеживать число дефектов полезно для оценки общей тенденции: если показатель растет, это означает, что баги выходят из-под контроля. Но помните, что, если этот показатель станет целевым, ваша команда может заняться в первую очередь классификацией тикетов, а не устранением проблем.
Размер развертывания
Размер развертывания непосредственно связан с частотой развертывания (см. выше). Он определяется количеством единиц сложности, которые входят в сборку или релиз, и с его помощью можно отслеживать размер пакета у определенной команды.
Если размеры развертываний небольшие, значит, команда регулярно делает коммиты изменений и пользуется всеми связанными с этим преимуществами. Однако оценки сложности в разных командах будут отличаться, поэтому эту метрику не стоит использовать для определения общего размера развертывания.
Заключение
Мониторинг этих метрик позволяет лучше оценить эффективность CI/CD-пайплайна и сформировавшиеся положительные или отрицательные тенденции.
Метрики можно использовать для выявления тех этапов процесса, которым стоит уделить дополнительное внимание. После внесения изменений рекомендуем отслеживать соответствующие показатели, чтобы понять, достигнут ли нужный эффект.
Тем не менее, нужно помнить: метрики могут быть полезны для оценки эффективности работы, но их необходимо рассматривать в широком контексте и в первую очередь продумывать, каких улучшений можно добиться, исходя из того или иного показателя. Помните, что цель — не улучшить числовые показатели, а обеспечить быстрый и надежный пайплайн, чтобы доставлять пользователям качественный продукт.