Статьи
Обучающие материалы
Интерактивные руководства
Показатели DevOps
Что, зачем и как делать для измерения успеха в DevOps
ТОМ ХОЛЛ
Консультант и специалист по DevOps
Старая поговорка о том, что «нельзя улучшить, не измерив», справедлива для DevOps и любой другой методики. Чтобы обещание DevOps о повышении скорости поставки и качества продуктов действительно сбылось, командам нужно собирать, анализировать и измерять множество показателей. Эти показатели DevOps снабжают команды DevOps необходимыми данными для наблюдения за конвейером разработки и контроля над ним.
Что такое показатели DevOps?
Показатели DevOps — это измеряемые параметры, которые показывают производительность конвейера DevOps для разработки программного обеспечения и помогают быстро выявить и устранить любые «узкие» места в процессе. Эти показатели можно использовать для отслеживания технических возможностей и рабочих процессов команды.
По сути методика DevOps нацелена на размытие границ между командами по разработке и эксплуатации и способствует более тесному сотрудничеству между разработчиками и системными администраторами. Показатели позволяют командам DevOps измерять и оценивать совместные рабочие процессы, а также отслеживать прогресс в достижении глобальных целей, включая повышение качества, ускорение циклов выпуска и повышение производительности приложений.
Четыре важнейших показателя DevOps
Для измерения производительности DevOps используется множество параметров, однако следующие четыре ключевых показателя обязательны для каждой команды DevOps.
1. Время внесения изменений
Один из важнейших показателей DevOps, которые нужно отслеживать, — это время внесения изменений. Его не следует путать со временем цикла (обсуждается ниже). Время внесения изменений представляет собой промежуток времени между внедрением коммита с изменением кода в магистральную ветку и его переходом в состояние готовности к развертыванию (например, после прохождения кодом всех необходимых предварительных тестов).
2. Частота сбоев при внесении изменений
Частота сбоев при внесении изменений — это процент изменений кода, требующих быстрого исправления или устранения других недостатков после развертывания в рабочей среде. Сюда не включаются сбои, выявленные во время тестирования и исправленные до развертывания кода.
3. Частота развертывания
Информация о частоте развертываний нового кода в рабочей среде имеет решающее значение для оценки успешности DevOps. Многие специалисты используют термин «поставка» для обозначения изменений кода, которые выпускают в промежуточную среду для подготовки к релизу, а слово «развертывание» применяют для изменений кода, выпускаемых в рабочую среду.
4. Среднее время восстановления
Среднее время восстановления (MTTR) показывает, сколько времени потребуется для восстановления после частичного перебоя в обслуживании или полного отказа. Это важный показатель, который необходимо отслеживать независимо от того, вызвано прерывание недавним развертыванием или отдельным сбоем системы.
См. решение
Инструменты для высококлассной команды DevOps
Связанные материалы
Важность структуры команды в DevOps
Измерение, использование и улучшение показателей DevOps
Подобно другим элементам жизненного цикла DevOps, к показателям DevOps применяется культура непрерывного совершенствования. Высокоэффективные команды отличает способность быстро получать обратную связь на каждом этапе разработки в сочетании с навыками и полномочиями для ее реализации. В книге о DevOps под названием Accelerate (Ускоряйся!) авторы отмечают: кроме четырех основных показателей (перечислены выше) есть еще 24 характеристики, которыми пользуются высокоэффективные команды разработчиков ПО. Большинство из этих характеристик (CI/CD, автоматизация тестирования, работа с небольшими пакетами, мониторинг и непрерывное обучение) рассматриваются ниже, однако мы советуем прочесть книгу Accelerate, чтобы узнать больше об исследованиях, на которые опираются эти методы.
Время внесения изменений
Высокоэффективные команды обычно измеряют время выполнения в часах, а команды со средней или низкой результативностью — в днях, неделях или даже месяцах.
Сократить время выполнения можно прежде всего благодаря автоматизации тестирования, магистральной разработке и работе с небольшими пакетами. Эти методы дают возможность разработчикам быстро получить обратную связь по качеству кода, для которого сделан коммит, чтобы можно было выявить и устранить любые дефекты. Большое время выполнения практически гарантировано, если разработчики вносят существенные изменения в разных ветках и полагаются на ручное тестирование для контроля качества.
Частота сбоев при внесении изменений
У высокоэффективных команд частота сбоев при внесении изменений находится в диапазоне от 0 до 15 процентов.
Методы, позволяющие сократить время выполнения (автоматизация тестирования, магистральная разработка и работа с небольшими пакетами), снижают и частоту сбоев при внесении изменений. Благодаря этим методам становится значительно проще выявить и устранить дефекты.
Отслеживание и отчеты о частоте сбоев при внесении изменений важны не только для выявления и исправления ошибок. Они помогают обеспечить соответствие новых релизов кода требованиям безопасности.
Частота развертывания
Высокоэффективные команды могут развертывать изменения по требованию и зачастую делают это несколько раз в день. Менее результативные команды часто ограничиваются развертыванием раз в неделю или раз в месяц.
Для развертывания по требованию нужен автоматизированный конвейер развертывания с механизмами автоматического тестирования и обратной связи (упоминаются в предыдущих разделах), который почти не требует вмешательства человека.
Среднее время восстановления
Высокоэффективные команды быстро восстанавливаются после сбоев системы (обычно на это уходит меньше часа), тогда как менее результативным командам может потребоваться целая неделя.
Для оперативного восстановления после сбоя нужно быстро определить, когда он произошел, затем развернуть исправление или выполнить откат изменений, повлекших сбой. Обычно для этого ведется непрерывный мониторинг работы системы, а в случае сбоя оперативный персонал получает оповещение. Таким сотрудникам нужно предоставить доступ к необходимым процессам, инструментам и правам для устранения инцидентов.
Акцент на показателе MTTR представляет собой отказ от исторической практики, согласно которой основное внимание должно уделяться средней наработке на отказ (MTBF). Такой подход свидетельствует о росте сложности современных приложений, что влечет за собой более частые сбои. Кроме того, это подчеркивает важность непрерывного обучения и совершенствования. Команды не ждут, пока развертывание станет «оптимальным», чтобы избежать сбоев (и сброса старого табло MTBF), а вместо этого выполняют непрерывное развертывание. Не нужно обвинять сотрудников за порчу «идеального» отчета по MTBF. Показатель MTTR поощряет ретроспективы без поиска виновных, чтобы помочь командам улучшить процессы и инструменты.
Другие связанные показатели
Другим важным показателем является время цикла, то есть время, которое команда тратит на работу над объектом, пока он не будет готов к поставке. В разработке время цикла — это промежуток времени от совершения разработчиками коммита до его развертывания в рабочей среде. Этот ключевой показатель DevOps помогает руководителям проектов и отделов разработки лучше понять, что хорошо работает в конвейере разработки. В результате они могут лучше согласовать свою работу с ожиданиями заинтересованных лиц и клиентов и ускорить поставку в команде.
Отчеты о времени цикла позволяют руководителям проектов задать ориентир для конвейера разработки и использовать его для оценки будущих процессов. Когда команды оптимизируют время цикла, у разработчиков обычно остается меньше незавершенной работы и неэффективных рабочих процессов.
При бережливом управлении продуктами основное внимание уделяется систематизации потока ценности, на которой наглядно представлен поток от концепции продукта или функции до поставки. Показатели DevOps дают массу ценной информации для эффективной систематизации потока ценности и управления им, однако для полноценной и комплексной оценки их следует дополнить другими бизнес-показателями и параметрами продукта. Например, благодаря диаграммам Burndown для спринтов можно проанализировать эффективность процессов оценки и планирования, а индекс потребительской лояльности (NPS) показывает, соответствует ли конечный результат потребностям клиентов.
Заключение
Непрерывное совершенствование — основной принцип работы команд, практикующих DevOps. Измерение и отслеживание производительности по времени внесения изменений, частоте сбоев при внесении изменений, частоте развертываний и показателю MTTR позволяет командам повысить скорость и качество работы.
С помощью Open DevOps от Atlassian команды получают все необходимое для разработки и эксплуатации программного обеспечения. Они могут создать нужный им пакет инструментов DevOps благодаря интеграциям с ведущими поставщиками и приложениями из Marketplace. Попробуйте прямо сейчас.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.
Сообщество DevOps
Образовательные программы DevOps
