Debugging Production Issues at 2 AM: A Survival Guide [Español]

# Depurando Problemas de Producción a las 2 AM: Una Guía de Supervivencia 2:17 AM. PagerDuty. La alerta dice 95% de tasa de error en el servicio de pago. 847 transacciones afectadas. Tu estómago se hunde. Estás despierto al instante; ese tipo particular de adrenalina que solo proviene de incidentes de producción. Tu teléfono ya está desbloqueado, la laptop arrancando, la cafetera gorgoteando para funcionar solo con memoria muscular. Esta es la página número 847 en tu carrera. Sí, lo llevas contado. Comenzaste a contar después de la página 200 cuando te diste cuenta de que esto iba a ser una parte definitoria de tu vida profesional, y si te iban a despertar a horas impías, más te valía tener datos sobre ello. El servicio de pago. Por supuesto, es el servicio de pago. Siempre es el servicio de pago, o la capa de autenticación, o ese microservicio en el que alguien juró que era "solo un simple envoltorio" hace tres años y que desde entonces se ha metastatizado en una dependencia crítica para la mitad de tu infraestructura. Tienes quizás 90 segundos antes de que se envíe la segunda página a tu gerente. Quizás tres minutos antes de que los clientes comiencen a inundar los canales de soporte. Quizás cinco minutos antes de que alguien de la cúpula directiva se despierte y comience a hacer preguntas en Slack. El reloj está corriendo, tus manos se mueven, y tu cerebro ya está revisando la lista de verificación mental que has construido a lo largo de cientos de estos incidentes. Este no es tu primer rodeo. Pero aquí está lo que nadie te dice sobre la depuración de producción a las 2 AM: nunca se vuelve más fácil. Solo te vuelves más rápido. Construyes mejores herramientas. Cometes menos errores estúpidos. Aprendes a confiar en tus instintos mientras cuestionas todo al mismo tiempo. Desarrollas un sexto sentido para lo que realmente está roto frente a lo que solo parece roto. Y lo más importante, aprendes que la diferencia entre un incidente de 10 minutos y uno de 4 horas a menudo se reduce a los primeros 60 segundos de tu respuesta. Esta guía es todo lo que desearía que alguien me hubiera dicho antes de la página número 1.

Los Primeros 60 Segundos: Triage Como Si Tu Trabajo Dependiera De Ello

El primer minuto de cualquier incidente de producción es pura gestión del caos. Tu cerebro todavía se está empezando a activar, probablemente no llevas pantalones, y necesitas tomar decisiones críticas que determinarán si este incidente se resuelve en minutos o en horas. Aquí está lo que hago, en orden, cada vez: Reconoce la página inmediatamente. No esperes a "investigar primero". Reconócelo. Esto detiene la cadena de escalación y señala a tu equipo que alguien se está ocupando de ello. He visto demasiados incidentes donde se pagó a varias personas porque el primer respondedor quería "solo echar un vistazo rápido" antes de reconocer. Esos 30 segundos de investigación te costaron respondedores de respaldo que podrían haber estado durmiendo. Abrir tu tablero de respuesta a incidentes. No la aplicación. No los registros. Tu tablero. El que te muestra la salud del sistema de un vistazo. Para mí, es un tablero de Grafana personalizado que muestra tasas de error, percentiles de latencia, grupos de conexión de bases de datos, profundidades de cola y CPU/memoria a través de todos los servicios críticos. Puedo ver el radio de explosión en menos de 5 segundos. Verifica si aún está ocurriendo. Esto suena obvio, pero me han pagado por problemas que se resolvieron 30 segundos antes de que sonara la alerta. Los sistemas de monitoreo tienen retraso. Los umbrales de alerta tienen ventanas de evaluación. A veces, el problema ya ha desaparecido, y necesitas saberlo antes de comenzar a revertir implementaciones o reiniciar servicios. Evalúa el impacto en los clientes. No impacto teórico, sino impacto real. ¿Cuántos usuarios están afectados ahora mismo? ¿Es el 100% del tráfico o el 5%? ¿Está aislado a una región, un segmento de clientes, una función? Esto determina la urgencia de tu respuesta y si necesitas despertar a más personas. En este incidente particular—el servicio de pago a las 2:17 AM—mi tablero me dijo todo lo que necesitaba saber en 8 segundos. Tasa de error: 94.7%. Solicitudes afectadas: 847 en los últimos 5 minutos. Distribución geográfica: global. Segmento de clientes: todos. Latencia de la API del proveedor de pagos: normal. Conexiones de base de datos: normales. El problema no estaba aguas arriba ni aguas abajo. Éramos nosotros. Ahí fue cuando supe que me esperaba una larga noche.

La Metodología de Depuración que Realmente Funciona Bajo Presión

Todos tienen una metodología de depuración cuando están tranquilos, con cafeína, y trabajando en un entorno de desarrollo a las 2 PM. Muy pocas personas tienen una metodología que se mantenga cuando estás medio dormido, el CEO está en el canal de incidentes, y cada segundo de inactividad está costando dinero real. Utilizo lo que llamo el enfoque "Radio de explosión a causa raíz". No es elegante, pero funciona cuando tu cerebro está funcionando al 60% de su capacidad. Comienza con el radio de explosión, no con la causa raíz. Esto es contraintuitivo. Cada instinto te dice que debes encontrar la causa raíz inmediatamente. Resiste ese instinto. Primero, comprende exactamente qué está roto y qué no. Mapea los límites del fallo. Esto sirve para dos propósitos: te previene de perseguir falsos positivos en sistemas saludables y a menudo apunta directamente a la causa raíz a través del proceso de eliminación. Para el incidente del servicio de pago, pasé 90 segundos mapeando el radio de explosión: - Iniciación de pago: fallando - Verificación de estado de pago: fallando - Webhooks de pago: fallando - Procesamiento de reembolsos: funcionando bien - Consultas de pago de administrador: funcionando bien Ese patrón me decía algo importante: las operaciones de lectura estaban bien, las operaciones de escritura estaban fallando. Ese es un problema de base de datos, un problema de cola o un problema de permisos. Tres posibilidades en lugar de treinta. Sigue el flujo de datos, no el flujo de código. Cuando estás depurando a las 2 AM, no tienes tiempo para rastrear a través del código. Sigue los datos. ¿Dónde entra una solicitud de pago al sistema? ¿A dónde va después? ¿Dónde falla? Abrí nuestro trazado distribuido (gracias a Dios que lo teníamos) y observé un solo request fluir a través del sistema. Pasó por autenticación, por limitación de velocidad, por validación, y murió en el momento en que intentó escribir en la base de datos. Base de datos. Ahí estaba. Verifica primero las cosas aburridas. Espacio en disco. Memoria. Grupos de conexión. Descriptores de archivo. Expiración de certificados. DNS. Las cosas aburridas destruyen más sistemas de producción de lo que lo harán los errores ingeniosos. Me han llamado a las 2 AM porque el trabajo cron de alguien llenó el disco. Me han llamado porque un certificado expiró. Me han llamado porque alguien cambió un TTL de DNS y no esperó la propagación. En este caso, el grupo de conexiones de base de datos estaba al 100%. Cada conexión estaba en uso. Pero, ¿por qué? El tráfico no había aumentado. Los patrones de consultas no habían cambiado. Algo estaba manteniendo las conexiones abiertas. Confía en tu monitoreo, pero verifica todo. Los sistemas de monitoreo mienten. No maliciosamente; son solo software, y el software tiene errores. He visto sistemas de monitoreo reportar servicios saludables que estaban completamente caídos. Los he visto reportar errores que no existían. Siempre verifica manualmente el camino crítico. Para sistemas de pago, mantengo una tarjeta de crédito de prueba y un comando curl listos. Puedo validar todo el flujo de pago en 10 segundos. Ejecuté mi pago de prueba. Se colgó durante 30 segundos y luego expiró. El monitoreo no mentía. Realmente estábamos caídos.

El Incidente Que Me Enseñó Todo Sobre Conexiones de Base de Datos

Déjame contarte sobre la página número 312. Eran 3:47 AM un martes de marzo, y cambió cómo pienso sobre la gestión de conexiones de base de datos para siempre. Estábamos ejecutando una venta flash. El tráfico era alto pero no sin precedentes; habíamos manejado picos más grandes. Entonces, de repente, cada servicio que tocaba la base de datos comenzó a expirar. Grupo de conexiones agotado. Síntomas clásicos. La respuesta obvia: aumentar el tamaño del grupo de conexiones. Así que lo hicimos. Lo duplicamos. Luego lo triplicamos. El problema empeoró. Ahí fue cuando aprendí que a veces la solución agrava el problema. Cada conexión que añadimos al grupo era otra conexión tratando de ejecutar una consulta en una base de datos que ya estaba sobrecargada. Nos estábamos DDoSando a nosotros mismos. ¿El problema real? Un desarrollador había añadido una nueva función que realizaba un escaneo completo en una tabla con 50 millones de filas. Sin índice. La consulta tardó 45 segundos en completarse. Cada solicitud que tocaba ese camino de código mantenía una conexión de base de datos durante 45 segundos. Con suficiente tráfico, agotamos el grupo de conexiones no porque no tuviéramos suficientes conexiones, sino porque cada conexión estaba atrapada esperando que esa consulta terrible terminara. La solución no era más conexiones. Era matar esa consulta, añadir un índice e implementar tiempos de espera de consulta a nivel de aplicación. Ese incidente me enseñó tres cosas: El agotamiento del grupo de conexiones es un síntoma, no una enfermedad. Cuando lo veas, no escales inmediatamente el grupo. Pregunta por qué las conexiones no se están liberando. ¿Son lentas las consultas? ¿Hay bloqueos? ¿Algo está manteniendo transacciones abiertas? El grupo de conexiones te está diciendo que hay un problema en otro lugar. Los tiempos de espera de consulta deberían estar en todas partes. Cada consulta de base de datos debería tener un tiempo de espera. Cada solicitud HTTP debería tener un tiempo de espera. Cada operación de cola debería tener un tiempo de espera. Los tiempos de espera no son opcionales. Son la diferencia entre un servicio degradado y un servicio completamente muerto. Cuando algo sale mal, los tiempos de espera te permiten fallar rápido en lugar de acumular conexiones bloqueadas hasta que todo el sistema colapse. Monitorear la utilización del grupo de conexiones no es suficiente. Necesitas monitorear la duración de las conexiones. ¿Cuánto tiempo se mantiene la conexión promedio? ¿Cuál es el P99? Si la duración promedio de la conexión salta de 50ms a 5 segundos, tienes un problema incluso si tu grupo aún no se ha agotado. Ese es tu sistema de alerta temprana. Regresando al incidente del servicio de pago a las 2:17 AM. Verifiqué la duración de la conexión. Promedio: 8 segundos. P99: