Monitoring i status

Presque toutes les pages de statut sur lesquelles vous tombez affichent de beaux chiffres. 100 pour cent d'uptime, tout en vert, pas une éraflure. Le problème est que ces chiffres ne signifient le plus souvent pas "tout a fonctionné", mais "personne ne regardait". L'absence de données est comptée comme un succès, et le client reçoit une jolie image sans correspondance avec la réalité.

Nous avons construit un monitoring qui fait quelque chose de plus difficile qu'un joli graphique : il dit la vérité, même quand la vérité est gênante. Quand nous ne savons pas comment un service s'est comporté, le résultat doit être "je ne sais pas", et non "tout va bien". À cela s'ajoutent une page de statut publique avec un historique honnête et une gestion des incidents menée là où l'équipe se trouve déjà. Cette étude de cas parle de comment calculer la disponibilité sans se tromper soi-même.

Le mécanisme du mensonge typique d'une page de statut est banal. Si sur une période donnée la sonde n'a collecté aucun échantillon et que malgré tout vous comptez cette période comme saine, votre uptime aura toujours l'air excellent. Moins vous regardez souvent, mieux vous vous en sortez, ce qui est absurde : un outil censé surveiller la disponibilité vous récompense de ne pas surveiller.

L'effet est commode et faux. Un graphique vert rassure l'équipe et le client, alors qu'en dessous il aurait pu y avoir une heure dont personne ne sait rien. Nous voulions exactement l'attitude inverse : "je ne sais pas" doit signifier "je ne sais pas", et non être discrètement arrondi vers "tout fonctionne".

Toute l'honnêteté de ce monitoring vient d'une seule décision : un échantillon a trois états possibles et non deux. Pas seulement "up" et "down", mais aussi "unknown" pour le temps où il n'y a tout simplement pas eu d'observation. Cette distinction est le cœur de tout le reste.

Dans la disponibilité n'entrent que les échantillons réellement collectés, c'est-à-dire les "up" et les "down". Les états "unknown" sont mis de côté, car il ne faut pas les feindre dans un sens ou dans l'autre. S'il n'y a eu aucune observation sur une période, le résultat n'est pas 100 pour cent et n'est pas zéro. Le résultat est vide, et c'est exactement ainsi que la page de statut l'affiche.

Un piège à part, ce sont les arrêts planifiés. Il est tentant de compter une fenêtre de maintenance comme du temps sain, parce qu'après tout "c'était une pause planifiée, pas une panne". Sauf qu'alors le graphique ment de nouveau, juste plus subtilement : il fait semblant que le service tournait alors qu'il était délibérément absent.

Nous avons pris un juste milieu qui est honnête dans les deux sens. Les fenêtres de maintenance sont marquées à part et ne comptent pas comme du temps d'arrêt, car ce n'est pas une panne. Mais elles ne font pas non plus semblant que tout tournait pendant ce temps. Sur le graphique on voit une interruption marquée comme maintenance, et non un fond vert artificiel. C'est le même principe qui gouverne tout le projet : nous n'arrondissons pas en notre faveur.

Un monitoring qui ne fait que compter, c'est la moitié du travail. L'autre moitié commence au moment où quelque chose tombe vraiment en panne. Ici, l'erreur classique est commise : la gestion de l'incident est poussée dans un outil séparé dans lequel personne ne veut se connecter au milieu de l'incendie. Nous sommes allés là où l'équipe se trouve déjà, c'est-à-dire sur Discord.

Le flux est court et n'exige aucun changement de contexte. Un changement d'état d'un service déclenche une notification. Un incident s'ouvre et se met à jour directement depuis le canal, sans se connecter à un autre panneau. La page de statut publique montre aux clients le déroulement et la clôture, clairement et sans enjoliver, aussi honnêtement que les chiffres d'uptime.

Le chiffre sur la page signifie exactement ce qu'il dit. Quand il indique 99.5 pour cent, ce sont 99.5 pour cent d'observations réelles, et non un artefact du fait que la sonde a dormi une demi-journée. Le client regarde la page de statut et voit un historique honnête : disponibilité, temps d'arrêt et fenêtres de maintenance séparés, et non un vert éternel qui ne signifie rien.

Quand quelque chose tombe en panne, l'équipe mène l'incident depuis l'endroit où elle est déjà, sans se connecter à un autre outil au pire moment possible. Le tout tient à un seul principe qui a l'air modeste et qui est rare : un monitoring auquel on peut se fier, parce qu'il admet ce qu'il ne sait pas au lieu de peindre les trous en vert.