Comment dirigez-vous pendant un incident de production ?

Question

Accepted Answer

Pendant un incident, votre rôle est de **rétablir le service calmement et de coordonner la réponse**, non pas d'être le héros qui le résout seul. Des rôles clairs, une communication calme et un parti pris pour atténuer d'abord séparent une réponse fluide du chaos.

## Comment gérer un incident

```text
1. ASSIGN roles — incident commander (coordinates), responders (fix),
   comms (updates stakeholders). One person can't do all three.
2. MITIGATE first — stop the bleeding (roll back, feature-flag off)
   before chasing root cause.
3. COMMUNICATE on a cadence — even "still investigating" every 15-30 min.
4. STAY CALM — the team mirrors your energy. Blame comes later, or never.
5. After: BLAMELESS post-mortem — fix the system, not the person.
```

## Atténuez avant de diagnostiquer

L'instinct de trouver la cause profonde est fort, résistez-y. Si une restauration de version rétablit le service, faites-le *d'abord*, puis enquêtez calmement avec la pression levée. Les utilisateurs se soucient d'être débloqués, pas de votre diagnostic.

## Un exemple concret

Un déploiement casse le checkout. Ne déboguez pas le nouveau code en direct sous pression. Restaurez immédiatement, confirmez que le checkout fonctionne, publiez une mise à jour, *puis* enquêtez sur le mauvais déploiement dans des conditions calmes.

## Un piège

Une rétrospective culpabilisante enseigne aux gens à cacher les problèmes. Gardez-la blameless, concentrez-vous sur les lacunes systémiques (pas de canary, pas d'alerte) qui l'ont permis.

## Pourquoi c'est important

Les incidents sont stressants et très visibles, la façon dont vous dirigez façonne à la fois le résultat et la confiance de l'équipe en vous.

La coordination calme et l'apprentissage blameless transforment une panne en un système qui est plus difficile à casser la prochaine fois.