Ключом к продуктивной стратегии DevOps являются эффективные и всесторонние трекинги и мониторинг. Составьте подробный план действий, чтобы понять, как работают процессы и проекты и как их улучшить с течением времени.
Ключевые показатели эффективности (KPI) DevOps усложняются тем фактом, что эта методология не имеет формальной основы, поэтому определение прогресса может различаться в разных организациях. Однако существуют общие и ключевые показатели эффективности, которые должны поддерживать проект DevOps в нужном направлении.
1. Частота развертывания
Инновации порождают быстрые технологические изменения. Отслеживайте частоту развертывания кода, чтобы получить четкое представление о том, как быстро внедряются новые функции и возможности. Этот показатель должен оставаться постоянным или иметь тенденцию к увеличению с течением времени. Снижение указывает на проблему где-то в рабочем процессе команды DevOps.
2. Время выполнения задачи
Определите, сколько времени требуется, например, исправить ошибки или добавить новую функцию. Длительные сроки могут свидетельствовать о неэффективности процессов, препятствующих внедрению изменений; Короткое время выполнения задачи может указывать на то, что процесс DevOps в целом проходит гладко.
Этот ключевой показатель эффективности DevOps должен стать отправной точкой для обнаружения закономерностей, по которым можно определить препятствия в разработке.
3. Объемы
Этот показатель неразрывно связан с частотой развертывания и определяет количество новых пользовательских историй или изменений кода, которые команда DevOps вносит с каждым выпуском или за определенный период времени. Этот ключевой показатель эффективности помогает измерить ценность развертывания для конечных пользователей и определить, думает ли команда об изменениях элементарно или все еще думает о больших и сложных развертываниях, часто встречающихся при Waterfall методологии.
В то время как большой объем изменений может быть признаком эффективного итеративного подхода к продукту, он также может быть показателем слишком узкого разделения проекта и изменений, происходящих исключительно ради изменений. Команды должны быть осторожны, чтобы не тратить слишком много времени на частые изменения кода, которые несущественны для их организации или конечных пользователей.
4. Неудачные развертывания
Изменения должны внедряться не только часто, но и плавно. Поддерживайте частоту сбоев на минимально возможном уровне. Потенциальные сбои включают изменения, которые приводят к проблемам с тайм-аутом для пользователей или требует отката для дальнейшей работы. Разработайте систему для отслеживания успеха и неудачи изменений. Высокая частота неудачных изменений влияет на конечных пользователей приложения и требует от администраторов дополнительных затрат времени на устранение неполадок и исправление ошибок, а не на реализацию важных инициатив.
5. Объем дефекта и процент брака
Изменение может быть развернуто успешно, но породить множество ошибок. Хотя эти ошибки не обязательно достаточно значительны, чтобы вызвать сбой, они негативно влияют на опыт конечного пользователя. В идеале KPI DevOps для объема дефектов должен оставаться как можно ниже. Однако некоторые организации принимают концепцию бюджета ошибок, утверждая, что 100% время безотказной работы и надежность негативно влияют на возможности приложений и бюджеты проектов. В своей самой базовой форме бюджет ошибок поощряет инновации и быстрые итерации с ожидаемым допустимым уровнем и частотой ошибок и простоев.
Также отслеживайте скорость устранения дефектов. Этот показатель DevOps представляет собой количество ошибок или дефектов, которые конечные пользователи выявляют в рабочей среде, по сравнению с количеством дефектов, зарегистрированных отделом обеспечения качества (QA) или группами разработчиков до развертывания. Высокий процент устранения дефектов указывает на проблему с тестами QA и проверкой кода.
6. Среднее время обнаружения
Не измеряйте ключевые показатели эффективности DevOps изолированно. Низкая частота неудачных изменений не является хорошим показателем, если для обнаружения проблемы требуется слишком много времени. Например, если среднее время обнаружения (MTTD- Mean Time To Detect) составляет 30 дней, это означает, что может потребоваться целый месяц для диагностики проблемы, которая приводит к увеличению количества отказов. MTTD должен уменьшаться со временем по мере развития процессов DevOps. Если MTTD высокое или имеет тенденцию к увеличению, проблемы, вызывающие эти существующие задержки, приведут к дополнительной перегрузке рабочего процесса DevOps в будущем. Быстрое обнаружение также является благом для безопасности, поскольку оно должно свести к минимуму охват потенциальной атаки.
7. Среднее время восстановления
Среднее время восстановления — еще одна ключевая метрика DevOps, которую администраторы должны поддерживать как можно ниже. Устраняйте проблемы, как только вы о них узнаете. Организации DevOps следуют принципу, согласно которому частые дополнительные изменения легче внедрять и легче исправлять, когда что-то идет не так. Если выпуск включает в себя высокую степень изменений и сложности, становится сложнее выявлять и решать проблемы в нем.
8. Приоритизация функций
Как часто конечные пользователи пользуются преимуществами продукта или услуги? Если ваша команда DevOps тратит время и усилия на создание и внедрение нового кода в рабочую среду, убедитесь, что эти функции ценны для целевой аудитории. BizDevOps усиливает ценность итерации для максимально быстрого удовлетворения потребностей пользователей. Если использование функций низкое или сокращается, переоцените факторы приоритизации вместе с руководством, чтобы определить лучший цикл обратной связи с пользователями.
9. Незапланированная работа
Эта метрика помогает отслеживать как качество выпусков ПО, так и общую продуктивность и удовлетворенность команды DevOps. Количественно определите объем работы над выпуском в начале цикла DevOps и сравните его с фактической работой, необходимой для завершения выпуска. Помните о незапланированной работе, которая завершается, а также о работе, которая была начата, но прекращена, и продолжающемся прогрессе после выпуска.
Чем больше времени разработчики и операционные администраторы тратят на незапланированную работу, например на исправление ошибок в рабочей среде, тем больше вероятность того, что проблема связана с подходом DevOps. Возможно, существуют проблемы с методами тестирования или существует разрыв между средами разработки, тестирования и производства.
Когда команды тратят много времени на тушение непредвиденных пожаров, общая производительность снижается, а риск ИТ-выгорания возрастает.
10. Скорость прохождения тестов безопасности
Сканирование уязвимостей не является обычным тестом в конвейере доставки ПО. Определите жизнеспособность теста и внедрите его, когда это возможно. Неудачный тест безопасности на этапе сборки может помешать запуску некоторых выпусков в производство. Если выпуски кода постоянно не проходят тесты на уязвимости, этот KPI DevOps предполагает, что команды игнорируют методы обеспечения безопасности выше по течению и в конечном итоге должны исправить эти проблемы.
11. Соответствие SLA
Время безотказной работы приложений — важный показатель для каждой ИТ-организации. Соглашения об уровне обслуживания требуют, чтобы инфраструктура, службы и поддерживающие приложения соответствовали высокой цели доступности. Службы должны быть подключены к сети как можно чаще, что обеспечивает достижение цели по времени безотказной работы до 99,9%.
12. Производительность приложения
Неожиданный приток конечных пользователей может создать проблемы с производительностью на уровне инфраструктуры. Помехи в хранилище, скачки ЦП, высокое потребление памяти и задержка в сети — все это распространенные побочные эффекты high load. Внимательно следите за этими стандартными аспектами производительности серверов, поддерживающих приложение. Увеличение числа конечных пользователей может потребовать создания дополнительной инфраструктуры. Однако снижение производительности без дополнительных запросов конечных пользователей может указывать на то, что ошибки или неэффективные изменения в процессе разработки и выпуска тормозят работу приложения. Проверяйте и исправьте их по мере их появления, чтобы обеспечить высокую доступность и удобство работы конечных пользователей.
Мы в CORE 24/7 проведем аудит вашей инфраструктуры, процессов и сможем предложить эффективные методы решения проблем в ваших процессах. Больше информации у нас на сайте!