Saber antes de que el cliente llame

Viernes, 16:40. Un cliente escribe que su aplicación va «lenta desde esta mañana». Abre el panel: todo está en verde. El procesador no pasa del 30 %, la memoria es estable, la sonda de disponibilidad responde 200 desde hace tres semanas sin interrupción. No ha visto nada y, sin embargo, el cliente tiene razón. Una hora después descubre que el 4 % de las peticiones tardan más de diez segundos, todas en el mismo punto de entrada, todas de clientes cuya cuenta contiene más de diez mil filas. Ninguna de sus sondas podía verlo: comprobaban que el servicio respondía, no que respondiera correctamente a todo el mundo.

Este desfase no es un defecto de herramientas, sino de método. Una sonda verifica una hipótesis que usted ha formulado de antemano: «¿está vivo el proceso?», «¿está lleno el disco?». Es excelente para las averías que ya ha vivido y ciega para todas las demás. Ahora bien, en producción, los incidentes que salen caros son casi siempre los que nadie había anticipado: una dependencia que se ralentiza sin caerse, una caché que se vacía, una consulta SQL cuyo plan de ejecución cambia tras una actualización de versión. La pregunta útil no es, por tanto, «¿tengo suficientes sondas?», sino «cuando llega un incidente inédito, ¿me permiten mis datos entender qué pasa sin desplegar código?». Eso es exactamente lo que designa la palabra observabilidad, y es un criterio medible, no un eslogan de proveedor.