Un premier game day : une expérience de chaos avec une hypothèse, un rayon d'impact et une règle d'abandon

Objectif

Apprendre, un jour choisi et sous surveillance de tous, ce qui se passe quand un composant tombe en panne, plutôt que de l'apprendre la nuit ; et répéter en même temps la réponse humaine (alertes, runbooks, rôles).

Prérequis

Une surveillance qui affiche le signal d'état stable en quasi temps réel ; une annulation testée pour la faute ; une entrée dans le calendrier des changements et, si la production est concernée, une note sur la page de statut ; un facilitateur qui n'est pas l'un des répondants.

Étapes

1. Choisir une faute plausible et réversible : arrêter une réplique, bloquer le port d'une dépendance, remplir une file d'attente, faire expirer un cache, révoquer un identifiant en environnement de préproduction (staging). Pas « couper la base de données ».
2. Définir l'état stable comme, selon les mots des Principles of Chaos Engineering, une sortie mesurable du système qui indique un comportement normal (taux de succès des requêtes, paiements finalisés par minute), et écrire l'hypothèse : « ce signal reste dans sa plage normale pendant que la réplique 2 est arrêtée ».
3. Écrire séparément le comportement système attendu et le comportement humain attendu : quelle alerte se déclenche et en combien de temps, quel runbook est utilisé, qui est appelé.
4. Fixer le rayon d'impact (une réplique, une région, une fraction du trafic) et la condition d'abandon (le signal sort de sa plage pendant plus d'un nombre défini de minutes, ou toute erreur visible par un client) avec la commande d'annulation prête dans un terminal.
5. Annoncer le début, injecter la faute, démarrer un chronomètre. Le facilitateur consigne les horodatages : faute injectée, première alerte, première action humaine, mitigation, rétablissement. Les répondants agissent comme lors d'une vraie alerte ; le facilitateur ne répond à aucune question à laquelle la surveillance pourrait répondre.
6. Annuler la faute à la fin planifiée ou en cas d'abandon ; vérifier l'état stable ; confirmer l'absence d'effets résiduels (files d'attente vidées, connexions réinitialisées, alertes effacées).
7. Débriefer dans l'heure : l'hypothèse a-t-elle été réfutée ? Quelle alerte ne s'est pas déclenchée, quelle étape de runbook était fausse, quel tableau de bord manquait ? Rédiger des actions à mener avec des responsables, comme pour un post-mortem.
8. Si une injection réelle n'est pas encore acceptable, exécuter d'abord le même scénario comme exercice sur table (tabletop). Le livre SRE décrit la « roue de l'infortune » (Wheel of Misfortune) : un maître du jeu présente un scénario et la paire d'astreinte raconte ce qu'elle ferait, le groupe apprenant à chaque tour.

Résultat attendu

Un compte rendu écrit de l'effet réel d'une faute, une courte liste des lacunes constatées, et une équipe qui s'est entraînée à déclarer et à traiter un incident sans panne réelle.

Limites et base de vérification

Un environnement de préproduction prouve moins que la production, et les Principles plaident pour la production car le comportement diffère selon l'environnement et le trafic ; une première exécution en préproduction reste néanmoins le point de départ le plus sûr. Le protocole est une synthèse des sources citées ; aucune conclusion tirée de son exécution n'est revendiquée.