Comment créer une page d'état : composantes, incidents et vérifications de disponibilité

Une page d'état indique à vos utilisateurs, en un seul endroit, si votre service fonctionne. Pour en créer une, il vous faut une liste de composantes (site web, API, paiements, courriel), un état actuel pour chacune, des incidents avec des mises à jour horodatées, un historique des incidents passés et, facultativement, des abonnements pour que les gens soient informés des problèmes sans avoir à vérifier. La page elle-même est simple. La décision importante concerne l'endroit où elle fonctionne : une page d'état doit rester en ligne lorsque votre application est en panne; elle ne doit donc pas partager l'hébergement, la base de données ou le pipeline de déploiement de ce qu'elle signale.

À quoi sert une page d'état

Quand quelque chose tombe en panne, les utilisateurs veulent savoir trois choses : est-ce seulement moi, êtes-vous au courant, et quand sera-ce réparé? Une page d'état répond aux trois sans une avalanche de billets de soutien. Elle bâtit aussi la confiance avec le temps, car un historique d'incidents visible, accompagné de comptes rendus honnêtes, montre comment vous gérez les problèmes.

Ce n'est pas un journal des modifications. Les nouvelles fonctionnalités vont sur une page des nouveautés; les pannes et les maintenances vont ici.

Ce que la page doit contenir

Données

Table	Champs clés
Composantes	Nom (application web, API, paiements, livraison de courriels), description, état actuel, ordre d'affichage, groupe
Incidents	Titre, impact (mineur, majeur, critique), statut (en enquête, identifié, sous surveillance, résolu), composantes touchées, heure de début, heure de résolution
Mises à jour d'incident	Incident, message, statut au moment de la mise à jour, date de publication, auteur
Fenêtres de maintenance	Titre, composantes touchées, début et fin prévus, message
Abonnés	Courriel, confirmé oui/non, composantes qui les intéressent, jeton de désabonnement

Les états des composantes forment en général une courte liste fixe : Fonctionnel, Performance dégradée, Panne partielle, Panne majeure, En maintenance.

Autorisations

Le public voit tout ce qui est publié. Seule votre équipe peut publier. Gardez la connexion d'administration séparée du système de connexion de votre application principale si possible, pour qu'une panne de votre fournisseur d'authentification ne vous empêche pas d'accéder à votre propre page d'état.

La décision clé : la garder indépendante

C'est là que la plupart des pages d'état maison échouent. Si votre page d'état :

fonctionne sur le même serveur ou le même compte d'hébergement que votre application,
lit dans la même base de données,
se trouve derrière la même configuration de domaine ou du même CDN,
ou est déployée par le même pipeline,

alors de nombreuses pannes la mettront aussi hors service, exactement au moment où les gens en ont besoin. Mesures pratiques :

Hébergement séparé. Un projet ou un fournisseur différent de l'application principale.
Son propre sous-domaine, comme status.exemple.com, pointé séparément dans le DNS. Voir comment fonctionnent les domaines et le DNS.
Ses propres données. Les incidents vivent dans le stockage de la page d'état, pas dans la base de données de votre application.
Une solution de repli statique. Certaines équipes rendent la page publique statique et la reconstruisent à chaque mise à jour, pour qu'il y ait presque rien à faire tomber.

Mises à jour manuelles ou vérifications automatisées

Manuel (pour commencer)

Votre équipe publie les incidents et change les états des composantes à la main depuis la page d'administration. C'est ainsi que fonctionnent beaucoup de pages d'état en pratique, car un jugement humain (« les paiements sont lents pour certains types de cartes ») est plus utile qu'un point rouge automatique.

Pour être averti rapidement des problèmes, utilisez un outil externe de surveillance de disponibilité qui vérifie votre application toutes les minutes environ et vous alerte par courriel, SMS ou messagerie. Beaucoup de services de surveillance ont des offres gratuites.

Automatisé

L'automatisation signifie que quelque chose vérifie régulièrement chaque composante et met à jour son état. Cela demande du code qui s'exécute selon un horaire, depuis l'extérieur de l'infrastructure de votre application principale. Deux modèles courants :

Un moniteur externe appelle votre page d'état par un webhook lorsqu'une vérification échoue ou se rétablit, et la page d'état met à jour la composante.
Une tâche planifiée dans l'hébergement de la page d'état interroge chaque composante et enregistre le résultat. Vérifiez comment votre hébergeur gère les tâches planifiées avant de vous y fier; notre guide sur l'exécution de tâches en arrière-plan explique les options.

Les changements automatisés peuvent osciller (en ligne, hors ligne, en ligne) sur un réseau lent. Exigez deux ou trois échecs consécutifs avant de changer un état, et laissez un humain confirmer avant d'annoncer une panne majeure.

Rédiger les mises à jour d'incident

Publiez tôt. « Nous enquêtons sur des signalements de connexions échouées » en quelques minutes vaut mieux qu'un message parfait une heure plus tard.
Dites ce que les utilisateurs remarquent, pas ce qui s'est cassé à l'interne.
Annoncez l'heure de la prochaine mise à jour, et tenez parole.
Concluez par un bref résumé une fois résolu : ce qui s'est passé, combien de temps cela a duré, ce que vous changez.

Une première invite qui fonctionne

Créez une page d'état autonome pour notre application Parcelio, hébergée séparément à l'adresse status.parcelio.com. Composantes : Site web, API de suivi, Notifications, Paiements, chacune avec l'un des états suivants : Fonctionnel, Performance dégradée, Panne partielle, Panne majeure ou En maintenance. La page publique affiche une bannière globale selon le pire état actuel, chaque composante avec son état, les incidents actifs avec leurs mises à jour horodatées, les plus récentes en premier, la maintenance à venir et la liste des incidents passés par mois. Chaque incident a sa propre page. Ajoutez une page d'administration protégée par mot de passe pour créer des incidents (titre, impact, composantes touchées), publier des mises à jour (message et statut : En enquête, Identifié, Sous surveillance, Résolu), changer les états des composantes et planifier la maintenance. Ajoutez un point de terminaison POST /api/check-result qui accepte le nom d'une composante et up/down depuis un moniteur externe, protégé par un jeton secret, et ne marque une composante comme Dégradée qu'après trois échecs consécutifs. Stockez tout dans la base de données propre à cette application. Design simple et calme qui se charge rapidement sur téléphone.

Étapes de construction

Page publique et administration avec incidents manuels. Cela seul constitue une page d'état fonctionnelle.
L'héberger séparément et pointer un sous-domaine vers elle.
Pages d'incident et historique.
Fenêtres de maintenance.
Abonnements. Inscription par courriel à double confirmation et notifications des nouveaux incidents et mises à jour. Le courriel nécessite un fournisseur; voir comment envoyer des courriels depuis votre application.
Webhook du moniteur si vous voulez des changements d'état automatisés.
Faites un exercice. Créez un faux incident, publiez des mises à jour, résolvez-le, vérifiez les courriels, puis supprimez-le.

Erreurs courantes

L'héberger avec l'application. L'erreur la plus fréquente et la plus grave.
Une page qui affiche toujours « Tous les systèmes fonctionnent ». Si elle ne montre jamais de problème, les utilisateurs cessent de lui faire confiance.
Pas d'horodatage ni de fuseau horaire. Affichez toujours les heures avec leur fuseau.
Dépendre de la connexion de votre application principale pour la page d'administration.
Le silence entre les mises à jour. « Aucun changement, nous travaillons toujours dessus » est une mise à jour valable.
Des états automatisés qui oscillent. Exigez des échecs répétés avant tout changement.

Quand un service de page d'état hébergé est le meilleur choix

Les services hébergés de pages d'état sont conçus pour résoudre le problème de l'indépendance : ils fonctionnent sur une infrastructure séparée, gèrent les notifications aux abonnés par courriel et par SMS, et incluent souvent la surveillance et des intégrations avec les outils de gestion des incidents. Si la disponibilité fait partie de ce que vos clients paient, ou si vous avez des obligations contractuelles de signaler les incidents, un service dédié vaut généralement le coût. Beaucoup offrent des formules gratuites ou à faible coût pour les petites équipes; vérifiez avant de construire.

Créez le vôtre si vous voulez un contrôle total sur le design et la formulation, si vos besoins sont simples (quelques composantes, mises à jour manuelles) ou si une page d'état fait partie d'un produit que vous construisez pour d'autres.

Le construire avec Mythex

Dans Mythex, vous pouvez créer la page d'état comme un projet distinct de votre application principale, ce qui lui donne un hébergement séparé et sa propre base de données. Décrivez-la dans le clavardage, vérifiez-la dans l'aperçu en direct, puis publiez-la et connectez un sous-domaine comme status.votredomaine.com (les domaines personnalisés sont offerts avec le forfait Pro). Gardez à l'esprit que les applications et bases de données Mythex publiées se mettent en veille lorsqu'elles sont inactives et se réveillent à la visite suivante; le premier chargement après une période calme peut donc être plus lent. Une page simple et légère aide.

Mythex ne documente pas les tâches planifiées; pour les vérifications automatisées, utilisez donc un outil externe de surveillance de disponibilité qui appelle un point de terminaison webhook de votre page d'état (voir la recette des webhooks). Les alertes par courriel aux abonnés passent par votre propre fournisseur, avec la clé stockée comme secret du projet (recette d'envoi de courriel).

Questions

Qu'est-ce qu'une page d'état?

Une page publique qui indique si chaque partie de votre service fonctionne, présente les incidents en cours et passés avec des mises à jour horodatées, et permet souvent aux gens de s'abonner aux notifications. Elle réduit la charge du soutien pendant les pannes.

Ma page d'état doit-elle être hébergée avec mon application?

Non. Si elle partage l'hébergement, la configuration de domaine ou la base de données de votre application, elle peut tomber lors de la même panne qu'elle est censée signaler. Hébergez-la séparément, sur un sous-domaine comme status.votredomaine.com.

Ai-je besoin d'une surveillance automatisée?

C'est utile, mais pas obligatoire pour commencer. De nombreuses petites équipes publient les incidents à la main et utilisent un outil externe de surveillance de disponibilité pour s'alerter. Les changements d'état automatisés peuvent venir plus tard.

Que doit dire une mise à jour d'incident?

Ce qui est touché, ce que les utilisateurs remarqueront, ce que vous faites et quand viendra la prochaine mise à jour. Court, simple et horodaté, même si la mise à jour dit « enquête en cours ».