Essayer gratuitement
7 min lecture Guide 755 of 877

Gestion des Incidents avec GitScrum

Quand les choses cassent, une réponse rapide compte. GitScrum aide les équipes à coordonner la réponse aux incidents et documenter les apprentissages pour la prévention future.

Catégories d'Incidents

Niveaux de Sévérité

CLASSIFICATION DE SÉVÉRITÉ D'INCIDENT:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ SEV 1 - CRITIQUE                                            │
│ 🔴 Panne complète ou perte de données                      │
│ • Tous les utilisateurs affectés                           │
│ • Fonctionnalité core cassée                               │
│ • Brèche de sécurité                                       │
│ Réponse: Toutes mains, escalade immédiate                  │
│ SLA: Accuser réception < 15 min, résoudre ASAP             │
│                                                             │
│ SEV 2 - HAUTE                                               │
│ 🟠 Feature majeure indisponible                            │
│ • Beaucoup d'utilisateurs affectés                         │
│ • Fonctionnalité significative cassée                      │
│ • Contournement existe mais pénible                        │
│ Réponse: Astreinte + équipe concernée                      │
│ SLA: Accuser réception < 1h, résoudre < 4h                 │
│                                                             │
│ SEV 3 - MOYENNE                                             │
│ 🟡 Feature dégradée                                        │
│ • Certains utilisateurs affectés                           │
│ • Contournement existe                                     │
│ • Feature non-critique                                     │
│ Réponse: Astreinte, escalader si besoin                    │
│ SLA: Accuser réception < 4h, résoudre < 24h                │
│                                                             │
│ SEV 4 - BASSE                                               │
│ 🟢 Problème mineur                                         │
│ • Peu d'utilisateurs affectés                              │
│ • Contournement facile                                     │
│ Réponse: Processus bug normal                              │
│ SLA: Triage < 24h                                          │
└─────────────────────────────────────────────────────────────┘

Réponse aux Incidents

Flux de Réponse

PROCESSUS DE RÉPONSE AUX INCIDENTS:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ 1. DÉTECTION                                                │
│    ↓                                                       │
│ • Alerte de monitoring se déclenche                        │
│ • Utilisateur signale problème                             │
│ • Membre de l'équipe remarque le problème                  │
│                                                             │
│ 2. TRIAGE (< 15 min pour SEV 1)                            │
│    ↓                                                       │
│ • Évaluer la sévérité                                      │
│ • Assigner un commandant d'incident                        │
│ • Créer tâche incident dans GitScrum                       │
│ • Notifier les parties prenantes                           │
│                                                             │
│ 3. INVESTIGATION                                            │
│    ↓                                                       │
│ • Rassembler l'équipe d'incident                           │
│ • Ouvrir canal d'incident                                  │
│ • Commencer l'investigation                                │
│                                                             │
│ 4. MITIGATION                                               │
│    ↓                                                       │
│ • Focus sur restaurer le service                           │
│ • Rollback si nécessaire                                   │
│ • Appliquer corrections temporaires                        │
│                                                             │
│ 5. RÉSOLUTION                                               │
│    ↓                                                       │
│ • Confirmer service restauré                               │
│ • Monitorer la stabilité                                   │
│ • Communiquer la résolution                                │
│                                                             │
│ 6. APPRENTISSAGE                                            │
│ • Planifier post-mortem                                    │
│ • Documenter la timeline                                   │
│ • Créer les actions correctives                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Rôles Incident

RÔLES DANS LA RÉPONSE:
═══════════════════════

COMMANDANT D'INCIDENT (IC):
├── Coordonne la réponse
├── Prend les décisions
├── Communique le statut
└── Assure le focus de l'équipe

COMMUNICATEUR:
├── Met à jour les parties prenantes
├── Gère la page de statut
├── Répond aux questions externes
└── Documente la timeline

EXPERTS TECHNIQUES:
├── Investiguent la cause
├── Proposent des solutions
├── Implémentent les fixes
└── Valident la résolution

RÈGLE IMPORTANTE:
┌─────────────────────────────────────────────────────────────┐
│ L'IC ne doit PAS être dans le code                         │
│ Son rôle est de coordonner, pas de fixer                   │
└─────────────────────────────────────────────────────────────┘

Tracking dans GitScrum

Tâche Incident

TEMPLATE TÂCHE INCIDENT:
════════════════════════

┌─────────────────────────────────────────────────────────────┐
│ 🚨 [INCIDENT] Titre descriptif                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ SÉVÉRITÉ: SEV 1 / SEV 2 / SEV 3 / SEV 4                    │
│ STATUT: Détecté → Investigué → Mitigé → Résolu             │
│                                                             │
│ IMPACT:                                                     │
│ • Services affectés: [Liste]                               │
│ • Utilisateurs impactés: [Nombre/Pourcentage]              │
│ • Début: [Timestamp]                                       │
│ • Détection: [Timestamp]                                   │
│                                                             │
│ TIMELINE:                                                   │
│ • 14:23 - Alerte reçue                                     │
│ • 14:25 - Incident déclaré, IC: Alice                      │
│ • 14:30 - Investigation commence                           │
│ • 14:45 - Cause identifiée: [Cause]                        │
│ • 15:00 - Mitigation appliquée                             │
│ • 15:15 - Service restauré                                 │
│ • 15:30 - Monitoring confirmé stable                       │
│                                                             │
│ CAUSE RACINE: [Brève description]                          │
│                                                             │
│ ACTIONS SUIVANTES:                                          │
│ ☐ Planifier post-mortem                                    │
│ ☐ Créer tickets de suivi                                   │
│ ☐ Mettre à jour runbooks                                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Labels et Filtres

ORGANISATION DES INCIDENTS:
═══════════════════════════

LABELS:
├── incident:sev1, incident:sev2, incident:sev3, incident:sev4
├── incident:active, incident:resolved, incident:postmortem-pending
├── service:api, service:web, service:database
└── cause:deploy, cause:infrastructure, cause:bug, cause:external

VUES GITSCRUM:
├── Incidents actifs (non résolus)
├── Incidents cette semaine
├── Incidents par sévérité
├── Post-mortems en attente
└── Tendance des incidents

Post-Mortem

Processus Post-Mortem

WORKFLOW POST-MORTEM:
═════════════════════

TIMING:
├── Planifier dans les 48h après résolution
├── Durée: 60-90 minutes
├── Participants: Équipe impliquée + stakeholders

AGENDA:
1. Contexte (5 min)
   ├── Rappel de ce qui s'est passé
   └── Impact business

2. Timeline (15 min)
   ├── Revue chronologique
   └── Identification des moments clés

3. Analyse (20 min)
   ├── Qu'est-ce qui a bien fonctionné?
   ├── Qu'est-ce qui n'a pas fonctionné?
   └── Où avons-nous eu de la chance?

4. Causes racines (15 min)
   ├── 5 Whys
   └── Facteurs contributifs

5. Actions (15 min)
   ├── Actions préventives
   ├── Actions d'amélioration
   └── Assignation et priorités

Template Post-Mortem

DOCUMENT POST-MORTEM:
═════════════════════

┌─────────────────────────────────────────────────────────────┐
│ POST-MORTEM: [Titre de l'incident]                         │
│ Date: [Date incident] | Sévérité: [SEV]                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ RÉSUMÉ:                                                     │
│ [2-3 phrases décrivant l'incident et l'impact]             │
│                                                             │
│ IMPACT:                                                     │
│ • Durée: X heures                                          │
│ • Utilisateurs affectés: X                                 │
│ • Revenue perdu: X€ (si applicable)                        │
│                                                             │
│ CAUSE RACINE:                                               │
│ [Explication technique de ce qui a causé l'incident]       │
│                                                             │
│ FACTEURS CONTRIBUTIFS:                                      │
│ • [Facteur 1]                                              │
│ • [Facteur 2]                                              │
│                                                             │
│ CE QUI A BIEN FONCTIONNÉ:                                   │
│ • Détection rapide grâce aux alertes                       │
│ • Communication claire                                     │
│                                                             │
│ CE QUI DOIT ÊTRE AMÉLIORÉ:                                  │
│ • Temps de rollback trop long                              │
│ • Documentation incomplète                                 │
│                                                             │
│ ACTIONS:                                                    │
│ ☐ [Action 1] - @Responsable - Date                         │
│ ☐ [Action 2] - @Responsable - Date                         │
│                                                             │
│ LEÇONS APPRISES:                                            │
│ • [Leçon partageable avec d'autres équipes]                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Liens Connexes