runbook-incident-response

Déclencheurs

• réaction aux incidents
• production indisponible
• panne de service
• défaillance système
• faille de sécurité
• perte de données
• dégradation des performances
• pic de taux d'erreur
• incident P0
• incident P1
• rollback nécessaire
• déploiement hotfix
• post-mortem
• analyse des causes racines
• triage des incidents
• alerte on-call
• récupération du système

Instructions

Quelque chose est cassé en production. Les utilisateurs sont affectés. La rapidité de réaction est importante, mais faire les choses correctement l'est tout autant. Ce runbook couvre la détection jusqu'au post-mortem. Durée : minutes à heures.

Classification de la sévérité

Équipes de réponse par sévérité

P0 Critique (utiliser organization_spawn avec tous) :

• Infrastructure Maintainer : Commandant incident — évaluer l'étendue, coordonner
• DevOps Automator : Exécution déploiement/rollback
• Backend Architect : Investigation des causes racines (système)
• Frontend Developer : Investigation côté client
• Support Responder : Mises à jour de la page de statut, notifications utilisateurs
• Executive Summary Generator : Mises à jour exécutives en temps réel

P1 Haute :

• Infrastructure Maintainer : Commandant incident
• DevOps Automator : Support déploiement
• Relevant Developer Agent : Implémentation du correctif
• Support Responder : Communication utilisateurs

P2 Moyenne :

• Relevant Developer Agent : Implémentation du correctif
• Evidence Collector : Vérifier le correctif

P3 Basse :

• Sprint Prioritizer : Ajouter au backlog

Étape 1 : Détection & Triage (0-5 minutes)

Déclencheur : Alerte monitoring / Rapport utilisateur / Détection agent

Infrastructure Maintainer :

1. Accuser réception de l'alerte
2. Évaluer l'étendue et l'impact (utilisateurs affectés, services impactés, données à risque ?)
3. Classifier la sévérité (P0/P1/P2/P3)
4. Utiliser organization_spawn pour activer l'équipe de réponse appropriée
5. Créer un canal/fil incident

Étape 2 : Investigation (5-30 minutes)

Investigation parallèle via organization_delegate :

• Infrastructure Maintainer : Vérifier les métriques système (CPU, mémoire, réseau, disque), examiner les logs d'erreur, vérifier les déploiements récents, vérifier les dépendances externes
• Backend Architect (P0/P1) : Vérifier la santé de la base de données, examiner les taux d'erreur API, vérifier la communication entre services, identifier le composant défaillant
• DevOps Automator : Examiner l'historique des déploiements, vérifier le statut CI/CD, préparer le rollback, vérifier l'état de l'infrastructure

Résultat : Cause racine identifiée ou réduite à un composant.

Étape 3 : Atténuation (15-60 minutes)

Arbre de décision :

• Causé par un déploiement récent : DevOps Automator exécute le rollback, Infrastructure Maintainer vérifie la récupération
• Causé par un problème d'infrastructure : Infrastructure Maintainer effectue une mise à l'échelle/redémarrage/basculement, vérifier la récupération
• Causé par un bug de code : Developer implémente le hotfix, Evidence Collector vérifie, DevOps Automator déploie le hotfix
• Causé par une dépendance externe : Infrastructure Maintainer active le fallback/cache, Support Responder communique aux utilisateurs

Tout au long du processus :

• Support Responder : Mettre à jour la page de statut toutes les 15 minutes
• Executive Summary Generator : Informer les stakeholders (P0 uniquement)

Étape 4 : Vérification de la résolution (Post-correctif)

• Evidence Collector : Vérifier que le correctif résout le problème, capturer des captures d'écran, confirmer l'absence de nouveaux problèmes
• Infrastructure Maintainer : Vérifier que les métriques reviennent à la normale, confirmer l'absence de défaillances en cascade, surveiller 30 minutes post-correctif
• API Tester (si lié à API) : Exécuter une régression sur les endpoints affectés, vérifier les temps de réponse, confirmer que les taux d'erreur sont au baseline

Étape 5 : Post-Mortem (Dans les 48 heures)

Utiliser organization_delegate pour Workflow Optimizer :

1. Reconstruction de la chronologie (quand introduit, détecté, résolu, durée totale d'impact)
2. Analyse des causes racines (qu'est-ce qui a échoué, pourquoi, pourquoi non détecté plus tôt, 5 Pourquois)
3. Évaluation de l'impact (utilisateurs affectés, impact financier, réputation, impact données)
4. Mesures de prévention (améliorations monitoring, améliorations tests, changements de processus, changements d'infrastructure)
5. Éléments d'action avec propriétaires et délais

Utiliser knowledge_write pour persister le rapport post-mortem. Sprint Prioritizer ajoute les tâches de prévention au backlog.

Modèles de communication

Mise à jour de la page de statut :

[TIMESTAMP] — Incident [SERVICE NAME]
Statut : [Investigating / Identified / Monitoring / Resolved]
Impact : [Description de l'impact utilisateur]
Action actuelle : [Ce que nous faisons]
Prochaine mise à jour : [Quand attendre la prochaine mise à jour]

Mise à jour exécutive (P0 uniquement) :

RÉSUMÉ INCIDENT — [TIMESTAMP]
SITUATION : [Service] est [down/degraded] affectant [N utilisateurs/% du trafic]
CAUSE : [Connue/Sous investigation] — [Brève description si connue]
ACTION : [Ce qui est fait] — ETA [estimation temps]
IMPACT : [Impact métier — revenu, utilisateurs, réputation]
PROCHAINE MISE À JOUR : [Timestamp]

Matrice d'escalade

Livrables

• [ ] Incident classifié avec niveau de sévérité
• [ ] Équipe de réponse activée dans le SLA
• [ ] Cause racine identifiée
• [ ] Correctif implémenté et vérifié
• [ ] Page de statut mise à jour tout au long du processus
• [ ] Stakeholders informés (P0/P1)
• [ ] Post-mortem complété dans les 48 heures
• [ ] Éléments d'action de prévention dans le backlog

Métriques de succès

• Détection à résolution P0 : < 30 minutes
• Détection à résolution P1 : < 2 heures
• Détection à résolution P2 : < 4 heures
• Taux de réalisation post-mortem : 100% pour P0/P1
• Taux incidents répétés : < 5%
• Fréquence mise à jour page de statut pendant incident : toutes les 15 minutes
• Mean time to detect (MTTD) : < 5 minutes
• Mean time to resolve (MTTR) : < 30 minutes

Vérifier

• La commande deploy a été réellement exécutée et la sortie build/log (ou URL deploy) est capturée
• L'URL déployée a été ouverte et a retourné un 2xx ; les routes clés ont été échantillonnées, pas seulement l'index
• Les variables d'environnement requises par l'app sont présentes dans l'environnement cible ; les défaillances de variables manquantes ont été exclues
• Un plan de rollback (ID déploiement précédent, git SHA, ou commande revert d'une ligne) est documenté avant de promouvoir en production
• Une vérification de santé/observabilité (logs, error tracker, page de statut) a été inspectée post-deploy ; le taux d'erreur baseline est enregistré
• Configuration DNS / domaine / SSL a été confirmée, pas supposée se reporter du déploiement précédent