Son las 3:17 de la madrugada. PagerDuty suena. El dashboard de latencia se ha pintado de rojo. Alguien en el canal de incidentes escribe: "Voy a reiniciar el servicio a ver si se arregla."
Esa frase es el síntoma de un problema más profundo que el incidente mismo: la ausencia de método. La mayoría de los equipos no fallan en troubleshooting por falta de habilidad técnica. Fallan porque no tienen un proceso de diagnóstico. Improvisan. Prueban cosas. Y cuando algo funciona, nadie sabe realmente por qué funcionó.
El anti-patrón: "probar cosas a ver qué pasa"
El troubleshooting por prueba y error tiene un costo que rara vez se mide. Cada acción sin hipótesis previa contamina el escenario. Un reinicio borra el estado del proceso. Un cambio de configuración introduce una variable nueva. Un rollback prematuro elimina la evidencia que necesitabas para entender la causa raíz.
He visto incidentes de 45 minutos convertirse en caídas de 4 horas porque alguien ejecutó tres "soluciones" simultáneas sin correlacionar ninguna con los síntomas observados. Al final, el sistema se recuperó solo por un timeout de conexión, y las tres acciones anteriores generaron dos problemas nuevos.
El troubleshooting efectivo no es velocidad. Es precisión bajo presión.
Un framework de 5 pasos: Contener, Observar, Hipotetizar, Validar, Documentar
Este no es un framework académico. Es el resultado de años diagnosticando incidentes en sistemas financieros, plataformas de alta disponibilidad y arquitecturas distribuidas con decenas de servicios.
- 1. Contener: Antes de diagnosticar, reduce el blast radius. Redirige tráfico si puedes. Activa fallbacks. Comunica al equipo que hay un incidente activo. El objetivo no es entender todavía — es limitar el daño.
- 2. Observar: Recopila datos antes de tocar nada. Métricas, logs, traces, estado de los pods, conexiones de red, consumo de recursos. La observación sin acción es la fase más valiosa y la más ignorada.
- 3. Hipotetizar: Formula una hipótesis basada en lo observado. No tres hipótesis a la vez. Una. Específica. Falsificable. "La latencia viene del pool de conexiones a la base de datos porque veo threads en estado WAITING."
- 4. Validar: Diseña una prueba que confirme o descarte tu hipótesis. Si la hipótesis es correcta, verás X. Si no, verás Y. Ejecuta la prueba. Si la hipótesis era incorrecta, vuelve al paso 2 con la nueva información.
- 5. Documentar: El postmortem no es burocracia. Es el mecanismo que convierte un fallo en conocimiento organizacional. Timeline, causa raíz, acciones tomadas, lecciones aprendidas. Sin documentación, el mismo incidente se repite.
Las herramientas que realmente importan
Las herramientas de diagnóstico no son opcionales. Son la diferencia entre opinar y saber. Estas son las que uso con frecuencia en incidentes reales:
- Thread dumps: para entender qué está haciendo cada hilo de la JVM. Deadlocks, contención de locks, threads bloqueados en I/O — todo aparece aquí.
- Heap dumps: cuando sospechas de memory leaks o presión de GC. Un heap dump con MAT o VisualVM revela qué objetos están consumiendo memoria.
- tcpdump / Wireshark: cuando el problema está en la red. Retransmisiones TCP, handshakes lentos, conexiones reseteadas. La red miente menos que los logs de aplicación.
- strace / ltrace: para ver las system calls que hace un proceso. Útil cuando el proceso parece "colgado" y no sabes en qué syscall está bloqueado.
- Logs correlacionados: no logs sueltos. Logs con trace ID, timestamp preciso y contexto suficiente para reconstruir el flujo completo de una petición.
La herramienta correcta depende de la capa donde sospechas que está el problema. Aplicación, runtime, sistema operativo, red — cada capa tiene sus instrumentos. Usar la herramienta equivocada es como buscar un problema de DNS con un profiler de CPU.
Caso real: cuando la latencia no era la aplicación
Un servicio crítico empezó a mostrar latencias de 2-3 segundos en llamadas que normalmente tomaban 50ms. El equipo asumió que era la aplicación. Escalaron memoria, aumentaron el pool de threads, revisaron queries a la base de datos. Nada cambió.
Aplicando el framework: contuvimos redirigiendo el 30% del tráfico a otra región. Luego observamos. Los thread dumps mostraban threads esperando respuesta de un servicio downstream. Pero el servicio downstream reportaba latencias normales.
La hipótesis: el problema no está en el servicio destino sino en la resolución de su nombre. Validación: ejecutamos dig contra el DNS resolver interno. Tiempo de respuesta: 1.8 segundos. El DNS resolver estaba saturado por un cronjob que generaba miles de queries simultáneas cada 5 minutos.
La causa raíz no tenía nada que ver con la aplicación, ni con la base de datos, ni con el servicio downstream. Era DNS. Un componente que nadie estaba monitoreando porque "DNS siempre funciona."
Sin el método, el equipo habría seguido optimizando la aplicación durante horas. Con el método, el incidente se resolvió en 23 minutos desde que empezó la observación sistemática.
Por qué documentar es parte del diagnóstico
El postmortem no es un castigo ni un trámite. Es la única forma de que el conocimiento generado durante un incidente sobreviva al incidente. Sin él, tres meses después el mismo equipo (o uno nuevo) enfrentará el mismo problema y empezará de cero.
Un buen postmortem incluye: timeline con timestamps, hipótesis probadas (incluyendo las incorrectas), causa raíz verificada, impacto medido, y acciones correctivas con responsable y fecha. No es un documento largo. Es un documento preciso.
El mejor troubleshooter no es el que más sabe — es el que mejor descarta. El método no reemplaza la experiencia, pero garantiza que la experiencia se aplique con disciplina.
