Ну во-первых, мне всегда интересно начинать с филологических изысканий, а значит понять, откуда вообще пошла такое сокращение. В данном случае суровые айтишники взяли первые буквы от DevOps Research and Assessment (DORA), которая подрузомевает под собой исследование и оценку в сфере DevOps'ов.
Как показало чтение по диаганали нескольких первых статей в гугле по этой теме, в недалекие 20е годы группа специалистов из гугла начала изучать состояние DevOps в разных организациях и пытаться понять, чем его можно ИЗМЕРИТЬ. И вроде как пришло к 4 ключевым показателям, а именно
- Deployment Frequency - частота деплоев
- Lead Time for Changes - время внесения изменений
- Change Failure Rate - коэффициент ошибок
- Time to Restore Service - время восстановления
На сколько я поняла все из того же чтения по диагонали это значения для АНАЛИЗА, а никак не для их достижения) Поэтому это ВСПОМОГАТЕЛЬНЫЙ инструмент, который мы можем посчитать и понять куда бежать, а никак не самоцель.
А теперь рассмотрим каждую из них для лучшего моего понимания.
Deployment Frequency, который при переводе в лоб звучит как частота деплоев, где под последним имеется ввиду развертывание и запуск веб-приложения или сайта в его рабочей среде, то есть на сервере или хостинге. Разработчик или его команда рано или поздно должна загрузить приложение, написанное на локальных компуктеров, в прод, из которого оно доступно конечным пользователям. Во всем этом процессе должны быть включены все тесты на многочисленных средах, проверка совместимости новых изменений с уже работающей инфраструктурой, и чем больше это мероприятие автоматизировано, тем легче получить какчественный продукт.
Так вот измерив частоту таких выкаток мы можем понять насколько просто разработчику донести какчественные изменения до пользователя и ответить на вопрос "как часто ваша команда успешно релизит на продакшен?" Чем чаще тем лучше.
Lead Time for Changes - время, необходимое на внесение изменений.
Вот мы нашли фичу, приоритизировали ее и взяли в спринт, потом кто-то начал работать над ней. После того как разработчик доволен - он открыл merge request, его проверили и наконец, наша фича приземлилась в master.
Сколько времени занимает путь от коммита в master до релиза на продакшен — это и есть время внесения изменений? Чем меньше тем лучше.
Change Failiure Rate - коэффициент ошибок.
Как бы мы не старались, но случается, что после нашего релиза возникают ошибки. Например, потому, что интегрейшен среда отличается от продакшен среды. Или мы не учли какой-то edge case. После таких случаев нужно проводить анализ и делать выводы, чтобы такое не повторялось в будущем.
Коэффициент ошибок — процент деплоев, которые привели к проблемам на продакшене. Чем меньше тем лучше.
Time to Restore Service
Время восстановления. Как бы мы не старались, шанс, что outage случиться очень высокий. Может подвести код, может подвести инфраструктура. Иногда может "помочь" природа, и наш дата центр затопит. Хорошо, когда мы знаем что делать в таких ситуациях, и как мы можем восстановить нашу систему.
Время восстановления — сколько времени нужно, чтобы восстановиться после ошибки на продакшене. Чем меньше — тем лучше.
Регулярно измеряя эти метрики вы можете получить оценку уровня DevOps и следить за ее прогрессом. Оценка может быть такой: Elite, High, Medium или Low.
А вдохновение взято отсюда: https://habr.com/ru/articles/583268/. И если сначала исключительно вдохновение, то к середине силы закончились и вдохновение превратилось в тупой копипаст. Да простит меня автор этой статьи.
з.ы. мне она кстати понравилась.