Root Cause Analysis

1) Qué es RCA y por qué es necesario

Análisis de causa raíz: un proceso estructurado para identificar las causas raíz de un incidente con el objetivo de eliminar la repetición. En el centro están los hechos, las relaciones causales y las mejoras sistémicas (procesos, arquitectura, pruebas), no la búsqueda de culpables.
Objetivos: prevenir la recaída, reducir el MTTR/incidencia de incidentes, mejorar el SLO, fortalecer la confianza de los reguladores y socios.

2) Principios (Cultura Justa)

Sin cargos. No castigamos a las personas, sino a las prácticas de riesgo.
Factología. Sólo datos verificables y artefactos.
E2E-look. De cliente a backend y proveedores.
La verificabilidad de las hipótesis. Cualquier afirmación - con prueba/experimento.
Cierre CAPA. Medidas correctivas y de advertencia con propietarios y plazos.

3) Artefactos de entrada y preparación

Línea de tiempo por UTC: T0 detección de → T + acciones → T + recuperación.
Datos de observación: registros, métricas (incluidas las cohortes), tracks, sintéticos, status page.
Cambios: lanzamientos, banderas de fichas, confecciones, eventos de proveedores.
Entorno: versiones, hash artefactos, SBOM, etiquetas de infraestructura.
Base del incidente: descripción del impacto (SLO/SLA, clientes, volumen de negocios), decisiones tomadas, workaround's.
Cadena de custodia: quién y cuándo recogió/alteró la evidencia (importante para el cumplimiento).

4) Técnicas de RCA: cuándo qué

1. 5 Por qué - averiguar rápidamente la cadena causal para problemas estrechos. Riesgo: «enrollar» el complejo sistema a la regla.
2. Diagrama de Ishikawa (Fishbone) - descomponer los factores por categorías: People/Process/Platform/Policy/Partner/Product. Útil al principio.
3. Fault Tree Analysis (FTA): deducción de un evento a un conjunto de causas (AND/OR). Para infraestructuras y fallas «en madera».
4. Causal Graph/Event Chain es un gráfico de dependencias con probabilidades y peso de contribución. Bueno para microservicios y proveedores externos.
5. FMEA (Failure Modes & Effects Analysis) - Prevención: modos de falla, gravedad (S), frecuencia (O), detectabilidad (D), RPN = S × O × D.
6. Change Analysis es una comparación de «cómo fue/cómo llegó a ser» (confites diff, schema, versiones).
7. Human Factors Review es el contexto de las decisiones de las personas (fatiga de alerta, malos playbucks, sobrecarga).

Ligamento recomendado: Fishbone → Change Analysis → Causal Graph/FTA → 5 Why por las ramas clave.

5) Proceso paso a paso de RCA

1. Iniciar: asignar un propietario de RCA, determinar el plazo de emisión del informe (por ejemplo, 5 días hábiles), reunir un comando (IC, TL, Scribe, representantes de proveedores).
2. Recopilar hechos: línea de tiempo, gráficos, lanzamientos, registros, artefactos; fijar versiones y controlar sumas.
3. Mapear impacto: qué SLI/SLO se han visto afectados, qué cohortes (países, proveedores, VIP).
4. Construir hipótesis: primarias, alternativas; marcar cuáles son verificables ahora.
5. Comprobar hipótesis: reproducción en stage/simulación/canario, análisis de tracks, inyección fault.
6. Identificar las causas raíz y propicias: tecnológicas, de procesos, organizativas.
7. Formar CAPA: correctivo (rectificar) y de advertencia (evitar); métricas de éxito y plazos.
8. Negociar y publicar el informe: base de conocimientos interna +, si es necesario, versión externa para clientes/reguladores.
9. Efecto de verificación: puntos de control en 14/30 días; Cierre de acciones.

6) Lo que se considera «causa raíz»

• pruebas débiles/banderas de seguridad, límites/alertas faltantes, documentación ambigua, impagos incorrectos, arquitectura frágil.
• A menudo se trata de una combinación de factores (configuración × ausencia de puerta × carga × proveedor).

7) CAPA: medidas correctivas y de prevención

• fix de código/confites, retroceso de patrón, cambio de límites/temporizaciones, adición de índices, réplica/charding, redistribución de tráfico, actualización de certificados.

• pruebas (contratos, casos de caos), alertas (burn rate, quórum sintético), política de lanzamientos (canary/blue-green), GitOps para confecciones, formación/check-list, duplicación de proveedores, ejercicios de DR.

A cada acción: propietario, deadline, efecto esperado, métrica de validación (por ejemplo, reducción de la tasa de cambio-falla en X%, falta de repeticiones durante 90 días).

8) Verificación de hipótesis y efectos

Experimentos: fault injection/chaos, tráfico de sombras, configuraciones A/B, carga con perfiles reales.
Métricas de éxito: recuperación de SLO, estabilización de p95/p99, ausencia de ráfagas de error-rate, reducción de MTTR, tendencia burn-rate y zero-reopen durante 30 días.
Puntos de control: D + 7, D + 30, D + 90 - Revisión de la ejecución de CAPA e influencia.

9) Plantilla de informe RCA (interno)

1. Breve resumen: qué pasó, cuándo, a quién le afectó.
2. Impacto: SLI/SLO, usuarios, regiones, facturación/multas (si las hay).
3. Timeline (UTC): eventos principales (alertas, soluciones, lanzamientos, ficks).
4. Observaciones y datos: gráficos, registros, rastreos, confecciones (diffs), estados de proveedores.
5. Hipótesis y verificaciones: aceptadas/rechazadas, referencias a experimentos.
6. Causas raíz: tecnológica, procesadora, organizativa.
7. Factores contribuyentes: «por qué no se notó/no se detuvo».
8. Plan CAPA: tabla de acciones con propietarios/plazos/métricas.
9. Riesgos y vulnerabilidades residuales: qué más hay que monitorear/probar.
10. Anexos: artefactos, referencias, gráficos (lista).

10) Ejemplo (breve, resumido)

Evento: 35% de caída en el éxito de los pagos a las 19: 05-19: 26 (SEV-1).
Impacto: 21 minas e2e-SLO violadas, 3 países afectados, devoluciones/indemnizaciones.
Razón 1 (ésos): la nueva versión del validador de tarjetas aumentó la latencia a 1. 2 con → tiempos de espera al proveedor.
Razón 2 (proz): faltaba canario para el proveedor «A», el lanzamiento pasó al 100% a la vez.
Causa 3 (org): el umbral de alerta por SLI empresarial no cubría la banda BIN específica (cohorte VIP).
CAPA: devolver la versión antigua del validador; introducir canario 1/5/25%; agregar SLI de negocios a las cohortes BIN; negociar un failover del 30% para el proveedor «B»; caso de caos «slow upstream».

11) Métricas de madurez del proceso RCA

Ejecución de CAPA a tiempo (% cerrado a los 30 días).
Reopen rate (incidentes reabiertos en 90 días).
Change-failure-rate antes/después.
Porcentaje de incidentes donde se encuentran causas sistémicas (no sólo «error humano»).
Cobertura de pruebas de nuevos escenarios de RCA.
Tiempo de publicación del informe (SLA).

12) Características de los dominios regulados (fintech/iGaming, etc.)

Informes al exterior: versiones cliente/reguladoras del informe sin detalles sensibles, pero con un plan de prevención de repeticiones.
Registro de auditoría e inmutabilidad: almacenamiento de artefactos, informes firmados, enlaces a tickets, CMDB, logs de lanzamiento.
Datos de usuario: despersonalización/enmascaramiento en ejemplos de registros.
Plazos de notificación: vincular a contratos y regulaciones (por ejemplo, N horas por notificación primaria).

13) Anti-patrones

«La culpa es de Vasya» - detenerse en el factor humano sin razones sistémicas.
La falta de verificaciones de hipótesis son conclusiones por intuición.
RCA demasiado general («el servicio estaba sobrecargado») - sin cambios específicos.
No hay CAPA o no hay propietarios/plazos - informe por el bien del informe.
Ocultar información: pérdida de confianza, imposibilidad de capacitar a la organización.
Reajuste de métricas sin ligamento con SLI SLO/Business.

14) Instrumentos y prácticas

Almacenamiento RCA (base wiki/knowledge) con metadatos: servicio, SEV, razones, CAPA, estado.
Plantillas y bots: generación de un marco de informe a partir de un incidente (línea de tiempo, gráficos, lanzamientos).
Gráfico de causalidad: construcción de un mapa causal de eventos (por ejemplo, basado en logs/tracks).
Catálogo de Chaos: scripts para reproducir incidentes pasados en un stage.
Dashboards «post RCA»: widgets individuales que confirman el efecto CAPA.

15) Lista de comprobación «lista para su publicación»

• La línea de tiempo y los artefactos están completos y verificados.
• Las causas raíz están determinadas y probadas por pruebas/experimentos.
• Las causas raíz y contribuyentes están separadas.
• CAPA contiene propietarios, plazos, métricas de efecto medibles.
• Hay un plan de verificación en 14/30 días.
• La versión para stakeholder externos está preparada (si es necesario).
• El informe pasó por esos/pros-rugidos.

16) Resultado

El RCA no es una retrospectiva en aras de la formalidad, sino un mecanismo de aprendizaje del sistema. Cuando se recogen los hechos, se comprueba la causalidad y los CAPA se encierran en métricas y son probados por experimentos, la organización se vuelve cada vez más resistente: los SLO son más estables, el riesgo de recaídas es menor y la confianza de usuarios y reguladores es mayor.