Gestion des Incidents : Construire une Culture de Fiabilité
La gestion des incidents n'est pas une question d'outils -- c'est une question de personnes, de processus et d'apprentissage. Les organisations qui gèrent bien les incidents n'ont pas moins de pannes ; elles récupèrent plus vite et apprennent davantage de chacune.
Cycle de Vie d'un Incident
Matrice de Sévérité
| Sévérité | Impact | Exemples | Temps de Réponse | Cadence de Maj | Qui est Alerte |
|---|---|---|---|---|---|
| SEV1 / P1 | Panne totale, risque de perte de données | Production down, paiements en échec | < 5 min | Toutes les 15 min | Astreinte + Manager + VP |
| SEV2 / P2 | Fonctionnalité majeure dégradée | Recherche cassée, latence > 10x | < 15 min | Toutes les 30 min | Astreinte + Manager |
| SEV3 / P3 | Fonctionnalité mineure dégradée, contournement possible | Dashboard lent, intégration non critique down | < 1 heure | Toutes les 2h | Équipe d'astreinte |
| SEV4 / P4 | Problème cosmétique, aucun impact utilisateur | Bruit dans les logs, bug mineur UI | Jour ouvré suivant | Quotidienne | Backlog équipe |
| SEV5 / P5 | Informationnel, risque potentiel | Tendance capacité, certificat expirant | Sprint planifié | Hebdomadaire | Backlog équipe |
Framework de Métriques
| Métrique | Définition | Cible (Org Mature) | Comment Mesurer |
|---|---|---|---|
| MTTD | Temps moyen de détection | < 5 min | Timestamp alerte - début panne |
| MTTA | Temps moyen d'acquittement | < 5 min (P1) | Timestamp ack - timestamp alerte |
| MTTM | Temps moyen d'atténuation | < 30 min (P1) | Timestamp atténuation - détection |
| MTTR | Temps moyen de résolution | < 4 heures (P1) | Timestamp résolution - détection |
| MTBF | Temps moyen entre pannes | Tendance à la hausse | Analyse de fréquence des incidents |
Extrait de la fiche « AZ-400 Domain 5: Instrumentation Strategy » · Demander la fiche complète
Construire une Culture Saine
L'astreinte ne devrait pas être pénible. Si l'astreinte est redoutée, c'est le signe de problèmes systémiques : trop d'alertes, runbooks insuffisants, ou manque d'automatisation.
Pratiquer les incidents. Organisez régulièrement des game days et du chaos engineering. Les équipes qui pratiquent la réponse aux incidents performent nettement mieux en situation réelle.
Partager largement. Publiez les postmortems à toute l'organisation. La valeur d'apprentissage d'un incident est proportionnelle au nombre de personnes qui lisent le postmortem.
Règle fondamentale : Les postmortems doivent être sans blâme. Se concentrer sur les systèmes et processus, jamais sur les individus.