Análisis de incidentes posteriores

1) ¿Por qué se necesita un análisis posterior a un incidente?

El análisis post-incidente (post-mortem/AAR) es un proceso estructurado de aprendizaje de la organización después de un fallo. El objetivo no es buscar culpables, sino identificar causas raíz y contribuyentes y consolidar acciones medibles (CAPA) que reduzcan el riesgo de repetición y el costo de incidentes, mejorando SLO, MTTR y la confianza de clientes/reguladores.

2) Principios (Cultura Justa)

Sin acusaciones: analizamos los sistemas, las decisiones y el contexto, no las personalidades.
Los hechos son más importantes que las opiniones: timeline, logs, métricas, tracks, artefactos de cambio.
E2E-look: desde síntomas en el cliente hasta adicciones internas y proveedores externos.
Verificabilidad: cada hipótesis está respaldada por un experimento/datos.
Cierre de ciclo: análisis de → CAPA → puntos de control → retest.

3) Cuándo iniciar el análisis y cuáles son los formatos

Obligatorio: SEV-0/1; Incumplimiento de los requisitos reglamentarios y de SLA; fuga de datos; Riesgo PR significativo.
Acelerado (light): SEV-2 con efectos notables o síntomas recurrentes.
AAR de comunicación: si la falla afectó a la página de estado/soporte, verificamos los SLAs de los updates y la calidad de los mensajes.

Plazos: borrador en 48-72 horas, versión final - hasta 5 días hábiles (a menos que se acuerde lo contrario).

4) Funciones y responsabilidades

Propietario del análisis (RCA Lead): organiza el proceso, conduce la reunión, es responsable de la calidad del informe y CAPA.
Detectent Commander (IC): proporciona la factología del incidente y la solución.
Líderes tecnológicos (por sistemas): análisis de las causas que confirman los artefactos.
Comms/Support/Legal: evaluación de comunicaciones y requisitos de cumplimiento.
Scribe: protocolo, recolección de pruebas, cumplimiento de la estructura.
Stakeholders producto/negocio: impacto en los clientes/volumen de negocios, priorización de CAPA.

5) Preparación: qué recoger antes de la reunión

Línea de tiempo (UTC): T0 detección → Tn recuperación; lanzamientos/banderas/confecciones, estado de los proveedores.
Datos de observación: gráficos SLI/SLO, error-rate, percentili, logs, trazados, capturas de pantalla.
Contexto de cambios: referencias a PR/deploy, migraciones de DB, banderas de fijación, planes de trabajo.
Importación: cohortes/regiones/proveedores afectados, minutos de inactividad, préstamos de SLA.
Comunicaciones: borradores/posts en la página de estado, respuestas de sapport, anuncios internos.
Políticas/playbucks: qué iba a pasar por un proceso donde había desviaciones.

6) Técnicas de análisis (seleccione una combinación)

5 Por qué: apertura rápida de la cadena causal (riesgo - simplificación excesiva).
Gráfico de Ishikawa: People/Process/Platform/Policy/Partner/Product.
Fault Tree Analysis (TLC): deducción de un evento a múltiples causas (AND/OR).
Análisis de cambios: lo que cambió durante el período de incidente vs estado estable.
Causal Graph: grafo de causalidad para microservicios complejos y dependencias externas.
Human Factors Review: fatiga, ruido informativo, runbook 'i irrelevantes.

7) Estructura del informe (plantilla)

1. Resumen (Executive Summary): qué, cuándo, a quién afectó, el estado final.
2. Impacto: SLI/SLO, usuarios, regiones/proveedores, min. inactividad, efectos financieros/regulatorios.
3. Timeline (UTC): eventos clave, lanzamientos, soluciones de IC, comunicaciones.
4. Observaciones y datos: gráficos, registros, tracks, diffs de configuraciones/esquemas.
5. Hipótesis y verificaciones: aceptadas/rechazadas, referencias a experimentos/simulaciones.
6. Causas raíz: sistema/proceso/técnica (lenguaje claro).
7. Factores contribuyentes: por qué no se notó/no se detuvo antes.
8. Lo que funcionó/lo que no funcionó: procesos, herramientas, personas.
9. CAPA: medidas correctivas y de advertencia con propietarios/plazos/métricas de éxito.
10. Plan de verificación: puntos de control D + 14/D + 30, criterios de cierre.
11. Versiones para exteriores: cliente/regulador (sin datos sensibles).
12. Aplicaciones: artefactos, enlaces a tickets/PR, capturas de pantalla de dashboards.

8) CAPA: cómo hacer que las acciones sean operativas

Cada acción tiene un propietario, un deadline y un KPI de efecto (por ejemplo, una reducción de la tasa de cambio-falla en X%, una repetición cero de 90 días, una reducción de la tasa de cambio en picos).
Comparta la medida Corrective (corregir) y Preventive (evitar).
Vincular a policy-as-code: alertas, SLO-gates, auto-scale/limites, GitOps.
CAPA cae en un backlog público con reseñas en las reuniones operativas semanales.

9) Verificación de efectos y cierre

Puntos de control: D + 7 (intermedio), D + 14/D + 30 (básico), D + 90 (total).
Verificación: pruebas/simulaciones (día de juego), tráfico de sombras, observabilidad (SLI estables en la zona verde), ausencia de recaídas.
El cierre sólo es posible con las métricas ejecutadas por CAPA y confirmadas.

10) Comunicaciones y cumplimiento

Interno: estado comprensible para productos/soporte/gestión, SLA apdates cumplidos.
Externo: página de estado, envíos a clientes/socios; lenguaje sin acusaciones, un claro plan de prevención.
Regulación: plazos de notificación, despersonalización de ejemplos, almacenamiento inmutable de informes y artefactos.

11) Métricas de madurez del proceso

Tiempo de publicación del informe: hecho vs SLA (por ejemplo, ≤5 días hábiles).
Tasa de compleción de CAPA:% de las acciones cerradas a tiempo.
Tasa de recuperación: proporción de incidentes repetidos en 90 días.
Proporción de causas sistémicas vs «error humano».
Higiene de alerta: reducción de los falsos pages, crecimiento de alertas cubiertas de runbook 'ami.
Cambio de métricas DORA: MTTR, cambie-failure-rate antes/después.

12) Hojas de cheques

Antes de la ruptura

• Se ha determinado el titular del RCA y la composición de los participantes.
• Se ha reunido una línea de tiempo y artefactos (registros/gráficos/lanzamientos/banderas).
• Se ha evaluado el impacto por cohorte/región/proveedor.
• Se han preparado borradores de las secciones «Impact» y «Time Line».
• Las políticas/playbacks relevantes se correlacionan con las acciones reales.

• Se han establecido hipótesis y fundamentos aceptados/rechazados.
• Se identifican las causas raíz y contribuyentes.
• Se formó un plan CAPA con KPI y plazos.
• Versiones acordadas del informe para partes externas (si es necesario).

• Informe publicado a tiempo, acceso por funciones.
• CAPA está inscrito en el backlog, los propietarios están confirmados.
• Se han asignado puntos de control y mini-simulación para la verificación.
• Runbook/SOP/alertas/documentación actualizados.

13) Anti-patrones

«El hombre X es culpable» - sin razones sistémicas → repetición.
Informe sin CAPA o sin propietarios/plazos - papel por el bien del papel.
No hay hechos/artefactos - conclusiones sobre las sensaciones.
Lenguaje demasiado general («sobrecarga DB») sin cambios específicos.
Ignorar las comunicaciones y el cumplimiento son riesgos reputacionales.
Cierre sin verificación de efectos - recaídas semanas después.

14) Mini plantillas

Casquillo del informe

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

Formulación de causa raíz (ejemplo)

CAPA (fragmento)

Habilitar enrutamiento canario a PSP-A (1%→5%→25%), propietario: @ payments-tl, hasta: 2025-11-07, KPI: incidentes P1 cero en lanzamientos de proveedores de 30 días.
Reconfigurar temporizadores/retiros con tiempo total ≤ SLA 800 ms, propietario: @ platform-sre, hasta: 2025-11-05, KPI: p99 <600 ms bajo carga N.
Añadir SLI de negocios por cohorte BIN, propietario: @ data-lead, hasta: 2025-11-10, KPI: detección de degradación <5 min.

15) Incrustación en la práctica diaria

RCA-rugido semanal: estado de CAPA, nuevas lecciones, actualizaciones de procesos.
Catálogo de post-mortems en wiki con etiquetas (servicio, SEV, razones) y búsqueda.
Simulaciones basadas en el incidente en 2-4 semanas para verificar las medidas.
Incluir lecciones en el onboarding on-call y actualizar los scripts de aprendizaje.

16) Resultado

El análisis post-incidente es un mecanismo de mejora del sistema. Cuando se recogen los hechos, se comprueba la causalidad, se miden y verifican las acciones, la entidad acumula capital operativo de fiabilidad: caen los MTTR e incidentes repetidos, crece la previsibilidad de los lanzamientos y la confianza de los clientes.