Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
SRE-METRICS Linux / DevOps

Расчет MTTR и метрик надежности: оценка времени устранения ошибок ПО

Обновлено: 15.09.2026  ·  Официальная база знаний

Проблема непредсказуемости времени простоя IT-систем

В высоконагруженных сервисах и распределенных системах простое знание количества инцидентов не дает понимания надежности инфраструктуры. Без расчета математического распределения времени устранения отказов невозможно сформировать реалистичные соглашения об уровне обслуживания (SLA / SLO / SLI).

МетрикаРасшифровкаНазначение
MTTRMean Time to Repair / ResolveСреднее время восстановления работоспособности сервиса после инцидента
MTBFMean Time Between FailuresСреднее время безотказной работы между последовательными сбоями
MTTFMean Time to FailureСреднее время до первого фатального отказа (для неремонтируемых систем)

Методология математического расчета и анализа MTTR

  1. Базовая формула среднего времени восстановления (MTTR):
    MTTR = (Общая сумма времени простоев: Downtime) / (Количество инцидентов: Incidents_Count)

    Пример: если за месяц веб-сервис падал 4 раза с временами простоя 10, 25, 15 и 30 минут, суммарный Downtime = 80 минут. MTTR = 80 / 4 = 20 минут.

  2. Выбор закона статистического распределения: время устранения программных сбоев на практике никогда не распределяется нормально (по Гауссу), так как имеет асимметричный длинный «хвост» сложных системных аварий. В теории надежности используют:
    • Логнормальное распределение (Log-normal distribution): классическая модель для описания времени человеческой реакции и отладки ПО при авариях.
    • Распределение Вейбулла: применяется для комплексных отказов инфраструктуры с учетом фактора старения и износа компонентов.
  3. Расчет доступности сервиса (Availability %):
    Availability = (MTBF / (MTBF + MTTR)) * 100%

    Для обеспечения надежности «четырех девяток» (99.99%) суммарный годовой простой не должен превышать 52.6 минут.

  4. Скрипт первичной оценки распределения инцидентов на Python:
    import numpy as npdata = np.array([12, 18, 15, 45, 22, 14, 85, 19])  # Время восстановления в минутахmean_mttr = np.mean(data)median_mttr = np.median(data)p95_mttr = np.percentile(data, 95)print(f"MTTR: {mean_mttr:.2f} мин | Медиана: {median_mttr:.2f} мин | P95: {p95_mttr:.2f} мин")

Рекомендация SRE: Никогда не используйте среднее арифметическое (Mean MTTR) как единственную целевую метрику. Один сложный инцидент длительностью 12 часов исказит среднее значение. Оценивайте Медиану (Median) и 95-й перцентиль (P95 MTTR) для контроля реального качества реагирования дежурных инженеров.

Практический опыт инженера: Практика ITSTM: При анализе логнормального распределения аварий стройте график плотности вероятности (PDF). Если на графике появляется второй пик, это прямое свидетельство системной проблемы: например, отсутствие четких регламентов эскалации на 2-ю и 3-ю линии поддержки.

Частые вопросы (FAQ)

В чем разница между Mean Time to Repair и Mean Time to Resolve?

Repair означает чисто техническое восстановление работоспособности системы (workaround / рестарт сервиса). Resolve включает полный цикл: устранение проблемы, верификацию данных и закрытие тикета в ITSM-системе.

Почему среднее время MTTR может вводить бизнес в заблуждение?

Среднее сглаживает катастрофические выбросы. Например, 9 сбоев по 2 минуты и 1 сбой на 60 минут дают MTTR = 7.8 минут, хотя клиенты пережили часовой критический простой.

Как автоматизация CI/CD снижает показатель MTTR?

Автоматизированные конвейеры развертывания позволяют выполнить моментальный откат релиза (Canary rollback) за секунды при обнаружении роста процента 5xx ошибок в APM.

Что такое 'Бюджет ошибок' (Error Budget)?

Это допустимый объем времени недоступности сервиса, рассчитанный на основе целевого SLO (например, 1 - 0.999 = 0.1% времени), который команда разработки может потратить на рискованные релизы.