MTTD, MTTA и MTTR: как измерить скорость обнаружения и устранения сбоев

MTTD показывает, сколько времени проходит до обнаружения сбоя, MTTA — до принятия уведомления ответственным, а MTTR при выбранном здесь определении — до восстановления пользовательской функции. Эти показатели полезны, когда нужно понять, почему посетители долго не могли оформить заказ: команда поздно заметила проблему, сообщение осталось без владельца или восстановление потребовало нескольких неудачных попыток.

Для расчёта недостаточно времени создания и закрытия заявки. Заявку могут открыть после звонка клиента, а закрыть через день после возвращения сайта в рабочее состояние. Ниже — практическая схема измерения для владельца сайта, разработчика и руководителя поддержки. Она разделяет реальные события, объясняет неопределённость и помогает обсуждать улучшения по конкретным задержкам.

Что означают MTTD, MTTA и MTTR

Слово mean в этих сокращениях означает среднее арифметическое. Сначала вычисляют длительность для каждого подходящего инцидента, затем складывают значения и делят на количество наблюдений. Важно, чтобы события измерялись одинаково: сравнение разных начальных и конечных точек создаёт видимость точности.

В обзоре показателей управления инцидентами Atlassian отдельно отмечена неоднозначность MTTR: сокращение используют для repair, recovery, respond и resolve. Поэтому запись «наш MTTR — 40 минут» без определения границ мало что объясняет. В этой статье принято mean time to recovery: среднее время от начала влияния инцидента до восстановления затронутой пользовательской функции. Это выбранное правило отчёта, а не единственная допустимая расшифровка.

Показатель	Границы в нашем журнале	Практический вопрос
MTTD	Начало влияния → первое обнаружение	Как долго проблема оставалась незамеченной?
MTTA	Первое уведомление ответственным → принятие ответственности	Как долго сообщение ждало владельца?
MTTR	Начало влияния → восстановление пользовательской функции	Сколько времени продолжалось нарушение выбранного сценария?

MTTR уже включает обнаружение и реакцию, поэтому складывать MTTD + MTTA + MTTR нельзя: часть времени посчитается повторно. Если нужна длительность работ после принятия ответственности, заведите отдельное поле «от принятия до восстановления». Не называйте его тем же MTTR без пояснения.

Какие временные точки нужно фиксировать

До первого отчёта договоритесь о событиях и доказательствах для каждого из них. Для сайта особенно важно описать пользовательский сценарий: открытие каталога, отправка заявки, вход в кабинет или оформление заказа. Главная страница может отвечать нормально, когда выбранный сценарий уже нарушен.

1. Начало влияния. Момент, когда функция перестала соответствовать заранее заданному условию. Если точный момент неизвестен, укажите оценку и интервал неопределённости.
2. Обнаружение. Первое зафиксированное распознавание проблемы системой или человеком. Это может быть событие мониторинга, запись оператора поддержки или подтверждённое обращение посетителя.
3. Первое уведомление. Момент, когда сигнал отправлен ответственным по принятому каналу. Для этой схемы считаем именно отправку; подтверждённую доставку, если она известна, сохраняем дополнительно.
4. Принятие ответственности. Конкретный человек подтвердил, что ведёт инцидент. Просмотр сообщения или автоматическая отметка бота не равнозначны этому событию.
5. Восстановление. Затронутая функция снова проходит согласованную проверку. Успешный перезапуск процесса сам по себе ещё не доказывает работоспособность заказа или заявки.
6. Окончательное исправление. Устранена причина или выполнено согласованное постоянное решение. После временного обхода эта точка может наступить значительно позже восстановления.
7. Закрытие записи. Завершено оформление карточки. Это административная точка; она не заменяет восстановление или окончательное исправление.

Все значения сохраняйте с датой, часовым поясом и достаточной точностью. Если один журнал использует местное время, а другой UTC, сначала приведите их к общей шкале. Для ручной записи минут обычно достаточно, но нельзя выдавать округлённую отметку за точность до секунды.

Заранее задайте условие стабильности восстановления. Например, для учебного процесса команда может потребовать несколько последовательных успешных проверок и контрольный заказ. При таком правиле временем восстановления считается подтверждение условия целиком. Само правило следует сохранять между периодами, иначе изменение проверки исказит сравнение.

Пример расчёта на четырёх инцидентах сайта

Рассмотрим полностью вымышленные данные. Это четыре отдельных сбоя в разные дни, все отметки внутри каждой строки относятся к одной дате и одному часовому поясу. Начало влияния считается установленным точно; все четыре функции восстановлены. Числа не описывают SiteGuard, конкретный хостинг или реального клиента.

Инцидент	Начало	Обнаружен	Уведомление	Принят	Восстановлен
А: ошибка каталога	09:00	09:04	09:05	09:08	09:40
Б: сбой отправки заявки	11:00	11:08	11:10	11:16	12:10
В: ошибка входа	13:00	13:02	13:02	13:03	13:25
Г: сбой оформления заказа	14:00	14:26	14:28	14:42	17:45

Для инцидента А обнаружение заняло четыре минуты, принятие после уведомления — три минуты, а полное время до восстановления — сорок минут. Между обнаружением и отправкой сообщения прошла ещё одна минута. Она относится к общей длительности, но не входит в MTTA по принятой здесь границе.

Инцидент	До обнаружения, мин	От уведомления до принятия, мин	От начала до восстановления, мин
А	4	3	40
Б	8	6	70
В	2	1	25
Г	26	14	225
Сумма	40	24	360

• MTTD = (4 + 8 + 2 + 26) / 4 = 10 минут.
• MTTA = (3 + 6 + 1 + 14) / 4 = 6 минут.
• MTTR = (40 + 70 + 25 + 225) / 4 = 90 минут.

Предположим, окончательные исправления выпущены в 10:30, 15:00, 14:15 и 20:00 соответственно. Эти отметки нужны для сопровождения оставшихся работ, но не меняют полученный MTTR восстановления. Если включить их в расчёт, получится другой показатель с другим смыслом.

Для проверки арифметики разложим общий интервал на непересекающиеся части. Средняя задержка между обнаружением и уведомлением равна (1 + 2 + 0 + 2) / 4 = 1,25 минуты. От принятия до восстановления прошло 32, 54, 22 и 183 минуты; среднее — 72,75 минуты. Получаем 10 + 1,25 + 6 + 72,75 = 90 минут. Такое равенство работает здесь, поскольку все части рассчитаны по одним четырём инцидентам.

Почему рядом со средним нужен длинный хвост

Значение MTTR 90 минут не означает, что обычный сбой длился полтора часа. Отсортированные длительности равны 25, 40, 70 и 225 минутам. Медиана составляет (40 + 70) / 2 = 55 минут, а максимальный случай — 225 минут. Один долгий инцидент заметно увеличил среднее.

Для небольшого сайта полезнее показать все четыре значения, чем строить внушительный график с десятками показателей. В нашем примере три инцидента восстановлены за 70 минут или быстрее, один потребовал 225 минут. Именно последний заслуживает отдельного разбора: задержался доступ к подрядчику, отсутствовал проверенный откат или сначала исследовали неверную гипотезу?

При достаточно большом числе наблюдений можно добавить p90 или p95, указав способ вычисления. На четырёх строках процентиль сильно зависит от метода интерполяции и не даёт устойчивой оценки редких тяжёлых событий. Максимум тоже зависит от размера выборки, поэтому рядом всегда нужны количество случаев и период.

Сравнивайте похожие группы: одинаковую критичность, затронутую функцию и режим поддержки. Небольшая ошибка оформления текста и остановка оплаты требуют разных действий. Смена состава инцидентов способна улучшить среднее без какого-либо ускорения команды. По той же причине не превращайте общий MTTR в персональный рейтинг разработчиков.

Как учитывать параллельные работы и передачу ответственности

Восстановление измеряется по часам, а не суммой трудозатрат. Допустим, с 14:42 до 15:12 разработчик проверяет последний релиз, администратор изучает базу, а руководитель поддержки уточняет затронутые заказы. Прошло тридцать минут календарного времени, хотя три человека могли потратить суммарно девяносто человеко-минут.

Эти задачи следует записать отдельно: исполнитель, начало, окончание, результат и влияние на следующее решение. Не складывайте параллельные интервалы в MTTR. Полезный вопрос — какая последовательность действий действительно задерживала восстановление. Если откат ждал подтверждения целостности данных, именно ожидание и проверка формировали существенную часть пути.

В главе Google SRE об управлении инцидентами выделены координация, распределение ролей и рабочая запись действий. Для небольшой команды это можно реализовать без сложной иерархии: один человек ведёт инцидент, остальные получают конкретные проверки и сообщают результаты в общий журнал.

При передаче инцидента следующему специалисту исходное принятие ответственности не обнуляйте. Зафиксируйте дополнительную передачу и подтверждение нового владельца. Иначе эскалация искусственно изменит MTTA. Когда одна первичная неисправность породила десятки уведомлений, объедините связанные сигналы под одним инцидентом; количество писем не должно превращаться в количество самостоятельных сбоев.

Если ответственный сам обнаружил проблему и сразу начал работу, не придумывайте несуществующее уведомление ради заполнения таблицы. Укажите канал «самостоятельное обнаружение» и сохраните реальные события. В отчёте MTTA для такого случая можно оставить неприменимым либо заранее определить отдельное правило учёта. Главное — не смешивать его без пояснения со случаями, когда сообщение отправлялось дежурному. Для оценки реакции на рассылку сравнивайте именно инциденты с рассылкой, а самостоятельные обнаружения показывайте отдельной группой.

Что делать, если точное начало сбоя неизвестно

Внешняя проверка наблюдает сайт в определённые моменты. Если проверка одной и той же функции прошла успешно в 10:00, а в 10:05 зафиксировала отказ, для модели одного непрерывного эпизода его начало находится между этими наблюдениями. При этом отказ не обязательно начался ровно в 10:05. Если успехи и отказы чередуются, двух результатов недостаточно для установления начала инцидента: фиксируем наблюдённый интервал и ищем другие свидетельства. В журнале самой проверки первое обнаружение отказа в этом примере записано в 10:05.

В указанной модели одного непрерывного эпизода задержка обнаружения лежит примерно между нулём и пятью минутами. Можно сохранить нижнюю и верхнюю границы, а в основном отчёте отдельно показать долю инцидентов с оценочным началом. Подстановка середины интервала допустима как явно оговорённая расчётная оценка, но не как установленный факт.

Уточнить начало могут серверные журналы, неуспешные операции, история релизов и обращения поддержки. Каждое уточнение оставляйте с источником и причиной изменения. Сообщение «у меня не работает уже час» полезно для расследования, но само по себе не даёт точной отметки до минуты.

Если данных о начале вообще нет, не записывайте ноль в MTTD. Оставьте значение неизвестным и отдельно посчитайте наблюдения с достаточными данными. Аналогично нельзя приравнять обнаружение к моменту первого письма, если известно, что система увидела отказ раньше. Отсутствующее поле обозначает пробел в измерении, а не мгновенную работу процесса.

Незакрытые инциденты и границы отчётного периода

У незавершённого восстановления пока нет конечной длительности. Если сбой начался в 22:00, а отчёт строится в 23:00, известно только, что он продолжается не меньше шестидесяти минут. Подставлять шестьдесят как окончательное значение MTTR нельзя. Исключать этот случай без пояснения тоже опасно: самые долгие проблемы могут исчезнуть из отчёта.

Для простого рабочего журнала выберите понятное правило: отчёт содержит все инциденты, начавшиеся в периоде. Для восстановленных рассчитывается среднее, рядом показываются количество продолжающихся и их текущая длительность. Такой MTTR явно подписывайте как среднее по восстановленным случаям выбранной группы. Пока остаются открытые случаи, результат предварительный.

Инцидент, начавшийся до отчётного месяца, покажите отдельной переходящей строкой. Для его полной длительности используйте настоящее начало, даже если оно находится за границей окна. Не обрезайте этот интервал первым числом месяца ради удобства: получится показатель времени внутри окна, а не время восстановления инцидента.

Завершённость зависит от конкретной метрики. Для продолжающегося сбоя MTTD и MTTA уже могут быть известны, хотя MTTR ещё нет. Поэтому рядом с каждым средним указывайте собственное число наблюдений. Разложение средних на этапы, показанное выше, нельзя проверять простым сложением, когда состав групп различается.

Отдельно учитывайте ситуации, когда за период не оказалось ни одного завершённого наблюдения. Значение MTTR тогда не равно нулю: среднее пока не определено. Покажите прочерк и пояснение, сколько инцидентов продолжается. Если завершённых сбоев нет потому, что нарушений вообще не обнаружено, это тоже другой случай. Нельзя объединять отсутствие событий, недостаток данных и мгновенное восстановление в один зелёный показатель. В ежемесячном отчёте достаточно короткой строки о составе выборки, чтобы руководитель правильно понял ограничение.

Минимальный журнал: какие поля и кто заполняет

Начните с одной строки на инцидент и короткого журнала значимых действий. Не требуйте от специалиста во время аварии писать подробное эссе. Сначала важны затронутая функция, владелец, текущая гипотеза и доказуемые отметки времени; подробности можно дополнить после восстановления.

Данные	Кто фиксирует	Чем подтверждает
Идентификатор, функция, критичность	Первый принявший инцидент	Описание наблюдаемого нарушения
Начало и его точность	Ответственный после сверки	Журнал ошибок или интервал наблюдений
Обнаружение и уведомление	Система либо сотрудник поддержки	Событие проверки, обращение, запись отправки
Принятие ответственности	Назначенный исполнитель	Явное подтверждение в карточке или чате
Восстановление функции	Исполнитель и проверяющий	Результат согласованного сценария
Постоянное исправление	Владелец последующей задачи	Ссылка на изменение и его проверку

В руководстве PagerDuty для участников инцидента запись значимых действий и выводов выделена в отдельную роль. В маленькой команде её может совмещать координатор. Существенно, чтобы решения не оставались только в голосовом звонке и переписке двух специалистов.

Добавьте статус, часовой пояс, ссылку на подтверждающие материалы и отметку «точное» или «оценочное». Храните исходные даты, а длительности вычисляйте формулами. Пустая ячейка не должна автоматически превращаться в ноль. Отрицательный интервал — повод проверить порядок событий и часы, а не исправить знак ради красивого среднего.

Как использовать измерения для ускорения восстановления

Обсуждайте отдельно каждый обнаруженный разрыв. Высокий MTTD требует проверить, наблюдается ли нужная функция и по какому признаку она считается сломанной. Низкое время обнаружения при большой задержке уведомления указывает на другой участок: правила подтверждения, маршрутизацию или очередь отправки. Увеличение частоты проверок здесь может не помочь.

При высоком MTTA сначала выясните, кто должен принять инцидент и что произойдёт при отсутствии ответа. В описании дежурства Google SRE подтверждение вызова связано с последующей работой над проблемой и при необходимости эскалацией. Для собственного проекта определите ответственного и резервного сотрудника, затем проверьте этот маршрут учебным сигналом.

Когда основная задержка возникает после принятия, изучайте конкретные препятствия: не было доступа, не подготовили откат, потеряли конфигурацию, долго ждали согласования. Выберите одну проверяемую меру. Например, подготовьте и испытайте процедуру возврата предыдущей версии, затем посмотрите, исчезло ли ожидание на следующем подходящем инциденте.

Не обещайте сокращение MTTR только за счёт подключения нового инструмента. Измерения дают исходные события; восстановление зависит также от архитектуры, полномочий, готовности команды и характера неисправности. Полезный результат разбора — конкретное изменение процесса, его владелец и способ проверить эффект.

Нужно ли вычитать ночь и ожидание подрядчика?

Для выбранного здесь MTTR восстановления часы идут непрерывно, пока пользовательская функция остаётся нарушенной. Ночь, ожидание доступа или ответ внешней команды не исчезают из пережитой посетителем длительности. Одновременно можно измерять активное время специалиста и время ожидания: эти данные объясняют причину задержки и помогают планировать поддержку. Если внутренний договор предусматривает отдельный расчёт только в рабочие часы, показывайте его самостоятельной строкой с календарём и правилами исключений. Подмена общей длительности рабочим временем даст более привлекательное число, но ответит на другой вопрос.

Как проверить, что изменение действительно помогло?

Сохраните прежние правила отбора инцидентов и начальные точки измерения. Рядом с датой изменения отметьте, что именно внедрили: резервного ответственного, новый сигнал или готовую процедуру отката. Затем сравните тот этап, на который должна была повлиять мера. Уменьшение MTTA после изменения маршрута уведомлений согласуется с ожидаемым эффектом, но одного удачного случая мало для уверенного вывода. Проверьте несколько сопоставимых наблюдений и их контекст. Если одновременно изменились нагрузка, состав команды или критичность сбоев, перечислите это в комментарии к сравнению.

Частые вопросы о расчёте

Какой MTTR считать хорошим для сайта?

Единого значения для всех проектов нет. Сначала определите критичную функцию, последствия её отказа, условия поддержки и выбранные границы метрики. Затем установите собственную цель и сравнивайте сопоставимые инциденты. Среднее обязательно дополняйте числом случаев и длительностью наиболее тяжёлых сбоев.

Можно ли считать MTTA от обнаружения?

Такое внутреннее измерение возможно, если оно прямо подписано. В этой статье MTTA начинается с первого уведомления, поэтому задержка его отправки учитывается отдельно. При сравнении с чужим отчётом сначала сверяйте определения: одинаковое сокращение не гарантирует одинаковые границы.

Нужен ли отдельный инцидент на каждую ошибку запроса?

Нет. Несколько запросов могут отражать одно продолжающееся нарушение. Зафиксируйте правило объединения и критерий восстановления. Если после подтверждённого восстановления возник новый отказ, решите по принятому правилу, является ли он повторным инцидентом, и сохраняйте связь с предыдущим событием.

С чего начать измерение на своём сайте

Выберите один важный сценарий, договоритесь о временных точках и заведите журнал. На первых инцидентах проверяйте полноту данных и причины задержек; сложная панель показателей понадобится только тогда, когда появится достаточно сопоставимых наблюдений.

Подключите SiteGuard для внешнего HTTP-контроля доступности важных страниц. Временные точки реакции и восстановления фиксируйте в журнале инцидентов.