Quand votre fournisseur tombe en panne
Dernière mise à jour:
Une page de statut d’un fournisseur est le tableau de bord public qu’un fournisseur de cloud, d’hébergement, de code ou de paiements entretient pour déclarer sa propre santé : un indicateur global, une liste de composants et une chronologie d’incidents écrite par le fournisseur lui-même pendant que ces incidents sont encore en cours. Bien la lire est une compétence d’opérateur, car le titre est un résumé et la vérité vit en dessous — dans quel composant est touché, dans quelle région, à quel impact déclaré, et jusqu’où l’incident a avancé dans le propre flux du fournisseur. Cet article enseigne cette lecture et se termine par ce qu’il faut faire dans les dix premières minutes quand le fournisseur en question est l’un de ceux dont vous dépendez. Commencez sur le tableau de statut des fournisseurs, qui rassemble les pages des grands fournisseurs en un instantané, et gardez présente tout au long du texte la question de est-ce en panne, ou est-ce seulement vous ? : les deux outils répondent aux moitiés opposées du même doute.
Deux choses différentes : l’indicateur et l’état de l’incident
Toute page de statut mature porte deux signaux séparés que les lecteurs confondent constamment. Le premier est l’indicateur global : un unique état résumé pour tout le service, en général l’un de none, minor, major, critical ou maintenance dans le flux lisible par machine derrière la page — le modèle documenté dans la documentation développeur de Statuspage, que la plupart des grands fournisseurs utilisent directement ou imitent de près. L’indicateur est délibérément grossier. Il existe pour qu’un lecteur occupé — ou une machine, comme notre tableau de statut — puisse répondre à « quelque chose ne va pas là-bas ? » en une seconde, et il est calculé à partir du composant le plus touché, du propre jugement du fournisseur, ou des deux.
Le second signal est l’incident lui-même, et il a son propre cycle de vie que l’indicateur aplatit. Un incident s’ouvre avec un nom, un impact déclaré et un état tiré d’un flux : en cours d’investigation (nous voyons des symptômes et ne connaissons pas encore la cause), identifié (nous connaissons la cause et nous travaillons dessus), sous surveillance (un correctif est sorti et nous observons s’il tient) et résolu (nous croyons qu’il est terminé, sous réserve du postmortem). Ces états portent une information que l’indicateur ne peut pas porter. Un incident critique sous surveillance depuis deux heures est en général en train de se terminer ; un incident minor entré en investigation il y a quatre minutes peut encore devenir n’importe quoi.
Lisez les deux, dans cet ordre, et lisez les mises à jour entre eux. La chronologie de courtes mises à jour sous un incident est l’endroit où le fournisseur vous dit les choses que le titre ne dira jamais : quel sous-système a échoué, quel contournement existe, si ce sont les données qui sont touchées ou seulement la disponibilité, et si la prochaine mise à jour est promise dans vingt minutes ou deux heures. Un incident dont les mises à jour cessent d’arriver est lui-même un signal — soit l’équipe est débordée, ce qui se corrèle avec une panne plus longue, soit l’incident a été silencieusement plié dans un plus grand. Les opérateurs qui photographient le titre et cessent de lire agissent de façon routinière sur la phrase la moins informative de la page.
Pourquoi « tous les systèmes opérationnels » peut quand même signifier que vous êtes en panne
L’indicateur résume le service entier, et les services modernes ne sont pas une seule chose. Un fournisseur peut être honnêtement vert à l’échelle globale pendant que la région où vous déployez, la seule surface de produit que vous appelez, la version héritée de l’API à laquelle vous êtes ancré ou le plan de contrôle dont vous avez besoin pour un déploiement échouent pour chaque client qui les touche. Les listes de composants existent précisément pour cela : une page comme la page de statut de GitHub décompose le service en opérations Git, requêtes API, Actions, Pages et davantage, et n’importe lequel d’entre eux peut être dégradé pendant que la bannière globale reste rassurante — ou l’inverse, avec la bannière rouge pour un composant que vous n’avez jamais utilisé.
Il y a aussi trois fossés plus silencieux. D’abord, le retard de déclaration : un fournisseur déclare un incident quand il l’a confirmé, pas quand la première erreur est survenue, donc les premières minutes de beaucoup de pannes montrent une page verte et un fil social en feu ; la page ne ment pas, elle est simplement en retard. Ensuite, les seuils : un fournisseur peut traiter un taux d’erreur de deux pour cent sur un niveau comme un bruit de fond normal et ne jamais rien déclarer, pendant que ces deux pour cent se concentrent exactement sur votre modèle de trafic. Enfin, la portée : les pages de statut décrivent le côté du câble du fournisseur. Une défaillance DNS, un problème de routage ou un chemin bloqué entre vos utilisateurs et un fournisseur sain produit une panne totale pour vous sous un indicateur vert — et c’est pourquoi la question compagnon, est-ce en panne ou est-ce seulement vous, doit être résolue depuis des points de vue indépendants, pas depuis la propre page du fournisseur.
La règle de travail est de traiter le vert comme « aucun incident déclaré », jamais comme « santé prouvée ». Quand votre propre surveillance dit que les utilisateurs échouent et que le fournisseur dit opérationnel, croyez votre surveillance en ce qui concerne vos utilisateurs et utilisez la page de statut pour un autre travail : vérifier si une déclaration apparaît plus tard, ce qui confirme rétroactivement la cause, et si le composant dont vous dépendez a un historique d’incidents ayant la même forme que celui que vous traversez.
Abonnez-vous aux composants, pas aux pages
La plupart des opérateurs s’abonnent à une page de statut comme ils s’abonnent à une lettre d’information : un abonnement, chaque incident, pour toujours — et ensuite, de façon prévisible, ils commencent à ignorer le courrier, car un flux global pour un grand fournisseur produit un goutte-à-goutte constant d’incidents pour des composants qu’ils n’utilisent pas, dans des régions qu’ils ne desservent pas. La fatigue d’alerte n’est pas un défaut de caractère ; c’est la bonne réponse à un signal mal délimité. Le correctif est mécanique et disponible sur presque chaque page de statut mature : abonnez-vous au niveau du composant. Le même modèle Statuspage qui définit les indicateurs permet aussi aux abonnés de filtrer par composant, et les fournisseurs qui font tourner leurs propres systèmes, comme la page de statut de Cloudflare, offrent le même choix par leurs propres flux d’abonnement.
Délimitez chaque abonnement à ce qui changerait réellement votre comportement à 3 heures du matin. Les composants que votre trafic de production appelle appartiennent au canal bruyant — celui qui appelle, envoie des messages ou au moins marque quelque chose que vous verrez en quelques minutes. Les composants que vous n’utilisez que pour les constructions, l’analytique ou l’outillage interne appartiennent à un canal silencieux que vous examinez aux heures de travail. Les composants que vous n’utilisez pas n’appartiennent nulle part : chaque notification que vous ignorez correctement rend la suivante plus facile à ignorer, y compris celle qui compte. Revisitez la liste chaque fois que la pile change, car les abonnements pourrissent dans les deux sens — de nouvelles dépendances auxquelles personne ne s’est abonné, et des mortes qui appellent encore un canal que personne ne regarde.
Préférez les flux lisibles par machine quand vous le pouvez. Le courrier est le canal le plus lent et le plus ignorables qu’offre une page de statut ; les webhooks et les flux peuvent alimenter votre propre tableau de bord, ouvrir un ticket interne, ou retourner la page d’attente préparée de votre équipe de support avant l’arrivée de la première plainte d’un utilisateur. Même une version légère paie : l’instantané de notre tableau de statut des fournisseurs est construit exactement à partir de ces flux publics, ce qui prouve que les données sont là pour être consommées de façon programmatique plutôt qu’admirées dans un onglet de navigateur dont il faut se souvenir de l’ouvrir.
Construisez votre propre inventaire de dépendances
Aucun des conseils ci-dessus ne fonctionne sans une liste, et la plupart des équipes découvrent pendant une panne qu’elles n’en ont pas. Un inventaire de dépendances est simplement la réponse écrite à une question qui sonne triviale et ne l’est pas : quels services externes, s’ils s’arrêtaient ce soir, nous arrêteraient — et lesquels ne feraient que nous embarrasser ? Construisez-le par beau temps. Parcourez votre architecture surface par surface — hébergement, DNS, hébergement de code et CI, les fournisseurs de base de données et de stockage, le processeur de paiement, les expéditeurs de courrier et de SMS, le fournisseur d’identité, le traqueur d’erreurs, l’étiquette d’analytique, les polices et scripts que vos pages chargent depuis le CDN d’un autre — et écrivez, pour chacun, le fournisseur, le composant que vous consommez réellement, où vit sa page de statut, et ce que vos utilisateurs vivent quand il échoue.
Classez chaque entrée selon la forme de sa défaillance, pas selon combien vous aimez le vendeur. Certaines dépendances sont dures : si elles s’arrêtent, vous vous arrêtez, et le seul travail disponible est la communication et l’attente. Certaines sont molles : le site fonctionne sans elles, dégradé — pas d’analytique, pas de widget de discussion, pas de personnalisation — et pour celles-là, l’inventaire doit dire qui peut les éteindre et comment. Et certaines sont cachées : les dépendances transitives que vous n’avez pas choisies, comme l’état de la région cloud dans laquelle tourne votre propre base de données SaaS, ou l’infrastructure de certificats et de DNS sous tout. Les dépendances cachées sont celles qui produisent la panne « tout est en panne et rien de ce que nous payons n’est sur la liste », et vous les trouvez en demandant à chaque vendeur, une fois, de quoi il dépend.
Gardez l’inventaire là où un incident peut l’atteindre : dans le runbook, à côté de la liste d’escalade, pas sur une page wiki que personne ne peut ouvrir quand le fournisseur d’identité est précisément ce qui est en panne. Une page suffit. Son travail pendant une panne est de transformer « quelque chose ne va pas » en une liste de vérification — pour chaque dépendance dure, en haut ou en bas, en trente secondes — et son travail après est d’être corrigé, car chaque incident réel vous apprend quelque chose sur une dépendance que vous aviez mal classée. Un inventaire qui n’est jamais corrigé est un document historique, pas opérationnel.
Les dix premières minutes d’une panne de fournisseur
De la minute zéro à deux : confirmez et localisez. Vérifiez votre propre surveillance pour être sûr que la défaillance est réelle et vôtre à annoncer, puis ouvrez le tableau de statut et la page du fournisseur suspect. Vous répondez à une question : y a-t-il un incident déclaré qui croise ce que vous utilisez — composant, région, produit ? Si oui, vous avez votre cause et votre premier message. Si non, élargissez la vérification : un autre fournisseur de votre inventaire, votre propre dernier déploiement, votre DNS. La plupart des faux drames meurent dans ces deux minutes, et la plupart des vrais y prennent leur forme.
Minutes deux à cinq : communiquez, clairement et tôt. Dites à vos utilisateurs, dans les canaux qu’ils lisent réellement, qu’un fournisseur en amont nommé a un incident, ce que cela signifie pour eux en termes pratiques — ce qui ne fonctionne pas, ce qui fonctionne encore, si leurs données sont en sécurité — et quand vous les mettrez à jour ensuite. Un message d’attente honnête envoyé à la minute quatre bat une explication précise envoyée à la minute quarante, car le silence est ce que les utilisateurs remplissent de leurs pires suppositions et des noms de vos concurrents. En interne, ouvrez un seul fil d’incident, nommez une seule personne pour parler, et horodatez tout ; vous vous en remercierez au postmortem, et l’équipe de support du fournisseur aussi si vous avez besoin d’elle.
Minutes cinq à dix : cessez d’aggraver les choses et préparez les atterrissages en douceur. Gelez les déploiements — un changement fait dans un incident amont actif ne peut pas être évalué et ne pourra peut-être même pas être annulé. Éteignez les nouvelles tentatives agressives et les tâches non essentielles qui martèlent le fournisseur défaillant ; la reprise est mesurablement plus lente quand dix mille clients réessaient à l’unisson, et certains fournisseurs vous limiteront jusqu’à une seconde panne, cette fois auto-infligée. Éteignez ou dégradez les dépendances molles que votre inventaire a marquées comme largables, affichez la page d’attente si vous en avez une, puis installez-vous dans le rythme que l’incident dicte : surveillez les mises à jour du fournisseur, mettez vos utilisateurs à jour aux heures promises qu’il y ait des nouvelles ou non, et ne changez rien d’autre à moins que les faits ne changent. La panne se terminera selon l’horaire du fournisseur, pas le vôtre ; vos dix minutes décident si vos utilisateurs s’en souviennent comme du mauvais jour de leur fournisseur ou comme du vôtre.