Мысли про измерение MTTR

Mean Time To Restore/Recover (здесь: среднее время восстановления) - cреднее время, необходимое для возвращения сервиса в рабочее состояние для пользователя после начала инцидента. Это бизнес-метрика, напрямую влияющая на доступность (Availability) и расход Error Budget. Фокус смещен с поиска и исправления корневой причины (Root Cause) на максимально быстрое устранение воздействия на пользователя.

Если проще: например, мы такси.

  • Инцидент - это когда спустило колесо.

  • MTTR — это время от момента, когда пассажир начал жаловаться "я жду, а машина не едет", до момента, когда мы присылаем ему другую исправную машину, и он поехал по своим делам.

Что важнее: понять, почему спустило колесо (гвоздь, бушная убитая резина, яма на дороге и тп)? - да, важно, и мы разберёмся, но после того, как пассажир уедет на заказанной услуге. Самле важное - не искать виноватых, а отвезти пассажира.

MTTR — это метрика скорости, как быстро мы "оживляем" сервис для пользователя.

  1. MTTR - это про пользователя. Пользователю всё равно, в чём была причина сбоя, сколько и каких PRB и инцидентов в компании, ему важно, чтобы сервис работал хорошо и сейчас.

  2. MTTR - это бизнесметрика. Каждая минута простоя — это потенциальные потерянные деньги, репутационный ущерб и недовольные клиенты и тп

  3. "Быстро восстановить и потом разобраться" != халтура. Это значит иметь готовые планы на случай аварии, инструменты для быстрого отката и культуру, где ценят скорость реакции. Расследование причины происходит после того, как сервис восстановлен.

  4. Error Budget - наш друг и нужно к нему идти всеми силами и внедрять его правильное понимание.

  5. Низкий MTTR позволяет нам быть более смелыми в инновациях и экспериментах, потому что мы знаем, что в случае ошибки мы быстро вернём всё обратно и никто не придет с претензиями.

Как можно счистать (не догма, а вариант):

MTTR можно измерять через сбор данных о времени обнаружения, диагностики и восстановления для каждого инцидента, с обязательным учетом контекста критичности продукта и его функции. Можно брать из инцидентов/постмортемов.

MTTR - комплексный показатель (именно на них нужно декомпозировать дашборды), состоит из следующих фаз:

  1. MTTD (Mean Time To Detect): время от начала сбоя до срабатывания алерта.

  2. MTTA (Mean Time To Acknowledge): время от алерта до принятия инцидента инженером.

  3. MTTF (Mean Time To Fix): время на диагностику и применение фикса.

  4. MTTV (Mean Time To Verify): время на подтверждение восстановления работы.

На существующем этапе зрелости начинать можно с "упрощенного" MTTR (время начала → время восстановления).

Что нужно сделать, чтобы начать считать:

    1. Фиксация времени: ввести строгий формат описания инцидента в JiraSM и добавить обязательные поля:

      • [ALERT] - время срабатывания алерта в мониторинге

      • [ACK] - время принятия инцидента дежурным инженером.

      • [FIX_DEPLOYED] - время применения фикса (неважно какого, что исправляет).

      • [RESOLVED] - время подтверждения восстановления по метрикам (SLO-метрики вернулись в норму).

    2. Один источник: настроить интеграцию между алертами и JiraSM для автоматического создания инцидентов с меткой [ALERT] - но тут можно подумать, начало инца - алерт.

Чуть попозже, после этого:

    1. Автоматизация сбора метрик: например, скрипт, который парсит тикеты/чаты и вычисляет MTTD, MTTA, MTTF, MTTV, агрегируя данные в систему мониторинга (или в Grafana).

    2. Анализ и выводы: проводить периодический разбор не самого MTTR, а его составляющих. Например, высокий MTTD указывает на плохие алерты, а высокий MTTF — на сложность диагностики или отсутствие ранбуков и т.п.

Триггер (Что запускает отсчет инцидента?)

  • Источник: Алертменеджер/мониторинг.

  • Метод: например, вебхук от алертинга, который создает запись об инциденте в JiraSM с меткой времени start_time.

Нужно настроить алерты так, чтобы они срабатывали на нарушение SLO, а не на любую мелкую проблему. Например, алерт при error_rate > 0.1% в течение 2 минут.

Фиксация времени восстановления (Самое сложное)

Это нельзя доверить человеку. Нужно делать автоматически. Есть два подхода:

А) на основе метрик

  1. Prometheus продолжает оценивать то же SLO, что вызвало инцидент.

  2. Как только условие ложно в течение N минут (например, error_rate < 0.1% в течение 5 минут), система отправляет вебхук, который закрывает инцидент и выставляет end_time.

Б) на основе действий ИМ или дежурных

  • Источник: JiraSM: человек меняет статус инцидента на "Resolved" или "Closed", система фиксирует это время как end_time.

  • Проблема: человек может забыть или задержать изменение статуса или указать его ничем не подтверждая.

Можно комбинировать, например: система автоматически предлагает закрыть инцидент ("Возможно, проблема решена, нажмите для подтверждения"), когда видит восстановление метрик и человек подтверждает.

Хранение и агрегация

  • БД (PostgreSQL, Clickhouse)

  • или

  • JiraSM API - например, раз в день джоба запрашивает через API все закрытые инциденты за период, вычисляет для каждого Time to Restore и агрегирует до MTTR.

Визуализация

  • Grafana: дашборд с графиком MTTR за разные периоды, с разбивкой по сервисам, командам, типам инцидентов и тп

Засады:

  • Оптимизация MTTR через автоматические перезапуски и откаты может привести к увеличению MTTD (Mean Time To Diagnose) корневой проблемы, так как симптомы маскируются, сложно найти RC.
  • Использование MTTR как просто "числа" бесполезно. Его необходимо декомпозировать на MTTD, MTTF и т.д., как указано выше, для точечной оптимизации процессов.
  • Стабильно низкий/красивый MTTR при растущем (или не уменьшающимся) количестве инцидентов одной и той же природы – признак того, что мы боремся с симптомами, а не с причинами, используя быстрые тактики восстановления или костыли.

Кто и что делает (в идеальном мире):

1. SRE + DevOps - это ИСПОЛНИТЕЛИ технины

  • Разработка и внедрение инструментов для автоматического отслеживания MTTR и их контроль/сопровождение

  • Создание runbooks / инструментов авторекавери для быстрого восстановления

  • Реализация механизмов быстрого отката (rollback), канареечных развертываний

  • Технический мониторинг и алертинг

2. Product manager - это ЗАКАЗЧИК и БИЗНЕС-КУРАТОР

  • Определение целевых значений MTTR и Error Budget вместе (учитывая все реалии) с инженерами

  • Приоритизация улучшений надежности наравне с фичами

  • Коммуникация с бизнесом о компромиссах между скоростью и стабильностью

  • Принятие решений когда тратить Error Budget

3. Incident manager - это ВЛАДЕЛЕЦ ПРОЦЕССА

  • Организация процесса, правка процесса IM2.0 с учетом MTTR, доведение изменений и т.п.

Как это выглядит на практике:

Процесс внедрения:

  1. SRE предлагает инструменты и метрики

  2. Продуктолог определяет бизнес-требования к доступности, документирует их, доводит до продуктовых команд необходимость выполнения

  3. SRE и продуктолог ВМЕСТЕ согласовывают целевые значения MTTR и Error Budget

  4. Инцидент менеджер формализует процесс работы с инцидентами

  5. Все команды обучаются и начинают работать по новым правилам

Периодически, например, ежеквартально/раз в полгода:

Продуктолог и SRE:

  • анализируют использование Error Budget, делают выводы, вносят запорсы на изменение и т.п.

  • приоритизируют работы по улучшению надежности

  • корректируют целевые показатели MTTR

MTTR — это НЕ "техническая метрика", а БИЗНЕС-метрика, за которую технические команды несут исполнительскую ответственность, а продуктолог — стратегическую.

Продуктолог отвечает на вопрос "Какой MTTR нам нужен для бизнеса?", а инженеры — "Как нам этого достичь технически?".

Без активного участия продуктолога MTTR останется просто "числом в дашборде", не влияющей на реальные приоритеты разработки и вообще ни на что.

Когда мы научимся и будем замерять Error budget,MTTR можно будет объяснить через бизнес-логику: у продукта есть "Бюджет доверия" на какой-то период времени, лимит допустимых "косяков".

Допустим, мы обещали пользователям 99.9% доступности. За месяц это, примерно 40 минут простоя. Эти 40 минут — наш Error budget и его можно и нужно тратить на неизбежные сбои.

Как его можно потратить?

  • Один долгий инцидент (8 часов) - спустили весь бюджет за один раз. Миллиард жалоб от пользователей и сопутствующий ущерб.

  • Десять коротких инцидентов (по 4 минуты каждый, итого 40 минут) — бюджет потрачен, но пользователи почти не заметили неудобств и большинство пользователей спокойны, не пишут жалобы и продолжают считать продукт надежным.

MTTR это НЕ про предотвращение сбоев (они вс егда были, есть и всегда будут), а про управление их последствиям, снижая MTTR, мы "дробим" один большой и болезненный простой на множество мелких и почти незаметных. Мы учимся быстро "тушить пожары", а не месяцами искать их причину.