Quand le veilleur meurt : pourquoi le silence n'est pas une bonne nouvelle

Vous avez configuré les alertes. Des semaines ont passé et pas un seul courriel n'est arrivé.

Il y a deux explications. Soit rien ne s'est réellement produit, soit le système d'alerte a cessé de fonctionner et vous l'ignorez. Vues de l'extérieur, les deux se ressemblent trait pour trait.

Et l'esprit humain a tendance à lire le silence comme une bonne nouvelle. C'est précisément pour cela que ce type de panne survit des mois sans être remarqué.

Ce n'est pas le même problème qu'un contrôle devenu muet

Ailleurs dans ce wiki nous avons écrit : quand un contrôle ne peut pas lire ses données, il ne doit pas se taire, il doit dire qu'il n'a pas pu lire.

Ce que nous décrivons ici se situe un cran au-dessus. Là, un contrôle à l'intérieur d'un veilleur en marche se taisait. Ici le veilleur lui-même a disparu. Il ne reste personne pour parler, donc personne non plus pour dire « je n'ai pas pu lire ».

Comment un veilleur meurt en silence

Le service s'arrête. Une mise à jour, un plantage, un manque de mémoire. Ce qui devrait vous prévenir est justement ce qui s'est arrêté.

Le chemin du courrier casse. Un mot de passe change, un fournisseur bloque, l'adresse rebondit. Le veilleur continue de travailler, écrit ses messages, et aucun ne vous parvient. C'est le cas le plus trompeur, car du côté serveur tout paraît sain.

Quelqu'un désactive et oublie. Les notifications sont coupées le temps d'enquêter sur un problème. Le problème est résolu. Les notifications restent coupées.

La machine s'éteint. Le cas extrême : rien n'est cassé, tout est simplement silencieux.

Les quatre ont ceci en commun : aucun ne produit de message. Et si votre façon de repérer une panne est de recevoir un message, alors les pannes sans message vous sont invisibles.

La solution a une autre forme : pas une alarme, un battement de cœur

Il faut inverser le sens.

Une alarme dit : parle quand quelque chose ne va pas. Un battement de cœur dit : dis « je suis vivant » à intervalles réguliers même quand rien ne se passe. Puis que quelqu'un remarque quand ce dire s'arrête.

La différence compte. Une alarme est un message à propos d'un problème ; un battement de cœur est un message à propos du messager lui-même. Ils répondent à des questions différentes et aucun ne remplace l'autre.

Dès qu'il y a un battement, le sens du silence change. Le silence porte désormais une information : quelque chose qui devrait parler ne parle pas.

Celui qui remarque doit être à l'extérieur de la machine surveillée

C'est la partie sur laquelle il faut s'arrêter. Une machine ne peut pas annoncer sa propre mort.

L'endroit qui juge le battement doit être à l'extérieur du serveur surveillé : une autre machine, un téléphone, un point externe. Un contrôle qui tourne dans le serveur s'éteint avec lui et ne dit rien à personne.

Même la version maison la plus simple suffit : que le serveur laisse une marque quelque part toutes les heures, et regardez l'âge de cette marque. Aucune installation compliquée n'est nécessaire ; la seule chose nécessaire est que le jugement se fasse ailleurs.

Le battement a son propre piège

Il y a ici une erreur de conception subtile, et la plupart des installations y tombent : rattacher le battement au calendrier de quelque chose que l'utilisateur peut désactiver.

Disons qu'il partage sa cadence avec le résumé quotidien. L'utilisateur désactive le résumé, qu'il trouvait excessif. Le battement s'arrête avec lui. La partie externe voit le signal cesser et déclenche une alerte « aucune nouvelle de votre serveur » alors que rien du tout ne se passe.

Vous devinez la suite : l'utilisateur s'inquiète une fois pour rien, et la deuxième fois il coupe l'alerte. Une fausse alerte produite par votre propre mécanisme de sécurité détruit la confiance en ce mécanisme plus vite que de ne pas en avoir du tout.

La règle : le battement doit avoir son propre calendrier, et ne reposer sur rien de désactivable.

La même forme, ailleurs

Dans l'article sur les tâches de sauvegarde de ce wiki nous avons écrit : ne regardez pas l'état de la tâche, regardez l'âge de la sauvegarde la plus récente.

La même forme réapparaît ici : ne demandez pas au système d'alerte s'il fonctionne, regardez l'âge du dernier signal. Un état est une affirmation, un âge est une mesure.

Et enfin, la seule chose à faire le jour de l'installation : provoquez volontairement une panne et regardez le courriel arriver. Une alerte non testée n'est pas un mécanisme, c'est un espoir.

Ce que fait Atlas

Atlas Watch envoie un résumé quotidien, signale les situations critiques immédiatement sans attendre le résumé, et à côté de cela émet un signal horaire « je suis vivant ».

Ce qui mérite d'être raconté, c'est à quoi ce signal n'est pas rattaché.

Le signal ne repose ni sur le calendrier du résumé quotidien ni sur celui de l'alarme. Ces deux-là ont leurs propres réglages et l'utilisateur peut désactiver l'un ou l'autre. Si le signal en dépendait, dès que l'utilisateur désactive le résumé le signal s'arrêterait aussi, et l'autre bout dirait « aucune nouvelle de ce serveur » alors que rien ne se passe. C'est pourquoi le signal a son propre calendrier.

Le deuxième détail suit la même logique : tant que le réglage de notification est désactivé, le fichier de calendrier du signal n'est pas écrit du tout. Il ne reste donc pas d'état intermédiaire « activé mais ne fonctionne pas » ; soit le signal existe, soit il n'existe pas.

Le chemin de notification lui-même est le vôtre : vous déclarez votre propre serveur de courrier, et le courriel part de votre serveur. Envoyer un signal à un point externe est un supplément facultatif, et le produit n'en dépend pas pour fonctionner.

La leçon générale : un mécanisme de sécurité ne doit pas s'appuyer sur les parties désactivables de ce qu'il protège. S'il le fait, il meurt en silence avec lui.