Четыре метрики и что они измеряют
Все четыре считаются от событий жизненного цикла сбоя — обнаружение, реакция, восстановление, следующий сбой:
- MTTA (Mean Time To Acknowledge) — среднее время от регистрации инцидента до того, как кто-то взял его в работу. Метрика реакции.
- MTTR (Mean Time To Recover/Repair) — среднее время от возникновения сбоя до восстановления услуги. Главная метрика «как быстро чиним».
- MTBF (Mean Time Between Failures) — среднее время между сбоями восстанавливаемой системы. Метрика «как редко ломается».
- MTTF (Mean Time To Failure) — среднее время до отказа невосстанавливаемого компонента (например, диска). Применяется к железу, которое меняют, а не чинят.
MTTA и MTTR — про скорость реакции и ремонта (что под контролем поддержки), MTBF и MTTF — про надёжность самой системы (что под контролем инженеров и вендоров).
Как считать: формулы и пример
Формулы простые — это средние за период:
MTTR = суммарное время восстановления / число сбоев
MTBF = суммарное время штатной работы / число сбоев
MTTA = суммарное время до взятия в работу / число инцидентовПример. За месяц (730 часов) услуга падала 4 раза, суммарный простой — 8 часов:
MTTR = 8ч / 4 = 2 часа на восстановление
Время штатной работы = 730 − 8 = 722ч
MTBF = 722ч / 4 ≈ 180 часов между сбоямиВажно: MTBF считается от времени штатной работы, а не от всего периода. На больших MTBF разница невелика, но методологически это время «между», а не «всего».
Чем отличаются от FRT и времени решения
Метрики службы поддержки (FRT и resolution time) и метрики надёжности измеряют разное, хотя кажутся похожими:
- FRT — первый ответ пользователю. MTTA — взятие в работу. Это не одно и то же: можно ответить «принято в работу» (FRT), но реально начать чинить позже (MTTA).
- Resolution time в helpdesk считается per-тикет и часто включает ожидание пользователя. MTTR — про восстановление услуги и не должен включать время, пока ждём ответа заявителя.
- FRT/resolution — взгляд со стороны заявителя. MTTR/MTBF — взгляд со стороны сервиса.
Поэтому MTTR и resolution time по одному инциденту почти всегда различаются — это нормально, они отвечают на разные вопросы. Смешивать их в одном отчёте без оговорок — частая причина споров «почему цифры не сходятся».
Доступность из MTBF/MTTR и типичные ошибки
Главная польза связки MTBF + MTTR — расчёт доступности (availability) услуги:
Доступность = MTBF / (MTBF + MTTR) × 100%
Для примера выше:
= 180 / (180 + 2) × 100% ≈ 98.9%Отсюда видно: повысить доступность можно двумя путями — реже ломаться (растить MTBF) или быстрее чинить (снижать MTTR). Для зрелых сервисов снижать MTTR обычно дешевле и быстрее, чем гнаться за безотказностью. Этот расчёт напрямую кормит Service Level Management и availability management.
Частые ошибки: считать MTTR по среднему без учёта выбросов (один 20-часовой инцидент искажает картину — смотрите ещё и медиану); включать в MTTR время ожидания пользователя; считать MTBF от полного периода вместо времени штатной работы; сравнивать MTTR разных по критичности услуг как единую цифру.
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Частые вопросы
В чём разница между MTTA и MTTR?
MTTA (Mean Time To Acknowledge) — среднее время до взятия инцидента в работу (реакция). MTTR (Mean Time To Recover) — среднее время до восстановления услуги (ремонт). MTTA — часть пути, MTTR — весь путь до восстановления.
Чем MTTR отличается от resolution time в helpdesk?
MTTR измеряет восстановление услуги со стороны сервиса и не должен включать ожидание ответа пользователя. Resolution time считается per-тикет со стороны заявителя и часто включает это ожидание. Поэтому цифры обычно расходятся — это нормально.
Как из MTBF и MTTR получить доступность?
Доступность = MTBF / (MTBF + MTTR) × 100%. Например, при MTBF 180ч и MTTR 2ч доступность ≈ 98.9%. Повысить её можно реже ломаясь (рост MTBF) или быстрее чинясь (снижение MTTR).
MTBF считается от всего периода или от времени работы?
От суммарного времени штатной работы (период минус простои), делённого на число сбоев. На больших MTBF разница мала, но методологически это время «между сбоями», а не «всего периода».
Почему нельзя смотреть только на средний MTTR?
Среднее искажается выбросами: один 20-часовой инцидент задирает MTTR, скрывая, что обычно чините за час. Смотрите среднее вместе с медианой и по сегментам критичности услуг.