Добрый день, меня зовут Павел Поляков, я Principal Engineer в каршеринг компании SHARE NOW, в Гамбурге в 🇩🇪 Германии. А еще я автор телеграм канала Хороший разработчик знает, где рассказываю обо всем, что обычно знает хороший разработчик.
Сегодня хочу поговорить о DORA метриках. Что это за зверь?
Почему DevOps это хорошо
Многие компании успешно внедрили практики DevOps в свой инженеринг. SHARE NOW сделал также. Команды в компании ответственны не только за разработку программ, но и за то как эти программы попадут в продакшен, и как они будут обслуживаться. You build it — you own it.
Мне лично это нравится. Как и предполагается, согласно идеям DevOps, у нас нет случаев "у меня локально работает, а как вы там запускаете я не знаю". Потому что запускают те же люди, которые и разрабатывают. Глобально у нас есть отдельная Platform команда. Она разрабатывает и поддерживает компоненты, которые мы используем в своем локальном DevOps.
Остается вопрос — как узнать что мы на правильном пути? Здесь нам и помогут DORA метрики.
Что такое DORA метрики?
В течение 6 лет группа DevOps Research and Assessment (DORA) из Google анализировала состояние DevOps в разных организациях. Они пришли к выводу, что оценить качество DevOps можно по четырем ключевым метрикам:
Deployment Frequency
Lead Time for Changes
Change Failure Rate
Time to Restore Service
Давайте рассмотрим их поближе.
Deployment frequency
Частота деплоев. Идеально, когда у нас столько автоматических тестов, что мы уверены в своем сервисе. Мы готовы релизить каждый билд, который проходит автоматические тесты. Еще лучше когда они очень быстрые. Но бывают и другие ситуации, например, что в команде правило — релизим раз в спринт, перед релизом 2 дня мануального тестирования. Такая ситуация конечно выглядит хуже.
Метрика частота деплоев отвечает на вопрос — как часто ваша команда успешно релизит на продакшен? Чем чаще тем лучше.
Lead Time for Changes
Время внесения изменений. Представьте, что мы разрабатываем фичу. Мы взяли ее в спринт, потом кто-то начал работать над ней. После того как разработчик доволен - он открыл merge request, его проверили и наконец, наша фича приземлилась в master.
Сколько времени занимает путь от коммита в master до релиза на продакшен — это и есть время внесения изменений? Чем меньше тем лучше.
Change Failiure Rate
Коэффициент ошибок. Как бы мы не старались, но случается, что после нашего релиза возникают ошибки. Например, потому, что интегрейшен среда отличается от продакшен среды. Или мы не учли какой-то edge case. После таких случаев нужно проводить анализ и делать выводы, чтобы такое не повторялось в будущем.
Коэффициент ошибок — процент деплоев, которые привели к проблемам на продакшене. Чем меньше тем лучше.
Time to Restore Service
Время восстановления. Как бы мы не старались, шанс, что outage случиться очень высокий. Может подвести код, может подвести инфраструктура. Иногда может "помочь" природа, и наш дата центр затопит. Хорошо, когда мы знаем что делать в таких ситуациях, и как мы можем восстановить нашу систему.
Время восстановления — сколько времени нужно, чтобы восстановиться после ошибки на продакшене. Чем меньше — тем лучше.
Регулярно измеряя эти метрики вы можете получить оценку уровня DevOps и следить за ее прогрессом. Оценка может быть такой: Elite, High, Medium или Low.
А как измерять?
Открытым остался вопрос — а как их измерять?
В оригинальной статье ребята из Google предлагают достаточно абстрактное решение. ETL job, который достает из абстрактного источника всю информацию (кто деплоил, что деплоили, какие ошибки были, как восстанавливались), обрабатывает ее и записывает итоговые метрики. Звучит просто, но где взять такой полный источник? Кто отвечает за разработку и поддержку этой ETL job?
Есть и другие варианты.
Например, gitlab поддерживает мониторинг Deployment frequency и Lead time for changes. Требуется лишь небольшая конфигурация.
Time to restore service мы уже измеряли, потому что у нас есть внутренняя Status page, куда все сервисы сообщают о перебоях в работе и восстановлении.
А измерение Change failure rate зависит от того как команды репортят ошибки. Например, можно отслеживать деплои с помощью NewRelic и там же отслеживать перебои в работе сервиса. Теперь добавляем эвристический алгоритм. Например, если после деплоймента в течение 30 минут произошел сбой, то мы предполагаем, что он был вызван последним деплойментом. Конечно же, здесь возможны ложно позитивные срабатывания, но так можно начать отслеживать эту метрику.
Вывод
Хорошо, когда решения принимаются на основе фактов, еще лучше когда эти факты выражены цифрами и их можно сравнить друг с другом. DORA метрики являются отличным стартом в мир DevOps метрик. Они понятны, их внедрение, как правило, не занимает много времени. А после их внедрения вы можете мониторить качество DevOps в вашей команде или компании.
Всего хорошего, подписывайтесь на Хороший разработчик знает, там я рассказываю истории, рассказываю про хард скиллы и про софт скиллы. Коротко и по делу — так говорят те, кто подписался.
Ссылки для продолжающих:
