Métricas de incidentes

1) Por qué medir incidentes

Las métricas de incidentes convierten eventos caóticos en un proceso administrado: ayudan a reducir los tiempos de reacción y recuperación, reducen la repetibilidad de las causas, prueban la ejecución de SLO/contratos y encuentran puntos de automatización. Un buen conjunto de métricas cubre todo el ciclo: detección → clasificación → escalada → acciones de mitigación → recuperación → análisis → CAPA.

2) Definiciones y fórmulas básicas

Intervalos de eventos

MTTD (Mean Time to Nat) = tiempo medio desde T0 (inicio real de la influencia) hasta la primera señal/detección.
MTTA (Mean Time To Acknowledge) = tiempo medio desde la primera señal hasta el ack on-call.
MTTM (Mean Time To Mitigate) = tiempo medio hasta que el impacto disminuye por debajo del umbral SLO (a menudo = tiempo antes de la solución de elusión/degradación UX).
MTTR (Mean Time To Recover) = tiempo medio hasta la recuperación completa del SLI objetivo.
MTBF (Mean Time Between Failures) = intervalo medio entre incidentes relevantes.

Tiempos operativos

Time to Declare - Desde T0 hasta el anuncio oficial del nivel SEV/incidente.
Time to Comms - Desde el anuncio hasta el primer apdate público/interno por SLA.
Tiempo en el estado: duración en cada etapa (triage/diag/fix/verify).

Frecuencia y participación

Recuento de incidentes - Número de incidentes durante el período.
Tasa de Incident - en 1k/10k/100k de transacciones o solicitudes exitosas (normalización).
SEV Mix - distribución por gravedad (SEV-0... SEV-3).
SLA Breach Count/Rate - Número/proporción de violaciones de SLA externas.
Change Failure Rate es el% de los incidentes causados por cambios (versiones/confecciones/migraciones).

Calidad de las señales y los procesos

% Páginas actuables es la proporción de paginas que han dado lugar a acciones significativas en el playbook.
False Positive Rate (Páginas) es la proporción de falsos positivos.
Detection Coverage es la proporción de incidentes detectados por la automatización (no por los clientes/soporte).
Tasa de recuperación: proporción de incidentes repetidos con la misma causa raíz ≤90 días.
CAPA Completion -% de las acciones correctivas/de advertencia cerradas a tiempo.
Comms SLA Adherence es la proporción de apdates publicados a la frecuencia requerida.

3) Mapa de métricas por etapas del incidente

4) Normalización y segmentación

Normalice los contadores por volumen (tráfico, operaciones exitosas, usuarios activos).
Segmentar por: región/tenante, proveedor (PSP/KYC/CDN), tipo de cambio (código/configuración/infra), hora del día (día/noche), fuente de detección (synthetic/RUM/infra/support).
Los SLI empresariales (éxito de pagos, registros, recargos) son importantes para las empresas: las métricas de incidentes se vinculan a su degradación.

5) Objetivos de umbral (puntos de referencia, adaptarse al dominio)

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).
Cobertura de detección: ≥ 85% por automatización.
% Actionable Pages: ≥ 80–90%; FP Pages: ≤ 5%.
Reopen Rate (90д): ≤ 5–10%.
CAPA Completion (a tiempo): ≥ 85%.

6) Atribución de causas e impacto de los cambios

Asigne una causa primaria (Code/Config/Infra/Provider/Security/Data/Capacity) y un trigger (release ID, cambio de configuración, migración, factor externo) a cada incidente.
Mantén MTTR/Count conectado a Change - cuánto contribuyen los lanzamientos y las confecciones (base para las políticas de Gates/Canarios).
Considere por separado los incidentes de Provider-caused (PSP/KYC/CDN/Cloud) para administrar rutas y contratos.

7) Comunicaciones e impacto del cliente

Time to First Public Update y Update Cadence (por ejemplo, cada 15/30 min).
Complaint Rate - tickets/quejas sobre 1 incidente, tendencia.
Status Accuracy es una proporción de apdates públicos sin retracciones.
NPS Post-Incident (por clientes clave) - un breve impulso después de la SEV-1/0.

8) Métricas de la calidad de la alerta alrededor de incidentes

Page Storm Index - Número de paginas/hora por llamada en el momento del incidente (mediana/p95).
Dedup Efficiency es la proporción de duplicados suprimidos.
Quorum Confirmation Rate es la proporción de incidentes donde el quórum de las sondas (≥2 fuentes independientes) ha funcionado.
Shadow→Canary→Prod la conversión de las nuevas reglas (Alert-as-Code).

9) Dashboards (conjunto mínimo)

1. Executive (28 días): número de incidentes, distribución SEV, MTTR/MTTM, SLA breaches, Reopen, CAPA.
2. SRE Operations: MTTD/MTTA по часам/сменам, Page Storm, Actionable %, Detection Coverage, Time to Declare/Comms.
3. Change Impact: porcentaje de incidentes relacionados con lanzamientos/confecciones, MTTR para incidentes de cambio, ventanas de servicio vs incidentes.
4. Proveedores: incidentes por proveedor, tiempos de degradación, cambios de ruta, SLA contractuales.
5. Heatmap por servicios/regiones: incidentes y MTTR en transacciones 1k.

Combine los gráficos SLI/SLO con anotaciones de lanzamiento y marcas SEV.

10) Esquema de datos de incidentes (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) Ejemplos de cálculos (idea 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) Relación con SLO y presupuestos de errores

Fijar SLO burn minutes en un incidente es el principal «peso» del evento.
Priorice la CAPA en función del peso total y SEV, en lugar del número de incidentes.
Coser burn con el impacto financiero (ejemplo: $/minuto de inactividad o $/transacción perdida).

13) Métricas de madurez del proceso (nivel de programa)

Tiempo de entrega postmortem: mediana desde el cierre del incidente hasta la publicación del informe.
Evidence Completeness: proporción de informes con línea de tiempo, gráficos SLI, logs, enlaces PR/comms.
Alert Hygiene Score: índice compuesto por actuable/FP/dedoop/quórum.
Defectos de mano: proporción de turnos donde se pierde el contexto de incidentes activos.
Coverage Training:% on-call que ha pasado simulaciones en un trimestre.

14) Lista de verificación de la implementación de métricas

• Se definen las marcas de tiempo unificado (UTC) y el contrato de eventos de incidentes.
• Se ha aceptado el diccionario SEV, las causas (root cause taxonomy) y las fuentes de detección.
• Las métricas se normalizan por volumen (tráfico/operaciones exitosas).
• Listos 3 dashboards: Executive, Operations, Change Impact.
• Alert-as-Code: cada regla de Page tiene un playbook y un propietario.
• Post mortem SLA (por ejemplo, borrador ≤72ch, final ≤5 esclavo. días).
• CAPA se trae con los KPI del efecto y las fechas D + 14/D + 30.
• Revisión semanal de Incident: tendencias, razones principales, estado de CAPA.

15) Anti-patrones

Contar sólo MTTR sin MTTD/MTTA/MTTM → pérdida de manejabilidad de las primeras fases.
No normalizar en volumen → los grandes servicios «parecen» peores.
El SEV desordenado → la incomparecencia de los incidentes.
La ausencia de Evidence → controversia en lugar de mejoras.
Enfoque en el número de incidentes en lugar de la influencia burn/SLO.
Ignorar a Reopen y CAPA → recaídas eternas.
«Métricas en Excel» sin descarga automática desde telemetría/ITSM.

16) Mini plantillas

Tarjeta de incidente (abreviado)

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

Informe ejecutivo (28 días, líneas clave)

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) Hoja de ruta (4-6 semanas)

1. Ned. 1: estándar de marcas de tiempo/campos, diccionario SEV/razones; escaparate básico de incidentes.
2. Ned. 2: cálculos MTTD/MTTA/MTTM/MTTR, normalización y SEV-dashboard.
3. Ned. 3: conjunto con lanzamientos/configuraciones, Detection Coverage y Alert Hygiene.
4. Ned. 4: Informe ejecutivo, SLA post mortem, rastreador CAPA.
5. Ned. 5-6: informes de proveedores, finmodelo de burn→$, objetivos trimestrales y revisión trimestral de Incident.

18) Resultado

Las métricas de incidentes no son sólo números, sino un guión gráfico de confiabilidad operativa. Cuando se mide todo el flujo (desde la detección a CAPA), se normalizan los indicadores, se asocian a SLO y cambios y se realizan revisiones regularmente, la organización previsiblemente reduce el tiempo de reacción, el costo y la repetibilidad de los incidentes - y los usuarios ven un servicio estable.