Qu'est-ce qu'une page de statut et que doit-elle contenir
Une page de statut est une page hébergée séparément de votre service, qui montre si chacune de ses parties fonctionne en ce moment, plus un journal des incidents en cours et passés. Son rôle est de répondre à « est-ce vous ou est-ce moi » sans que personne n'ait à ouvrir un ticket de support.
Ce qui figure sur une page de statut
Une page de statut a trois niveaux, et l'essentiel de la valeur se trouve dans les deux premiers.
Le niveau supérieur est l'état actuel de chaque composant que vous listez. Les composants sont les éléments qu'un client peut distinguer : le site web, l'API, le tableau de bord, les connexions, le parcours de paiement, le backend d'une application mobile. L'état est en général une échelle courte plutôt qu'un binaire, de sorte que vous puissiez dire « dégradé » pour un service lent mais qui répond, plutôt que de choisir entre une coche verte fausse et une croix rouge pire encore.
Le niveau intermédiaire est le flux d'incidents. Chaque incident est une entrée courte avec une heure de début, une description claire de ce que les clients vont remarquer, et des mises à jour ajoutées au fil de l'évolution de la situation, se terminant par une note de résolution. Les incidents passés restent visibles, ce qui transforme la page en registre plutôt qu'en simple interrupteur.
Le niveau inférieur est l'historique : la disponibilité sur les 30 ou 90 derniers jours par composant. C'est la partie la moins urgente et celle que lisent le plus souvent les personnes qui vous évaluent.
Publique ou privée
Une page de statut publique est accessible à quiconque possède le lien, et c'est le bon choix quand vos clients sont le grand public ou quand vous publiez un SLA. Elle absorbe aussi le trafic pendant une panne, venant de personnes qui ne sont pas du tout clientes.
Une page de statut privée est réservée aux clients connectés ou à un public interne. Les équipes l'utilisent quand la liste des composants exposerait l'architecture interne, quand les incidents concernent des clients grands comptes nommément désignés, ou quand la page couvre des systèmes internes qu'aucun tiers ne devrait pouvoir énumérer. Le compromis est que quiconque ne peut pas y accéder contactera le support à la place.
Quel que soit votre choix, hébergez la page loin de l'infrastructure qu'elle décrit. Une page de statut qui tombe en même temps que le service est pire que l'absence de page de statut, car son silence pendant une panne se lit comme une affirmation que tout va bien.
Rédiger un incident
Une entrée d'incident est écrite pour un client, pas pour les ingénieurs qui le corrigent. Cela signifie le symptôme d'abord, la cause plus tard, voire pas du tout.
- Ouvrez l'incident dès que vous avez confirmé le problème, même si vous n'en connaissez pas encore la cause. « Nous enquêtons sur des signalements d'erreurs au passage en caisse », publié à la deuxième minute, vaut plus qu'une explication complète à la quatre-vingt-dixième.
- Dites ce qu'un client va voir et ce qu'il peut faire à ce sujet, y compris une solution de contournement s'il y en a une.
- Mettez à jour selon un rythme que vous annoncez d'emblée, et publiez la mise à jour même quand c'est « toujours aucun changement ». Le silence se lit comme un abandon.
- Clôturez avec une heure de résolution et, pour tout ce qui est long ou sévère, une courte note sur ce qui s'est passé ensuite.
Faites correspondre l'état du composant à l'incident. Un incident ouvert sur un composant qui affiche encore vert est le moyen le plus rapide de perdre la confiance envers la page. Si la défaillance sous-jacente est un serveur refusant les requêtes, 503 Service Unavailable est la réponse que vos clients ont le plus de chances de vous citer.
Maintenance programmée
Les travaux planifiés ont leur place sur la même page, annoncés à l'avance avec une fenêtre et un impact attendu. Les publier à l'avance transforme une coupure en rendez-vous : les clients qui ont vu l'avis ne créent pas de ticket, et ceux qui ne l'ont pas vu peuvent au moins trouver l'explication pendant que ça se passe.
Distinguez la maintenance d'un incident visuellement et dans le registre, et respectez honnêtement la fenêtre annoncée. Une fenêtre de maintenance qui déborde régulièrement habitue les gens à ignorer la suivante.
Pourquoi cela réduit la charge de support
Pendant une panne, la file de support se remplit d'une même question posée de nombreuses fois. Une page de statut y répond une fois, à une adresse que vous pouvez pointer depuis votre réponse automatique de support, l'état d'erreur de votre application et vos comptes sociaux. Cela transforme une heure de triage répétitif en un simple lien.
L'effet secondaire porte sur la confiance. Publier les incidents coûte moins cher qu'il n'y paraît, car les clients qui ont remarqué la panne savent déjà qu'elle s'est produite. Ce qu'ils jugent, c'est si vous les en avez informés.
D'où vient le statut
Une page de statut ne vaut que ce que vaut la surveillance qui se trouve derrière. Si une personne doit remarquer une panne avant que la page ne change, la page aura toujours un temps de retard sur les clients qui la lisent, donc les états des composants doivent être pilotés par des vérifications qui s'exécutent en continu depuis l'extérieur de votre réseau. HostTracker héberge des pages de statut alimentées par sa propre surveillance, qui vérifie depuis plus de 300 points de contrôle répartis dans 158 villes, sur 13 types de moniteurs, de sorte que l'état d'un composant suit les résultats des vérifications plutôt que de dépendre de quelqu'un qui se souvient de le mettre à jour. Pour voir à quoi ressemblent ces vérifications, consultez le guide de la vérification HTTP, et le reste de la section des concepts de surveillance pour les termes qui l'entourent.