Cuando el vigilante muere: por qué el silencio no es buena noticia

Configuraste los avisos. Han pasado semanas y no ha llegado ni un solo correo.

Hay dos explicaciones. O realmente no ha pasado nada, o el sistema de avisos dejó de funcionar y tú no lo sabes. Desde fuera las dos se ven idénticas.

Y la mente humana tiende a leer el silencio como buena noticia. Justo por eso este tipo de avería vive meses sin que nadie la note.

Esto es un problema distinto al de un chequeo que se calla

En otra parte de esta wiki escribimos: cuando un chequeo no puede leer sus datos no debe callarse, debe decir que no pudo leer.

Lo que describimos aquí está un escalón por encima. Allí se callaba un chequeo dentro de un vigilante que funcionaba. Aquí el vigilante mismo ha desaparecido. No queda nadie que hable, así que tampoco nadie que diga "no pude leerlo".

Cómo muere un vigilante en silencio

El servicio se detiene. Una actualización, una caída, falta de memoria. Lo que te avisaría es justo lo que se detuvo.

Se rompe el camino del correo. Cambia una contraseña, un proveedor bloquea, la dirección rebota. El vigilante sigue trabajando, escribe sus mensajes, y ninguno te llega. Este es el más engañoso, porque del lado del servidor todo parece sano.

Alguien lo apaga y lo olvida. Se apagan las notificaciones temporalmente mientras se investiga algo. El problema se resuelve. Las notificaciones siguen apagadas.

La máquina se apaga. El caso extremo: no hay nada roto, simplemente todo está en silencio.

Los cuatro comparten algo: ninguno produce un mensaje. Y si tu forma de notar una avería es recibir un mensaje, entonces las averías que no producen mensajes te son invisibles.

La solución tiene otra forma: no una alarma, un latido

Hay que invertir el sentido.

Una alarma dice: habla cuando algo va mal. Un latido dice: di "estoy vivo" a intervalos regulares aunque no pase nada. Y luego que alguien note cuando ese decir se detiene.

La diferencia importa. Una alarma es un mensaje sobre un problema; un latido es un mensaje sobre el mensajero mismo. Responden preguntas distintas y ninguno sustituye al otro.

En cuanto hay un latido, el significado del silencio cambia. El silencio ahora lleva información: algo que debería hablar no está hablando.

Quien lo note debe estar fuera de la máquina vigilada

Esta es la parte en la que conviene detenerse. Una máquina no puede anunciar su propia muerte.

El lugar que juzga el latido tiene que estar fuera del servidor vigilado: otra máquina, un teléfono, un punto externo. Un chequeo que corre dentro del servidor se apaga con él y no le dice nada a nadie.

Basta con la versión casera más simple: que el servidor deje una marca en algún sitio cada hora, y tú mires la edad de esa marca. No hace falta un montaje complicado; lo único necesario es que el juicio ocurra en otro sitio.

El latido tiene su propia trampa

Aquí hay un error de diseño sutil, y la mayoría de los montajes cae en él: atar el latido al calendario de algo que el usuario puede apagar.

Digamos que comparte la temporización con el resumen diario. El usuario apaga el resumen, porque le parecía demasiado. El latido se corta con él. La parte externa ve el señal detenerse y lanza una alerta de "sin noticias de tu servidor" mientras no está pasando absolutamente nada.

Puedes adivinar el resultado: el usuario se asusta una vez para nada y la segunda vez apaga la alerta. Una falsa alarma producida por tu propio mecanismo de seguridad destruye la confianza en ese mecanismo más rápido que no tener ninguno.

La regla: el latido debe tener su propio calendario, sin apoyarse en nada que se pueda apagar.

La misma forma, en otro sitio

En el artículo sobre trabajos de copia de esta wiki escribimos: no mires el estado del trabajo, mira la edad de la copia más reciente.

La misma forma reaparece aquí: no le preguntes al sistema de avisos si funciona, mira la edad de la última señal. Un estado es una afirmación, una edad es una medida.

Y por último, lo único que hay que hacer el día de la instalación: provoca una avería a propósito y mira llegar el correo. Una alarma sin probar no es un mecanismo, es una esperanza.

Qué hace Atlas

Atlas Watch envía un resumen diario, avisa de las situaciones críticas de inmediato sin esperar al resumen, y junto a eso emite una señal horaria de "estoy vivo".

Lo que merece contarse es a qué no está atada esa señal.

La señal no se apoya ni en el calendario del resumen diario ni en el de la alarma. Ambos tienen sus propios ajustes y el usuario puede apagar cualquiera de los dos. Si la señal dependiera de ellos, en el momento en que el usuario apagase el resumen la señal se cortaría también, y el otro extremo diría "sin noticias de este servidor" aunque no pase nada. Por eso la señal tiene su propio calendario.

El segundo detalle sigue el mismo razonamiento: mientras el ajuste de notificación está apagado, el archivo de temporización de la señal no se escribe en absoluto. Así no queda un estado intermedio de "encendido pero no funciona"; o la señal existe o no existe.

El camino de notificación es tuyo: defines tu propio servidor de correo, y el correo sale de tu servidor. Enviar una señal a un punto externo es un añadido opcional, y el producto no depende de él para funcionar.

La lección general: un mecanismo de seguridad no debe apoyarse en las partes apagables de lo que protege. Si lo hace, muere en silencio junto con ello.