Análisis de Causa Raíz
Ir más allá de los síntomas para encontrar causas sistémicas.
1Por Qué Importan las Causas Raíz
La mayoría de la resolución de problemas aborda síntomas, no causas.
¿Falló el despliegue? Revertir y volver a desplegar. ¿Bug en producción? Aplicar un hotfix. ¿La compilación es lenta? Agregar más servidores de compilación.
Estas soluciones abordan el dolor inmediato. El problema desaparece... hasta que regresa. Porque no arreglaste lo que lo causó.
El análisis de causa raíz significa preguntar "¿por qué?" hasta encontrar la causa sistémica—aquello que, si se arregla, evitaría que el problema se repita.
El despliegue no falló por un fallo aleatorio. Falló porque el conjunto de pruebas es inestable. El conjunto de pruebas es inestable porque las pruebas comparten estado. Las pruebas comparten estado porque el framework de pruebas no se entendió cuando se configuró.
Arregla el síntoma inmediato (reintentar el despliegue) y volverás a intentarlo mañana. Arregla la causa raíz (corregir la comprensión del framework de pruebas) y los despliegues dejan de fallar.
El análisis de causa raíz toma más tiempo al principio. Pero ahorra exponencialmente más tiempo al prevenir la recurrencia.
El Peligro de las Soluciones Rápidas
Cada solución rápida que no aborda las causas raíz crea un patrón: el problema se repite, lo arreglas de nuevo, se vuelve 'normal'. Eventualmente tienes un sistema sostenido por soluciones temporales, donde los problemas reales son invisibles bajo capas de parches.
2Los Cinco Por Qué
Los Cinco Por Qué es la técnica de causa raíz más simple: sigue preguntando "¿por qué?" hasta llegar a una causa raíz, usualmente alrededor de cinco iteraciones.
Ejemplo:
Problema: Producción estuvo caída durante 2 horas.
- ¿Por qué? Se desplegó una configuración incorrecta.
- ¿Por qué? El cambio de configuración no se probó.
- ¿Por qué? No tenemos pruebas de cambios de configuración.
- ¿Por qué? La configuración se gestiona separadamente del código.
- ¿Por qué? El equipo de infraestructura la configuró antes de que el equipo de desarrollo adoptara GitOps.
Causa raíz: Separación histórica de la configuración del código en el pipeline de despliegue.
Contramedida: Mover la configuración al mismo repositorio y pipeline de CI/CD que el código de la aplicación.
Trampas de los Cinco Por Qué:
- Detenerse demasiado pronto: "Error humano" nunca es una causa raíz. ¿Por qué ocurrió el error? ¿Qué sistema lo permitió?
- Un solo hilo: Los problemas reales a menudo tienen múltiples causas. Los Cinco Por Qué pueden perder cadenas causales paralelas.
- Basado en opiniones: Sin datos, podrías preguntar "¿por qué?" y obtener especulación en lugar de hechos.
- Búsqueda de culpables: Si los Cinco Por Qué degeneran en "¿quién la arruinó?", se están usando mal.
Los Cinco Por Qué funcionan mejor como punto de partida, complementados con datos y múltiples perspectivas.
3Diagramas de Ishikawa (Espina de Pescado)
El diagrama de Ishikawa, también llamado espina de pescado o diagrama de causa-efecto, ayuda a explorar múltiples categorías de causas simultáneamente.
El problema es la "cabeza" del pez. Las categorías principales de causas son las "espinas". Las subcausas se ramifican de cada espina.
Categorías comunes (las 6 M):
- Mano de obra: Personas, habilidades, capacitación
- Método: Procesos, procedimientos
- Máquina: Herramientas, equipo, sistemas
- Material: Entradas, datos, dependencias
- Medición: Métricas, monitoreo, retroalimentación
- Medio ambiente (Entorno): Factores externos, contexto
Para software, podrías adaptar:
- Personas: Habilidades, comunicación, estructura del equipo
- Proceso: Flujo de trabajo, transferencias, políticas
- Tecnología: Herramientas, infraestructura, arquitectura
- Datos: Entradas, estado, dependencias
- Medición: Visibilidad, monitoreo, alertas
- Entorno: Servicios externos, carga, contexto
El diagrama ayuda a los equipos a hacer una lluvia de ideas de causas sistemáticamente en lugar de anclarse en la primera idea. Revela que los problemas usualmente tienen múltiples causas contribuyentes.
Combina Técnicas
Usa los Cinco Por Qué para profundizar en cada rama de la espina de pescado. La espina de pescado asegura que explores ampliamente; los Cinco Por Qué aseguran que explores profundamente. Juntos son poderosos.
Incidente: Falla de despliegue causó interrupción de 2 horas. Los Cinco Por Qué llevaron a: configuración no probada → configuración gestionada separadamente → decisión arquitectónica histórica. Espina de pescado reveló: tampoco había manual de despliegue (Proceso), ni proceso canary (Método). Se abordaron los tres.
Incidente: Falla de despliegue causó interrupción de 2 horas. Conclusión del post-mortem: 'El desarrollador debería haber tenido más cuidado'. Elemento de acción: 'Tener más cuidado la próxima vez'. El problema se repite dos semanas después con un desarrollador diferente.
- Arreglar síntomas sin causas raíz lleva a problemas recurrentes
- Los Cinco Por Qué profundizan preguntando '¿por qué?' repetidamente
- El error humano nunca es una causa raíz—pregunta qué sistema lo permitió
- Los diagramas de espina de pescado ayudan a explorar múltiples categorías de causas
- Usa datos, no especulación, para validar cadenas causales
- •Detenerse en 'error humano' o 'falta de atención'
- •Usar los Cinco Por Qué sin datos para validar suposiciones
- •Encontrar una causa y detenerse (los problemas a menudo tienen múltiples causas)
- •Convertir el análisis de causa raíz en asignación de culpas