GH GambleHub

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

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) Карта метрик по стадиям инцидента

СтадияКлючевые метрикиВопрос
ОбнаружениеMTTD, Detection Coverage, Source Mix (monitoring vs users)Насколько быстро и кто выявляет проблему?
РеакцияMTTA, Time to Declare, Page-to-Ack %, Escalation LatencyКак быстро команда мобилизуется и присваивает SEV?
МитигированиеMTTM, Workaround Success %, Change Freeze LatencyКак быстро снижается влияние до безопасного уровня?
ВосстановлениеMTTR, SLO Burn Stopped Time, Residual Risk WindowКогда сервис полностью вернулся в норму?
КоммсTime to Comms, Comms SLA Adherence, Sentiment/ComplaintsНасколько качественно и вовремя коммуницируем?
ОбучениеPostmortem Lead Time, CAPA Completion/Overdue, Reopen RateУчимся ли мы и закрываем ли петлю улучшений?

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 во время инцидента (медиана/p95).
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-идея)

MTTR за период (медиана):
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');
Detection Coverage:
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';
Change Failure Rate (за 28 дней):
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 (например, черновик ≤72ч, финал ≤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 и изменениями и регулярно проводите обзоры, организация предсказуемо снижает время реакции, стоимость и повторяемость инцидентов — а пользователи видят стабильный сервис.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.