Essayer gratuitement
8 min lecture Guide 95 of 877

Gérer les Problèmes Urgents de Production

Les incidents de production demandent une réponse immédiate et coordonnée. Les capacités de gestion d'incidents de GitScrum aident les équipes à répondre rapidement via des workflows d'escalade dédiés, intégration communication temps réel, et suivi structuré des incidents. La clé est d'avoir des playbooks répétés pour que les équipes agissent instinctivement plutôt que de découvrir sous pression, puis mener des post-mortems approfondis pour prévenir la récurrence.

Framework Réponse Incidents

Classification Sévérité

NIVEAUX SÉVÉRITÉ INCIDENTS:
┌─────────────────────────────────────────────────────────────┐
│ DÉFINIR SÉVÉRITÉ                                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ SEV-1: CRITIQUE                                             │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Définition:                                             ││
│ │ • Service core complètement en panne                    ││
│ │ • Perte données ou brèche sécurité                      ││
│ │ • Tous clients affectés                                 ││
│ │                                                         ││
│ │ Exemples:                                               ││
│ │ • Base données production hors ligne                    ││
│ │ • Traitement paiements échoué                           ││
│ │ • Système authentification en panne                     ││
│ │                                                         ││
│ │ Réponse:                                                ││
│ │ • Tous sur le pont immédiatement                        ││
│ │ • Leadership notifié en 5 minutes                       ││
│ │ • Communication client en 15 minutes                    ││
│ │ • Updates continus jusqu'à résolution                   ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ SEV-2: HAUT                                                 │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Définition:                                             ││
│ │ • Feature majeure indisponible                          ││
│ │ • Dégradation performance significative                 ││
│ │ • Nombreux clients affectés                             ││
│ │                                                         ││
│ │ Réponse:                                                ││
│ │ • Équipe on-call engagée en 15 minutes                  ││
│ │ • Heures bureau: team lead au courant                   ││
│ │ • Updates toutes les 30 minutes                         ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ SEV-3: MOYEN                                                │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Définition:                                             ││
│ │ • Problèmes feature mineure                             ││
│ │ • Contournement disponible                              ││
│ │ • Quelques clients affectés                             ││
│ │                                                         ││
│ │ Réponse:                                                ││
│ │ • Traiter dans la journée ouvrable                      ││
│ │ • Suivre dans workflow normal                           ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Rôles Incident

STRUCTURE ÉQUIPE RÉPONSE:
┌─────────────────────────────────────────────────────────────┐
│ ATTRIBUTION RÔLES                                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ COMMANDANT INCIDENT (IC):                                   │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUI: Ingénieur on-call ou leader désigné                ││
│ │                                                         ││
│ │ RESPONSABILITÉS:                                        ││
│ │ • Coordonne toutes activités réponse                    ││
│ │ • Prend décisions d'escalade                            ││
│ │ • Assigne tâches aux membres équipe                     ││
│ │ • Décide quand déclarer "résolu"                        ││
│ │                                                         ││
│ │ PAS RESPONSABLE DE:                                     ││
│ │ • Débugger code (délègue aux autres)                    ││
│ │ • Écrire communications client                          ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ LEAD TECHNIQUE:                                             │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUI: Ingénieur plus expérimenté disponible              ││
│ │                                                         ││
│ │ RESPONSABILITÉS:                                        ││
│ │ • Enquête cause racine                                  ││
│ │ • Implémente correctifs                                 ││
│ │ • Conseille IC sur décisions techniques                 ││
│ │ • Coordonne avec autres ingénieurs                      ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ LEAD COMMUNICATIONS:                                        │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUI: PM, lead support, ou communicateur désigné         ││
│ │                                                         ││
│ │ RESPONSABILITÉS:                                        ││
│ │ • Met à jour page statut                                ││
│ │ • Notifie parties prenantes                             ││
│ │ • Répond aux demandes clients                           ││
│ │ • Maintient chronologie incident                        ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ SCRIBE:                                                     │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QUI: Tout membre équipe disponible                      ││
│ │                                                         ││
│ │ RESPONSABILITÉS:                                        ││
│ │ • Documente tout en temps réel                          ││
│ │ • Enregistre décisions et raisons                       ││
│ │ • Capture chronologie événements                        ││
│ │ • Crée base pour post-mortem                            ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Workflow Réponse

Réponse Initiale

15 PREMIÈRES MINUTES:
┌─────────────────────────────────────────────────────────────┐
│ ACTIONS IMMÉDIATES                                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ MINUTE 0-5: DÉTECTION & DÉCLARATION                         │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Alerte déclenchée (monitoring) ou signalée           ││
│ │ 2. On-call reçoit notification                          ││
│ │ 3. Vérifier incident est réel (pas fausse alarme)       ││
│ │ 4. Déclarer niveau sévérité                             ││
│ │ 5. Créer canal/tâche incident                           ││
│ │                                                         ││
│ │ DANS GITSCRUM:                                          ││
│ │ Créer tâche: "INCIDENT: [Description brève]"            ││
│ │ Ajouter labels: incident, sev-1 (ou niveau approprié)   ││
│ │ Assigner: Commandant Incident                           ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ MINUTE 5-10: MOBILISATION                                   │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Appeler membres équipe pertinents (si nécessaire)    ││
│ │ 2. Ouvrir war room (appel vidéo ou canal chat)          ││
│ │ 3. Assigner rôles: IC, Lead Tech, Comms, Scribe         ││
│ │ 4. Briefer tout le monde sur faits connus               ││
│ │                                                         ││
│ │ IC DIT:                                                 ││
│ │ "Nous avons SEV-1: [description]. Je suis IC. [Nom]     ││
│ │  est Lead Tech. [Nom] gère comms. [Nom] est scribe.     ││
│ │  Voici ce qu'on sait..."                                ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Communication

Updates Statut

PATTERNS COMMUNICATION:
┌─────────────────────────────────────────────────────────────┐
│ TENIR PARTIES PRENANTES INFORMÉES                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ UPDATES INTERNES (dans GitScrum Discussions):               │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TEMPLATE:                                               ││
│ │                                                         ││
│ │ **[HEURE] UPDATE INCIDENT - [NOM INCIDENT]**            ││
│ │                                                         ││
│ │ **Statut:** Investigation / Identifié / Mitigation      ││
│ │ **Impact:** [Qui/quoi est affecté]                      ││
│ │ **Action actuelle:** [Ce qu'on fait]                    ││
│ │ **Prochain update:** [Heure prochain update]            ││
│ │                                                         ││
│ │ Exemple:                                                ││
│ │ "14:35 UPDATE INCIDENT - Latence API                    ││
│ │  Statut: Identifié                                      ││
│ │  Impact: 50% requêtes API timeout                       ││
│ │  Actuel: Rollback du déploiement de 13:45               ││
│ │  Prochain update: 14:45 ou quand résolu"                ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ FRÉQUENCE UPDATES:                                          │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SEV-1: Toutes les 15 minutes ou changement statut       ││
│ │ SEV-2: Toutes les 30 minutes                            ││
│ │ SEV-3: Sur changement statut                            ││
│ │                                                         ││
│ │ Même sans progrès: "Investigation continue. Pas d'info" ││
│ │ Silence est pire que "pas de nouvelles"                 ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Post-Incident

Post-Mortem Sans Blâme

APPRENDRE DES INCIDENTS:
┌─────────────────────────────────────────────────────────────┐
│ STRUCTURE POST-MORTEM                                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ DOCUMENTER DANS NOTEVAULT:                                  │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ # Post-Mortem: [Nom Incident] - [Date]                  ││
│ │                                                         ││
│ │ ## Résumé                                               ││
│ │ • Durée: 2h 15m                                         ││
│ │ • Impact: 45% utilisateurs affectés                     ││
│ │ • Sévérité: SEV-1                                       ││
│ │                                                         ││
│ │ ## Chronologie                                          ││
│ │ | Heure | Événement                           |         ││
│ │ |-------|-------------------------------------|         ││
│ │ | 13:45 | Déploiement en production           |         ││
│ │ | 14:02 | Premier signalement client          |         ││
│ │ | 14:15 | Incident déclaré                    |         ││
│ │ | 14:30 | Cause racine identifiée             |         ││
│ │ | 15:00 | Rollback terminé                    |         ││
│ │ | 16:00 | Récupération complète confirmée     |         ││
│ │                                                         ││
│ │ ## Cause Racine                                         ││
│ │ Migration BD dans déploiement a supprimé index          ││
│ │ nécessaire pour chemin requête principal.               ││
│ │                                                         ││
│ │ ## Items Action                                         ││
│ │ • Ajouter tests performance requêtes au CI              ││
│ │ • Changer fenêtre déploiement heures faible trafic      ││
│ │ • Ajouter vérification dépendance index revue migration ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ PRINCIPES SANS BLÂME:                                       │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ "Le système a permis que ça arrive"                   ││
│ │ ❌ "Jean a causé la panne"                               ││
│ │                                                         ││
│ │ Focus: Comment empêcher TOUT ingénieur de faire         ││
│ │        cette erreur, pas "qui a fait l'erreur"          ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
└─────────────────────────────────────────────────────────────┘

Solutions Connexes