MTTR, MTBF и MTTA: метрики надёжности простыми словами

Когда сервис падает, команда обычно задаёт два вопроса: «как быстро мы это заметили?» и «как быстро восстановили?». Для бизнеса важен и третий: «как часто такое вообще происходит?». На эти вопросы отвечают метрики MTTA, MTTR и MTBF — базовый язык надёжности, понятный разработчикам, DevOps и владельцам продукта.

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

MTTR, MTBF и MTTA особенно полезны рядом с SLI, SLO и SLA. SLO задаёт желаемый уровень надёжности, а MTTR и соседние метрики показывают, почему он выдерживается или нет: проблемы узнают слишком поздно, восстановление затягивается или сбои повторяются слишком часто.

Что такое MTTR, MTBF и MTTA

Начнём с коротких определений.

MTTA — Mean Time To Acknowledge, среднее время до подтверждения инцидента. Показывает, сколько проходит от обнаружения проблемы системой мониторинга до момента, когда ответственный человек или команда взяли инцидент в работу.

MTTR — чаще всего Mean Time To Recovery или Mean Time To Repair, среднее время восстановления после сбоя. Показывает, сколько сервис был в нерабочем или деградированном состоянии до возврата к нормальной работе.

MTBF — Mean Time Between Failures, среднее время между сбоями. Показывает, как долго система в среднем работает без инцидентов.

Если совсем просто:

• MTTA отвечает на вопрос: «как быстро мы проснулись и начали реагировать?»;
• MTTR отвечает на вопрос: «как быстро мы вернули сервис в рабочее состояние?»;
• MTBF отвечает на вопрос: «как редко у нас вообще случаются сбои?».

Для сайта или API это выглядит так. Сервис работает нормально. Начинается сбой: пользователи получают 500, 502, 503, таймауты или не могут открыть страницу. Мониторинг доступности замечает проблему и отправляет уведомление. Дежурный подтверждает инцидент, начинает диагностику, откатывает релиз или чинит инфраструктуру. Сервис снова отвечает корректно. Позже команда разбирает причину и принимает меры, чтобы сбой не повторился.

В этой истории MTTA — от алерта до принятия в работу, MTTR — от начала сбоя до восстановления, MTBF — время нормальной работы между предыдущим и текущим сбоем.

Почему у MTTR несколько значений

У MTTR есть классическая путаница: аббревиатура одна, а расшифровок несколько. В инженерной и SRE-практике встречаются как минимум четыре варианта.

1) Mean Time To Repair — среднее время ремонта. Обычно это время, за которое команда устраняет техническую неисправность: перезапускает сервис, чинит конфигурацию, возвращает базу из бэкапа, заменяет узел.

2) Mean Time To Recovery — среднее время восстановления. Ближе к пользовательскому опыту: сервис снова выполняет свою функцию, даже если корневая причина ещё не устранена полностью. Например, команда переключила трафик на резервный контур, а сломанный кластер починит позже.

3) Mean Time To Resolve — среднее время полного решения. Сюда входят диагностика, восстановление, проверка, закрытие тикета, коммуникация с пользователями и действия после инцидента. Такая MTTR почти всегда больше, чем recovery.

4) Mean Time To Respond — среднее время реакции. Иногда так называют интервал от обнаружения до начала активных действий, но для этого лучше использовать отдельную метрику MTTA или MTTD, чтобы не путать реакцию и восстановление.

Для операционной надёжности сайта обычно полезнее считать Mean Time To Recovery: сколько пользователь реально страдал от недоступности или деградации. Для внутренних процессов можно отдельно считать Mean Time To Resolve: сколько команда тратит на полное закрытие инцидента.

Главное — зафиксировать определение в документации. Например:

MTTR в нашей команде — это время от начала пользовательского влияния до восстановления SLI до нормального уровня.

Такое определение хорошо связывается с SLO. Если вы ещё не разделяете эти понятия, полезно сначала разобраться в статье «Что такое SLI, SLO и SLA».

Как считать MTTR, MTTA и MTBF

Формулы простые, но качество результата зависит от того, какие события вы записываете.

MTTA = сумма времени до подтверждения / количество инцидентов

Если за месяц было 5 инцидентов, а подтверждали их через 2, 4, 6, 8 и 10 минут, MTTA будет:

(2 + 4 + 6 + 8 + 10) / 5 = 6 минут

MTTR = сумма времени восстановления / количество инцидентов

Если сбои длились 12, 18 и 30 минут, MTTR будет:

(12 + 18 + 30) / 3 = 20 минут

MTBF = общее время нормальной работы / количество сбоев

Если система за период работала без сбоев 700 часов, а значимых отказов было 4, MTBF будет:

700 / 4 = 175 часов

На практике стоит договориться о нескольких временных точках:

• started_at — когда началось влияние на пользователей;
• detected_at — когда проблему обнаружила система мониторинга или пользователь;
• acknowledged_at — когда ответственный принял инцидент;
• mitigated_at — когда влияние на пользователей прекратилось или стало приемлемым;
• resolved_at — когда причина устранена и инцидент закрыт.

Тогда можно считать несколько полезных интервалов:

Важно не смешивать плановые работы и аварии. Если вы заранее выключили сайт на обслуживание, предупредили пользователей и уложились в окно, это не тот же тип события, что внезапный отказ базы данных. Плановые работы можно учитывать отдельно, особенно если они влияют на SLA или пользовательский опыт.

Не все инциденты одинаковы: один сбой мог затронуть только внутреннюю админку, другой — оплату, третий — главную страницу сайта. Для MTTR полезно иметь фильтры по сервису, критичности и уровню влияния.

Как эти метрики связаны с инцидентом

Удобнее всего понимать MTTA, MTTR и MTBF через временную линию инцидента.

Сначала система работает нормально — это период uptime. Затем появляется неисправность: например, новый релиз вызывает рост ошибок 500, балансировщик перестаёт видеть backend, истёк сертификат, DNS-запись указывает не туда или база перестаёт принимать соединения.

Дальше возможны разные сценарии.

1) Проблему сразу видит мониторинг — лучший вариант. Проверка сайта, API или health endpoint возвращает ошибку, алерт уходит в Telegram, почту, Slack или другой канал. Если мониторинг доступности настроен извне, он показывает не только состояние сервера, но и то, как сервис виден пользователю снаружи. Например, Statuser проверяет сайт с заданным интервалом и присылает уведомление о сбое.

2) Проблему первым замечает пользователь — тревожный сигнал. Значит, MTTD и часто MTTA зависят не от инженерной системы, а от жалоб. Такие инциденты обычно дороже: к техническому восстановлению добавляются репутационные потери и ручная коммуникация.

3) Алерт пришёл, но его долго никто не взял — проблема с MTTA. Причины бывают разными: неясный владелец сервиса, шумные алерты, ночные уведомления без эскалации, отсутствие on-call графика. Про организацию дежурств и ответственности полезно читать вместе с темой инцидент-менеджмента.

4) Инцидент взяли быстро, но долго чинили — проблема с MTTR. Команда не понимает причину, нет runbook, сложно откатить релиз, нет доступа к логам, восстановление базы не проверялось, зависимости между сервисами запутаны.

5) Починили быстро, но сбои повторяются — проблема с MTBF. Команда хорошо тушит пожары, но не устраняет системную причину. Тут нужны постмортемы, работа с техническим долгом, тестирование отказов и изменение архитектуры.

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

MTTR рядом с SLO и error budget

SLI, SLO и SLA отвечают на вопрос «какой уровень сервиса мы обещаем или хотим поддерживать». MTTR, MTTA и MTBF отвечают на вопрос «какие процессы и свойства системы помогают или мешают этот уровень удерживать».

Например, у вас есть SLO: 99.9% успешных запросов за 30 дней. Ошибки и недоступность съедают error budget. Если инциденты редкие и короткие, бюджет расходуется медленно. Если сбои частые или долгие, бюджет сгорает быстро.

Связь можно описать так:

1) Высокий MTTA увеличивает длительность инцидента — проблема уже влияет на пользователей, но команда ещё не реагирует. Даже если само исправление занимает 5 минут, позднее обнаружение и подтверждение могут превратить небольшой сбой в заметное нарушение SLO.

2) Высокий MTTR быстро съедает error budget — сервис может падать нечасто, но каждый раз надолго. Для публичного сайта, интернет-магазина или API партнёров это особенно болезненно.

3) Низкий MTBF означает частые инциденты — даже короткие сбои становятся постоянным фоном. Команда привыкает к алертам, пользователи — к нестабильности, а технический долг растёт.

4) Метрики помогают выбирать инвестиции — плохой MTTA указывает на алерты и дежурства, плохой MTTR — на runbook, автоматизацию отката и резервирование, плохой MTBF — на причины повторных отказов.

Здесь полезны burn rate alerts: они показывают, как быстро расходуется error budget, и помогают реагировать не на каждый шум, а на реально опасные темпы деградации. Подробнее об этом — в статье «Что такое burn rate alerts и почему их рекомендует Google SRE».

Как измерять метрики без самообмана

MTTR и MTBF легко испортить красивой отчётностью. Чтобы метрики помогали, а не украшали презентации, нужны единые правила.

1) Считайте от пользовательского влияния — если API перестал отвечать в 10:00, мониторинг заметил в 10:03, а команда увидела в 10:07, начало инцидента лучше фиксировать как 10:00. Иначе вы будете улучшать не надёжность, а способ подсчёта.

2) Разделяйте обнаружение, подтверждение и восстановление — одна общая цифра «мы починили за 25 минут» ничего не объясняет: возможно, 20 минут ушло на поиск ответственного, а само исправление заняло 5 минут.

3) Не усредняйте всё подряд — среднее значение скрывает хвосты. Два инцидента по 5 минут и один на 2 часа дадут умеренный средний MTTR, но бизнес запомнит именно двухчасовой простой. Полезно смотреть не только average, но и медиану, p90, p95, а для малых команд — просто список самых долгих инцидентов.

4) Классифицируйте инциденты — отдельно считайте критичные сбои, частичную деградацию, проблемы отдельных регионов, внутренние сервисы, ошибки провайдера. Одна общая MTTR по всей компании редко помогает принять решение.

5) Фиксируйте данные во время инцидента — после восстановления люди забывают точное время событий. Лучше вести timeline сразу: в чате инцидента, тикете, status page или отдельном шаблоне.

6) Исключайте дубли — если один и тот же сбой породил 30 алертов от разных проверок, это один инцидент, а не 30 отказов. Иначе MTBF станет бессмысленным.

Системы мониторинга помогают собрать часть временных точек автоматически: когда проверка стала падать, когда восстановилась, какие коды ответа были получены. Для внешней доступности это особенно полезно: сервер может считать себя здоровым, но пользователь снаружи видит таймаут, проблему DNS или ошибку TLS. Базовые принципы такого подхода разобраны в статье «Что такое uptime monitoring и как он работает».

Как уменьшить MTTA

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

1) Назначьте владельцев сервисов — у каждого критичного компонента должен быть понятный ответственный: команда, канал связи, правило эскалации. Алерт «что-то сломалось где-то» почти всегда теряет время.

2) Уберите шумные алерты — если половина уведомлений не требует действий, люди начинают их игнорировать. Это прямой путь к росту MTTA. Алерт должен означать: «нужно принять решение или выполнить действие». Подробно про это — в статье «Как строить алерты, которые не раздражают».

3) Используйте эскалации — если первый дежурный не подтвердил инцидент за заданное время, уведомление должно уйти следующему человеку или каналу. Иначе ночной сбой может ждать утра.

4) Проверяйте не только сервер, но и пользовательский путь — процесс может быть жив, CPU в норме, а сайт недоступен из-за DNS, SSL, прокси или маршрутизации. Внешние проверки доступности хорошо дополняют внутренние метрики.

5) Настройте разные уровни срочности — ошибка в админке и падение оплаты не должны будить одинаково. Критичные пользовательские сценарии требуют более короткого интервала проверки и более жёсткой эскалации.

6) Репетируйте процесс — даже простая учебная тревога показывает, кто получает уведомления, у кого нет доступа, где устарела инструкция и какой канал связи не работает.

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

Как уменьшить MTTR и увеличить MTBF

MTTR и MTBF требуют более глубокой работы. Первая метрика про скорость восстановления, вторая — про устойчивость системы и качество инженерных решений.

1) Пишите runbook для типовых аварий — что делать при росте 5xx, переполнении диска, отказе базы, истечении сертификата, ошибке деплоя, проблемах DNS. Runbook не должен быть длинным документом: достаточно списка проверок, команд, ссылок на дашборды и критериев эскалации.

2) Делайте быстрый откат релизов — если новый деплой сломал сервис, команда должна уметь быстро вернуться к предыдущей версии. Чем сложнее откат, тем выше MTTR. Здесь помогают feature flags, blue-green deployment и простые процедуры релиза.

3) Автоматизируйте восстановление — ручные действия медленнее и чаще ошибаются. Перезапуск зависшего процесса, переключение на резервный инстанс, очистка очереди, масштабирование воркеров или восстановление конфигурации должны быть максимально предсказуемыми.

4) Улучшайте наблюдаемость — без логов, метрик и трассировок команда тратит время на догадки. Для API полезно смотреть RED-метрики: rate, errors, duration. Для инфраструктуры — CPU, память, диск, сеть, saturation. Хорошая отправная точка — «Четыре золотых сигнала в мониторинге».

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

6) Устраняйте корневые причины — если каждый понедельник растёт нагрузка и падает база, не стоит гордиться быстрым рестартом. Нужно понять причину: индексы, connection pool, lock contention, нехватка ресурсов, плохой запрос, лимиты провайдера.

7) Пишите постмортемы без поиска виноватых — цель не наказать человека, а изменить систему так, чтобы ошибка не повторялась или не приводила к такому ущербу. Хороший шаблон есть в статье «Как писать постмортемы».

8) Проектируйте деградацию вместо полного отказа — если внешний сервис оплаты недоступен, можно временно поставить заказ в очередь. Если рекомендации не работают, основная покупка всё равно должна быть доступна. Если один регион недоступен, часть пользователей можно перевести на другой.

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

FAQ

Что важнее: MTTR или MTBF?

Зависит от системы. Для критичных сервисов важны обе метрики: сбои должны случаться редко, а восстановление — быть быстрым. Низкий MTTR не компенсирует ежедневные падения, а высокий MTBF не спасает, если редкий сбой длится несколько часов.

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

Для пользовательской надёжности лучше считать от начала влияния на пользователей. Отдельно можно считать MTTD и MTTA, чтобы видеть, сколько времени ушло на обнаружение и подтверждение.

Что делать, если инцидентов мало и средние значения нестабильны?

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

Плановые работы входят в MTTR?

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

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