Полное руководство по метрикам DORA
1 декабря 2022 г.Цифровая современная экономика определяется изобретательностью компаний в предоставлении продуктов, которые привлекают клиентов и приносят доход, а также их способностью эффективно обеспечивать высококачественные результаты. Чтобы оставаться на вершине своей игры, инженерные группы все чаще используют DevOps и непрерывную интеграцию/непрерывную доставку (CI/CD) для обеспечения успешной доставки программного обеспечения. n n Поскольку ускоренное внедрение процессов и инструментов DevOps продолжается, руководители групп разработчиков сталкиваются с ключевыми вопросами измерения воздействия и окупаемости процессов DevOps. Лидеры в области продуктов и разработки оценивают, как они могут управлять своими возможностями по доставке программного обеспечения, учитывая распределенный характер задействованных команд, технологий и приложений. n n В разработке программного обеспечения почти невозможно увидеть, как каждая часть процесса разработки сочетается друг с другом, без надежных точек данных, которые можно отслеживать между командами. Поскольку команды разбросаны по всему миру и разбиты на множество разных более мелких команд, работающих над меньшими частями более крупного проекта, становится еще труднее сказать, кто, что и когда делает, что блокирует и какая именно проблема вызывает задержка.
Показатели DORA, предложенные командой Google DORA, служат путеводной звездой для команд DevOps, снабжая команды информацией, необходимой им для наблюдения и контроля над процессом разработки программного обеспечения.
Что такое показатели DORA?
В 2018 году исследовательская программа Google под руководством DevOps Research and Assessment (DORA) team опросили тысячи команд разработчиков из разных отраслей, чтобы определить, что отличает высокоэффективную команду от низкоэффективной. Исследовательская группа представила следующие четыре ключевых показателя, свидетельствующих об успешной разработке и доставке программного обеспечения:
* Частота развертывания (DF), * Среднее время выполнения изменений (MLT), * Среднее время восстановления (MTTR) и * Частота отказов изменений (CFR).
Результаты и данные исследования DORA стали ориентиром для людей, отвечающих за отслеживание эффективности DevOps в своих организациях. n Их крайне важно отслеживать, поскольку они помогают руководителям DevOps и инженеров определять пропускную способность (скорость) и стабильность (качество) доставки программного обеспечения. Они демонстрируют, как команды разработчиков могут быстрее предлагать более качественные продукты клиентам. Эти метрики предоставляют руководителям осязаемые данные для оценки эффективности DevOps в организации, составления отчетов для руководителей и предложений по улучшению. n n Метрики DORA не ограничиваются только метриками; Они обеспечивают наглядность деятельности разработчиков и соответствующих успешных результатов, позволяя разработчикам повысить производительность своих команд. Показатели DORA позволяют руководителям и руководителям инженерных систем развивать высокоэффективные команды, предоставляя представление о текущей производительности и помогая руководителям составить план действий по улучшению.
Четыре ключевых показателя DORA
Частота развертывания
Частота, с которой команда вносит изменения в рабочую среду, измеряется частотой развертывания. Этот показатель представляет скорость, с которой ваша команда поставляет программное обеспечение. n По данным DORA, высокопроизводительные команды стараются выпускать более мелкие и частые развертывания. Благодаря этому процессу клиенты выигрывают от более быстрого окупаемости, а команда разработчиков выигрывает от меньшего риска (небольшие изменения означают более быстрое исправление, когда изменения вызывают проблемы в работе).
Изменить время выполнения
Общий период с момента начала работы над запросом на изменение до момента его запуска в производство и, следовательно, предоставления заказчику известен как время выполнения запроса на изменение. Вы можете использовать время выполнения (не путать с временем цикла/временем выполнения), чтобы определить эффективность вашего процесса разработки. Длительное время выполнения может быть вызвано неэффективной процедурой или узким местом в конвейере разработки или развертывания.
n Сравнение времени первого добавления кода для конкретной проблемы со временем развертывания является наиболее типичным способом оценки времени выполнения. Сравнение времени выбора проблемы для разработки и времени ее развертывания является более тщательным (но и более трудным для точного определения) методом.
n Высокоэффективные команды измеряют время выполнения заказа в часах, а средне- и низкоэффективные команды — в днях, неделях и даже месяцах. Автоматизация тестирования, разработка на основе магистралей и работа с небольшими партиями имеют решающее значение для сокращения времени выполнения заказа. Эти методы позволяют разработчикам получать немедленную обратную связь о качестве кода, который они вносят, позволяя им видеть и исправлять любые недостатки. Если разработчики работают над крупными модификациями, которые находятся в разных ветвях, и полагаются на ручное тестирование для контроля качества, почти гарантировано длительное время выполнения.
n Изменить процент отказов
Отношение количества развертываний к количеству сбоев известно как частота сбоев при изменении. Тем не менее, определение того, что представляет собой отказ, имеет решающее значение. Эта статистика DORA будет уникальной для вас, вашей команды и предоставляемых вами услуг. На самом деле, по мере развития вашей команды, она, скорее всего, будет меняться. n Наиболее типичная ошибка — сосредоточиться на общем количестве сбоев, а не на частоте сбоев изменений. Проблема в том, что это будет поощрять неправильное поведение. Наша цель — доставлять изменения как можно быстрее. Если вы просто смотрите на общее количество сбоев, естественной реакцией будет попытка ограничить количество развертываний, чтобы уменьшить количество инцидентов. Как было сказано ранее, трудность в этом заключается в том, что модификации настолько значительны, что влияние сбоя, если он произойдет, будет значительным, что приведет к ухудшению качества обслуживания клиентов. Когда происходит сбой, вы хотите, чтобы он был настолько незначительным и понятным, чтобы не вызывать серьезного беспокойства. n Процент неудач элитных команд составляет 0-15 процентов. Сокращение количества сбоев при развертывании значительно повлияет на общую производительность команды. Все хотят тратить меньше времени на исправления и исправления и больше времени на создание выдающихся продуктов. n n Среднее время восстановления (MTTR)
Процесс реагирования на инциденты включает несколько шагов, и MTTR — лишь один из них. Во-первых, вы должны определить, есть ли проблема. Как быстро вы можете отправить замену после того, как вы ее нашли? Вот что такое MTTR.
n Время, необходимое для обнаружения проблемы, само по себе является показателем, известным как MTTD (среднее время до обнаружения). Если вы можете быстро обнаружить проблему, вы можете уменьшить MTTD почти до нуля, а поскольку MTTD учитывается при расчете MTTR, улучшение MTTD также помогает увеличить MTTR. n Высокоэффективные команды быстро восстанавливаются после системных сбоев, обычно в течение часа, в то время как менее эффективным командам на восстановление может потребоваться до недели.
n Возможность быстрого восстановления после сбоя зависит от способности распознавать сбой, как только он возникает, и выпускать средства исправления или откатывать любые изменения, вызвавшие сбой. Обычно это достигается за счет непрерывного мониторинга состояния системы и уведомления оперативного персонала о каждом сбое. Для разрешения инцидентов операционные сотрудники должны иметь соответствующие протоколы, инструменты и разрешения.
Другие связанные показатели
Время цикла — еще один важный показатель, который следует учитывать. Это количество времени, которое команда тратит на работу над элементом, пока он не будет готов к отправке. Время цикла в разработке программного обеспечения — это время, которое проходит с момента, когда разработчики берут на себя обязательство, до момента его развертывания в рабочей среде. n Ознакомьтесь с записью в нашем блоге о времени цикла: https://www.hatica.io/blog/cycle-time/ n n Метрики DORA и управление потоком создания ценности
Поток создания ценности символизирует непрерывный поток ценности для потребителей, а управление потоком создания ценности помогает организации отслеживать и управлять этим потоком от концепции до реализации. Показатели DORA неразрывно связаны с управлением потоком создания ценности в каждой компании-разработчике программного обеспечения. Многие этапы сквозной разработки программного обеспечения связаны и измеряются с надлежащим управлением потоком создания ценности, чтобы гарантировать, что полная ценность продукта или услуги достигает клиентов эффективно.
Цель управления потоком создания ценности — предлагать высококачественное программное обеспечение со скоростью, которая нужна вашим клиентам, что повышает ценность вашей компании.
Измерения DORA служат основой для этого подхода, поскольку они представляют собой проверенный набор тестов DevOps, которые стали отраслевыми стандартами. Они обнаруживают неэффективность или потери, которые вы можете использовать для оптимизации и устранения узких мест в своих рабочих процессах. Когда показатели DORA вашей команды улучшаются, повышается и эффективность всего потока создания ценности.
💡 Непрерывное совершенствование — основной принцип команд DevOps. Hatica предоставляет команде разработчиков возможность измерять и отслеживать производительность в зависимости от времени выполнения изменений, частоты отказов изменений, частоты развертывания и MTTR, что позволяет командам ускорить скорость и повысить качество. Запросить демонстрацию →
Первоначально опубликовано здесь.
Оригинал