Debugging a las 2 AM: Lo Que Realmente Ayuda
Cuando producción se cayó y tu cerebro está nublado, estas son las herramientas y hábitos que te salvan.
Son las 2 AM. Tu teléfono acaba de vibrar con una alerta de PagerDuty. Algo se rompió en producción. Tu cerebro está funcionando a un 40% de su capacidad, con suerte.
Este no es el momento para debugging ingenioso. Este es el momento para técnicas sistemáticas, aburridas y confiables que funcionan incluso cuando estás medio dormido.
Esto es lo que he aprendido de demasiados incidentes nocturnos.
Paso 1: ¿Qué Cambió?
El 90% de los bugs en producción son causados por algo que cambió recientemente. Un deploy. Una actualización de configuración. Una migración de base de datos. Un certificado expirado.
Antes de ponerte a leer código, averigua qué es diferente de cuando funcionaba.
Compara la configuración actual con la última que funcionaba bien. Una herramienta de diff de texto convierte esto en una operación de 10 segundos en vez de estar entrecerrando los ojos comparando dos archivos lado a lado.
En serio. Una vez pasé 45 minutos debuggeando una falla "misteriosa" de API que resultó ser una coma mal puesta en un config JSON. Un diff lo habría detectado en segundos.
Paso 2: Lee el Error Real
Esto suena obvio. No lo es.
Cuando estás cansado, ves un mensaje de error y empiezas a hacer hipótesis de inmediato. "Ah, seguro es la conexión a la base de datos." Te pasas 20 minutos revisando la base de datos. El mensaje de error decía TypeError: Cannot read property 'name' of undefined. Nada que ver con la base de datos.
Lee el error. Léelo de nuevo. Lee el stack trace. Síguelo hasta la línea exacta de código.
Paso 3: Haz el Error Legible
Los logs de producción son un desastre. Todo está en una línea, los objetos JSON no tienen formato, los timestamps están en epoch Unix.
Copia ese bloque de JSON, pégalo en un formateador de JSON, y de repente puedes leer la respuesta de error.
Tengo una pestaña con un formateador permanentemente abierta. Durante incidentes, la uso cada pocos minutos para darle sentido a respuestas de API, entradas de log y archivos de configuración.
Paso 4: Aísla, No Adivines
Los cerebros cansados aman adivinar. "A lo mejor es esto. Déjame probar cambiar aquello."
Resiste eso. Cada cambio al azar que haces agrega incertidumbre. Ahora no sabes si el problema original se arregló o si tu arreglo introdujo un problema nuevo.
En cambio: reproduce el error con la entrada más pequeña posible. Quita todo lo que no sea necesario. Encuentra la única variable que importa.
Paso 5: Revisa lo Aburrido
Antes de meterte en el código, revisa:
- DNS: ¿Está resolviendo correctamente?
- Certificados: ¿Se venció alguno?
- Espacio en disco: ¿Está lleno el servidor?
- Memoria: ¿Algo tiene una fuga?
- Dependencias: ¿Se cayó alguna API externa?
Tengo una nota adhesiva en mi monitor con estos cinco puntos. Durante un incidente, los reviso primero. Han sido la causa raíz más seguido que bugs reales de código.
El Kit de Debugging de las 2 AM
Estas son las pestañas del navegador que abro cuando una alerta me despierta:
- Diff de texto — para comparar configs, variables de entorno, archivos de deploy
- Formateador de JSON — para leer respuestas de API y entradas de log
- Probador de regex — para buscar patrones en los logs
- Un editor de texto plano — para anotar lo que he probado
El último importa más de lo que crees. A las 2 AM, tu memoria a corto plazo es basura. Anota lo que probaste y qué pasó. Tu yo del futuro se lo va a agradecer al yo del pasado.
Después del Incidente
Una vez apagado el fuego, no te vayas a dormir sin más. Invierte cinco minutos anotando:
- Qué se rompió
- Por qué se rompió
- Qué lo arregló
- Cómo prevenirlo la próxima vez
Mañana no te vas a acordar. Anótalo ahora.
El mejor debugging a las 2 AM no se trata de ser inteligente. Se trata de ser sistemático. Haz diff del config. Lee el error. Formatea los logs. Revisa lo aburrido. Anótalo todo. Esa es toda la estrategia.