Por qué una comprobación de estado 200 OK puede ocultar una caída total del servicio

Un servicio de comercio electrónico autoalojado pareció estar completamente operativo para su sistema de monitoreo durante toda una noche, devolviendo códigos de estado exitosos cada cinco minutos. En realidad, el túnel de origen del backend había dejado de funcionar horas antes, lo que causó que cada presentación de comprador fallara mientras la página frontend permanecía accesible a través de la caché.

Qué sucedió

El incidente comenzó cuando el túnel de origen que conectaba el borde de la red de distribución de contenido (CDN) con el servidor backend dejó de responder. A pesar de esta falla crítica, la comprobación de salud automatizada continuó informando que el servicio estaba sano. La comprobación realizaba una simple solicitud GET a la página orientada al comprador, que la CDN servía desde su caché utilizando la última versión conocida buena del HTML. Esto resultó en un código de estado 200 OK, señalando al sistema de monitoreo que todo funcionaba correctamente.

Mientras tanto, los usuarios reales que intentaban realizar compras experimentaron un colapso completo. Sus navegadores enviaban solicitudes POST con datos de formulario para presentar pedidos. A diferencia de la página HTML estática, estas llamadas API dinámicas no podían ser servidas desde la caché de la CDN. Fueron dirigidas directamente al túnel de origen, que estaba muerto. El nodo de borde devolvió una página de error 1033 para estas solicitudes, pero como nadie estaba observando activamente los registros de errores orientados al usuario, la falla pasó desapercibida para el equipo de operaciones. Cinco presentaciones reales de tres redes diferentes fallaron durante esta ventana, sin embargo, no se dispararon alertas.

Esta situación surgió de una corrección anterior destinada a resolver un problema diferente. Un incidente previo había involucrado una ruta estática que el borde respondía independientemente del origen, llevando a falsos positivos. El equipo corrigió esto apuntando la comprobación de salud a la página de compra, que sí depende del origen. Sin embargo, mantuvieron el método GET para la comprobación. Aunque la ruta era correcta, el método no lo era, ya que una GET en caché no verifica la vitalidad de la lógica de procesamiento del backend.

Detalles clave

• La comprobación de salud se ejecutaba cada cinco minutos y recibía consistentemente una respuesta 200 OK de la caché de la CDN.
• El túnel de origen estuvo caído durante varias horas, causando que todas las solicitudes POST de los compradores fallaran con un error 1033.
• Cinco intentos reales de compra fallaron en tres redes separadas sin disparar ninguna alerta operativa.
• La corrección anterior cambió el objetivo de la comprobación de salud a la página de compra, pero incorrectamente la mantuvo como una solicitud GET.
• Una solicitud POST a un endpoint JSON-RPC habría forzado al origen a responder, revelando la caída inmediatamente.
• La resolución final solo requirió un cambio de una línea para cambiar el método de la comprobación de salud de GET a POST.

Contexto

Para entender este fallo, es útil distinguir cómo manejan las CDNs diferentes métodos HTTP. Una solicitud GET recupera datos y suele ser almacenable en caché. Las CDNs almacenan copias de estas respuestas en ubicaciones de borde cercanas a los usuarios para reducir la latencia y la carga sobre el servidor de origen. Si el origen cae, la CDN puede continuar sirviendo estas copias en caché, haciendo que el sitio parezca activo incluso cuando el backend es inalcanzable. Esto es útil para leer contenido, pero engañoso para verificar la salud del sistema.

En contraste, las solicitudes POST se utilizan para enviar datos al servidor, como presentar un formulario o crear un registro. Estas solicitudes generalmente no se almacenan en caché porque cambian el estado de la aplicación. Cuando llega una solicitud POST, la CDN debe reenviarla al servidor de origen para su procesamiento. Si el origen está caído, la solicitud falla inmediatamente. Por lo tanto, una comprobación de salud que usa GET puede solo verificar la disponibilidad de la caché, mientras que una comprobación POST verifica la disponibilidad de la lógica real de la aplicación y la conectividad de la base de datos.

Por qué importa

Para equipos que ejecutan su propio software, este incidente destaca una trampa común en la observabilidad: medir la cosa equivocada. Un código de estado es evidencia sobre una solicitud específica, no sobre el servicio entero. Si tu comprobación de salud no imita la ruta crítica de tus usuarios, proporciona una falsa sensación de seguridad. En este caso, la comprobación midió la resiliencia de la caché de la CDN en lugar de la salud del backend de la aplicación. Esta distinción es crucial para quienes alojan sus propios servicios y dependen del monitoreo automatizado para detectar caídas antes que los clientes.

El costo de esta mala configuración fue significativo en términos de pérdida de confianza e ingresos. Como el sistema de monitoreo reportó éxito, ningún ingeniero fue alertado y el problema persistió durante horas. El silencio de los registros era engañoso; los registros de la CDN mostraban respuestas 200 exitosas, enmascarando los errores 1033 que ocurrían en las rutas no almacenadas en caché. Esto demuestra que el registro exhaustivo y las alertas deben tener en cuenta la diferencia entre el éxito a nivel de borde y la funcionalidad a nivel de origen. Sin alinear las comprobaciones de salud con el comportamiento del usuario, los equipos corren el riesgo de perder fallos silenciosos que solo se hacen aparentes cuando los clientes se quejan.

Qué puedes hacer

• Audita tus comprobaciones de salud para asegurarte de que usen el mismo método HTTP y ruta que tus acciones de usuario más críticas.
• Reemplaza las simples comprobaciones GET en páginas en caché con solicitudes POST a endpoints dinámicos que requieran procesamiento de origen.
• Valida que tu comprobación de salud espere contenido específico en el cuerpo de la respuesta, no solo un código de estado 200.
• Prueba tu monitoreo derribando deliberadamente el servidor de origen para ver si la comprobación de salud reporta correctamente un fallo.
• Implementa comprobaciones separadas para la disponibilidad de la CDN y la salud del origen para distinguir entre problemas de caché de borde y del backend.
• Revisa los registros tanto para tipos de solicitud exitosos como fallidos para asegurar que tus alertas cubran interacciones dinámicas no almacenadas en caché.