6 min lecture • Guide 341 of 877
Workflow de Réponse aux Incidents
Les incidents arrivent. Ce qui compte c'est comment vous répondez. Une bonne réponse aux incidents minimise l'impact client, réduit le stress et crée des opportunités d'apprentissage. Une mauvaise réponse prolonge les pannes et épuise les équipes. Ce guide couvre les workflows pratiques de réponse aux incidents.
Phases d'Incident
| Phase | Focus | Durée |
|---|---|---|
| Détection | Alerte déclenchée | Minutes |
| Triage | Évaluer sévérité | Minutes |
| Réponse | Fix/mitiger | Variable |
| Communication | Informer stakeholders | Continu |
| Résolution | Service restauré | - |
| Post-mortem | Apprendre et améliorer | Jours |
Niveaux de Sévérité
Classification
SÉVÉRITÉ D'INCIDENT:
════════════════════
P1 - CRITIQUE:
─────────────────────────────────────
Impact:
├── Panne complète du service
├── Feature majeure complètement down
├── Brèche de sécurité
├── Perte/corruption de données
├── Tous les clients affectés
└── Business critique
Réponse:
├── Toutes mains sur le pont
├── Escalade immédiate
├── Direction informée
├── Communication externe
├── Tout lâcher
└── Jusqu'à résolution
P2 - HAUTE:
─────────────────────────────────────
Impact:
├── Feature significative altérée
├── Contournement peut exister
├── Beaucoup de clients affectés
├── Service dégradé
└── Inconvénient majeur
Réponse:
├── Répondants dédiés
├── Manager informé
├── Support client au courant
├── Fix haute priorité
└── Résolu en quelques heures
P3 - MOYENNE:
─────────────────────────────────────
Impact:
├── Feature mineure affectée
├── Impact client limité
├── Contournement disponible
├── Sous-ensemble d'utilisateurs
└── Inconvénient modéré
Réponse:
├── Prochain jour ouvrable
├── Priorisé dans backlog
├── Communication interne
└── Résolu cette semaine
P4 - BASSE:
─────────────────────────────────────
Impact:
├── Problèmes cosmétiques
├── Inconvénient mineur
├── Contournement trivial
└── Très peu d'utilisateurs
Réponse:
├── Travail planifié
├── Backlog normal
└── Quand capacité disponible
Workflow de Réponse
Détection
DÉTECTION D'INCIDENT:
═════════════════════
SOURCES DE DÉTECTION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MONITORING AUTOMATIQUE (préféré): │
│ ├── Alertes d'application (erreurs, latence) │
│ ├── Alertes d'infrastructure (CPU, mémoire, disque) │
│ ├── Alertes de synthétique (health checks) │
│ └── Alertes business (transactions, conversions) │
│ │
│ RAPPORTS CLIENTS: │
│ ├── Tickets support │
│ ├── Réseaux sociaux │
│ └── Appels directs │
│ │
│ DÉTECTION INTERNE: │
│ ├── Équipe remarque problème │
│ ├── Tests échouent │
│ └── Déploiement suspect │
│ │
│ OBJECTIF: Détecter avant les clients │
│ MÉTRIQUE: TTD < 5 minutes │
│ │
└─────────────────────────────────────────────────────────────┘
Triage
TRIAGE D'INCIDENT:
══════════════════
QUESTIONS CLÉS:
├── Quel est l'impact utilisateur?
├── Combien d'utilisateurs affectés?
├── Y a-t-il un contournement?
├── Est-ce que ça empire?
└── Quelle est la sévérité?
MATRICE DE DÉCISION:
┌─────────────────────────────────────────────────────────────┐
│ Impact │ Tous users │ Beaucoup │ Peu │ Aucun │
├─────────────────────────────────────────────────────────────┤
│ Core down │ P1 │ P1 │ P2 │ P3 │
│ Major dégradé │ P1 │ P2 │ P2 │ P3 │
│ Minor affecté │ P2 │ P3 │ P3 │ P4 │
│ Cosmétique │ P3 │ P4 │ P4 │ P4 │
└─────────────────────────────────────────────────────────────┘
ACTIONS DE TRIAGE:
├── Déclarer sévérité
├── Pager l'astreinte appropriée
├── Créer canal incident
└── Commencer timeline
Mitigation
STRATÉGIES DE MITIGATION:
═════════════════════════
ORDRE DE PRÉFÉRENCE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. ROLLBACK │
│ Si déploiement récent suspect │
│ Temps: Minutes │
│ Risque: Bas │
│ │
│ 2. FEATURE FLAG │
│ Désactiver la feature problématique │
│ Temps: Secondes │
│ Risque: Très bas │
│ │
│ 3. SCALING │
│ Ajouter capacité si surcharge │
│ Temps: Minutes │
│ Risque: Bas │
│ │
│ 4. CIRCUIT BREAKER │
│ Isoler le composant défaillant │
│ Temps: Minutes │
│ Risque: Moyen (dégradation) │
│ │
│ 5. HOTFIX │
│ Fix rapide en production │
│ Temps: 30 min+ │
│ Risque: Moyen à élevé │
│ │
│ RÈGLE: Restaurer le service d'abord, comprendre après │
│ │
└─────────────────────────────────────────────────────────────┘
Communication
Stakeholders
MATRICE DE COMMUNICATION:
═════════════════════════
QUI INFORMER PAR SÉVÉRITÉ:
┌─────────────────────────────────────────────────────────────┐
│ Stakeholder │ P1 │ P2 │ P3 │ P4 │ Comment │
├─────────────────────────────────────────────────────────────┤
│ Équipe technique │ ✓ │ ✓ │ ✓ │ ✓ │ Canal incident │
│ Manager │ ✓ │ ✓ │ ○ │ │ Slack/SMS │
│ Direction │ ✓ │ ○ │ │ │ Email/Appel │
│ Support client │ ✓ │ ✓ │ ✓ │ │ Canal dédié │
│ Clients (public) │ ✓ │ ✓ │ │ │ Page statut │
│ Ventes/Account │ ✓ │ ○ │ │ │ Si client affecté │
└─────────────────────────────────────────────────────────────┘
✓ = Toujours, ○ = Si pertinent
FRÉQUENCE DES UPDATES:
├── P1: Toutes les 15 min
├── P2: Toutes les 30 min
├── P3: Toutes les heures
└── P4: Quand résolu
Post-Mortem
Structure
TEMPLATE POST-MORTEM:
═════════════════════
1. RÉSUMÉ (5 min de lecture)
├── Que s'est-il passé?
├── Impact?
├── Durée?
└── Comment résolu?
2. TIMELINE DÉTAILLÉE
├── Heure: Événement
├── Heure: Détection
├── Heure: Actions prises
└── Heure: Résolution
3. CAUSE RACINE (5 Whys)
└── Analyse approfondie
4. CE QUI A FONCTIONNÉ
└── Bonnes pratiques à maintenir
5. CE QUI DOIT S'AMÉLIORER
└── Lacunes identifiées
6. ACTIONS CORRECTIVES
├── Action | Owner | Deadline
└── Priorité et suivi
GitScrum pour les Incidents
Tracking et Suivi
GESTION DANS GITSCRUM:
═══════════════════════
PENDANT L'INCIDENT:
├── Créer tâche type "Incident"
├── Assigner sévérité (label)
├── Timeline dans commentaires
└── Statut: En Investigation → Mitigé → Résolu
APRÈS L'INCIDENT:
├── Lier au post-mortem
├── Créer actions comme sous-tâches
├── Label: postmortem-action
├── Sprint: Prochaine itération
└── Suivi jusqu'à complétion
MÉTRIQUES:
├── Nombre incidents par mois
├── MTTD, MTTA, MTTR
├── Taux complétion actions
└── Incidents récurrents