7 min lecture • Guide 811 of 877
Réponse aux Incidents et Post-Mortems
Les incidents arrivent. GitScrum aide les équipes à documenter les incidents, suivre les remédiations et capturer les apprentissages pour l'amélioration continue.
Réponse aux Incidents
Processus de Réponse
FLUX DE RÉPONSE AUX INCIDENTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. DÉTECTER │
│ ────────── │
│ • Alerte monitoring se déclenche │
│ • Client signale problème │
│ • Membre équipe remarque problème │
│ │
│ 2. TRIER │
│ ───────── │
│ • Évaluer sévérité (SEV1, SEV2, SEV3) │
│ • Identifier services impactés │
│ • Pager l'astreinte appropriée │
│ │
│ 3. RÉPONDRE │
│ ────────── │
│ • Assembler équipe incident │
│ • Ouvrir canal incident │
│ • Commencer investigation │
│ │
│ 4. MITIGER │
│ ─────────── │
│ • Focus sur restaurer le service │
│ • Rollback si nécessaire │
│ • Appliquer corrections temporaires │
│ │
│ 5. RÉSOUDRE │
│ ────────── │
│ • Confirmer service restauré │
│ • Monitorer pour stabilité │
│ • Communiquer résolution │
│ │
│ 6. APPRENDRE │
│ ──────── │
│ • Planifier post-mortem │
│ • Documenter timeline │
│ • Créer actions correctives │
│ │
└─────────────────────────────────────────────────────────────┘
Niveaux de Sévérité
CLASSIFICATION PAR SÉVÉRITÉ:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEV1 (Critique): │
│ Panne complète, tous utilisateurs affectés │
│ Réponse: Immédiate, toutes mains │
│ Exemples: Site down, perte de données, brèche sécurité │
│ │
│ SEV2 (Majeur): │
│ Service dégradé, beaucoup d'utilisateurs affectés │
│ Réponse: Sous 30 min, astreinte primaire │
│ Exemples: Feature core cassée, performance sévèrement │
│ dégradée, paiements échouent │
│ │
│ SEV3 (Mineur): │
│ Impact limité, contournement existe │
│ Réponse: Jour ouvrable suivant │
│ Exemples: Feature secondaire cassée, erreurs │
│ intermittentes, problème UI │
│ │
└─────────────────────────────────────────────────────────────┘
Communication d'Incident
Communication Interne
COMMUNICATION PENDANT L'INCIDENT:
═════════════════════════════════
CANAL INCIDENT (Slack/Teams):
├── Créé immédiatement
├── Nommé: #incident-YYYY-MM-DD-description
├── Participants: Équipe concernée + stakeholders
└── Bot: Enregistre tout automatiquement
MISES À JOUR RÉGULIÈRES:
├── Toutes les 15-30 min pour SEV1
├── Toutes les heures pour SEV2
├── Format: Statut | Ce qu'on fait | Prochaine update
EXEMPLE:
┌─────────────────────────────────────────────────────────────┐
│ 🟠 UPDATE 14:45 │
│ │
│ STATUT: Investigation en cours │
│ IMPACT: API paiement down, 0 transactions │
│ ACTION: Rollback du dernier déploiement en cours │
│ ETA: 15 min pour rollback complet │
│ NEXT UPDATE: 15:00 │
└─────────────────────────────────────────────────────────────┘
Communication Externe
PAGE DE STATUT:
═══════════════
MISES À JOUR PUBLIQUES:
├── Honnêtes mais pas techniques
├── Focus sur l'impact utilisateur
├── Mises à jour régulières
└── Confirmation de résolution
EXEMPLE:
┌─────────────────────────────────────────────────────────────┐
│ 🟠 Dégradation du service de paiement │
│ Mis à jour il y a 5 minutes │
│ │
│ Nous rencontrons des difficultés avec notre système │
│ de paiement. Certains paiements peuvent échouer. │
│ │
│ Nos équipes travaillent activement à la résolution. │
│ Nous vous tiendrons informés toutes les 30 minutes. │
│ │
│ Impact: Paiements par carte │
│ Début: 14:23 UTC │
└─────────────────────────────────────────────────────────────┘
Post-Mortems
Culture Sans Blâme
PRINCIPES DU POST-MORTEM SANS BLÂME:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRINCIPES FONDAMENTAUX: │
│ │
│ 1. Les gens ont fait de leur mieux avec l'info qu'ils │
│ avaient à ce moment-là │
│ │
│ 2. Les erreurs humaines sont des symptômes, pas des │
│ causes racines │
│ │
│ 3. Si une erreur était facile à faire, elle sera │
│ refaite par quelqu'un d'autre │
│ │
│ 4. Le but est d'améliorer le système, pas de punir │
│ │
│ 5. La sécurité psychologique permet l'honnêteté │
│ │
│ À DIRE: │
│ • "Comment le système a-t-il permis cela?" │
│ • "Quelles informations manquaient?" │
│ • "Comment faciliter la bonne action?" │
│ │
│ À NE PAS DIRE: │
│ • "Qui a fait ça?" │
│ • "Comment as-tu pu rater ça?" │
│ • "Tu aurais dû savoir..." │
│ │
└─────────────────────────────────────────────────────────────┘
Structure du Post-Mortem
TEMPLATE POST-MORTEM:
═════════════════════
┌─────────────────────────────────────────────────────────────┐
│ POST-MORTEM: [Titre] │
│ Date incident: [Date] | Sévérité: [SEV] │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📋 RÉSUMÉ EXÉCUTIF │
│ [3-5 phrases: quoi, impact, résolution] │
│ │
│ 📊 MÉTRIQUES D'IMPACT │
│ • Durée: X heures │
│ • Utilisateurs affectés: X │
│ • Transactions perdues: X │
│ • Revenue impacté: X€ │
│ • TTD (Time to Detect): X min │
│ • TTR (Time to Resolve): X min │
│ │
│ 📅 TIMELINE DÉTAILLÉE │
│ 14:15 - Déploiement du commit abc123 │
│ 14:23 - Première alerte reçue │
│ 14:25 - Incident déclaré │
│ 14:30 - Investigation commence │
│ 14:45 - Cause identifiée │
│ 15:00 - Rollback initié │
│ 15:15 - Service restauré │
│ 15:30 - Confirmé stable │
│ │
│ 🔍 CAUSE RACINE │
│ [Analyse technique approfondie] │
│ │
│ 🧠 5 WHYS │
│ 1. Pourquoi le paiement a échoué? │
│ → Le timeout était trop court │
│ 2. Pourquoi le timeout était trop court? │
│ → Config non mise à jour pour nouveau provider │
│ 3. Pourquoi config non mise à jour? │
│ → Pas de checklist de migration │
│ 4. Pourquoi pas de checklist? │
│ → Processus de changement de provider non documenté │
│ 5. Pourquoi pas documenté? │
│ → Première migration de ce type │
│ │
│ ✅ CE QUI A BIEN FONCTIONNÉ │
│ • Détection rapide (8 min) │
│ • Communication claire │
│ • Rollback fonctionnel │
│ │
│ ❌ CE QUI DOIT ÊTRE AMÉLIORÉ │
│ • Tests de config en staging │
│ • Documentation des migrations │
│ • Canary deployments │
│ │
│ 📝 ACTIONS │
│ ☐ Créer checklist migration provider - @Alice - 15 Fév │
│ ☐ Ajouter test de timeout en CI - @Bob - 20 Fév │
│ ☐ Implémenter canary deploy - @Carol - 1 Mars │
│ │
└─────────────────────────────────────────────────────────────┘
Suivi des Actions
Tracking dans GitScrum
GESTION DES ACTIONS POST-MORTEM:
═════════════════════════════════
CRÉER DES TÂCHES GITSCRUM:
├── Liées à l'incident original
├── Label: postmortem-action
├── Priorité: Haute (prévient récurrence)
├── Sprint: Priorisées rapidement
SUIVI:
┌─────────────────────────────────────────────────────────────┐
│ ACTIONS POST-MORTEM EN COURS │
├─────────────────────────────────────────────────────────────┤
│ Incident │ Action │ Owner │ Status │ Due │
├─────────────────────────────────────────────────────────────┤
│ INC-042 │ Checklist migration │ Alice │ 🟡 │ 15/2 │
│ INC-042 │ Test timeout CI │ Bob │ ✅ │ 20/2 │
│ INC-039 │ Monitoring latence │ Carol │ 🔄 │ 1/3 │
│ INC-038 │ Runbook DB failover │ Dave │ ✅ │ Done │
└─────────────────────────────────────────────────────────────┘
Métriques d'Incidents
Dashboard
MÉTRIQUES À SUIVRE:
═══════════════════
VOLUME:
├── Incidents par mois/trimestre
├── Par sévérité
├── Par service/équipe
└── Tendance ↗ ou ↘
TEMPS DE RÉPONSE:
├── TTD (Time to Detect): Temps avant détection
├── TTA (Time to Acknowledge): Temps avant prise en charge
├── TTM (Time to Mitigate): Temps avant mitigation
└── TTR (Time to Resolve): Temps avant résolution
QUALITÉ:
├── Actions post-mortem complétées: %
├── Incidents répétés: Nombre (doit être 0)
├── Satisfaction équipe: Score
└── Temps moyen entre incidents