Plantilla de análisis de causa raíz

Un análisis de causa raíz identifica la condición o falla específica que, de haberse eliminado, habría evitado el incidente — a diferencia de los síntomas que notaste y de los factores contribuyentes que lo empeoraron o lo hicieron más probable. Una plantilla de análisis de causa raíz para incidentes de TI mantiene esas tres cosas separadas en la página, que es justo donde fallan la mayoría de los análisis apresurados.

Por ejemplo: una base de datos se quedó sin conexiones (síntoma), porque un conjunto de consultas analíticas mantuvo las conexiones abiertas demasiado tiempo (factor contribuyente), porque no se aplicaba ningún tiempo de espera a las consultas (causa raíz).

No todo incidente necesita un RCA formal. Hazlo cuando un incidente es de alta severidad, repite una falla anterior, incumple un SLA o es probable que vuelva a ocurrir sin una corrección específica. Los problemas menores y puntuales con una causa obvia y ya corregida normalmente no necesitan el ejercicio completo — basta con anotar la causa en el informe de incidente.

No hay un único método correcto — elige el que se ajuste a la complejidad del incidente.

• Cinco porqués — pregunta "por qué" repetidamente, cada vez sobre la respuesta anterior, hasta llegar a una causa sobre la que puedas actuar. Rápido y simple; funciona mejor para incidentes directos con una sola causa.
• Diagrama de espina de pescado (Ishikawa) — agrupa las causas potenciales en categorías como personas, proceso, tecnología y entorno. Útil cuando es probable que varios factores se hayan combinado para causar el incidente.
• Análisis de árbol de fallas — mapea la combinación lógica de fallas que tuvieron que ocurrir juntas para que el incidente sucediera. Adecuado para sistemas complejos con múltiples rutas de falla.
• Análisis de cambios — compara el estado del sistema antes y después del incidente para aislar qué cambió. Efectivo cuando el incidente ocurrió poco después de un despliegue, un cambio de configuración o una migración.

La plantilla a continuación usa Cinco porqués por defecto, con un desglose estilo espina de pescado al lado — cambia o combina métodos según lo requiera el incidente.

Planteamiento del problema

Una reformulación breve y factual de lo que falló — no el informe de incidente completo. Enlázalo en lugar de repetirlo.

Método utilizado

Nombra el método (Cinco porqués, espina de pescado, árbol de fallas, análisis de cambios) para que quien lo lea después entienda cómo se llegó a la conclusión.

El análisis

El razonamiento en sí — la cadena de porqués, los factores categorizados, el árbol de fallas o la comparación antes/después. Esta es la parte que merece más cuidado; un análisis apresurado tiende a detenerse en la primera respuesta plausible en lugar de la real.

Detonante, causa raíz y factores contribuyentes

Separa tres cosas: el detonante (el evento inmediato que inició el incidente — un despliegue, una consulta, un cambio de configuración), la causa raíz (la condición más profunda que permitió que se convirtiera en un incidente, descrita como un sistema o proceso — nunca como una persona o equipo) y los factores contribuyentes (condiciones que lo hicieron más probable, más largo o más grave, sin ser el detonante ni la causa). Marca la causa raíz como sospechada o confirmada según la evidencia.

Acciones correctivas y preventivas

Las acciones correctivas arreglan lo que ya está roto; las preventivas reducen la probabilidad de recurrencia o de un incidente similar en otro lugar. Cada acción necesita un responsable y, para las de alta prioridad, una fecha límite.

Verificación

Confirma que la corrección realmente aborda la causa raíz, no solo el síntoma — y registra cómo y cuándo se comprobó. Un RCA que nunca se verifica puede dejar la causa real sin resolver sin que nadie lo note.

El siguiente ejemplo continúa el incidente INC-2026-017 usado en la plantilla de informe de incidente.

Título del RCA: ¿Por qué se agotó el pool de conexiones de la base de datos? Incidente relacionado: INC-2026-017 Método utilizado: Cinco porqués Detonante: Un lote de consultas analíticas de larga duración comenzó a mantener conexiones abiertas durante varios minutos cada una.

Cinco porqués

Causa raíz

No se aplicaba ningún tiempo de espera a las consultas en el pool de conexiones compartido, por lo que las consultas analíticas de larga duración podían consumir conexiones indefinidamente. Estado: Confirmada.

Factores contribuyentes

• Las cargas de trabajo analíticas y las de cara al cliente compartían el mismo pool de conexiones.
• No existía una alerta para la saturación del pool de conexiones.

Acciones correctivas y preventivas

Verificación

Confirmada mediante pruebas de carga de la carga de trabajo analítica con el nuevo tiempo de espera y el aislamiento del pool; sin agotamiento de conexiones tras dos semanas de monitoreo.

Un RCA suele ser un insumo del postmortem, no un reemplazo — y viene después del informe de incidente, no en su lugar.

Consulta nuestra plantilla de informe de incidente de TI para el registro que alimenta el RCA; la plantilla de postmortem estará disponible pronto.

• No te detengas en la primera causa plausible. Sigue preguntando por qué hasta llegar a algo sobre lo que puedas actuar, no solo a algo que suene suficiente.
• Distingue lo confirmado de lo sospechado. No presentes una teoría de trabajo como una conclusión verificada.
• Involucra a las personas cercanas al trabajo, no solo al líder del incidente — a menudo conocen el "por qué" que no se ve en los logs.
• Separa la causa raíz de los factores contribuyentes. Corregir un factor contribuyente sin abordar la causa raíz no evitará una recurrencia.
• Evita culpar. Pregunta qué permitió que el sistema fallara, no quién hizo el cambio.
• Verifica la corrección. Confirma que aborda la causa raíz, no solo el síntoma inmediato.

¿Cuál es la diferencia entre una causa raíz y una causa?

Una causa es cualquier cosa que contribuyó al incidente. La causa raíz es la específica que, de haberse eliminado, lo habría evitado — todo lo demás es un factor contribuyente.

¿Cuántos "porqués" se necesitan?

Tantos como haga falta para llegar a algo accionable — a menudo alrededor de cinco, a veces menos o más. Detente cuando la siguiente respuesta sea algo que tu equipo realmente pueda corregir.

¿Un RCA reemplaza al postmortem?

No. El RCA explica la causa; el postmortem usa ese análisis, junto con el informe de incidente, para documentar lecciones e impulsar cambios más amplios.

¿Quién debería hacer el RCA?

Normalmente el responsable del incidente o un facilitador designado, con aportes de las personas que estuvieron más cerca de los sistemas afectados durante el incidente.

Define qué severidades requieren un RCA, quién es responsable y cómo los hallazgos alimentan tu postmortem y tus acciones correctivas — igual que lo harías para un informe de incidente. Hecho de forma consistente, un RCA convierte cada incidente en una mejora específica y verificable, no solo en una historia sobre lo que salió mal.

La plantilla se basa en cómo los equipos con manuales de ingeniería públicos hacen sus revisiones post-incidente. Cabe destacar que ninguno prescribe un método de análisis. Lo que estandarizan es el umbral, el plazo, el responsable y dónde viven las acciones correctivas, y la plantilla sigue ese criterio.