Les grandes entreprises ont des rotations d'astreinte, des commandants d'incident, des matrices de sévérité et un budget d'outillage à la hauteur. Une équipe de trois a un chat de groupe et celui qui est réveillé. Cette équipe a quand même des incidents, ils arrivent quand même à 02 h 40, et la question n'est pas de savoir s'il faut un processus, mais combien peu de processus capture l'essentiel de la valeur. Voici ce que nous avons écrit pour une équipe de trois personnes qui exploite une plateforme de paiement, ce que nous lisons pendant un incident, et ce que nous écrivons après. Le tout tient sur deux pages, volontairement.
Ce que nous décidons avant, pour ne pas le décider à 02 h 40
Les pires décisions d'incident sont celles prises sous pression par quelqu'un qui vient d'être réveillé. Donc le petit nombre de décisions qui comptent est pris à l'avance et écrit là où l'alerte renvoie.
La sévérité, en trois lignes.
| Niveau | Définition | Réponse |
|---|---|---|
| S1 | Les utilisateurs ne peuvent pas faire ce pour quoi ils paient : le checkout échoue, la connexion échoue, les données sont fausses | Maintenant. Qui le voit agit. On réveille quelqu'un si nécessaire. |
| S2 | Dégradé : lent, une fonctionnalité cassée, des erreurs pour certains utilisateurs | Dans l'heure en journée, le lendemain matin la nuit |
| S3 | Interne : un job a échoué, un tableau de bord est faux, quelque chose que l'utilisateur ne voit pas | Le prochain jour ouvré |
Le but du tableau n'est pas la précision. C'est que « c'est un S1 ? » ait une réponse en une ligne, et que la réponse décide s'il faut appeler quelqu'un.
Qui est premier intervenant cette semaine. Pas une rotation avec de l'outillage ; un nom dans le sujet du canal, changé le lundi. Cette personne garde le téléphone allumé et regarde en premier. Tous les autres sont en second. C'est du best-effort, nous le disons, et ça n'a jamais été un problème une seule fois, parce que l'alternative, personne n'étant sûr de qui regarde, est pire que n'importe quelle réponse imparfaite.
La première règle : revenir en arrière avant de déboguer. S'il y a eu un déploiement dans les dernières heures et que le symptôme a commencé après, le retour arrière est un changement de tag et prend quatre minutes. Faites ça d'abord. Le débogage vient après, sur staging, l'incident clos. Le nombre de fois où revenir en arrière a été la mauvaise décision : zéro. Le nombre de fois où déboguer d'abord a coûté une heure de panne supplémentaire : trois, toutes avant que nous n'écrivions la règle.
La page de runbook par alerte
Chaque alerte qui peut appeler renvoie à une page, et chaque page a les mêmes cinq titres. Voici la vraie pour l'alerte de taux d'erreur, légèrement caviardée.
Cinq titres. Ce que ça signifie est une phrase, parce que le nom de l'alerte ne suffit jamais à 02 h 40. Regarder d'abord, c'est exactement trois choses, chacune un lien ou une commande, dans l'ordre qui trouve la cause le plus vite ; au-delà de trois, les gens sautent la liste. Retour arrière, c'est la commande exacte et la condition pour l'utiliser. Causes connues, c'est la mémoire accumulée de l'équipe : chaque incident passé sur cette alerte, avec ce qui l'a corrigé, une ligne chacun. Qui prévenir, c'est le canal et la page de statut.
La section Causes connues est celle qui grandit et celle qui rapporte. La moitié de nos incidents sont des répétitions de quelque chose dans cette liste, et pour ceux-là, le temps entre l'appel et le correctif est le temps de lire la ligne.
Ce que nous lisons à 02 h 40
L'alerte. Elle contient le lien vers le runbook, parce que la règle d'alerte porte une annotation avec l'URL. Puis la page de runbook. Puis les trois liens de Regarder d'abord, dans l'ordre. C'est tout. Il n'y a pas de rôle de commandant d'incident à attribuer ni de pont à ouvrir, parce que nous sommes trois et dans le même chat.
Ce que nous ne lisons délibérément pas : les documents d'architecture, la page de santé des services de la console cloud, le dernier mois de commits. Si les trois liens ne trouvent rien et qu'il y a eu un déploiement, retour arrière. S'il n'y a pas eu de déploiement, la quatrième étape est la trace : trouver une requête en échec et ouvrir sa trace, qui pointe généralement vers le service réellement cassé plutôt que vers celui qui signale des erreurs.
La communication, avec des modèles
Deux publics, deux modèles, tous deux écrits à l'avance pour que personne ne rédige de prose pendant une panne.
En interne, dans #incidents, dans les cinq minutes suivant la prise en charge :
S1 · erreurs api ~3 % depuis 02:31 · j'examine · dernier déploiement hier 21:40 · retour arrière d'abord
Une ligne. Sévérité, symptôme, depuis quand, ce que vous faites. Mettez la ligne à jour toutes les quinze minutes, ou quand quelque chose change, même si la mise à jour est « j'examine toujours ». Le silence est la chose que les gens ne supportent pas.
En externe, sur la page de statut, pour les S1 seulement :
Nous constatons des erreurs élevées sur le checkout depuis 02:31 UTC. Nous avons identifié la cause et déployons un correctif. Prochaine mise à jour dans 30 minutes.
La page de statut est un fichier HTML statique dans un bucket S3 derrière CloudFront, sur un domaine séparé, avec un script qui la bascule entre « operational », « degraded » et « outage » et ajoute un message. Elle ne coûte rien, ne dépend de rien qui pourrait faire partie de l'incident, et une commande suffit pour la mettre à jour. Un produit de page de statut hébergé convient aussi ; les propriétés importantes sont qu'elle soit hors du rayon d'explosion et que la mise à jour prenne quelques secondes.
Ce que nous écrivons après
Une page, dans les deux jours ouvrés, sans blâme par construction parce qu'elle a trois questions et qu'aucune n'est « qui » :
- Ce qui s'est passé, sous forme de chronologie. Alerte à 02:31, prise en charge à 02:34, retour arrière à 02:41, taux d'erreur normal à 02:45, cause racine identifiée à 10:20 le lendemain. Les heures viennent du canal, pas de la mémoire.
- Pourquoi c'est arrivé, et pourquoi ça n'a pas été détecté plus tôt. La seconde moitié est la plus utile. « La migration a verrouillé la table » est la cause ; « nous ne chronométrons pas les migrations sur un snapshot de staging » est la lacune.
- Ce que nous changeons. Au plus trois points, chacun avec un responsable et une semaine. Le point le plus fréquent, de loin, est une nouvelle ligne dans les Causes connues d'un runbook. Le deuxième est une nouvelle alerte. Le troisième est un changement dans une checklist.
La note post-incident va dans le dépôt, à côté des runbooks, dans un dossier daté. Après dix-huit mois, il y en a quatorze, et les lire dans l'ordre est le meilleur document d'intégration que nous ayons.
Ce que nous ne faisons pas, et pourquoi ça va
Pas d'astreinte formelle avec des politiques d'escalade : trois personnes, un téléphone allumé, best-effort, dit clairement. Pas de commandant d'incident : le premier intervenant l'est, et si c'est gros il le dit et quelqu'un d'autre se joint. Pas de sévérité au-delà de trois niveaux. Pas de cellule de crise. Pas de réunion de post-mortem sans blâme ; la note suffit, et elle est discutée au prochain point régulier.
Tout cela est la bonne chose pour une organisation d'ingénierie de cinquante personnes. Pour trois, c'est de la cérémonie, et la cérémonie à 02 h 40 est ce qui fait que les gens ne signalent pas le S2 qui aurait été un S1 au matin.
Le processus tient sur deux pages : le tableau de sévérité, le nom du premier intervenant, la règle du retour arrière, le modèle de runbook, les deux modèles de message, les trois questions post-incident. Il a fallu un après-midi pour l'écrire et il a été lu, dans l'urgence, quatorze fois.
Si vous voulez les deux pages comme point de départ, adaptées à votre stack, nous les écrirons avec vous.