Métricas de incidentes

1) Por que medir incidentes

As métricas de incidentes transformam eventos caóticos em um processo controlado, ajudando a reduzir o tempo de resposta e recuperação, reduzindo a repetência das causas, comprovando o cumprimento de SLO/contratos e encontrando pontos de automação. Um bom conjunto de métricas cobre todo o ciclo: detecção classificação escalação ação mitigante recuperação análise do CAPA.

2) Definições básicas e fórmulas

Intervalos de evento

MTTD (Mean Time To Detect) = tempo médio de T0 (início real da influência) até o primeiro sinal/detecção.
MTTA (Mean Time To Acknowledge) = tempo médio entre o primeiro sinal e ack on-call.
MTTM (Mean Time To Mitigate) = tempo médio até a redução do impacto abaixo do limite SLO (muitas vezes = tempo até a decisão contornada/degradação UX).
MTTR (Mean Time To Recover) = tempo médio até a recuperação completa do SLI de destino.
MTBF (Mean Time Between Failures) = intervalo médio entre os incidentes relevantes.

Tempos operacionais

Time to Declare - desde T0 até o anúncio oficial do nível de SEV/incidente.
Time to Comms - do anúncio ao primeiro update público/interno por SLA.
Time in State - Duração de cada etapa (triage/diag/fix/verify).

Frequências e participações

Invident Count - O número de incidentes durante o período.
Invident Rating - em 1k/10k/100k transações ou solicitações de sucesso (normalização).
SEC Mix - Distribuição por gravidade (SEC-0... SEC-3).
SLA Breach Count/Rate - número/proporção de violações da SLA externa.
Mudar Failure Rate -% dos incidentes causados por alterações (lançamentos/configs/migração).

Qualidade dos sinais e processos

% Actionable Pages é a proporção de pagas que resultaram em ações sensíveis de playbook.
False Positivo Rate (Patges) é uma proporção de falsos efeitos.
Detation Coverage - proporção de incidentes detectados por automação (e não por clientes/suporte).
Reopen Rate - proporção de incidentes repetidos com a mesma causa raiz de ≤90 dias.
CAPA Complition -% das ações de correção/advertência encerradas dentro do prazo.
Comms SLA Adherence é a proporção de updates publicados na frequência necessária.

3) Mapa de métricas sobre os estágios do incidente

4) Normalização e segmentação

Normalize os contadores de volume (tráfego, operações bem sucedidas, usuários ativos).
Segmenta por: região/tenante, provedor (PSP/KYC/CDN), tipo de alteração (código/config/infra), hora do dia (day/night), fonte de detecção (synthetic/RUM/infra/suporte).
Os negócios são importantes para o negócio SLI (sucesso de pagamentos, registro, reposição) - as métricas de incidentes atrelem à sua degradação.

5) Metas liminares (orientações, adapte ao domínio)

MTTD: ≤ 5 min para Tier-0, ≤ 10-15 min para Tier-1.
MTTA: ≤ 5 min (24/7), ≤ 10 min (follow-the-sun).
MTTM: ≤ 15 min (Tier-0), ≤ 30-60 min (Tier-1).
MTTR: ≤ 60 min (Tier-0), ≤ 4 h (Tier-1).
Detation Coverage: ≥ 85% automático.
% Actionable Pages: ≥ 80–90%; FP Pages: ≤ 5%.
Reopen Rate (90д): ≤ 5–10%.
CAPA Complition (dentro do prazo): ≥ 85%.

6) Atribuição das causas e impacto das alterações

A cada incidente, atribua primary causa (Código/Config/Infra/Provider/Security/Data/Capacity) e trigger (release ID, alteração config, migração, fator externo).
Mantenha a Mudança-linked MTTR/Count - Quanto lançamentos e configs contribuem (base para políticas de gate/canarinho).
Leve em conta os incidentes Provider-caused (PSP/KYC/CDN/Cloud) para gerenciar rotas e contratos.

7) Comunicações e impactos de clientes

Time to First Public Update e Update Cadence (por exemplo, a cada 15/30 min).
Complaint Rating - tíquetes/queixas de 1 incidente, tendência.
Status Accuracy é uma proporção de updates públicos sem retoques.
Post-Invident NPS (por clientes-chave) é um impulso breve após o SEC-1/0.

8) Métricas de qualidade de alerting em torno de incidentes

Page Storm Index - número de pagay/hora por on-call durante o incidente (mediana/p95).
O Dedup Efficiency é uma proporção de duplicados suprimidos.
Quorum Confirmation Rate é a proporção de incidentes onde o quórum das sondas (≥2 fontes independentes) funcionou.
Shadow→Canary→Prod Conversão de novas regras (Alert-as-Code).

9) Dashboards (conjunto mínimo)

1. Executive (28 dias): número de incidentes, distribuição de SEV, MTTR/MTTM, SLA breaches, Reopen, CAPA.
2. SRE Operations: MTTD/MTTA по часам/сменам, Page Storm, Actionable %, Detection Coverage, Time to Declare/Comms.
3. Mudar Impact: Proporção de incidentes relacionados com lançamentos/configs, MTTR para mudanças-incidente, janelas de serviço vs incidentes.
4. Provers: incidentes de provedores, tempo de degradação, mudança de rota, SLA contratual.
5. Heatmap por serviços/regiões: incidentes e MTTR em 1k transações.

Combine os gráficos SLI/SLO com anotações de lançamento e marcas de SEV.

10) Esquema de dados do incidente (recomendado)

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) Exemplos de cálculo (SQL-ideia)

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) Conexão com SLO e orçamento de erros

Capture o SLO burn minutos sobre o incidente é o principal «peso» do evento.
Priorize o CAPA em relação ao peso total do burn e do SEV, em vez do número de incidentes.
Curte o burn com o impacto financeiro (exemplo: $/minuto de inatividade ou $/transação perdida).

13) Métricas de maturidade de processo (programa-level)

Postmortem Lead Time: Mediana desde o encerramento do incidente até a publicação do relatório.
Evidence Completeness: proporção de relatórios com timeline, gráficos SLI, logs, links para PR/comms.
Alert Hygiene Score: índice composto por actionable/FP/deadup/quorum.
Handover Defins: proporção de turnos onde o contexto de incidentes ativos foi perdido.
Training Coverage:% on-call que foram simulados por trimestre.

14) Folha de cheque de implantação de métricas

• Foram definidas as marcas de tempo (UTC) e o contrato de eventos do incidente.
• O dicionário SEC, as causas (root causa taxonomy) e as fontes de detecção foram adotados.
• As métricas são normalizadas em volume (tráfego/operações bem-sucedidas).
• Estão prontos 3 dashbord: Executive, Operations, Mudou Impacto.
• Alert-as-Code: Cada regra Page tem um playbook e um dono.
• Pós-mortem SLA (por exemplo, rascunho ≤72ch, final ≤5 escravo. dias).
• CAPA trechos com o efeito KPI e datas D + 14/D + 30.
• Invident Review semanal: tendências, melhores causas, status CAPA.

15) Anti-pattern

Contar apenas MTTR sem MTTD/MTTA/MTTM → perda da governabilidade das fases iniciais.
Não normalizar em volume → grandes serviços «parecem» piores.
O SV sem sistema → a comparabilidade dos incidentes.
A ausência de Evidence → disputas em vez de melhorias.
Foco no número de incidentes em vez de influência burn/SLO.
Ignorar Reopen e CAPA → reincidência eterna.
«Métricas em Excel» sem descarregar automaticamente da telemetria/ITSM.

16) Mini-modelos

Cartão de ocorrência (sock.)

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

Relatório Executive (28 dias, linhas-chave)

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) Mapa de trânsito (4-6 semanas)

1. Ned. 1: padrão de marcas de tempo/campo, dicionário de SEV/causas; vitrine básica dos incidentes.
2. Ned. 2: Cálculos MTTD/MTTA/MTTM/MTTR, normalização e V-dashboard.
3. Ned. 3: conexão com lançamentos/configs, Detecção Coverage e Alert Hygiene.
4. Ned. 4: Relatório executivo, SLA pós-mortem, CAPA-rastreador.
5. Ned. 5-6: relatórios de provedores, Finmodel burn→$, metas trimestrais e Invident Review trimestral.

18) Total

As métricas de incidentes não são apenas números, mas o storyboard da fiabilidade operacional. Quando você mede todo o fluxo (de detecção a CAPA), normaliza os indicadores, relaciona-os a SLO e alterações e faz revisões regulares, a organização reduz previsivelmente o tempo de resposta, o custo e a repetência dos incidentes - e os usuários veem um serviço estável.