MTBF и MTTR
MTBF (Mean Time Between Failures) - наработка на отказ: сколько времени сервис работает от одного сбоя до следующего.
MTTR (Mean Time To Recovery) - время восстановления: сколько уходит на то, чтобы вернуть сервис в работоспособное состояние.
Это два базовых показателя надёжности. Вместе они показывают, какие сервисы отказывают чаще других и где компания теряет больше всего времени на ремонт.
Задача
Посчитать для каждого сервиса частоту отказов и скорость восстановления, а также определить, каким метрикам действительно можно доверять при планировании и в отчётах.
Две главные ошибки при расчётах
- Описывать время восстановления одним средним значением. Несколько затяжных аварий сильно завышают среднее число, и оно перестаёт отражать длительность обычного инцидента.
- Считать частоту отказов суммарно по всем сервисам. Показатель «сбой каждые 8 часов» по всей компании не даёт понимания, какой конкретно сервис работает ненадёжно.
Как это считается
Метод из семейства описательной аналитики.
- Время восстановления (MTTR). Для каждого инцидента фиксируется время от возникновения до полного восстановления. Из этих данных рассчитываются три ключевых показателя:
Медиана - точка, до которой закрывается 50% всех инцидентов.
Среднее значение - сумма длительности всех сбоев, делённая на их количество.
P95 (95-й перцентиль) - граница, дольше которой длятся только 5% самых тяжёлых сбоев.
Дополнительно рассчитывается: какую долю от общего времени простоя формируют эти 5% тяжёлых аварий. Если половину и больше - процесс восстановления фактически делится на два разных режима: стандартный и аварийный. - Наработка на отказ (MTBF).
Для конкретного сервиса: период наблюдения, делённый на количество его отказов.
Для всей компании: тот же подход показывает общую частоту инцидентов в инфраструктуре.
Требования к данным:
Точное время начала и окончания каждого инцидента (или итоговая длительность в минутах/часах).
Привязка сбоя к конкретному сервису (для расчёта MTBF).
Примечание: незакрытые на момент расчёта инциденты в метрику MTTR не включаются.
Пример результата
На примере банковского процессинга.
Основной объём мелких сбоев сосредоточен слева от медианы. Справа от линии P95 находится редкая группа тяжёлых аварий: численно их мало, но именно они формируют основную часть совокупного простоя.
Практическая польза
- Выбор метрик для отчётов. В отчётах и KPI следует указывать медиану и P95, а не среднее арифметическое.
Почему: среднее значение (3 ч 19 мин) создаёт ложную картину. Из-за него бизнес считает, что любой рядовой сбой ликвидируют за три часа (хотя половина решается за 14 минут), но при этом недооценивает тяжесть реальных аварий (9+ часов). - Разделение регламентов и эскалация. Поскольку сбои делятся на быстрые (массовые) и затяжные (системные), порядок работы с ними должен быть разным. Временные пороги эскалации эффективнее привязывать к реальному распределению (медиане и P95):
До 30 минут: устранение дежурной сменой по стандартным инструкциям (runbooks).
После 30-60 минут (превышение стандартного времени): подключение L3-инженеров и назначение координатора инцидента (Incident Commander).
После 2 часов: эскалация на руководителя отдела и сбор оперативного штаба.
После 4-8 часов (приближение к P95): включение кризисного протокола (привлечение архитектора, вендоров, перевод на резервные схемы). - Фокус внимания и ресурсов. Основной ресурс разработки и эксплуатации нужно направить на 5% самых тяжёлых аварий. Сокращение их количества или длительности даст максимальный эффект, так как именно они формируют 77% совокупного простоя.
- Приоритизация сервисов (по MTBF). Сравнение наработки на отказ определяет рейтинг проблемных систем и задаёт порядок работы:
Оплата услуг: сбой раз в 3,7 дня (самый проблемный сервис)
Процессинговый центр: сбой раз в 4,1 дня
Переводы: сбой раз в 5,2 дня
Этот список подскажет, с какого сервиса начинать инженерные улучшения и послужит отправной точкой отсчёта при проверке результатов через квартал.