6 min lecture • Guide 836 of 877
Réponse aux Incidents pour les Équipes de Développement
Quand les choses cassent, le processus aide. GitScrum aide les équipes à suivre les incidents aux côtés du travail de développement, connectant les corrections à leurs événements déclencheurs.
Bases des Incidents
Qu'est-ce qu'un Incident
DÉFINITION D'INCIDENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ UN INCIDENT EST: │
│ ─────────────── │
│ Interruption non planifiée du service │
│ Dégradation significative de la qualité de service │
│ Violation de SLA ou SLO │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NIVEAUX DE SÉVÉRITÉ: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SEV-1 (CRITIQUE): ││
│ │ • Panne complète du service ││
│ │ • Feature majeure cassée pour tous les utilisateurs ││
│ │ • Perte de données ou brèche de sécurité ││
│ │ Réponse: Toutes mains, 24/7 ││
│ │ ││
│ │ SEV-2 (HAUTE): ││
│ │ • Panne partielle ou dégradation ││
│ │ • Feature majeure cassée pour certains utilisateurs ││
│ │ • Contournement existe mais pénible ││
│ │ Réponse: Immédiate pendant heures de travail ││
│ │ ││
│ │ SEV-3 (MOYENNE): ││
│ │ • Feature mineure cassée ││
│ │ • Performance dégradée mais utilisable ││
│ │ • Petit sous-ensemble d'utilisateurs affectés ││
│ │ Réponse: Jour ouvrable suivant ││
│ │ ││
│ │ SEV-4 (BASSE): ││
│ │ • Problèmes cosmétiques ││
│ │ • Inconvénient mineur ││
│ │ Réponse: Travail planifié ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OBJECTIF: Restaurer le service ASAP, apprendre après │
└─────────────────────────────────────────────────────────────┘
Phases d'Incident
Workflow de Réponse
CYCLE DE VIE D'INCIDENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PHASE 1: DÉTECTER │
│ ───────────────── │
│ SOURCES: │
│ • Alertes de monitoring automatisées │
│ • Rapports clients │
│ • Équipe interne remarque │
│ │
│ MÉTRIQUES: │
│ • TTD (Time to Detect): Cible < 5 min │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PHASE 2: TRIER │
│ ───────────── │
│ ACTIONS: │
│ • Évaluer la sévérité │
│ • Identifier les services impactés │
│ • Estimer l'impact utilisateur │
│ • Décider de l'escalade │
│ │
│ MÉTRIQUES: │
│ • TTA (Time to Acknowledge): Cible < 15 min │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PHASE 3: RÉPONDRE │
│ ─────────────── │
│ ACTIONS: │
│ • Assembler l'équipe │
│ • Ouvrir canal de communication │
│ • Investiguer la cause │
│ • Appliquer mitigation │
│ │
│ MÉTRIQUES: │
│ • TTM (Time to Mitigate): Variable selon sévérité │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PHASE 4: RÉSOUDRE │
│ ───────────────── │
│ ACTIONS: │
│ • Confirmer service restauré │
│ • Valider stabilité │
│ • Communiquer résolution │
│ • Planifier post-mortem │
│ │
│ MÉTRIQUES: │
│ • TTR (Time to Resolve): Cible dépend de SLA │
│ │
└─────────────────────────────────────────────────────────────┘
Rôles et Responsabilités
Équipe d'Incident
RÔLES DANS LA RÉPONSE:
═══════════════════════
COMMANDANT D'INCIDENT (IC):
┌─────────────────────────────────────────────────────────────┐
│ • Coordonne toute la réponse │
│ • Prend les décisions finales │
│ • Gère l'escalade │
│ • Ne fait PAS le travail technique │
│ • Assure le focus de l'équipe │
└─────────────────────────────────────────────────────────────┘
LEAD TECHNIQUE:
┌─────────────────────────────────────────────────────────────┐
│ • Dirige l'investigation technique │
│ • Propose des solutions │
│ • Implémente les fixes │
│ • Valide la résolution │
└─────────────────────────────────────────────────────────────┘
COMMUNICATEUR:
┌─────────────────────────────────────────────────────────────┐
│ • Met à jour les parties prenantes │
│ • Gère la page de statut │
│ • Répond aux questions │
│ • Documente la timeline │
└─────────────────────────────────────────────────────────────┘
SCRIBE (optionnel pour gros incidents):
┌─────────────────────────────────────────────────────────────┐
│ • Documente tout en temps réel │
│ • Note les timestamps │
│ • Capture les décisions │
│ • Prépare le post-mortem │
└─────────────────────────────────────────────────────────────┘
Communication
Pendant l'Incident
PATTERNS DE COMMUNICATION:
══════════════════════════
CANAL D'INCIDENT:
├── Créer immédiatement
├── Nom: #incident-YYYY-MM-DD-titre
├── Ajouter les personnes concernées
└── Épingler les infos clés
MISES À JOUR RÉGULIÈRES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Même si pas de nouvelle info: │
│ "15:45 - Toujours en investigation. Équipe analyse les │
│ logs du service auth. Prochaine update dans 15 min." │
│ │
│ Quand vous avez de l'info: │
│ "16:00 - Cause identifiée: timeout dans l'API externe. │
│ Implémentons un fallback. ETA résolution: 30 min." │
│ │
│ À la résolution: │
│ "16:30 - Service restauré et stable. Monitoring normal. │
│ Post-mortem planifié pour demain 10h." │
│ │
└─────────────────────────────────────────────────────────────┘
FORMAT RECOMMANDÉ:
├── Timestamp
├── Statut actuel
├── Action en cours
├── ETA si possible
└── Prochaine update
Post-Mortem
Après l'Incident
PROCESSUS POST-MORTEM:
═══════════════════════
TIMING:
├── Planifier dans les 48h
├── Tenir dans la semaine
├── Participants: Équipe impliquée
AGENDA (60-90 min):
├── 1. Timeline (15 min)
├── 2. Analyse cause racine (20 min)
├── 3. Ce qui a bien fonctionné (10 min)
├── 4. Ce qui doit s'améliorer (15 min)
├── 5. Actions correctives (15 min)
└── 6. Wrap-up (5 min)
PRINCIPES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SANS BLÂME: │
│ • Focus sur les systèmes, pas les personnes │
│ • "Comment le système a permis l'erreur?" │
│ • "Quelles gardes-fou manquaient?" │
│ │
│ ORIENTÉ ACTION: │
│ • Chaque apprentissage → action concrète │
│ • Chaque action → propriétaire + deadline │
│ • Suivi dans GitScrum │
│ │
└─────────────────────────────────────────────────────────────┘
GitScrum pour les Incidents
Tracking
GESTION DANS GITSCRUM:
═══════════════════════
TÂCHE INCIDENT:
├── Type: Incident
├── Label: sev1/sev2/sev3/sev4
├── Priorité: Critique/Haute
├── Timeline dans commentaires
└── Lien vers post-mortem
ACTIONS POST-MORTEM:
├── Créées comme sous-tâches
├── Label: postmortem-action
├── Priorisées dans backlog
└── Suivies jusqu'à complétion
MÉTRIQUES:
├── Nombre d'incidents par mois
├── MTTR (Mean Time To Resolve)
├── Actions complétées
└── Incidents récurrents (doit être 0)