mean time to repair, MTTR

Среднее время ремонта (MTTR) — это метрика, которая отражает, сколько времени в среднем требуется организации, чтобы устранить именно технический сбой и вернуть работоспособность конфигурационной единицы или ИТ-услуги на уровне «исправлено». На практике MTTR применяют для оценки ремонтопригодности и эффективности работы команд поддержки, а также для выявления узких мест в диагностике, доступности запчастей, взаимодействии с поставщиками и процедуре управления изменениями при ремонте. MTTR полезен в управлении доступностью, управлении мощностями и производительностью, управлении инцидентами и управлении проблемами, когда нужно понять, насколько быстро устраняются типовые отказы и как это влияет на доступность и надёжность. Важная граница термина: MTTR описывает время ремонта, а не «возвращение услуги пользователям любой ценой». Например, переключение на обходное решение или на резервный компонент может восстановить предоставление услуги, но не означает, что исходная КЕ отремонтирована. Также MTTR не предназначен для измерения времени ожидания согласований, бизнес-решений о приоритете или длительности выполнения сервисных запросов.

Частая ошибка — отождествлять MTTR со средним временем восстановления услуги. Среднее время ремонта заканчивается в момент, когда КЕ или ИТ-услуга отремонтирована, тогда как восстановление услуги может включать дополнительные шаги по возврату в рабочую среду, проверкам, валидации, развёртыванию, синхронизации данных и снятию временных мер. Обратная ситуация тоже встречается: услуга может быть быстро восстановлена за счёт обходного решения или переключения на резерв, но ремонт первопричины займёт существенно дольше; в таком случае MTTR будет большим, а показатели восстановления услуги — лучше. Ещё одна ловушка — неверная точка старта и финиша измерения: важно фиксировать момент сбоя и момент завершения ремонта, а не момент регистрации инцидента или закрытия записи в инструменте. MTTR также не следует использовать изолированно как «оценку качества» команды поддержки: на него влияют дизайн услуги, ремонтопригодность, доступность диагностических данных, договорённости с поставщиками, логистика и ограничения окна изменений. Наконец, сравнение MTTR между разными услугами без учёта их архитектуры и уровней услуги приводит к ошибочным управленческим выводам.