Кількість інцидентів / MTTR / MTBF

Інциденти, MTTR і MTBF — базовий набір SRE-метрик надійності. Кількість інцидентів відображає частоту збоїв, MTTR (Mean Time to Restore) — швидкість відновлення сервісу, а MTBF (Mean Time Between Failures) — середній час між збоями. Разом ці показники показують стабільність платформи, зрілість процесів інцидент-менеджменту та виконання SLO/SLA.

Що вимірює показник

Обсяг і якість інцидентів за пріоритетами (P0–P3), швидкість виявлення/реакції/відновлення та стійкість сервісу між інцидентами. Доречно окремо відслідковувати MTTD (time to detect) і MTTA (time to acknowledge), а також частку повторних інцидентів і порушень SLA.

Розрахунок

  • Incident Count = Кількість підтверджених інцидентів за період (окремо P0/P1/P2/P3)
  • Incident Rate = Інциденти / Період (або на 1 млн запитів, на 1 тис. користувачів)
  • MTTD = avg(Час виявлення − Час початку інциденту)
  • MTTA = avg(Час підтвердження онколом − Час виявлення)
  • MTTR = avg(Час відновлення − Час початку) — у межах визначення «відновлення сервісу»
  • MTBF = avg(Час початку наступного інциденту − Час відновлення попереднього)
    Альтернатива: (Часове вікно − Σ Downtime) / К-сть інцидентів
  • Breach Rate, % = Інциденти з порушенням SLA / Усі інциденти × 100

Зафіксуйте політику: що вважаємо «початком/кінцем» інциденту, календарні чи бізнес-години, облік часткових деградацій (вага за трафіком/користувачами), дедуплікація пов’язаних подій і критерії P0–P3.

Джерела даних

Моніторинг/APM/логінг (метрики/трейси/логи), синтетичні перевірки, PagerDuty/On-call, ITSM/інцидент-менеджмент (JSM/ServiceNow), CI/CD (деплої/rollback), статус-сторінка, журнали постмортемів.

Інтерпретація

  • Incident Count↑ — технічний борг, слабкі тести/перевірки, високий change failure rate
  • MTTR↑ — повільна діагностика/ескалація, брак рунабучних скриптів, неякісні алерти
  • MTBF↓ — крихкість архітектури, нестабільні залежності, ризикові релізи
  • Перевіряйте вплив на SLO/SLA, Error Budget і клієнтські метрики (CSAT, конверсія)

Корисні розрізи

  • Сервіс/ендпоінт; регіон/зона; середовище (prod/stage)
  • Тип інциденту: інфраструктура/деплой/конфіг/залежність/безпека
  • Первинна причина (RCA): код/зміни/ємність/мережа/БД/кеш/черги
  • Команда/онкол-роуль; час доби/зміна; реліз/канарний/rollback

Візуалізації на дашборді

  • Тренди Incident Count, MTTR, MTBF з цільовими коридорами
  • Таймлайн інцидентів із анотаціями деплоїв та SLA-порушеннями
  • Heatmap за пріоритетами/сервісами/регіонами
  • Pareto RCA та повторюваних проблем
  • Зв’язок з Uptime, Error Budget burn, латентністю та помилками 5xx

Як ставити цілі

Приклади: P0 ≤ 1/кв., MTTR P0 ≤ 30–60 хв, MTBF для ядра ≥ 30 днів. Впровадьте error budget policy, канарні/blue-green релізи, автодіагностику та рунабучні скрипти, SLO-алерти на burn rate (1/6 год), регулярні постмортеми з CAPA.

Типові помилки

  • Подвійний облік пов’язаних подій/алертів як окремих інцидентів
  • Невірне визначення старт/стоп; мікс календарних/бізнес-годин
  • Ігнор часткових деградацій та ваги за трафіком/користувачами
  • Фокус лише на середньому без P50/P90 і сегментів P0–P3
  • Відсутність зв’язку з деплоями, тестами та Capacity/SLI

Запитання для обговорення

  • Які 3 RCA дають 80% інцидентів і як їх прибрати?
  • Де скоротити MTTR: детекція, ескалації, рунабучні скрипти?
  • Який ефект канарних релізів/фіче-флагів на Incident Rate?
  • Чи відповідають алерти SLO/SLI та чи налаштований burn rate?