Cómo manejar errores en producción sin volverte loco

Un sistema en producción sin una estrategia sólida de error handling es una bomba de relojería. No es si fallará, sino cuándo. La mayoría de los desarrolladores se centran en el código que funciona, pero pocos invierten tiempo en cómo el sistema debe comportarse cuando los errores en producción ocurren.

Esto no es solo cuestión de escribir try-catch o devolver un 500. Se trata de visibilidad, de entender qué ha fallado, cuándo, dónde y por qué, sin tener que bucear en servidores o depender de que un cliente te lo reporte.

Impacto de los errores en producción

Un error en producción bien manejado es un incidente. Un error sin manejar es un desastre. La diferencia no está en el fallo en sí, sino en la capacidad de tu equipo para detectarlo, diagnosticarlo y resolverlo a tiempo. No se trata de eliminar todos los errores —eso es imposible— sino de controlar su impacto.

Lo que sí puedes controlar es la información que generas sobre ese error y cómo te llega. Esto se reduce a dos elementos clave: un logging robusto y un sistema de alertas inteligente. Sin ellos, estás ciego.

Una buena estrategia de logging es el primer paso

El logging no es un vertedero de información. Es una herramienta de diagnóstico. Un buen log te dice la historia completa de lo que pasó: qué usuario estaba haciendo qué, en qué momento, con qué datos de entrada y qué error específico ocurrió. Mi regla es: si no puedes replicar el error con la información de los logs, tu estrategia de logging es deficiente.

Esto significa usar logs estructurados, con un formato consistente (JSON es lo más común), que permitan filtrar y buscar fácilmente. Evita los logs excesivamente verbosos que ocultan la información importante bajo una montaña de ruido. Si quieres profundizar, tengo un artículo sobre las buenas prácticas de logging en aplicaciones que te puede guiar.

Configurando alertas efectivas, no ruido

Recibir una alerta por cada incidente en producción es el camino más rápido hacia la fatiga de alertas. El objetivo no es que el sistema grite, sino que susurre cuando hay un problema menor y grite solo cuando hay algo crítico. Las alertas deben ser procesables.

Una alerta sin contexto es inútil. Debe incluir la descripción del error, el servicio afectado, la severidad y un enlace directo a los logs relevantes. Para casos críticos, un sistema de notificaciones en tiempo real, como Telegram o Slack, es lo que uso con mis clientes para asegurar una respuesta rápida.

Aquí un ejemplo de cómo se podría implementar una alerta simple que monitoree los logs de errores y dispare una notificación:

#!/bin/bash

# Este script busca "ERROR" en los logs y notifica si encuentra ocurrencias recientes.
LOG_FILE="/var/log/mi-aplicacion/app.log"
LAST_CHECK_FILE="/tmp/last_error_check.timestamp"
THRESHOLD_SECONDS=300 # Buscar errores en los últimos 5 minutos

# Obtener la fecha de la última comprobación
if [ -f "$LAST_CHECK_FILE" ]; then
    LAST_CHECK=$(cat "$LAST_CHECK_FILE")
else
    LAST_CHECK=$(date -d "1 minute ago" +%s) # Primera ejecución, mira el último minuto
fi

# Buscar errores desde la última comprobación
NEW_ERRORS=$(awk -v last_check="$LAST_CHECK" '{
    # Suponiendo que el log tiene un timestamp UNIX en la primera columna
    timestamp = $1
    if (timestamp > last_check && $0 ~ /ERROR/) {
        print $0
    }
}' "$LOG_FILE")

if [ -n "$NEW_ERRORS" ]; then
    MESSAGE="🚨 ¡NUEVOS ERRORES EN PRODUCCIÓN! 🚨\n\n$(echo -e "$NEW_ERRORS" | head -n 5)\n\nVer logs completos en: ssh://[email protected]/var/log/mi-aplicacion/app.log"
    # Llama a tu script de notificación (ej. un webhook de Telegram)
    # curl -X POST -H 'Content-Type: application/json' -d "{\"text\": \"$MESSAGE\"}" "https://api.telegram.org/botTOKEN/sendMessage?chat_id=CHAT_ID"
    echo -e "$MESSAGE" # Para pruebas
fi

# Actualizar el timestamp de la última comprobación
date +%s > "$LAST_CHECK_FILE"

Este script es un punto de partida. Lo que hago en estos casos es integrar esto con un sistema de alertas por Telegram que permite notificaciones directas al móvil del equipo.

Tradeoff honesto: visibilidad frente a complejidad

Implementar un sistema robusto de error handling, logging y alertas no es trivial. Requiere una inversión inicial en diseño, configuración y mantenimiento.

Lo que ganas:

• Paz mental: Sabes que los problemas no pasarán desapercibidos.
• Resolución rápida: Diagnóstico preciso y ágil.
• Estabilidad del negocio: Menos tiempo de inactividad, mayor confianza del cliente.
• Mejora continua: Los errores son datos para mejorar el sistema.

Lo que complicas:

• Inversión inicial: Tiempo y recursos en configurar herramientas y flujos.
• Mantenimiento: Los sistemas de logging y alertas también necesitan atención y ajustes.
• Curva de aprendizaje: El equipo debe saber cómo interpretar y actuar sobre la información.

Lo que no negocias: Que un fallo en producción sea una sorpresa. La proactividad es clave.

Mi regla para la gestión de errores en producción

Mi regla es simple: si un cliente me llega con un problema en producción y no tiene logs decentes o un sistema de alertas básico, lo primero que hago es montar eso. No importa cuán complejo sea el problema, sin visibilidad, estás adivinando. La diferencia entre el código que funciona en local y el que aguanta en producción es precisamente esta capacidad de reaccionar ante lo inesperado.

Un incidente en producción es una oportunidad para aprender y mejorar el sistema, pero solo si se tiene visibilidad.

Si estás diseñando un sistema de notificaciones para tu aplicación, considera cómo integrar estas alertas de forma efectiva; tengo un artículo sobre el diseño de un sistema de notificaciones que te puede ser útil. Y si necesitas una visión más amplia de la salud de tus servidores, te recomiendo revisar la monitorización básica de un VPS para mantener todo bajo control.