Я узнал о... #3: DevOps фреймворк DORA
DORA - это DevOps фреймворк из 4-х метрик, которые помогают оценить эффективность и качество релизного процесса.
Фреймворк придумала компания с таким же названием (DevOps Research and Assessment). Скорее всего, чтобы проще продавать свой консалтинг. В 2018-м году эту компанию купил Google Cloud и сделал своей... командой.
Вообще, про эти метрики в том или ином виде я знал. Но не знал, как они систематизированы и по-умному называются.
Собственно, сами метрики:
1) Частота деплоя (deployment frequency)
Показывает, насколько адекватный уровень автоматизированного тестирования. И умеет ли команда релизить точечно, а не сразу всё.
Критерии:
отлично: несколько раз в день;
хорошо: раз в 1-7 дней;
средне: несколько раз в месяц;
плохо: реже, чем раз в месяц.
2) Время от коммита до деплоя (Lead Time)
Показывает, как долго мы тормозим с бюрократией после момента, когда код уже готов. Низкое значение - неэффективное тестирование, процессы ревью или разработки.
Критерии:
отлично: меньше дня;
хорошо: от 1-го до 7 дней;
средне: 7-30 дней (*по оценке компании DORA, я бы сказал, что это плохой результат);
плохо: дольше месяца.
3) % сбоев после релиза (Change Failure Rate)
Показывает, как часто мы ломаем прод релизами. Что говорит о том, насколько хорошо мы прорабатываем требования, умеем тестировать и в целом о предсказуемости того, что мы выкладываем.
Критерии (% релизов, которые привели к сбою):
отлично: <5%;
хорошо: <10%;
средне: <15%;
плохо: >15%.
4) Скорость восстановления (Mean Time To Recovery)
Показывает, как быстро мы поднимаем прод, если он сломался (упал, пришёл DDOS, выключились сервера). А ещё, умеем ли мы определять и измерять сбои. Упавшим продомом считается или факт того, что существенная часть системы недоступна, или коммит с hotfix'ом.
Критерии (как быстро поднимаем прод):
отлично: меньше часа;
хорошо: меньше дня;
средне: меньше дня;
плохо: больше дня.
Когда это нужно?
Для себя я выделил три критерия, когда эти метрики имеет смысл считать:
Когда есть конкретный продукт в активной стадии развития с постоянной командой хотя бы из 3-5 разработчиков. Т.е. это не что-то, что получает несколько фич в месяц или находится в стадии активного саппорта.
Когда компания большая, в которой появилось много команд с продуктами и нужно выстроить хоть какое-то понимание в среднем по компании. Вот тут, кстати, важно не начать погоню за метриками, т.к. все внутренние проекты живут в своём темпе. Нельзя выставить одинаковые метрики всем поголовно в качестве KPI.
Когда СТО\CIO нужны хоть какие-то метрики для отчётности. Чтобы объяснить инвесторам или нетехнической части C level'a, что в компании или команде хороший DevOps процесс (или, наоборот, плохой).
DORA метрики измеряются через GitLab или почти любую другую систему CI \ CD. GitLab умеет считать всё это из коробки. За исключением, наверное, падения прода (что тоже можно добавить вручную или вебхуками \ alert manager'ами).
---
Мой Telegram канал про разработку.
Мой open source проект для бекапа PostgreSQL - GitHub.