Cet article raconte une erreur qui est entièrement la mienne. Elle porte sur l’outil de supervision que nous avons écrit et que nous utilisons pour surveiller les sites de nos clients. Pendant plusieurs jours, il a produit des alertes fausses, et je les ai lues sans les mettre en doute.
Le matin en question
J’ouvre ma boîte, et j’ai quarante-sept alertes. Des mises en page cassées, des sites dégradés, des rétablissements. Sur des sites qui, quelques heures plus tôt, allaient très bien.
Plutôt que de régler un seuil au hasard, je décide de faire ce que j’aurais dû faire trois jours plus tôt : ouvrir chaque site concerné, dans un navigateur, et regarder. Quarante-sept sites, un par un.
Quarante-trois n’avaient absolument rien. Mise en page intacte, pages complètes, boutons en place. Quatre alertes seulement correspondaient à quelque chose de réel, et deux d’entre elles étaient déjà réglées.
Ce que j’ai cherché, et ce que ce n’était pas
Ma première hypothèse était mauvaise : je pensais que le seuil de détection de mise en page était trop sensible, et j’ai commencé à chercher de quel pourcentage le remonter. C’est le réflexe le plus courant, et c’est presque toujours le mauvais : il fait disparaître le symptôme et laisse la cause en place.
Ce qui m’a mis sur la piste, c’est une remarque de bon sens que je me suis faite en regardant la liste : tous ces sites vivent sur deux serveurs seulement. Ce n’était donc pas quarante-trois problèmes, c’était deux.
La vraie cause, et elle vient de nous
Pour vérifier qu’une page s’affiche correctement, notre moteur ne se contente pas de demander la page. Il demande aussi tous les fichiers qu’elle réclame : les feuilles de style, les scripts, les polices. C’est précisément ce qui lui permet de voir une mise en page cassée là où les autres outils voient du vert.
Sauf que sur une page riche, cela représente plusieurs dizaines de requêtes, et que plusieurs sites du même serveur étaient vérifiés dans la même minute. Le serveur, très raisonnablement, a fini par répondre « trop de requêtes » sur une partie des fichiers.
Et notre moteur lisait cette réponse comme un fichier disparu.
Il annonçait donc une mise en page cassée, avec une belle preuve à l’appui, sur des sites parfaitement intacts. Le coupable, c’était notre propre débit. Je passais mes matinées à traiter des alertes que je fabriquais moi-même.
Le défaut d’à côté, encore plus gênant
En vérifiant les courriels de près, j’ai trouvé autre chose. Certains messages contenaient encore leurs marqueurs de gabarit non remplacés : au lieu de la durée réelle ou du code d’erreur, le courriel affichait le nom de la variable. Depuis le début.
Personne ne me l’avait signalé, moi compris, parce que le titre du message suffisait à comprendre de quel site il s’agissait et qu’on ne lisait plus le corps. C’est exactement le signe qu’un outil est en train de devenir du bruit : on ne lit plus que l’objet.
Et pendant que je corrigeais tout ça, je me suis envoyé deux fausses alertes de plus, en lançant les tests de l’outil sur sa configuration réelle. Une suite de tests qui envoie de véritables courriels d’alerte, c’est une faute de conception de ma part, et elle a maintenant son garde-fou dans le code.
Les quatre corrections
Un problème d’apparence ne peut plus être annoncé comme une panne. Ce n’est pas un réglage, c’est une règle du code : les causes qui touchent l’apparence d’une page, mise en page dégradée, lenteur, indexation, sont plafonnées à « dégradé » et ne peuvent pas franchir le niveau « hors service ». Un site qui répond mais s’affiche mal mérite une remarque dans l’outil, pas un réveil à trois heures du matin.
Une réponse « trop de requêtes » n’est plus lue comme un fichier absent. Le moteur la compte à part, comme ce qu’elle est : un signe qu’il interroge trop vite, pas un signe que le fichier a disparu.
Les pannes qui partagent une adresse IP deviennent une seule alerte. Un serveur qui tombe avec quarante sites dessus produit un courriel, pas quarante. C’est ce qui décide si une boîte mail reste lisible.
Chaque règle de décision a désormais sa propre suite de tests. Pas des tests globaux qui vérifient que l’outil démarre, mais un jeu de contrôles par règle, qui vérifie ce qu’elle doit refuser autant que ce qu’elle doit signaler. Au moment où j’écris, l’ensemble représente 1 720 contrôles automatisés, tous rejoués avant chaque livraison.
Le résultat mesuré
Sur les vingt-quatre heures qui ont suivi la mise en service des corrections, sur le même parc de sites : zéro courriel pour un problème d’apparence, contre trente-deux la veille. Et aucune panne réelle manquée sur la période, ce qui est l’autre moitié de la vérification, celle qu’on oublie de faire quand on est content d’avoir fait taire le bruit.
La leçon, et elle est inconfortable
J’ai passé trois jours à traiter des alertes en supposant qu’elles disaient vrai. La leçon que j’en tire tient en une phrase que j’ai écrite dans notre documentation interne : l’instrument mentait avant le sujet.
Quand un outil de mesure produit une masse de résultats inhabituelle, la première hypothèse à tester n’est pas que le monde a changé. C’est que l’instrument s’est déréglé. Cette hypothèse est désagréable parce qu’elle met en cause son propre travail, ce qui explique probablement qu’on la teste en dernier.
Le corollaire vaut aussi pour vous, si vous recevez des alertes de votre prestataire : une alerte qu’on n’a jamais vérifiée à la main ne prouve rien. Ni dans un sens, ni dans l’autre.
Pour aller plus loin
Le raisonnement général sur ce qu’une supervision devrait regarder est dans votre site répond, et il est cassé quand même. La liste concrète est dans sept pannes qu’un test de disponibilité ne voit pas.
L’outil dont il est question ici s’appelle UptimeEZ, et son code est public : les quatre corrections décrites plus haut sont lisibles, avec les tests qui les vérifient. Si vous voulez voir ce qu’il dit de votre site, écrivez-nous.