La disponibilidad no es una pregunta de sí o no

Un lector nos preguntó por qué marcábamos como inaccesible un servidor que en su navegador abría sin problemas. Él tenía razón y nosotros también. El servidor responde la mayoría de las veces — y el resto corta la conexión.

Un servidor, dos verdades

Le enviamos veinticinco peticiones. Alrededor de un tercio volvió así:

curl: (56) Recv failure: Connection reset by peer

No es un timeout. No es un problema de TLS. La conexión se abre, la petición sale y el servidor cuelga a mitad de respuesta. Separar las peticiones tres segundos no cambió nada, así que tampoco es limitación de tasa. Nuestras propias mediciones coinciden: el 31% de los sondeos a ese host fallan.

Por qué una sola comprobación miente

Si un servidor falla una petición de cada tres, comprobarlo una vez no te dice casi nada. Dos de cada tres veces lo llamarás sano y la tercera roto — y ambas respuestas son igual de erróneas, porque la verdad es un porcentaje, no un estado.

Con las alertas es peor. Dos fallos seguidos parecen una caída. Con una tasa de fallo del 31%, dos seguidos ocurren alrededor del 9% de las veces: aproximadamente una vez al día si compruebas cada dos horas. Eso no es una caída. Es aritmética.

¿Cómo de común es esto?

Rastreamos el catálogo buscando servidores que no están ni fiablemente operativos ni fiablemente caídos. Unos 180 ocupan ese punto medio inestable, fallando entre el 10% y el 90% de las veces. Es una porción pequeña del ecosistema — y una porción grande de la confusión.

Qué hacer con ello

• Si eliges un servidor: lee el porcentaje, no la insignia. Uno al 70% fallará en producción, en silencio, una llamada de cada tres.
• Si operas un servidor: los reinicios intermitentes de conexión suelen apuntar al proxy o balanceador que hay delante, no a la aplicación. Los registros de la aplicación se verán limpios.
• Si construyes monitorización: nunca decidas con una sola muestra. Exige una racha y di la tasa en voz alta.