Analyse post-incident : exploiter l'historique des alertes

Une fois l'incident résolu, la tentation est grande de passer à autre chose. C'est pourtant le meilleur moment pour comprendre ce qui s'est passé : les souvenirs sont frais et l'historique des alertes contient presque tout ce qu'il faut pour reconstituer les faits. Une revue post-incident d'une demi-heure évite souvent que le même problème revienne le mois suivant.

Reconstituer la chronologie

Le premier travail consiste à aligner les événements sur une seule ligne de temps, en filtrant l'historique sur le ou les systèmes concernés :

1. Le premier signal : la première alerte, même mineure, liée à l'incident. Elle précède souvent de plusieurs heures l'alerte critique qui a fait réagir l'équipe.
2. La prise en compte : le moment où quelqu'un a vu l'alerte et l'a acquittée.
3. Les actions : redémarrages, nettoyages, bascules, avec leur heure.
4. La résolution : le retour à la normale constaté par la supervision, pas seulement « ça a l'air de remarcher ».

Notez aussi les alertes secondaires déclenchées par l'incident principal (service dépendant injoignable, file d'attente qui s'allonge) : elles montrent la propagation de la panne et expliquent le bruit reçu pendant l'incident.

Mesurer les délais

Trois durées résument l'efficacité de la réponse :

Un délai de prise en charge long avec une résolution rapide pointe vers les canaux d'alerte : l'information est arrivée, mais personne ne l'a vue. Une détection tardive pointe vers les seuils : la supervision a vu le problème trop tard.

Distinguer la cause du symptôme

L'alerte qui a déclenché l'intervention décrit rarement la cause. « Service web injoignable » est un symptôme ; la cause peut être un disque plein qui a bloqué la base de données, elle-même saturée par une sauvegarde mal planifiée. Remonter la chronologie jusqu'au premier signal, puis demander « pourquoi » à chaque étape, mène en général à la vraie cause en trois ou quatre questions.

Repérer les problèmes récurrents

Un incident isolé se corrige ; un incident récurrent se traite à la racine. Sur plusieurs semaines d'historique :

• comptez, par système, le nombre d'alertes et de problèmes : un même système en tête plusieurs semaines de suite a un problème de fond ;
• repérez les alertes qui se déclenchent et se résolvent seules à heure fixe : souvent une tâche planifiée (sauvegarde, antivirus, traitement de nuit) qui dépasse un seuil mal calibré ;
• identifiez les alertes jamais traitées : soit elles ne servent à rien et doivent être revues, soit elles sont ignorées à tort.

Les deux derniers cas relèvent du réglage des alertes plus que de l'infrastructure. Voir comment éviter les faux positifs et réduire la fatigue d'alertes.

Conduire la revue sans chercher de coupable

La revue post-incident n'est utile que si chacun peut dire ce qu'il a fait, y compris ses erreurs. Le principe dit « sans recherche de coupable » (blameless) part d'une idée simple : si une personne a pu commettre l'erreur, le système l'a permise, et c'est le système qu'il faut corriger. Une revue efficace se termine par :

• une chronologie validée par les participants ;
• la cause racine, ou l'hypothèse la plus probable ;
• deux ou trois actions concrètes, avec un responsable et une date : un seuil à ajuster, une procédure à écrire, une alerte à ajouter sur le premier signal.

Au-delà, la liste d'actions ne sera pas suivie.

Conserver la mémoire des incidents

Les historiques d'alertes ne sont pas conservés indéfiniment. Pour les incidents marquants, consignez la chronologie et les conclusions dans votre outil de tickets ou votre documentation interne au moment de la revue. Le rapport mensuel complète ce suivi en donnant, mois après mois, une vue d'ensemble de la disponibilité et des incidents.

Dans Logiserv

Avec l'offre Business, Logiserv conserve l'historique des notifications push reçues sur vos appareils pendant 30 jours : filtre par système, par statut et par sévérité, acquittement avec message et fermeture manuelle d'un problème. La présentation des notifications résume l'offre ; le mode d'emploi détaille l'historique et les canaux d'alerte.

Pour aller plus loin

• Passer d'une supervision réactive à une supervision proactive
• Superviser en équipe : rôles, alertes et accès partagés
• Fatigue d'alertes Zabbix : causes et remèdes
• Faux positif : définition