07 Tester, provoquer une panne et réparer

Injectez une panne connue, diagnostiquez-la grâce à ClickStack, appliquez une correction et prouvez le rétablissement.

Résultat attendu

En environ 20 minutes, vous allez traiter un incident, de la panne jusqu’au rétablissement vérifié. Ce module prolonge directement le module 06 et utilise le MCP ClickStack configuré au module 00.

Étape 1 — Choisir une panne

Commencez par la panne 01. La panne 02 est un second exercice rapide ; la panne 03 nécessite un jeu de données plus volumineux pour échouer de manière fiable.

Branche	Panne attendue	Service à reconstruire
`fault/01-map-not-loading`	Les polygones de la carte disparaissent ; les autres cartes fonctionnent	front-end
`fault/02-zone-stats-500`	Les données de la carte des zones échouent avec une erreur HTTP 500	back-end
`fault/03-slow-dashboard`	La requête de tendance arrive à expiration ; à utiliser uniquement avec plusieurs mois de données	back-end

Étape 2 — Injecter et reproduire la panne

L’exemple suivant injecte la panne 01 tout en préservant votre travail local :

cd "$(git rev-parse --show-toplevel)"
git stash push --include-untracked -m "before-module-07"
git switch build-workshop-v1
git switch fault/01-map-not-loading

cd workshops/build_workshop/app
docker compose --env-file .env.workshop \
  -f docker-compose.workshop.yml \
  -f docker-compose.otel.yml \
  up -d --build frontend

Ouvrez une nouvelle session de navigateur sur localhost:8080. La carte vide est maintenant le résultat attendu ; toute panne ailleurs ne fait pas partie de ce scénario.

Étape 3 — Diagnostiquer à partir des preuves

Donnez le symptôme à l’agent, pas la réponse :

Using the clickstack MCP, investigate the current workshop failure.
Correlate frontend and backend telemetry, identify the root cause, and cite the exact
events, request, response content type, or trace that supports the conclusion.
Do not edit code yet.

Pour la panne 01, examinez également ClickStack → Client Sessions. Les preuves utiles sont une erreur du front-end et l’échec d’analyse d’une ressource ; les traces saines du back-end constituent aussi une preuve, car elles permettent de circonscrire l’impact.

ClickStack Client Sessions montrant l’erreur du front-end et la répétition de la session avec la carte vide

Avant de corriger quoi que ce soit, notez :

le composant défaillant ;
les preuves qui le démontrent ;
un contrôle de rétablissement qui échoue avant la correction et réussit après celle-ci.

Étape 4 — Corriger et reconstruire

Demandez à l’agent d’apporter la modification minimale qui corrige la cause démontrée, puis reconstruisez le service concerné. Pour la panne 01 :

docker compose --env-file .env.workshop \
  -f docker-compose.workshop.yml \
  -f docker-compose.otel.yml \
  up -d --build frontend

Pour la panne 02 ou 03, remplacez frontend par backend.

Ouvrez une nouvelle session de navigateur. Le symptôme initial doit avoir disparu et ClickStack ne doit afficher aucune nouvelle erreur correspondante. Les anciens événements de l’incident restent présents dans la plage temporelle sélectionnée ; comparez les horodatages au lieu de vous attendre à ce que l’historique disparaisse.

Étape 5 — Revenir à la référence saine

Préservez votre tentative de correction, rétablissez build-workshop-v1 et reconstruisez les deux services de l’application :

cd "$(git rev-parse --show-toplevel)"
git stash push --include-untracked -m "module-07-fix"
git switch build-workshop-v1

cd workshops/build_workshop/app
docker compose --env-file .env.workshop \
  -f docker-compose.workshop.yml \
  -f docker-compose.otel.yml \
  up -d --build frontend backend

Vérification finale

Le symptôme injecté est apparu avant la correction.
L’agent a cité la télémétrie qui démontre la cause racine.
Le même contrôle de rétablissement réussit après la correction.
Une nouvelle session ne crée aucune nouvelle erreur correspondante.
git branch --show-current renvoie build-workshop-v1.

Passez à 08 Chat et Langfuse.