Preguntarle a un servicio si está bien no sirve de nada

El túnel que conecta el servidor de un cliente con su portal estuvo caído dos días. Nadie lo vio. No porque nadie mirara: porque todo lo que se miraba contestaba bien.

Lo que decía el servidor#

Name            Status   StartType
----            ------   ---------
Cloudflared     Stopped  Automatic
TrevaiConector  Running  Automatic

Automático significa que arranca solo cuando el servidor arranca. Y no arrancó. El otro servicio, instalado con un supervisor que lo reintenta, sí volvió. Éste, registrado directo, se quedó tirado — y Windows no considera eso una falla: el servicio no falló, simplemente no está corriendo.

La misma semana había pasado lo mismo en otro cliente. Y un mes antes, otra vez. Tres veces el mismo patrón, en dos servidores distintos, con el mismo resultado: el servicio dice lo que debería ser, no lo que es.

Lo que decía el chequeo de salud#

Un mes antes, con otro servicio, aprendimos la versión más traicionera de esto.

GET /health          200 OK    0.33 s
POST /api/query      ---       45 s, sin respuesta

El health check contestaba 200 en un tercio de segundo. Toda consulta real moría a los 45. El servicio estaba vivo en el sentido más inútil de la palabra: el proceso existía, aceptaba conexiones, y no podía hacer nada de lo que existía para hacer.

Un monitor que pregunta «¿estás bien?» recibe «sí» de un servicio que no puede trabajar. Y lo pone en verde.

La regla que sale de las dos#

No preguntarle a un servicio si está bien. Pedirle que haga su trabajo.

Para el túnel, no es ¿está corriendo? sino ¿ha estado corriendo desde el último arranque del servidor? — porque la falla no es que se caiga, es que no vuelve.

Para el conector, no es ¿contesta el health? sino ¿contesta una consulta real, y en cuánto? — y esa consulta la cronometramos.

Para la base de datos, no es ¿está el servicio arriba? sino ¿cuándo fue la última vez que se escribió el archivo? — un motor arriba con la base sin escribirse en horas hábiles es un sistema detenido que nadie ha reportado todavía.

Y el respaldo, que es donde más duele#

PLANTA_20260908_2340.fbk      51.2 MB   08-sep 23:40
PLANTA_20260907_2340.fbk      51.2 MB   07-sep 23:40

«¿Existe el respaldo de anoche?» es la pregunta equivocada. Un respaldo de cero bytes existe y tiene fecha de hoy. Lo que hay que preguntar es cuánto pesa, cuánto pesaba ayer, y si eso tiene sentido para una empresa que operó ese día.

Y una trampa que descubrimos al medirlo: se respaldan cinco bases en cinco archivos. Comparar «el más nuevo contra el anterior» compara bases distintas. Cada una se compara contra la suya, y se reporta la más atrasada — porque si una deja de respaldarse, las otras cuatro la esconden.

Lo que hicimos#

1. Recuperación automática en los servicios que no volvían. Reinicio a los 5, 30 y 60 segundos, y arranque retrasado para que la red ya esté lista cuando lo intenten. Dos comandos por servicio. Cierra el patrón que ya había pasado tres veces.

2. Una sonda que se para adentro y mide trabajo, no estado. Cada quince minutos manda hacia afuera lo que midió: servicios desde el último arranque, la base por su última escritura, el respaldo por su peso. El servidor habla; nadie le pregunta.

3. Y si la sonda deja de hablar, ese silencio es la alarma. No hay nada que preguntarle a un servidor que no manda su parte: la ausencia ya es el dato.

Lo que queda como regla#

Lo que se ve desde afuera es la puerta, no la casa. Un servicio que contesta es un servicio que contesta. Nada más.

«Automático» no es «arrancó». Es una intención. Hay que medir si se cumplió.

Y lo que no se pueda medir se reporta como no medible, con nombre. Un hueco declarado es información. Un verde sin evidencia es un tablero que miente.

Casos reales de dos empresas mexicanas, una manufacturera y un distribuidor industrial. Se omitieron nombres y todo dato que permita identificarlas. Los nombres de servicio y archivo son la evidencia y no identifican a nadie fuera de ellas.