Atelier : refondre un jeu d'alertes bruyant
Auditer un jeu d'alertes existant, identifier le bruit et le reconstruire autour de SLO actionnables.
À retenir
- L'audit d'un jeu d'alertes commence par mesurer déclenchements et actions réelles, pas les intentions.
- Les SLO doivent être calibrés sur l'historique réel du service, pas sur un idéal théorique.
- Toute nouvelle règle d'alerte doit être backtestée avant sa mise en production.
- Une refonte réussie réduit fortement le volume de pages sans dégrader la détection.
Méthode d'audit d'un jeu d'alertes
L'objectif de cet atelier est de partir d'un jeu d'alertes réel (souvent hérité, accumulé au fil des incidents) et de le refondre en suivant une méthode reproductible.
Étape 1 — Inventaire et classification
Listez toutes les alertes actives sur les 90 derniers jours avec, pour chacune : nombre de déclenchements, sévérité, existence d'un runbook, action réellement prise par l'astreinte.
| Alerte | Déclenchements/mois | Runbook ? | Action prise |
|---|---|---|---|
| CPU > 80% | 42 | Non | Aucune (ignorée) |
| Disque > 90% | 3 | Oui | Extension volume |
| Erreur 5xx > 2% | 1 | Oui | Rollback déploiement |
Point clé
toute alerte déclenchée plus de dix fois par mois sans action corrective documentée est une candidate directe à la suppression ou à la reformulation en ticket.
Étape 2 — Redéfinir en SLI/SLO
Pour chaque service critique, identifiez les SLI pertinents (disponibilité, latence, taux d'erreur, fraîcheur des données) et fixez un SLO réaliste basé sur l'historique, pas sur un idéal théorique à 100 %.
# Exemple Terraform : déclaration d'un SLO via un provider de monitoring
resource "datadog_service_level_objective" "checkout_availability" {
name = "checkout-availability-slo"
type = "metric"
description = "Disponibilité du service checkout sur fenêtre glissante 30 jours"
thresholds {
timeframe = "30d"
target = 99.9
warning = 99.95
}
query {
numerator = "sum:checkout.requests.success{*}.as_count()"
denominator = "sum:checkout.requests.total{*}.as_count()"
}
}
Étape 3 — Écrire les nouvelles règles et les tester
Chaque nouvelle règle d'alerte doit être testée avant déploiement, idéalement via des données historiques rejouées (backtesting) pour vérifier qu'elle aurait détecté les incidents passés sans générer de faux positifs excessifs.
Attention
déployer une nouvelle règle d'alerte directement en production sans backtesting revient à changer une politique de sécurité sans test préalable — le risque de silence sur un vrai incident ou de saturation par de faux positifs est réel.
Étape 4 — Revue et documentation
Chaque alerte conservée doit avoir un runbook associé, versionné avec le code d'infrastructure, et revu par au moins une autre personne que son auteur.
Sur le terrain
dans un exercice réel de refonte, une équipe passe fréquemment de 60 alertes actives à une quinzaine d'alertes basées sur des SLO, avec une réduction du volume de pages nocturnes de l'ordre de 70 à 80 %, sans dégradation du temps de détection des incidents réels.
Astuce
conservez une trace des alertes supprimées pendant au moins un trimestre (commentées dans le dépôt Git, pas effacées) afin de pouvoir les réactiver rapidement si un mode de défaillance oublié réapparaît.