Insights — Exploitation
Une alerte que personne ne lit ne protège personne.
Toutes les plateformes que nous reprenons ont déjà de la supervision. Ce qui manque n'est pas un outil de plus, mais un tri : ce qui mérite un réveil, ce qui peut attendre le lendemain, et ce que l'on ne regarde jamais.
01 — Le constat
Le nombre d'alertes augmente toujours plus vite que la capacité à les traiter.
Un seuil ajouté après chaque incident, une sonde de plus à chaque migration : en deux ans, la même plateforme passe de vingt alertes par semaine à deux cents. À ce niveau, plus personne ne lit, tout le monde filtre — et l'alerte qui compte se noie dans celles qui n'ont jamais rien annoncé.
Une supervision utile ne se mesure pas au nombre de métriques collectées, mais au nombre d'incidents détectés avant les utilisateurs. C'est la seule statistique qui compte, et elle se pilote.
01Pourquoi le mur d'alertes arrive toujours
Une alerte est presque toujours ajoutée dans l'urgence, juste après un incident, par la personne qui vient d'être réveillée. Personne ne supprime jamais rien, parce que supprimer un seuil donne l'impression de retirer une protection.
Le résultat est prévisible : un système où la valeur d'une alerte n'est jamais évaluée. Nous appliquons la règle inverse — toute alerte qui se déclenche trois fois sans conséquence est révisée ou supprimée, et cette revue est planifiée, pas laissée à la bonne volonté.
02Les quatre questions qui trient
Avant d'ajouter ou de garder une alerte, quatre questions suffisent. Elles prennent deux minutes et évitent deux ans de bruit.
- Est-ce que cela empêche un utilisateur de travailler ?
- Est-ce que quelqu'un peut agir maintenant, à cette heure-là ?
- Le seuil vient-il d'une mesure, ou d'une intuition ?
- La même alerte s'est-elle déjà déclenchée sans conséquence ?
03Ce que nous surveillons réellement
Nous surveillons peu, mais nous surveillons des signaux qui annoncent une panne avant qu'elle ne produise un incident : l'espace disque et sa vitesse de remplissage, la réussite des sauvegardes et la date du dernier test de restauration, l'expiration des certificats, la profondeur des files d'attente, la latence au 95e centile et le taux d'erreurs côté serveur.
Ces signaux ont une propriété commune : ils ne dépendent pas de la charge du moment. Ils disent où va le système, pas seulement où il est — c'est exactement ce qu'une console ne montre pas.
- Espace disque et tendance de remplissage
- Sauvegardes : succès, ancienneté, dernier test de restauration
- Certificats et noms de domaine : date d'expiration
- Files d'attente et travaux en retard
- Latence au 95e centile et taux d'erreurs
02 — Questions courantes
Ce qu'on nous demande sur la supervision
Faut-il changer d'outil pour cela ?
Rarement. Les plateformes que nous installons — Prometheus, Grafana, OpenTelemetry — sont libres et suffisent largement. Le travail utile n'est pas le choix de l'outil, mais la définition des seuils et leur revue périodique.
Combien de temps pour mettre en place une supervision utile ?
Deux à trois semaines pour couvrir les signaux structurels d'une plateforme existante, avec les seuils réglés sur des mesures réelles et non sur des valeurs par défaut. La revue des alertes, elle, ne s'arrête jamais : elle fait partie de l'exploitation.
Que se passe-t-il la nuit et le week-end ?
C'est la première question à trancher, avant l'outil. Une astreinte n'a de sens que si les alertes qui la déclenchent sont peu nombreuses et réellement actionnables. Tout le reste se traite le lendemain, avec un journal et un ordre de priorité.
Vous voulez savoir ce que votre supervision ne voit pas ?
Revue de supervision : nous relevons les signaux surveillés, les alertes muettes, les seuils jamais revus et les points de rupture non couverts, puis nous remettons un plan par ordre d'urgence.