Команда сравнивает среднее время восстановления сервисов, учитывая только инциденты, зафиксированные мониторингом. Какое искажение возникает в такой метрике?
Такая метрика может занижать реальное время восстановления и давать необъективное сравнение сервисов. В расчёт попадают только инциденты, которые мониторинг обнаружил, поэтому незамеченные сбои, поздно обнаруженные проблемы и обращения пользователей исключаются из выборки.
Это искажает MTTR — среднее время восстановления или устранения инцидента. Для корректного анализа нужно явно определить границы измерения и учитывать все релевантные инциденты, а не только автоматически обнаруженные.
Метрики восстановления появились как ответ на ограниченность показателей, описывающих только процесс выпуска и тестирования. Число пройденных тестов или частота релизов не показывают, насколько быстро команда возвращает систему в рабочее состояние после сбоя.
В эксплуатационных процессах стали отдельно измерять время обнаружения, время реакции и время восстановления. Это позволяет оценивать не только наличие дефектов, но и способность организации быстро ограничивать последствия отказов.
Предположим, у двух сервисов одинаковое число реальных сбоев. У первого развитый мониторинг: он фиксирует проблемы почти сразу. У второго мониторинг слабый, поэтому часть инцидентов обнаруживается пользователями через несколько часов.
Если считать MTTR только по событиям мониторинга, второй сервис может выглядеть лучше: поздно обнаруженные инциденты вообще не попадут в расчёт. При этом пользователь фактически дольше испытывал последствия сбоя.
Возникают три риска:
Восстановление обычно измеряют метрикой MTTR — Mean Time to Recovery, Restore или Resolve. Расшифровка зависит от принятого в организации словаря: где-то измеряют возврат сервиса к приемлемому состоянию, а где-то — полное устранение первопричины. Поэтому само название недостаточно: в регламенте нужно зафиксировать начало и конец интервала.
Типичная схема выглядит так:
Если использовать только автоматические срабатывания, метрика измеряет не «время восстановления сервиса», а более узкую величину: время восстановления обнаруженных мониторингом инцидентов. Это допустимо как отдельная аналитика, но её нельзя без оговорок трактовать как полную MTTR.
Практический способ снизить искажение — объединять источники: события мониторинга, обращения пользователей, записи службы поддержки, ручные сообщения команды и журналы инцидентов. При объединении нужно устранять дубли, иначе один сбой будет посчитан несколько раз.
Важно разделять MTTD — время обнаружения — и MTTR. Долгое общее ожидание может быть вызвано не медленным устранением, а поздним обнаружением. Если смешать эти интервалы, команда не поймёт, что улучшать: наблюдаемость, процесс оповещения или техническое восстановление.
Среднее значение также не всегда достаточно. Один редкий очень долгий инцидент может скрыться за несколькими быстрыми восстановлением. Поэтому полезно дополнительно смотреть медиану и высокие перцентили, например время, быстрее которого завершается 95% восстановлений.
Сравнивать MTTR между сервисами можно только при сопоставимых условиях: одинаковых правилах включения инцидентов, одинаковом определении восстановления, близкой критичности систем и аналогичном качестве наблюдаемости. Иначе корректнее анализировать динамику одного сервиса во времени, чем строить рейтинг команд.
Метрика не объясняет первопричину и сама по себе не доказывает высокое качество процесса. Уменьшить MTTR можно, например, быстрым откатом, ручным отключением функции или временным снижением функциональности. Это может быть правильным решением при инциденте, но не означает, что первопричина устранена. Поэтому MTTR следует рассматривать вместе с долей повторных инцидентов, временем обнаружения и результатами анализа причин.
У интернет-магазина два платёжных сервиса. Команда сравнила их MTTR только по инцидентам, созданным системой мониторинга: у первого получилось 18 минут, у второго — 11 минут. На основании этого второй сервис сочли более зрелым.
Рассматривались следующие варианты:
Выбрали третий вариант. Для каждого инцидента стали фиксировать время фактического начала нарушения, время обнаружения, время восстановления пользовательского сценария и время окончательного устранения причины. После этого выяснилось, что у второго сервиса автоматический мониторинг действительно быстрее восстанавливал обнаруженные сбои, но часть ошибок платежей не имела технического сигнала и выявлялась пользователями спустя часы.
В результате команда не стала просто «улучшать MTTR». Она добавила контроль успешности пользовательских платежных операций и отдельно сократила время обнаружения. Это дало более точную картину качества и помогло устранить риск, который первоначальная метрика скрывала.
Нет, если цель — измерить скорость восстановления сервиса. Закрытие задачи может произойти значительно позже: после анализа, подготовки постоянного исправления, документирования и проверки предотвращающих мер. Для операционной устойчивости окончанием обычно выбирают момент возврата сервиса к согласованному уровню, а устранение первопричины измеряют отдельным показателем или этапом.
Смешивание этих событий делает метрику зависимой от административной скорости закрытия задач. Команда может формально улучшить показатель, закрывая инциденты раньше, хотя пользовательский сервис восстановился не быстрее.
MTTR показывает скорость восстановления после обнаруженного инцидента, но не учитывает автоматически частоту сбоев, их масштаб и время до обнаружения. Сервис может быстро восстанавливаться, однако часто падать или долго оставаться неисправным до появления сигнала.
Для оценки риска нужно смотреть совокупность показателей: частоту и серьёзность инцидентов, MTTD, MTTR, долю затронутых пользователей и длительность недоступности. Быстрое восстановление полезно, но не заменяет предотвращение повторяющихся отказов и улучшение наблюдаемости.
Нужно заранее определить правила корреляции и жизненный цикл инцидента. Повторные проявления одной причины в пределах согласованного окна не должны автоматически считаться независимыми инцидентами, если сервис между ними фактически не вернулся к устойчивому состоянию.
Также полезно контролировать не только среднюю MTTR, но и суммарное время воздействия, количество затронутых пользователей, долю повторных инцидентов и перцентили. Эти показатели затрудняют улучшение отчётности без реального уменьшения ущерба. Окончательное правило должно быть единым для всех сервисов и не меняться после получения неудобного результата.