Метрики інцидентів

1) Навіщо вимірювати інциденти

Метрики інцидентів перетворюють хаотичні події в керований процес: допомагають знижувати час реакції і відновлення, зменшувати повторюваність причин, доводити виконання SLO/договорів і знаходити точки автоматизації. Хороший набір метрик покриває весь цикл: виявлення → класифікація → ескалація → мітигуючі дії → відновлення → розбір → CAPA.

2) Базові визначення та формули

Подієві інтервали

MTTD (Mean Time To Detect) = середній час від T0 (фактичний початок впливу) до першого сигналу/виявлення.
MTTA (Mean Time To Acknowledge) = середній час від першого сигналу до ack on-call.
MTTM (Mean Time To Mitigate) = середній час до зниження впливу нижче порога SLO (часто = час до обхідного рішення/деградації UX).
MTTR (Mean Time To Recover) = середній час до повного відновлення цільових SLI.
MTBF (Mean Time Between Failures) = середній інтервал між релевантними інцидентами.

Операційні часи

Time to Declare - від T0 до офіційного оголошення рівня SEV/інциденту.
Time to Comms - від оголошення до першого публічного/внутрішнього апдейта по SLA.
Time in State - тривалість на кожному етапі (triage/diag/fix/verify).

Частотні та часткові

Incident Count - кількість інцидентів за період.
Incident Rate - на 1k/10k/100k успішних транзакцій або запитів (нормалізація).
SEV Mix - розподіл по тяжкості (SEV-0... SEV-3).
SLA Breach Count/Rate - число/частка порушень зовнішніх SLA.
Change Failure Rate -% інцидентів, викликаних змінами (релізи/конфіги/міграції).

Якість сигналів і процесів

% Actionable Pages - частка пейджів, що призвели до осмислених дій по плейбуку.
False Positive Rate (Pages) - частка помилкових спрацьовувань.
Detection Coverage - частка інцидентів, виявлених автоматикою (а не клієнтами/підтримкою).
Reopen Rate - частка повторних інцидентів з тією ж кореневою причиною ≤90 днів.
CAPA Completion -% коригувальних/попереджувальних дій, закритих вчасно.
Comms SLA Adherence - частка апдейтів, опублікованих за необхідною частотою.

3) Карта метрик за стадіями інциденту

4) Нормалізація та сегментація

Нормалізуйте лічильники на обсяг (трафік, успішні операції, активні користувачі).
Сегментуйте за: регіону/тенанту, провайдеру (PSP/KYC/CDN), типу зміни (код/конфіг/інфра), часу доби (day/night), джерелу детекції (synthetic/RUM/infra/support).
Для бізнесу важливі бізнес-SLI (успіх платежів, реєстрацій, поповнень) - метрики інцидентів прив'язуйте до їх деградації.

5) Порогові цілі (орієнтири, адаптуйте під домен)

MTTD: ≤ 5 хв для Tier-0, ≤ 10-15 хв для Tier-1.
MTTA: ≤ 5 хв (24/7), ≤ 10 хв (follow-the-sun).
MTTM: ≤ 15 хв (Tier-0), ≤ 30-60 хв (Tier-1).
MTTR: ≤ 60 хв (Tier-0), ≤ 4 год (Tier-1).
Detection Coverage: ≥ 85% автоматикою.
% Actionable Pages: ≥ 80–90%; FP Pages: ≤ 5%.
Reopen Rate (90д): ≤ 5–10%.
CAPA Completion (вчасно): ≥ 85%.

6) Атрибуція причин і вплив змін

Кожному інциденту присвоюйте primary cause (Code/Config/Infra/Provider/Security/Data/Capacity) і trigger (release ID, конфіг-зміна, міграція, зовнішній фактор).
Ведіть Change-linked MTTR/Count - наскільки релізи і конфіги вносять вклад (база для політик гейтів/канарок).
Окремо враховуйте Provider-caused інциденти (PSP/KYC/CDN/Cloud), щоб управляти маршрутами і контрактами.

7) Комунікації та клієнтський імпакт

Time to First Public Update і Update Cadence (наприклад, кожні 15/30 хв).
Complaint Rate - тікети/скарги на 1 інцидент, тренд.
Status Accuracy - частка публічних апдейтів без ретракцій.
Post-Incident NPS (за ключовими клієнтами) - короткий імпульс після SEV-1/0.

8) Метрики якості алертингу навколо інцидентів

Page Storm Index - число пейджів/година на одного on-call під час інциденту (медіана/р95).
Dedup Efficiency - частка пригнічених дублікатів.
Quorum Confirmation Rate - частка інцидентів, де спрацював кворум зондів (≥2 незалежних джерела).
Shadow→Canary→Prod конверсія нових правил (Alert-as-Code).

9) Дашборди (мінімальний набір)

1. Executive (28 днів): кількість інцидентів, SEV-розподіл, MTTR/MTTM, SLA breaches, Reopen, CAPA.
2. SRE Operations: MTTD/MTTA по годинах/змінах, Page Storm, Actionable%, Detection Coverage, Time to Declare/Comms.
3. Change Impact: частка інцидентів, пов'язаних з релізами/конфігами, MTTR для change-інцидентів, вікна обслуговування vs інциденти.
4. Providers: інциденти по провайдерам, час деградації, перемикання маршрутів, договірні SLA.
5. Heatmap по сервісах/регіонах: інциденти і MTTR на 1k транзакцій.

Поєднуйте графіки SLI/SLO з анотаціями релізів і відмітками SEV.

10) Схема даних інциденту (рекомендована)

incident_id, sev, state, service, region, tenant, provider?,
t0_actual, t_detected, t_ack, t_declared, t_mitigated, t_recovered,
source_detect (synthetic    rum    infra    support),
root_cause (code    config    infra    provider    security    data    capacity    other),
trigger_id (release_id    change_id    external_id),
slo_impact (availability    latency    success), burn_minutes,
sla_breach (bool), public_updates[], owners (IC/TL/Comms/Scribe),
postmortem_id, capa_ids[], reopened_within_90d (bool)

11) Приклади розрахунків (SQL-ідея)

sql
SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_recovered - t0_actual))/60) AS mttr_min
FROM incidents
WHERE t0_actual >= '2025-10-01' AND t_recovered IS NOT NULL AND sev IN ('SEV-0','SEV-1','SEV-2');

sql
SELECT 100.0 SUM(CASE WHEN source_detect <> 'support' THEN 1 ELSE 0 END) / COUNT() AS detection_coverage_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

sql
SELECT 100.0 COUNT() FILTER (WHERE trigger_id IS NOT NULL) / NULLIF(COUNT(),0) AS change_failure_rate_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

12) Зв'язок з SLO і бюджетами помилок

Фіксуйте SLO burn minutes на інцидент - це головна «вага» події.
Пріоритизуйте CAPA за сумарним burn і SEV-вагою, а не за кількістю інцидентів.
Зшивайте burn з фінансовим імпактом (приклад: $/хвилину простою або $/втрачену транзакцію).

13) Метрики зрілості процесу (program-level)

Postmortem Lead Time: медіана від закриття інциденту до публікації звіту.
Evidence Completeness: частка звітів з таймлайном, графіками SLI, логами, посиланнями на PR/коммс.
Alert Hygiene Score: складений індекс по actionable/FP/дедуп/кворум.
Handover Defects: частка змін, де втрачено контекст активних інцидентів.
Training Coverage: % on-call, що пройшли симуляції за квартал.

14) Чек-лист впровадження метрик

• Визначені єдині часові мітки (UTC) і контракт подій інциденту.
• Прийнятий словник SEV, причини (root cause taxonomy) і джерела детекції.
• Метрики нормалізуються на об'єм (трафік/успішні операції).
• Готові 3 дашборда: Executive, Operations, Change Impact.
• Alert-as-Code: кожна Page-правила має плейбук і власника.
• Пост-мортем SLA (наприклад, чернетка ≤72ch, фінал ≤5 раб. днів).
• CAPA трікаються з KPI ефекту і датами D + 14/D + 30.
• Щотижневий Incident Review: тренди, топ-причини, статус CAPA.

15) Анти-патерни

Рахувати тільки MTTR без MTTD/MTTA/MTTM → втрата керованості ранніх фаз.
Не нормалізувати за обсягом → великі сервіси «здаються» гіршими.
Безсистемний SEV → непорівнянність інцидентів.
Відсутність Evidence → суперечки замість поліпшень.
Фокус на кількості інцидентів замість burn/SLO-впливу.
Ігнорувати Reopen і CAPA → вічні рецидиви.
«Метрики в Excel» без автоматичного вивантаження з телеметрії/ITSM.

16) Міні-шаблони

Картка інциденту (скор.)

INC: 2025-11-01-042 (SEV-1)
T0=12:04Z, Detected=12:07, Ack=12:09, Declared=12:11,
Mitigated=12:24, Recovered=12:48
Service: payments-api (EU)
SLI: success_ratio (-3.6% к SLO, burn=18 мин)
Root cause: provider (PSP-A), Trigger: status red
Comms: first 12:12Z, cadence 15m, SLA met
Links: dashboards, logs, traces, release notes

Звіт Executive (за 28 днів, ключові рядки)

Incidents: 12 (SEV-0:1, SEV-1:3, SEV-2:6, SEV-3:2)
Median MTTR: 52 мин; Median MTTD: 4 мин; MTTA: 3 мин; MTTM: 17 мин
Detection Coverage: 88%; Actionable Pages: 86%; FP Pages: 3.2%
Change Failure Rate: 33% (4/12) — 3 связаны с конфигом
Reopen(90d): 1/12 (8.3%); CAPA Completion: 82% (2 просрочены)
Top Root Causes: provider(4), config(3), capacity(2)

17) Дорожня карта (4-6 тижнів)

1. Нед. 1: стандарт міток часу/полів, словник SEV/причин; базова вітрина інцидентів.
2. Нед. 2: розрахунки MTTD/MTTA/MTTM/MTTR, нормалізація і SEV-дашборд.
3. Нед. 3: зв'язка з релізами/конфігами, Detection Coverage і Alert Hygiene.
4. Нед. 4: Executive-звіт, SLA пост-мортемів, CAPA-трекер.
5. Нед. 5–6: провайдерські звіти, фінмодель burn→$, квартальні цілі і квартальний Incident Review.

18) Підсумок

Метрики інцидентів - це не просто числа, а розкадрування операційної надійності. Коли ви вимірюєте весь потік (від виявлення до CAPA), нормалізуєте показники, пов'язуєте їх з SLO і змінами і регулярно проводите огляди, організація передбачувано знижує час реакції, вартість і повторюваність інцидентів - а користувачі бачать стабільний сервіс.