Вольный перевод статьи.

Как метрики определили DevOps

начало положила команда DevOps Research and Assessment (DORA), Они выделили четыре ключевых метрики, которые являются основой для измерения успеха

Deployment Frequency: (частота развертывания) относится к частоте успешных выпусков программного обеспечения в производство. Этот показатель измеряет, как часто команда выпускает и успешно разворачивает новые версии программного обеспечения в рабочей среде. Высокая частота развертывания может указывать на более частые итерации разработки и доставки, что в свою очередь способствует более быстрой реакции на изменения и потребности пользователей, а также улучшению общей эффективности процессов DevOps.

Lead Time for Changes: (время выполнения изменений) измеряет время, прошедшее с момента фиксации изменения кода (например, коммита) до того момента, когда это изменение становится готовым для развертывания (в развертываемом состоянии). Этот показатель позволяет оценить, насколько быстро команда может превратить кодовое изменение в рабочее приложение, готовое к развертыванию в производственной среде. Уменьшение времени выполнения изменений обычно способствует более быстрой и эффективной разработке и доставке программного обеспечения.

Mean Time to Recovery: Среднее время восстановления (Mean Time to Recovery, MTTR) измеряет время, прошедшее с момента возникновения прерывания из-за развертывания или сбоя системы до полного восстановления работы системы. Этот показатель помогает определить, насколько быстро команда может восстановить работоспособность системы после возникновения проблемы или сбоя. MTTR является важной метрикой для оценки эффективности инцидентного управления и улучшения процессов восстановления.

Change Failure Rate: Показатель частоты неудач при изменениях (Change Failure Rate) указывает, насколько часто изменения или исправления (hotfixes), внесенные командой, приводят к сбоям или отказам после развертывания кода в производственной среде. Этот показатель является важной метрикой в контексте DevOps и оценивает надежность и стабильность процесса развертывания и обновления программного обеспечения.

Больше информации тут:

С момента публикации книги “Accelerate” команда LinearB увидела, как работа DORA преобразила область DevOps. Однако вскоре стало понятно, что четыре ключевых метрики DORA в одиночку недостаточно для измерения разнообразных и растущих организаций, практикующих DevOps.

DORA helped DevOps move from “darkness to visibility.” But once there’s full illumination, leaders need a full understanding of what makes one team more effective than another — and what characterizes the top tier of development teams that are truly elite.

LinearB co-founder and CEO Ori Keren

Что не так с DORA метриками ?

• DORA являются отстающими индикаторами, проще и более эффективно выявлять тенденции и предпринимать превентивные действия, чем спешить исправлять ошибки после неудачных итераций.

• Метрики DORA не точно измеряют бизнес-влияние. В пример приводится супер заряженная машина, которая идеально работает, но едет в другом направлении. Некоторые метрики, такие как время цикла и частота развертывания, важны для внутренней команды, но не имеют смысла для бизнеса в целом. Разработчики заботятся о относительной скорости разделов кода (как бы маленьких они ни были), чтобы обеспечивать плавную работу своего пайплайна, но руководители бизнеса хотят видеть всю функциональность – постоянно и как можно чаще. Скорость не имеет значения, если нет согласования с остальным бизнесом и команда не предоставляет то, что сделает клиентов счастливыми.
• Метрики DORA являются важными показателями текущего состояния, но они не являются планами изменений; они являются отправной точкой.

The New Metrics

Для того чтобы внести изменения в инженерные команды, исследование от LinearB выявило 10 метрик внутри 3 групп, которые имеют наибольшее значение в современной методологии DevOps.

• Жизненный цикл доставки ( Delivery Lifecycle Metrics )
• Рабочий процесс разработчиков ( Developer Workflow Metrics )
• Согласованность с бизнесом ( Business Alignment Metrics )

Delivery Lifecycle Metrics

1. Время цикла (Cycle time)

Время цикла (часто синоним Lead Time изменений ) является одной из четырех ключевых метрик DORA. Оно представляет собой время, прошедшее с момента первого коммита до момента, когда изменение достигает пользователей, охватывая время написания кода, время подбора задачи, время ревью и время на деплой.

Эффективное время цикла для элитных команд составляет менее 42 часов.

2. Время кодирования (Coding time)

Эта метрика измеряет время, затраченное с момента начала первого коммита до выдачи запроса на слияние (pull request, PR).

Для элитных команд время кодирования – менее 30 минут.

3. Время подбора (Pickup time)

Это время начинается после выдачи запроса на слияние (PR) и заканчивается после того, как будет оставлен первый комментарий.

Для элитных команд время подбора составляет менее 1 часа.

4. Время рецензии (Review time)

Эта метрика охватывает процесс рецензии кода и слияния PR, начиная с первого комментария и заканчивая моментом, когда изменения объединяются с основной веткой кода.

Для элитных команд время рецензии составляет менее 1 часа

5. Время развертывания (Deploy time)

Это измерение времени с момента слияния ветки (branch merge) до момента выпуска кода.

Для элитных команд время развертывания составляет менее 1 часа

Developer Workflow Metrics & How Elite Teams Perform

6. Частота развертывания (Deploy frequency)

Эта метрика измеряет, насколько часто код выпускается в производство. Она выше, когда время развертывания (deploy time) ниже. Ее также можно рассматривать как функцию времени цикла (cycle time).

Элитные команды делают деплой кода ежедневно.

7. Размер пул реквеста (PR)

Это, безусловно, один из наиболее важных ведущих индикаторов здоровой разработки. Меньшие PR = более быстрое восприятие, более быстрые и более глубокие рецензии, более быстрые слияния и более высокая частота развертывания.

В элитных командах в среднем менее 105 изменений кода в их PR.

8. Уровень “брака” (Rework rate)

Эта метрика измеряет уровень изменений в коде (code churn). Переделывание относится к изменениям в коде, возникшим в коде, который старше 21 дня. Более высокие уровни переделывания могут быть индикаторами проблем с качеством.

У элитных команд уровень переделывания составляет менее 2%.

Business Alignment Metrics

9. Точность планирования (Planning accuracy)

Эта метрика определяет, насколько точно выполнено планирование, то есть насколько совпадает то, что было запланировано, с тем, что было фактически доставлено.

Элитные команды имеют точность планирования 80% и более.

10. Точность определения объема (Capacity Accuracy)

Точность определения объема показывает, берут ли ваши команды “правильное” количество работы. Эта метрика измеряет соотношение всех завершенных (запланированных и незапланированных) задач к запланированной работе.

Элитные команды имеют точность определения объема более 85%.

Это означает, что они эффективно управляют рабочей нагрузкой, беря на себя необходимое количество работы и успешно завершая ее.

PS: остаток статьи маркетинг

PPS: Accelerate State of DevOps 2021

Типовые моменты которые стоит отработать на берегу

1. Прояснить требования к роли
2. Дать четкие, измеримые задачи на первые пару месяцев
3. Постепенное продвижение в сложные задачи
4. Не бросать одного, выстроить связь с остальной командой
5. Дать понимание о команде в целом, выстроить связь со смежными подразделениями

Теперь пройдемся по каждому пункту поподробнее

SRE – это широкая и разносторонняя роль.

Ваше определение SRE может отличаться от определения этой роли в других компаниях, где работал ваш новый сотрудник. Или вы вообще не определила четкие цели для SRE. Это может привести к неясному представлению о работе, которую нужно выполнять. В итоге, роли, на которые вы нанимаете сотрудников, становятся менее четкими.

Новые сотрудники могут быть эффективными только в той степени, в которой им известно, что нужно делать.

Постепенное продвижение в сложные задачи

Существует старая поговорка, которая гласит, что нельзя бежать, не научившись сначала ходить.

Это справедливо и в контексте обеспечения эффективности новых сотрудников в долгосрочной перспективе.

Знаю примеры когда руководители поступают следующим образом: предоставляют срок адаптации в 4-6 недель с ненапряжными заданиями, а затем бросают нового сотрудника “под Сталингад”.

Такой подход не всегда применим..

Дать конкретные, измеримые задачи в первые несколько месяцев

Важно предоставить новым сотрудникам конкретные и измеримые задачи в первые несколько месяцев работы. Если этого не делать, это может привести к недоиспользованию их потенциала, неопределенности и, как следствие, снижению продуктивности. Ниже представлены некоторые возможные шаги, которые помогут решить эту проблему:

1. Разработайте план адаптации: Создайте структурированный план адаптации для новых сотрудников, который включает в себя конкретные цели и задачи на первые несколько месяцев.
2. Установите ожидания: Объясните новым сотрудникам, какие результаты от них ожидаются в течение первых нескольких месяцев, и как они будут измеряться.
3. Прозрачность в задачах: Предоставьте им четкий список задач, которые они должны выполнять, и определите приоритеты.
4. Регулярные обзоры: Устраивайте регулярные обзоры прогресса, чтобы убедиться, что новые сотрудники понимают, как идет выполнение задач, и чтобы у них была возможность задавать вопросы и получать обратную связь.
5. Определите ключевые метрики успеха: Определите ключевые показатели, которые помогут измерить успех выполнения задач и оценить производительность новых сотрудников.
6. Дайте возможность для обучения: Предоставьте новым сотрудникам ресурсы и поддержку для обучения и развития, чтобы они могли успешно выполнять свои задачи.

Обеспечивая новым сотрудникам конкретные и измеримые задачи, вы помогаете им быстрее адаптироваться и стать более продуктивными членами команды.

Отсутствие конкретных, измеримых задач в первые месяцы работы

Это связано с недостатком ясности в роли.

Если у вас есть ясное представление о том, что должен делать ваш новый сотрудник, гораздо легче установить измеримые цели для того, на чем следует сосредоточить его внимание.

Это бывает сложно, если вы не знаете, с чего начать адаптацию нового сотрудника.

Некоторые конкретные и измеримые виды работы могут включать в себя:

• Наблюдение за работой других SRE при реагировании на инциденты (измеряется числом инцидентов).
• Написание отчетов об инцидентах (измеряется числом отчетов и выводами).
• Документирование процессов по мере их изучения (измеряется числом процессов).
• Написание кода для улучшения инструментов (измеряется количеством строк и коммитов).

Это может показаться банальным, но это конкретно и измеримо. Установка таких задач поможет не только новым сотрудникам ориентироваться, но и обеспечит более ясное представление о том, каким образом их работа будет измеряться и оцениваться.

Выстроить связи с остальной командой SRE

Это может сильно зависеть от того, где находится команда – в офисе, гибридно или полностью удаленно.

Это также может изменяться в зависимости от наличия у вас инициатив по созданию командного духа.

Ключевым моментом является создание эмоциональной связи между новым сотрудником и работой/командой.

Вот 3 способа, как вы можете усилить эмоциональную связь с вашей командой:

1. Программы ротации “бадди”. Соединение новых сотрудников с “бадди” (наставником) полезно, но один “бадди” означает одну сильную связь. Поворачивайте “бадди” в команде через разумное время, например, каждые 4 недели, чтобы распространить “рабочее дружеское чувство”.
2. Участие в совместных проектах. Вовлекайте новых сотрудников в проекты или активности, в которых участвуют несколько членов вашей команды. Это может включать проекты, такие как планирование ресурсов под новую систему, создание нового протокола реагирования на инциденты.
3. Регулярные встречи с руководителем. Это должно быть само собой разумеющимся, но, каюсь, сам оправдываю себя что постоянно занят и забываю о том, что недавно нанял новых сотрудников. Разумно заранее назначать расписание для очень коротких встреч.

Идеальный режим: проводить устные встречи в назначенные интервалы.

Режим “автопилота”: написать заранее электронные письма для отправки в назначенные интервалы.

Внесение ясности в то, как SRE вписывается в общую организацию

Последнее, чего хочет новый сотрудник, – это наступать на чужие ноги, особенно на ноги людей за пределами вашей команды SRE. Это может произойти, если вы не четко определите конкретную роль SRE в организации.

Что рекомендуется?

Явно донести до нового сотрудника, как функция SRE поддерживает более широкую инженерную функцию, включая:

1. Что разработчики несут ответственность за, например, “вы сами создаете, вы сами управляете” (“you build it, you run it”) или “мы управляем этим для вас” (“we run it for you”), или это гибридная модель.
2. Если другие функции обладают типичной способностью SRE, например, отдельная команда мониторинга, работающая независимо от команды SRE.
3. Сколько помощи нужно другим функциям, например, нужна ли помощь команде по безопасности при работе с сервисами во время инцидента? Нужна ли поддержка разработчикам во время инцидента?

Ясное и явное общение по этим вопросам поможет новому сотруднику лучше понять, как его работа вписывается в общую картину организации и какие ожидания у него есть по отношению к другим функциям и командам. Это поможет избежать недоразумений и конфликтов.