Réponse a incident¶
Organiser une réponse structurée avec des rôles clairs, une war room et des runbooks.
Les trois rôles fondamentaux¶
Une réponse efficace repose sur la séparation des responsabilités. Trois rôles couvrent l'essentiel des besoins.
| Rôle | Responsabilité | Ne fait pas |
|---|---|---|
| Incident Commander (IC) | Coordonné la réponse, prend les décisions, géré la timeline | Ne touche pas aux systèmes |
| Comms Lead | Redige les mises à jour, géré la statuspage, notifie les stakeholders | Ne coordonné pas la technique |
| Tech Lead | Dirige le diagnostic, supervise les actions techniques | Ne communique pas avec l'extérieur |
Sur les P3/P4, une seule personne peut cumuler plusieurs rôles. Sur un P1, la séparation est obligatoire pour éviter la surchargé cognitive.
Montee en puissance des rôles¶
flowchart LR
A([Alerte]) --> B[On-call ingenieur\nIC provisoire]
B --> C{P1 ou P2 ?}
C -- Non --> D[Resolution par on-call\nroles cumules]
C -- Oui --> E[IC designe\nComms Lead designe]
E --> F[Tech Lead designe\nEquipes specialistes]
F --> G[War Room ouverte]La war room¶
La war room est un espace de coordination dédié, isole du bruit des canaux habituels.
Structure du canal¶
- Nom normalise :
#inc-YYYYMMDD-<service>(ex :#inc-20240315-paiement) - Toujours commencer par un message fixe (pinned) avec : sévérité, IC, Comms Lead, Tech Lead, heure de début
- Mettre à jour le message fixe à chaque changement majeur
Règles de la war room¶
| Règle | Pourquoi |
|---|---|
| Seule la war room fait foi pour l'état de l'incident | Evite les informations contradictoires |
| Toute action technique est annoncee avant exécution | Permet de correlater les effets |
| Pas de discussions parallèles hors du canal | Réduit les silos d'information |
| L'IC à le dernier mot sur les décisions | Evite les blocages par consensus |
Timeline temps réel¶
L'IC ou un scribe dédié documente chaque événement avec un horodatage.
| Heure | Acteur | Action / Constat |
|---|---|---|
| 14:03 | Alerte | CPU > 95 % sur prod-api-02 |
| 14:05 | on-call | Confirmation impact : 503 sur /checkout |
| 14:07 | IC | Incident déclaré P1, war room ouverte |
| 14:12 | Tech Lead | Hypothèse : fuite connexion DB |
| 14:18 | Tech Lead | Rollback deploy 14h00 initié |
| 14:24 | on-call | Taux d'erreur retombe a 0 % |
| 14:26 | IC | Service confirme stable — incident mitigue |
La timeline sert de base au post-mortem et permet de reconstituer exactement ce qui s'est passe.
Runbooks d'urgence¶
Un runbook d'urgence est une procédure pas-a-pas pour les scenarios d'incidents les plus fréquents.
Structure d'un runbook¶
- Titre : nom du scenario (ex : "Redémarrage du service de paiement")
- Déclencheur : symptomes typiques qui justifient ce runbook
- Pre-requis : accès, permissions nécessaires
- Étapes : actions ordonnées avec commandes ou chemins UI
- Vérification : comment confirmer que l'action a eu l'effet voulu
- Escalade : que faire si le runbook ne suffit pas
Bonnes pratiques¶
- Testez les runbooks régulièrement (chaos day, exercices)
- Versionnez-les avec le code (GitOps)
- Linkez les runbooks depuis les alertes (annotation dans Grafana, Datadog)
- Limitez un runbook a un seul scenario : privilegiez la clarte sur l'exhaustivité
Lien avec la documentation
Les runbooks d'urgence sont distincts de la documentation opérationnelle générale. Ils doivent être concis, actionables en situation de stress. Voir le chapitre Documenter les runbooks pour la structure détaillée.