Les pages de statut publiques

Une page de statut publique (status page) est une page sur le service, publiée pour des gens qui n'ont pas de compte : vos clients, vos visiteurs, quiconque en détient l'adresse. Elle vit sur le même serveur Webmonit, à une adresse de la forme /status/quelquechose, et elle s'ouvre sans connexion.

Elle existe pour répondre à une seule question, posée par quelqu'un qui n'ira pas enquêter : est-ce que ça vient de moi, ou est-ce que ça vient d'eux ?

Ce qu'on y trouve#

En haut, un bandeau qui donne la réponse en une ligne — All systems operational (tout fonctionne), Some systems are degraded (certains services sont dégradés), Some systems are down (certains services sont en panne), ou Maintenance in progress (maintenance en cours) — avec l'heure du calcul et la fréquence à laquelle la page se rafraîchit d'elle-même.

En dessous, les composants : des catégories nommées par l'administrateur, chacune tenant quelques lignes. Une ligne est une chose dont un visiteur peut se soucier, portant l'intitulé que l'administrateur lui a donné — « Hébergement web », « Messagerie », « Serveurs de noms » — et jamais le nom d'une machine, sauf si l'administrateur a choisi d'en écrire un. Chaque ligne porte un mot (Operational, Degraded, Down, Maintenance, Not served here, No data), une bande de petites barres, et un chiffre de disponibilité.

Les barres sont le passé récent, une barre par heure ou par jour selon la profondeur réglée par l'administrateur — vingt-quatre heures par défaut. Les barres vertes sont des heures ou des jours sans rien de travers ; les oranges et les rouges ne le sont pas. Le chiffre à côté est la part des mesures qui n'ont pas trouvé la chose en panne, sur la période mesurée, et la page dit de quelle période il s'agit.

Une ligne qui représente plusieurs machines faisant le même travail ne passe pas au rouge parce que l'une d'elles est tombée. Elle affiche Partial — 2 of 3 operational (partiel — 2 sur 3 opérationnelles), ce qui est la vérité : le service tient, avec moins derrière lui. Les lignes restent repliées tant que tout va bien dessous et s'ouvrent d'elles-mêmes dès que quelque chose ne va pas, de sorte qu'un visiteur n'a jamais à cliquer pour trouver ce qui est cassé.

Là où l'administrateur l'a demandé, une ligne peut porter un petit graphique des 24 dernières heures : le temps de réponse typique des sites, l'aller-retour réseau vers les machines, ou le nombre de requêtes DNS répondues par seconde.

Ensuite, si des maintenances sont déclarées, celles qui sont annoncées — en cours d'abord, puis celles prévues dans les quinze jours à venir par défaut — chacune avec le titre et la note écrits par l'administrateur.

Et en bas, les incidents : les quatre-vingt-dix derniers jours par défaut, chacun avec son statut (ongoing, en cours, ou resolved, résolu), la date d'ouverture, la durée, et les mots écrits pour le public. Quand il n'y en a aucun, la page écrit « No incident to report » — aucun incident à signaler — ce qui est tout l'intérêt d'en publier une.

Ce qu'elle ne montre jamais#

Une page de statut n'est pas une version réduite de l'interface. Ce qu'elle ne porte pas, elle ne le porte pas par construction.

Elle ne montre aucun chiffre concernant les cibles de quelqu'un d'autre. Elle ne montre rien de ce que font les machines à l'intérieur — leur charge, leurs disques, depuis combien de temps elles tournent : cela regarde l'administrateur et un visiteur ne pourrait rien en faire. Elle ne montre aucune preuve d'incident — pas de corps de page, pas d'en-têtes, aucun détail d'erreur au-delà de la phrase écrite pour le public. Et rien d'autre sur le serveur n'est joignable depuis elle : aucun lien vers l'intérieur, aucune liste, aucune recherche. Un visiteur qui suit l'adresse obtient cette page, et cette page seulement.

Un incident n'y figure que si l'administrateur l'a explicitement publié, et alors dans les mots qu'il a écrits pour cela — un titre public et une note publique, distincts du résumé technique que montre l'interface. Un incident que personne n'a publié n'existe pas sur la page de statut, si bruyant qu'il ait été à l'intérieur.

Publier un incident#

Ce que la page dit de ce qui s'est passé est écrit par l'administrateur, depuis History › Published dans l'interface — jamais sur la page publique elle-même. Deux entrées :

• Depuis un incident mesuré : dans History, chaque incident porte un bouton Publish (et sa propre page un bouton Publish on the status page). Le formulaire s'ouvre avec le sujet, l'heure d'ouverture et, s'il est terminé, sa résolution déjà remplis.
• À la main, avec Declare an incident, pour ce que rien n'a mesuré — un incident chez le fournisseur en amont, une cause vue de l'extérieur, une période où les sondes dormaient.

Dans les deux cas, le formulaire demande la page concernée (ou toutes), un impact — Outage, Degraded performance ou Notice — un titre, ce qui est touché (groupes, machines, sites), et une première mise à jour : un statut et quelques lignes. La page nomme ce qui est touché par les libellés qu'elle donne à ces choses, « Name servers » plutôt que le nom d'une machine, sauf si la case name the machines est cochée.

Ensuite l'incident vit : chaque mise à jour postée depuis sa page dans l'interface porte un statut — Investigating, Identified, Monitoring, Resolved — et les mots qui vont avec. Resolved le clôt à cette heure-là ; tout autre statut le rouvre. Une mise à jour peut être corrigée ou retirée après coup, sauf la première, car une chronologie a un début.

Sur la page de statut, un incident ouvert est en haut avec son impact, son statut, sa dernière mise à jour et ce qu'il touche ; un incident résolu figure parmi les incidents passés, avec sa durée. Chacun a sa propre adresse, /status/quelque-chose/incidents/N, avec toute la chronologie. Un incident publié, ce sont des mots et des dates : il ne porte aucune preuve et ne change aucun chiffre de disponibilité — les barres disent ce qui a été mesuré, l'incident dit ce qui s'est passé.

Pour un site ou un espace client qui veut dire « il y a un incident » sans lire la page, /status/quelque-chose/incidents.json répond, sans aucun jeton, avec les incidents ouverts et leurs mises à jour ; ?days=30 ajoute ceux résolus dans les trente derniers jours.

Qui décide de ce qui y figure#

L'administrateur, entièrement : l'adresse de la page, son titre, la phrase qui la sous-titre, quelles catégories existent et quelles lignes y entrent, comment chaque ligne est intitulée, sur quelle profondeur remontent les barres, combien de jours d'incidents sont listés, à quelle distance les maintenances sont annoncées, et à quelle fréquence la page se recalcule. Il décide aussi, ligne par ligne, si les machines qui sont derrière et les services qu'elles rendent apparaissent quand un visiteur déplie la ligne.

Créer et modifier les pages de statut est une fonction d'administration. Un compte client, en lecture seule ou non, n'en construit pas — mais on peut lui donner l'adresse de l'une d'elles, et lui-même peut la donner à ses propres clients.

La lire honnêtement#

Le vert d'une page de statut est une promesse sur ce que la ligne mesure, et rien de plus large. Si la ligne représente un groupe de machines, le vert signifie que ces machines répondent ; il ne certifie pas qu'un site précis sur l'une d'elles sert la bonne page. La page de votre site dans l'interface est l'instrument fin ; la page de statut est l'instrument public.

Le chiffre de disponibilité est une part de mesures, pas une déclaration contractuelle. Un trou dans les barres signifie que rien n'a été mesuré à ce moment-là, et non que tout allait bien.

Et la page est faite pour tenir le jour où l'on en a besoin. Elle est recalculée au plus une fois par son propre rythme — toutes les trente secondes par défaut — et servie depuis cette unique copie à tout le monde, de sorte que mille personnes arrivant en même temps coûtent un seul calcul. Elle se relit toute seule par un rafraîchissement HTML ordinaire et n'a besoin d'aucun script pour fonctionner, parce qu'une page de statut qui tombe quand la plateforme va mal est pire que pas de page de statut du tout.