Causa raíz en minutos: método para sistemas distribuidos

En un sistema distribuido, una sola operación del cliente puede atravesar una aplicación móvil, una puerta de enlace de APIs, varios microservicios, una cola de mensajes, dos bases de datos y un proveedor externo. Cuando algo falla, el síntoma aparece en un lugar y la causa suele estar en otro.

Bajo presión, los equipos tienden a investigar lo que conocen mejor. El de base de datos revisa la base de datos, el de red revisa la red, y cada uno confirma que su parte está bien. El tiempo se va en descartar sin orden. Un método explícito no reemplaza la experiencia, pero evita que el triaje dependa de quién esté de turno.

Antes de empezar, una aclaración: restaurar el servicio va primero. Si hay una mitigación segura y evidente, como revertir un despliegue reciente, se aplica, y la investigación sigue después con el servicio estable.

Paso 1: acotar el impacto

La primera pregunta no es "¿qué falló?", sino "¿qué está fallando, para quién y desde cuándo?". Acotar el impacto reduce el espacio de búsqueda más que cualquier otra acción.

• Qué operaciones: ¿fallan todas las transacciones o solo algunas? Si solo fallan los pagos con tarjeta y los inicios de sesión funcionan, ya se descartó buena parte del sistema.
• Qué usuarios: ¿todos o un segmento? Una versión de la aplicación, un canal, un país, un tipo de cliente.
• Dónde: ¿una región, una zona de disponibilidad, un clúster, un nodo?
• Desde cuándo: la hora exacta de inicio es el dato más valioso del paso 3.
• Cómo: ¿errores, lentitud, resultados incorrectos? No se investiga igual un aumento de latencia que una respuesta equivocada.

Para responder rápido hace falta que la telemetría tenga dimensiones útiles: versión, región, canal, tipo de operación. Si las métricas solo existen como un total, no se puede segmentar.

Paso 2: seguir la traza

Con el impacto acotado, se toma una muestra de operaciones fallidas o lentas y se sigue su recorrido. Una traza distribuida muestra cada salto de la solicitud entre servicios, con su duración y su resultado. Permite ver dónde se origina el error y dónde se consume el tiempo.

Al leer trazas conviene buscar:

• El primer tramo (span) con error, no el último. El servicio que devuelve el error al cliente suele ser solo el mensajero.
• Tramos con duración anómala comparados con trazas sanas de la misma operación.
• Reintentos repetidos, que amplifican la carga sobre un servicio ya degradado.
• Llamadas a dependencias externas con tiempos de espera agotados.

Desde la traza se salta a los logs del servicio sospechoso usando el identificador de traza. Ese salto es posible solo si los logs incluyen el identificador. Es un detalle de implementación que define si el triaje toma minutos u horas.

Paso 3: correlacionar con cambios y despliegues

Cuando un sistema que funcionaba deja de hacerlo, es frecuente que algo haya cambiado. Por eso, con la hora de inicio del paso 1, se revisa qué cambió en esa ventana:

• Despliegues de aplicaciones, incluidos los de otros equipos que comparten dependencias.
• Cambios de configuración, de reglas de firewall, de certificados o de secretos.
• Cambios de infraestructura: escalado, parches, actualizaciones de versión de la base de datos o del orquestador.
• Cambios externos: actualizaciones del proveedor, vencimientos, cambios de tráfico por una campaña comercial.

Esta correlación es rápida si los eventos de cambio llegan a la plataforma de observabilidad y aparecen marcados en los mismos gráficos que las métricas. Si viven solo en la herramienta de ITSM o en el sistema de integración continua, alguien tiene que buscarlos a mano. Recomendamos integrar el registro de cambios y el pipeline de despliegue con la observabilidad como práctica estándar.

Paso 4: revisar saturación

Si no hay un cambio que explique el problema, la siguiente sospecha es la capacidad. Un recurso saturado degrada todo lo que depende de él, y el síntoma puede aparecer lejos del recurso.

El método USE, propuesto por Brendan Gregg, ordena esta revisión: para cada recurso, mirar utilización, saturación y errores. Los recursos a revisar no son solo CPU y memoria:

• Pools de conexiones a bases de datos y a servicios externos.
• Hilos de trabajo y colas internas de las aplicaciones.
• Profundidad de colas de mensajes y retraso de los consumidores.
• Límites de tasa (rate limits) de APIs internas y de proveedores.
• Cuotas de la nube, límites de descriptores de archivo, espacio en disco para logs.

Un pool de conexiones agotado, por ejemplo, no se ve en la CPU del servidor, pero se nota en la latencia de todas las operaciones que lo usan.

Paso 5: validar la hipótesis

Al llegar aquí suele haber una hipótesis. El error frecuente es darla por buena porque encaja con la historia. Una hipótesis de causa raíz se valida con tres preguntas:

1. ¿Explica todo el impacto observado? Si la causa propuesta es un nodo de base de datos, pero también fallan operaciones que no lo usan, la hipótesis está incompleta.
2. ¿Explica el momento de inicio? La causa debe ser anterior o simultánea al primer síntoma.
3. ¿Se puede comprobar? Revertir el cambio, aislar el nodo o liberar el recurso debería mejorar el síntoma. Si se actúa sobre la supuesta causa y nada cambia, hay que volver al paso 2.

Documentar cada hipótesis descartada y por qué también es útil. Evita que otra persona la revise de nuevo durante el mismo incidente y alimenta el análisis posterior.

Por qué el método falla sin código instrumentado

Los cinco pasos dependen de datos que la infraestructura sola no produce. Una plataforma APM como Dynatrace o Datadog instrumenta automáticamente buena parte del tráfico y de los entornos de ejecución más comunes. Eso es valioso, pero tiene límites:

• Contexto que se corta: si un servicio pasa trabajo a una cola o a un proceso propio sin propagar el contexto de traza, la traza se rompe y el paso 2 se queda a ciegas. OpenTelemetry y el estándar W3C Trace Context resuelven esto, pero alguien tiene que aplicarlos en el código donde la instrumentación automática no llega.
• Logs sin estructura: un texto libre sin identificador de traza ni campos consistentes no se puede correlacionar ni filtrar con rapidez.
• Errores silenciados: excepciones capturadas y descartadas, o respuestas con código 200 que contienen un error, no aparecen en ninguna métrica.
• Falta de significado de negocio: la plataforma ve llamadas HTTP, pero no sabe que una de ellas es "autorizar pago" ni qué tipo de cliente la hizo. Sin esos atributos, el paso 1 no puede segmentar.

Plataforma observable no es lo mismo que aplicación observable. Escribir software observable es una decisión de desarrollo: logs estructurados, identificadores de correlación, propagación de contexto, métricas de negocio y eventos significativos. Conviene incluirlo en los criterios de aceptación de cada servicio, igual que las pruebas.

Checklist de triaje

Paso	Pregunta clave	Señal principal	Requisito de instrumentación
0. Mitigar	¿Hay una acción segura que restaure el servicio ya?	Historial de cambios recientes	Capacidad de revertir despliegues
1. Acotar el impacto	¿Qué falla, para quién, dónde y desde cuándo?	Métricas de servicio segmentadas	Dimensiones de versión, región, canal y operación
2. Seguir la traza	¿Dónde nace el error o la demora?	Trazas distribuidas y logs	Propagación de contexto e identificador de traza en logs
3. Cruzar con cambios	¿Qué cambió en la ventana de inicio?	Eventos de despliegue y configuración	Envío de eventos de cambio a la plataforma
4. Revisar saturación	¿Qué recurso está al límite?	Utilización, saturación y errores por recurso	Métricas de pools, colas y límites
5. Validar la hipótesis	¿Explica todo el impacto y el momento de inicio?	Efecto de la acción correctiva	Registro de hipótesis y acciones en el incidente

Después del incidente, la revisión posterior sin culpables debe responder dos preguntas además de la causa: ¿qué paso del método tomó más tiempo? y ¿qué dato faltó? Las respuestas suelen apuntar a una mejora de instrumentación concreta, que es la forma más directa de que el siguiente triaje sea más corto.