Comment construire une page de statut en laquelle les clients ont réellement confiance

La plupart des pages de statut existent. Peu d'entre elles inspirent confiance. Une page qui est toujours verte pendant les pannes est pire qu'aucune page, car elle apprend aux clients à arrêter de la consulter. Une page de statut digne de confiance possède quatre propriétés : elle est honnête sur ce qui est cassé, elle est rapide à admettre les incidents, elle délimite soigneusement l'impact, et elle répond à la question « est-ce que cela m'affecte ? » sans obliger le lecteur à chercher. Ce guide explique comment en concevoir une.

Ce que les clients attendent réellement d'une page de statut

Deux questions motivent chaque visite sur une page de statut. Les clients veulent savoir si la chose qui les intéresse est cassée, et si quelqu'un l'a remarqué. Tout le reste est décoratif.

Si la page répond aux deux questions au premier coup d'œil, les clients lui font confiance et arrêtent d'appeler le support. Si elle ne répond à aucune, chaque incident produit cinq tickets de support supplémentaires et une lente perte de crédibilité. La conception visuelle compte moins que la structure de ce qui est affiché au-dessus de la ligne de flottaison.

Les quatre propriétés d'une page digne de confiance

Quatre propriétés distinguent une page de statut utile d'une page de vanité. Réussissez ces quatre points et les clients feront confiance à la page lors d'un véritable incident.

• Honnêteté. Si quelque chose est cassé, cela apparaît comme cassé. Si vous ne savez pas encore, la page indique « en cours d'investigation ». Du vert pendant un véritable incident détruit la confiance pour toujours.
• Rapidité. Les incidents sont publiés dans les minutes suivant la détection. Une mise à jour de statut qui accuse une heure de retard sur les pannes réelles est perçue comme du marketing.
• Clarté du périmètre. Le client peut déterminer, en quelques secondes, si l'incident affecte ce qu'il utilise. Région, domaine produit et gravité sont les trois dimensions à étiqueter.
• Langage clair. Les mises à jour sont rédigées sur le même ton que vous utiliseriez pour expliquer l'incident à un ami, et non en prose corporate au passif.

Des mises à jour d'incident qui fonctionnent

La plupart des modèles de page de statut adoptent par défaut un ton passif et prudent. « Nous enquêtons sur des signalements de latence élevée. » Cela se lit comme une dérobade. Le schéma qui inspire confiance est l'inverse : nommez ce qui est cassé, nommez l'impact utilisateur, nommez ce que vous faites pour y remédier.

Une bonne première mise à jour ressemble à : « Les connexions échouent pour environ 30 % des clients dans les régions UE. Notre bascule de base de données est en cours, ETA 10 minutes. » Une bonne résolution ressemble à : « Les connexions sont rétablies. La cause racine était un script de bascule bloqué. Nous avons ajouté un watchdog pour que cela ne puisse plus se figer silencieusement. » Les deux sont courtes. Les deux nomment l'impact, l'action et le suivi.

Cadrer correctement l'impact

Une page de statut globale unique est la mauvaise abstraction dès lors que vous avez plus d'une gamme de produits ou d'une région. Le client avec un déploiement uniquement aux États-Unis se moque que votre région UE connaisse une latence élevée.

• Découpez votre page par composant : l'API, le tableau de bord, l'ingestion, la facturation, etc. Affichez un statut par composant, et non un indicateur global unique.
• Ajoutez une dimension région ou environnement lorsque cela s'applique. Marquez explicitement la région affectée pendant les incidents.
• Affichez les incidents des 90 derniers jours sous le statut en direct. La vue historique est ce que les visiteurs consultent pour décider si vous êtes suffisamment fiable pour leur faire confiance.
• Si vous le proposez, exposez un flux RSS ou JSON afin que les clients intéressés puissent s'abonner dans leur propre outillage.

La maintenance planifiée sans le silence

La maintenance planifiée est la partie la plus facile à bien gérer sur une page de statut, et l'une des plus souvent négligées. Publiez la fenêtre 48 heures à l'avance, résumez ce qui sera affecté et ce qui ne le sera pas, et publiez un suivi confirmant l'achèvement.

Traitez la maintenance planifiée avec le même ton que les mises à jour d'incident. Nommez la fenêtre. Nommez les services affectés. Nommez l'impact. Une publication de maintenance soignée évite un ticket de support. Une publication vague en crée une douzaine.

La fiabilité de la page de statut elle-même

Hébergez la page de statut indépendamment de votre infrastructure principale. Si votre page de statut renvoie la même erreur de base de données que votre tableau de bord lors d'une panne de base de données, la page elle-même devient partie intégrante de l'incident. Une page de statut qui se charge depuis un fournisseur séparé, une région séparée ou un CDN statique constitue ce petit effort de discipline architecturale qui paie dès la première véritable panne. La plupart des équipes le découvrent à leurs dépens.