Dépannage, réponse d'urgence et gestion d'incident

Quand un système de production se met à dysfonctionner, trois compétences distinctes entrent en jeu : savoir diagnostiquer méthodiquement (le dépannage), savoir réagir sous pression quand tout casse (la réponse d'urgence), et savoir coordonner plusieurs personnes pour limiter les dégâts (la gestion d'incident). Le SRE traite ces trois sujets comme des disciplines apprenables et enseignables — non comme un don inné — et les outille avec des modèles, des rôles et des processus éprouvés à l'échelle de Google. C'est l'objet de ce chapitre, qui couvre le dépannage efficace, la réponse d'urgence et la gestion d'incident.

Le dépannage est une compétence apprenable

On considère souvent le dépannage (troubleshooting) comme une aptitude que certains possèdent et d'autres non. Cette croyance vient de ce qu'expliquer comment dépanner est aussi difficile qu'expliquer comment faire du vélo : pour ceux qui le pratiquent souvent, c'est un processus ancré, presque inconscient. Le SRE affirme au contraire que le dépannage s'apprend et s'enseigne.

Le dépannage efficace repose sur deux facteurs complémentaires : une compréhension générique du processus de diagnostic (indépendante de tout système) et une connaissance solide du système en cause. On peut investiguer un problème uniquement par les premiers principes — c'est même une excellente façon d'apprendre comment un système fonctionne — mais cette approche est moins efficace que de savoir comment les choses sont censées se comporter. Comme le résume Brian Redman, « être expert, c'est plus que comprendre comment un système est censé fonctionner ; l'expertise s'acquiert en cherchant pourquoi il ne fonctionne pas ».

La théorie : la méthode hypothético-déductive

Formellement, le dépannage est une application de la méthode hypothético-déductive (hypothetico-deductive method) : à partir d'un ensemble d'observations sur un système et d'une base théorique pour comprendre son comportement, on formule itérativement des hypothèses sur les causes possibles d'une panne, puis on teste ces hypothèses. Le modèle idéalisé enchaîne les étapes suivantes.

   ┌────────────────────────────────────────────────────────────┐
   │                                                             │
   ▼                                                             │
Rapport de   →  Triage   →  Examen   →  Diagnostic  →  Test/      │
problème        (triage)    (examine)   (diagnose)    Traitement  │
                                                      (test &     │
                                                       treat)     │
                                                         │        │
                          hypothèse réfutée / à affiner ─┘        │
                                                         │        │
                          hypothèse confirmée → cause racine      │
                                                         ▼        │
                                                     Guérison ────┘
                                                     (cure) + post-mortem

On part d'un rapport de problème indiquant que quelque chose ne va pas. On consulte ensuite la télémétrie et les journaux (logs) pour comprendre l'état courant. Combinées à notre connaissance de la conception du système, de son fonctionnement attendu et de ses modes de défaillance, ces données permettent d'identifier des causes plausibles. On teste alors les hypothèses de deux manières : soit en comparant l'état observé à nos théories pour trouver des preuves confirmant ou infirmant, soit en « traitant » le système — c'est-à-dire en le modifiant de façon contrôlée — pour observer les résultats. On répète jusqu'à isoler la cause racine, puis on prend une action corrective et on rédige un post-mortem. Réparer la cause immédiate (proximate cause) n'a pas besoin d'attendre la cause racine.

Ces fallacies logiques s'évitent en se rappelant que toutes les pannes ne sont pas équiprobables. Comme on l'enseigne aux médecins : « quand vous entendez un galop, pensez aux chevaux, pas aux zèbres ». À conditions égales, il faut préférer les explications les plus simples (rasoir d'Occam) — sans oublier qu'un système souffre plus souvent de plusieurs petits problèmes ordinaires dont la conjonction explique tout, que d'un unique problème rare. Et surtout : corrélation n'est pas causalité. Une perte de paquets dans un cluster et des disques durs défaillants peuvent partager une cause commune (une coupure de courant) sans que l'un cause l'autre.

En pratique : du rapport de problème à la guérison

Rapport de problème

Tout commence par un rapport de problème (problem report) : une alerte automatique ou un collègue qui dit « le système est lent ». Un bon rapport indique le comportement attendu, le comportement réel et, si possible, comment le reproduire. Idéalement, les rapports ont une forme cohérente et sont stockés dans un endroit consultable — un système de suivi de bugs. C'est une pratique courante à Google d'ouvrir un bug pour chaque problème, même reçu par e-mail ou messagerie : cela crée un journal d'investigation réutilisable et évite de concentrer la charge sur quelques personnes que les rapporteurs connaissent, plutôt que sur la personne d'astreinte (on-call) du moment.

Triage

Une fois le rapport reçu, il faut décider quoi en faire. La sévérité varie : du bug touchant un seul utilisateur dans des circonstances précises (avec un contournement) jusqu'à la panne globale complète. La réponse doit être proportionnée : déclarer une urgence générale (all-hands-on-deck) est justifié pour la seconde, mais excessif pour le premier.

Examen

Il faut pouvoir examiner ce que fait chaque composant pour savoir s'il se comporte correctement. Trois outils principaux composent la boîte à outils.

Outil	Ce qu'il apporte	Détail Google
Métriques / time-series	Point de départ pour trouver où le problème a commencé	Tracer les séries temporelles et leurs opérations révèle corrélations et anomalies
Journaux (logs)	Comprendre précisément ce que faisait un processus à un instant donné	Texte pour le débogage en temps réel ; binaire structuré pour l'analyse rétrospective ; niveaux de verbosité ajustables à la volée, échantillonnage statistique
État courant exposé	Voir l'état d'un serveur sans schéma d'architecture	Les serveurs Google exposent des points d'accès (endpoints) montrant les RPC récents, des histogrammes de taux d'erreur et de latence ; Borgmon peut tracer une valeur jusqu'aux métriques sources

Le traçage (tracing) des requêtes à travers toute la pile, avec un outil comme Dapper, offre une vue puissante du fonctionnement d'un système distribué. Pour Shakespeare, en envoyant manuellement une requête à /api/search avec curl, vous obtenez un code HTTP 502 (Bad Gateway) sans charge utile, mais avec un en-tête X-Request-Trace listant les serveurs dorsaux (backends) responsables : vous pouvez désormais cibler ces backends précis.

Diagnostic

Plusieurs pratiques génériques aident même sans connaissance du domaine.

• Simplifier et réduire. Si les composants ont des interfaces bien définies et des transformations connues d'entrée vers sortie, on peut observer les données qui circulent entre eux pour repérer le fautif. Injecter des données de test connues à chaque étape (une forme de test en boîte noire) est très efficace. Un cas de test reproductible accélère énormément le débogage.
• Diviser pour régner. Dans un système multicouche, on remonte la pile systématiquement d'un bout à l'autre. Pour les très grands systèmes, la bissection (bisection) — couper le système en deux et examiner les chemins de communication — est plus rapide.
• Demander « quoi », « où », « pourquoi ». Un système en panne fait souvent encore quelque chose — juste pas ce qu'on veut. Trouver ce qu'il fait, puis pourquoi et où ses ressources sont consommées. C'est proche de la technique des « cinq pourquoi » (Five Whys) de Taiichi Ohno.
• Ce qui l'a touché en dernier. Les systèmes ont de l'inertie : un système qui marche tend à continuer jusqu'à ce qu'une force externe — un changement de configuration, un déplacement de charge — l'en empêche. Les changements récents sont un excellent point de départ.

Pour illustrer le « quoi/où/pourquoi » : un cluster Spanner a une latence élevée et ses RPC expirent. Pourquoi ? Les tâches serveur saturent leur CPU. Où ? Le profilage montre qu'elles trient des entrées de journaux. Où dans le tri ? Dans l'évaluation d'une expression régulière sur des chemins de fichiers. Solution : réécrire la regex pour éviter le retour sur trace (backtracking), ou utiliser un moteur à exécution linéaire garantie.

Test et traitement

Une fois une courte liste de causes possibles établie, on utilise la méthode expérimentale pour confirmer ou réfuter les hypothèses. Quelques principes de conception des tests :

• un test idéal présente des alternatives mutuellement exclusives, écartant un groupe d'hypothèses et en retenant un autre ;
• le plus probable d'abord : effectuer les tests par ordre décroissant de vraisemblance, en tenant compte des risques pour le système ;
• attention aux facteurs confondants : une règle de pare-feu peut faire échouer un ping depuis votre poste alors qu'il réussirait depuis le serveur applicatif ;
• les tests actifs peuvent avoir des effets de bord qui faussent les résultats suivants (activer la journalisation verbeuse peut aggraver un problème de latence et brouiller l'analyse) ;
• certains tests ne sont que suggestifs : reproduire une condition de course (race condition) à la demande est souvent impossible.

Guérison

Idéalement, l'ensemble des causes est réduit à une seule, qu'on cherche à prouver. Prouver définitivement une cause en reproduisant le problème à volonté est difficile en production : les systèmes sont complexes (plusieurs facteurs conjoints peuvent être la cause), dépendants du chemin (path-dependent), et la reproduction en production est parfois impossible ou inacceptable. On se contente souvent de facteurs causaux probables. Une fois la cause trouvée, on rédige le post-mortem : ce qui a mal tourné, comment on a traqué le problème, comment on l'a corrigé, comment l'empêcher de revenir.

L'étude de cas App Engine illustre tout cela : une application voyait latence, CPU et nombre de processus exploser sans changement de code ni hausse de trafic. Une fausse piste (la corrélation avec l'appel merge_join, suggérant un indexage sous-optimal) s'est révélée fallacieuse quand on a vu que même le contenu statique ralentissait. Le traçage Dapper a montré une fenêtre de ~250 ms où l'application faisait « quelque chose » sans émettre aucun RPC. La cause racine : un bug de longue date créait un objet de liste blanche (whitelist) à chaque accès d'un chemin précis ; un scanner de sécurité automatisé en a généré des milliers, vérifiés à chaque requête — d'où des réponses pathologiquement lentes, sans aucun appel RPC. Comme l'a dit un développeur : « je ne sais pas encore où est le feu, mais je suis aveuglé par la fumée qui sort de ce cache de liste blanche ».

Rendre le dépannage plus facile

Les deux leviers les plus fondamentaux sont structurels : intégrer l'observabilité — métriques en boîte blanche (white-box) et journaux structurés — dans chaque composant dès la conception, et concevoir des interfaces bien comprises et observables entre composants. Propager un identifiant de requête unique à travers tous les RPC évite de devoir réconcilier manuellement les journaux d'un composant amont avec ceux d'un composant aval, accélérant le diagnostic. Simplifier, contrôler et journaliser les changements réduit le besoin même de dépanner.

Réponse d'urgence : quand tout casse

Les choses cassent, c'est la vie. Ce qui distingue une organisation, c'est comment ses gens réagissent à une urgence — une qualité qui demande de la préparation et un entraînement périodique. Le premier conseil est simple : ne paniquez pas. Vous n'êtes pas seul, le ciel ne tombe pas, et personne n'est en danger physique (seuls de pauvres électrons sont en péril). Si vous vous sentez débordé, appelez plus de monde — quitte à alerter (page) toute l'entreprise.

Le chapitre tire ses leçons de trois urgences réelles de Google, classées par déclencheur.

Urgence	Déclencheur	Ce qui a sauvé la situation	Leçon clé
Induite par un test	Bloquer l'accès à 1 base de test sur 100 a révélé des dépendances cachées ; services internes et externes inaccessibles	Abandon immédiat du test ; restauration des permissions sur réplicas et bascules ; effort parallèle pour corriger la bibliothèque	Tester les procédures de rollback au préalable ; suivre le processus d'incident
Induite par un changement	Une config poussée globalement un vendredi a déclenché un crash-loop sur toute la flotte externe (et interne)	Surveillance instantanée ; rollback en 5 min par l'ingénieur du push ; outils en ligne de commande et communications hors-bande (out-of-band)	Canary rigoureux quel que soit le risque perçu ; ne pas dépendre uniquement d'outils hébergés sur la flotte en panne
Induite par un processus	Une 2ᵉ requête d'extinction (turndown) avec un bug a envoyé toutes les machines à la file Diskerase (« zéro veut parfois dire tout »)	Bascule du trafic des petites vers les grandes installations ; désactivation de toute l'automatisation ; reconstruction manuelle priorisée	Ajouter des contrôles de cohérence (sanity checks) ; le processus d'incident, mûri, a permis une coordination superbe

Apprendre du passé, ne pas le répéter

Tous les problèmes ont une solution — même non évidente, surtout pour celui dont le pager hurle. Si vous n'en trouvez pas, élargissez votre filet : impliquez plus de coéquipiers. Souvent, la personne avec le plus de contexte est celle dont l'action a déclenché l'incident ; mettez-la à contribution. Une fois l'urgence atténuée, ne négligez pas de nettoyer et de documenter l'incident.

La meilleure façon d'apprendre est de garder un historique des pannes (history of outages). Soyez complet, honnête, et posez les questions difficiles. Cherchez des actions spécifiques qui empêcheraient une récurrence, tactiquement comme stratégiquement. Tenez chacun responsable du suivi de ces actions. Posez aussi les grandes questions, même improbables : et si l'alimentation du bâtiment tombe ? Si le datacenter principal s'éteint d'un coup ? Si quelqu'un compromet votre serveur web ? Enfin, encouragez les tests proactifs : tant qu'un système n'a pas réellement échoué, vous ne savez pas comment il réagira. Préférez-vous une panne à 2 h du matin un samedi, ou un test soigneusement préparé et surveillé par vos meilleurs profils ?

Gérer les incidents

Une gestion d'incident efficace est la clé pour limiter la perturbation et rétablir le service au plus vite. Si vous n'avez pas répété votre réponse à l'avance, la rigueur s'évapore en situation réelle. Le livre oppose deux récits du même incident pour le démontrer.

L'anatomie d'un incident non géré

Mary, d'astreinte un vendredi 14 h, voit son pager exploser : un datacenter ne sert plus, puis un deuxième, puis un troisième sur cinq ; le trafic restant surcharge les autres. Elle plonge dans les logs, tente un rollback (inutile), appelle Josephine (réveillée à 3 h 30 du matin), pendant que Sabrina et Robin « jettent juste un œil ». Un dirigeant téléphone, furieux ; les VP réclament une estimation et lancent des suggestions « difficiles à réfuter ». Sans concertation, Josephine appelle Malcolm, qui a une intuition sur l'affinité CPU et déploie un changement en production — qui achève les serveurs. Tout le monde faisait son travail. Pourtant l'incident a dégénéré pour trois raisons :

• Focalisation excessive sur le problème technique : Mary, recrutée pour ses compétences, est absorbée par la tâche et incapable de penser à la vue d'ensemble.
• Communication médiocre : personne ne sait ce que font les autres ; les dirigeants enragent, les ingénieurs disponibles sont mal employés.
• Cavalier seul (freelancing) : Malcolm modifie le système avec les meilleures intentions, sans se coordonner — aggravant gravement la situation.

Les éléments du processus

La gestion d'incident de Google s'inspire du Système de commandement des incidents (Incident Command System, ICS), réputé pour sa clarté et son passage à l'échelle. Un bon processus présente quatre caractéristiques.

D'abord, une séparation récursive des responsabilités (recursive separation of responsibilities) : chacun connaît son rôle et ne marche pas sur les plates-bandes d'autrui. Contre-intuitivement, cette séparation claire donne plus d'autonomie, puisqu'on n'a plus à remettre en cause le travail de ses collègues. Si la charge d'un rôle devient excessive, on demande des renforts au responsable planification et l'on délègue — quitte à créer des sous-incidents.

Rôle	Responsabilité
Commandant d'incident (incident commander)	Détient l'état de haut niveau ; structure la cellule de crise et assigne les responsabilités selon le besoin et la priorité ; détient de facto tout rôle non délégué ; lève les obstacles qui gênent les Ops
Responsable opérationnel (Ops lead)	Applique les outils opérationnels au problème ; seul groupe autorisé à modifier le système pendant l'incident
Responsable communication (communications lead)	Visage public de la cellule ; émet des mises à jour périodiques (souvent par e-mail) aux intervenants et aux parties prenantes ; tient le document à jour
Planification (planning)	Soutient les Ops sur le long terme : ouvrir des bugs, commander le dîner, organiser les passations, et tracer les écarts du système pour les annuler une fois l'incident clos

Ensuite, un poste de commandement reconnu (recognized command post) : les parties intéressées doivent savoir où interagir avec le commandant — souvent une « war room » centrale, ou la coordination par e-mail et IRC. Google a trouvé IRC d'un grand secours : très fiable, il sert de journal des communications, avec des bots qui consignent le trafic de l'incident (utile au post-mortem) et les alertes, et permet à des équipes géographiquement dispersées de se coordonner.

Puis un document d'état d'incident vivant (live incident state document) — la responsabilité la plus importante du commandant. Éditable par plusieurs personnes simultanément (Google Docs, ou Google Sites), il peut être brouillon mais doit être fonctionnel : un modèle facilite sa génération, et l'information la plus importante en haut le rend utilisable. On le conserve pour l'analyse post-mortem. Petit principe de bon sens : ne faites pas dépendre votre gestion d'incident du logiciel même que vous tentez de réparer.

Enfin, des passations de relais nettes (clear, live handoff) : le poste de commandant doit être passé explicitement en fin de journée. Le commandant sortant met le nouveau au courant, déclare sans ambiguïté « tu es maintenant le commandant d'incident, d'accord ? », et ne quitte l'appel qu'après acquittement ferme. La passation est communiquée à tous, pour qu'on sache à tout moment qui dirige.

Quand déclarer un incident

Mieux vaut déclarer tôt un incident puis le clore vite que de devoir monter le dispositif des heures après le début d'un problème qui s'aggrave. Posez des conditions claires. Un événement est un incident si l'une des affirmations suivantes est vraie :

• avez-vous besoin d'impliquer une seconde équipe pour corriger le problème ?
• la panne est-elle visible des clients ?
• le problème reste-t-il non résolu après une heure d'analyse concentrée ?

Formuler la stratégie à l'avance, la structurer pour passer à l'échelle et l'exercer régulièrement réduit le délai moyen de rétablissement (MTTR) et offre une façon moins stressante de travailler sur les problèmes émergents. Les meilleures pratiques tiennent en quelques mots : prioriser (arrêter l'hémorragie, rétablir le service, préserver les preuves) ; préparer et documenter les procédures à l'avance ; faire confiance en donnant pleine autonomie dans chaque rôle ; s'introspecter sur son état émotionnel et appeler du renfort si la panique monte ; considérer les alternatives périodiquement ; pratiquer jusqu'à l'automatisme.

À retenir

• Le dépannage est apprenable : il combine une méthode générique (méthode hypothético-déductive) et la connaissance du système, en enchaînant rapport → triage → examen → diagnostic → test/traitement → guérison.
• Les pièges classiques — sauter sur une cause, biais de confirmation, corrélations fallacieuses — s'évitent en se rappelant que « corrélation n'est pas causalité » et qu'on doit penser « chevaux, pas zèbres ».
• En triage, arrêtez l'hémorragie d'abord : rétablissez le service avant de chercher la cause racine ; comme un pilote, pilotez l'avion avant de diagnostiquer.
• L'observabilité (métriques, journaux structurés, état exposé, traçage Dapper) doit être intégrée dès la conception, avec un identifiant de requête unique propagé à travers les RPC.
• Les trois urgences Google (induites par un test, un changement, un processus) enseignent les mêmes leçons : ne pas paniquer, élargir le filet, tester les rollbacks, garder des communications hors-bande, et conserver un historique des pannes pour ne pas les répéter.
• Un incident non géré dégénère par focalisation technique, mauvaise communication et cavalier seul ; la gestion d'incident (inspirée de l'ICS) y répond par la séparation des rôles — commandant d'incident, responsable opérationnel, communication, planification — un poste de commandement reconnu, un document d'état vivant et des passations nettes.
• Déclarez un incident tôt (seconde équipe impliquée, impact client, ou plus d'une heure sans solution), exercez le cadre régulièrement et faites tourner les rôles : on réduit ainsi le MTTR tout en travaillant plus sereinement.