Час реакції на інциденти

Час реакції на інциденти показує, як швидко команда виявляє подію, підтверджує її та бере в роботу. Зазвичай виділяють три компоненти: MTTD (time to detect — від початку інциденту до виявлення), MTTA (time to acknowledge — від виявлення до підтвердження онколом) і TTE/Time to Engage (до залучення відповідної команди). Короткий час реакції знижує даунтайм і ймовірність порушення SLO/SLA.

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

Швидкість переходу від події до активної роботи над її усуненням у розрізі пріоритетів (P0–P3), сервісів, регіонів і каналів алертингу (PagerDuty/Slack/телефон). Окремо контролюйте автоалерти vs ручні репорти, робочі/поза робочими годинами та чергові зміни.

Розрахунок

  • MTTD = avg(DetectedAt − IncidentStart)
  • MTTA = avg(AcknowledgedAt − DetectedAt)
  • TTE (Engage) = avg(EngagedAt − DetectedAt) або до приєднання потрібної ролі (DB/SRE/App)
  • Response SLA, % = Інциденти з MTTA ≤ ціль / Релевантні інциденти × 100
  • Рахуйте окремо P50/P90 для стабільності й порівнюйте «on-hours» vs «off-hours»

Зафіксуйте початок/кінець відліку, часові пояси, бізнес- vs календарні години, правила об’єднання пов’язаних подій та ескалаційні рівні.

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

Моніторинг/APM, системи алертингу та онколлів (PagerDuty/Opsgenie), логи інцидентів ITSM (JSM/ServiceNow), канали комунікації (Slack/телефонія), статус-сторінка, календарі чергувань.

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

  • MTTD↑ — недостатній покрив SLI/синтетики, «німий» алертинг, пороги не налаштовані
  • MTTA↑ — проблеми з онкол-графіками, ескалаціями, мобільністю або шумом алертів
  • TTE↑ — нечіткі рунабуки, відсутність автотегів сервісів/залежностей, слабкий триаж
  • Високі значення ведуть до MTTR↑ і витрати error budget

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

  • Пріоритет (P0–P3); сервіс/ендпоінт; регіон/зона
  • On-hours vs off-hours; команда/роль (SRE/DB/Network/App)
  • Тип алерта (авто/ручний); джерело (APM/лог/синтетика)
  • Причина (RCA): код/конфіг/інфра/залежність/міграція

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

  • Тренд P50/P90 MTTD/MTTA/TTE із цільовими коридорами
  • Heatmap реакції по сервісах/годинах/чергах
  • Воронка «подія → виявлено → підтверджено → залучено → відновлено»
  • Зв’язок із MTTR/Uptime та breach rate

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

Орієнтири для P0: MTTD ≤ 1–2 хв, MTTA ≤ 5 хв, TTE ≤ 10 хв. Налаштуйте автоескалації й мультиканальні алерти, скоротіть шум (alert hygiene), впровадьте рунабуки й автодіагностику, підтримуйте актуальні онкол-розклади та тренінги.

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

  • Відсутність єдиного джерела часу подій; плутанина таймзон
  • Шумні/дубльовані алерти без агрегації та кореляції
  • Немає «after-hours» політики й компенсації — повільна реакція вночі
  • Невизначені ролі ескалації; ручний триаж без шаблонів

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

  • Які алерти найчастіше ігноруються/запізно підтверджуються і чому?
  • Де скоротити MTTA за рахунок автоескалацій/онкол-покриття?
  • Які рунабуки потрібні для швидшого TTE і стабільного триажу?
  • Чи узгоджені цілі реакції з SLO/SLA для P0/P1?