При отслеживании ключевых метрик DevOps необходимо сосредоточится не на плюсах или минусах, основанных на каком-либо одном показателе, а скорее на статистике, которую эти метрики показывают, когда совместно анализируются.
👉Продолжаем рассматривать основные показатели KPI, которые используются на практике:
► Скорость ухода от ошибок (Defect Escape Rate)
Каждое развертывание программного обеспечения сопряжено с риском появления новых ошибок. Они могут не быть обнаружены, пока тестирование не будет завершено. Хуже того, они могут быть найдены конечным пользователем. Этот параметр отслеживает, как часто ошибки обнаруживаются на этапе предварительного тестирования по сравнению с продакшн-средой. Эта цифра может служить ценным показателем общего качества выпусков программного обеспечения.
► Время выполнения (Lead Time)
Время выполнения отображает информацию об эффективности всего процесса разработки. Этот показатель также указывает на текущую способность удовлетворять растущие потребности пользователей. Время выполнения начинает свой отсчет, когда от пользователя поступил запрос и заканчивается, когда запрос полностью выполнен. Частью Lead Time является Process Time — время за которое по факту выполнен пользовательский запрос. Отсчет начинается когда команда приступила к выполнению задачи до полного выполнения запроса.
► Объем ошибок (Defect Volume)
Эта метрика фокусируется на фактическом объеме ошибок. Большой объем ошибок для конкретного приложения может указывать на проблемы с управлением данными разработки или тестирования.
► Доступность (Availability)
Доступность указывает степень простоя для данного приложения. Это может измеряться как полной, так и частичной доступностью. При этом для планового технического обслуживания может потребоваться некоторое снижение доступности. Тщательно отслеживайте как запланированные простои, так и незапланированные отключения, помня о том, что 100-процентная доступность может оказаться невозможной.
► Соответствие SLA (SLA compliance)
Время безотказной работы приложений является важным показателем для каждой ИТ-организации. Соглашения об уровне обслуживания требуют, чтобы инфраструктура, службы и поддерживающие приложения соответствовали высокой цели доступности. Сервисы должны быть в максимально возможной степени доступны пользователям, что позволяет достигать SLA 99,99%.
► Незапланированная работа (Unplanned Work)
Этот показатель помогает отслеживать как качество выпусков программного обеспечения, так и общую продуктивность команды DevOps. Определите объем работы для выпуска в начале цикла DevOps и сравните его с фактической работой, необходимой для завершения выпуска. Чем больше времени разработчики и администраторы тратят на незапланированную работу, такую как устранение ошибок в производственной среде, тем хуже. Возможно, существует недостаток тестирования или разрыв между средами разработки, тестирования и производства. Когда команды проводят много времени в борьбе с непредвиденными «пожарами», общая производительность снижается, а риск выгорания возрастает.
#devops #cicd #pipeline #git #sla
