Alerting

Seuils, SLO, SLI, on-call, fatigue d'alerte, escalade et comment concevoir un système d'alertes efficace.

Pourquoi l’alerting est-il important ?

Disposer de métriques et de tableaux de bord ne sert à rien si personne ne les consulte lorsqu’un problème survient. L’alerting est le mécanisme qui transforme les données d’observabilité en actions : il notifie les bonnes personnes lorsqu’une situation requiert une attention, avant que les utilisateurs ne soient affectés.

Mais un système d’alertes mal conçu peut être pire que l’absence d’alertes. Si l’équipe reçoit 50 alertes par jour qui ne nécessitent aucune action, elle finit par toutes les ignorer — y compris les alertes critiques.

SLI, SLO et SLA

SLI (Service Level Indicator)

Un SLI est une métrique quantitative qui mesure un aspect du service du point de vue de l’utilisateur :

Disponibilité : Pourcentage de requests réussies.
Latence : Pourcentage de requests complétées en moins de X ms.
Throughput : Requests traitées par seconde.
Exactitude : Pourcentage de réponses contenant des données correctes.

SLO (Service Level Objective)

Un SLO est un objectif interne portant sur un SLI. Il définit le niveau de service que l’équipe s’engage à maintenir :

« 99,9 % des requests doivent être complétées en moins de 500ms. »
« La disponibilité mensuelle doit être d’au moins 99,95 %. »
« 99 % des paiements doivent être traités en moins de 3 secondes. »

SLA (Service Level Agreement)

Un SLA est un contrat formel assorti de conséquences (généralement financières) en cas de non-respect. Les SLA sont généralement moins stricts que les SLO internes afin de conserver une marge de sécurité.

Error Budget

L’error budget est la différence entre 100 % et le SLO. Si votre SLO de disponibilité est de 99,9 %, votre error budget mensuel est de 0,1 % — soit environ 43 minutes de downtime autorisées.

L’error budget permet de prendre des décisions éclairées :

S’il reste beaucoup de budget : vous pouvez privilégier les fonctionnalités et la vitesse de développement.
Si le budget s’épuise : privilégiez la stabilité et réduisez les risques.

Conception des alertes

Alertes basées sur les symptômes vs les causes

Alertes par symptômes (recommandé) : « Le taux d’erreurs 5xx dépasse 1 %. » Elles détectent l’impact sur l’utilisateur.
Alertes par causes : « L’utilisation du CPU dépasse 90 %. » Elles peuvent générer des faux positifs — un CPU élevé ne signifie pas toujours qu’il y a un problème.

Privilégiez les alertes par symptômes. Utilisez les alertes par causes uniquement comme complément à des fins de diagnostic.

Seuils statiques vs dynamiques

Seuils statiques : Valeurs fixes définies manuellement.

Avantage : Simples à comprendre et à configurer.
Inconvénient : Ne s’adaptent pas aux variations de trafic.

Seuils dynamiques : Calculés automatiquement à partir des tendances historiques.

Avantage : S’adaptent aux variations normales (davantage de trafic pendant les heures de bureau).
Inconvénient : Plus complexes à mettre en œuvre et susceptibles de générer des faux positifs lors de changements légitimes.

Sévérités

Définissez des niveaux de sévérité clairs, associés à des actions :

Sévérité	Signification	Action	Exemple
Critical	Impact direct sur l’utilisateur	Notification immédiate, on-call	Service indisponible, erreurs > 5 %
Warning	Dégradation potentielle	Notification pendant les heures de bureau	Latence élevée, disque à 80 %
Info	Situation à surveiller	Consignation dans le canal de l’équipe	Deploy terminé, scaling event

Fenêtres d’évaluation

N’alertez pas sur des pics instantanés. Utilisez des fenêtres temporelles pour éviter les faux positifs :

for: 5m — La condition doit se maintenir pendant 5 minutes avant de déclencher l’alerte.
Des fenêtres plus longues pour les métriques bruitées, plus courtes pour les métriques critiques.

Fatigue d’alerte

Qu’est-ce que c’est ?

La fatigue d’alerte survient lorsque l’équipe reçoit tellement d’alertes qu’elle cesse d’y prêter attention. C’est l’un des problèmes les plus courants et les plus dangereux en exploitation.

Signes de fatigue d’alerte

L’équipe met les alertes en sourdine sans les investiguer.
Les alertes s’accumulent sans être traitées.
Les incidents réels sont détectés par les plaintes des utilisateurs, et non par les alertes.
L’équipe on-call est épuisée et démotivée.

Comment la combattre

Chaque alerte doit être actionnable : Si elle ne requiert aucune action humaine, ce n’est pas une alerte — c’est un log ou une métrique.
Revue périodique : Passez les alertes en revue chaque mois. Supprimez celles qui n’ont donné lieu à aucune action utile.
Regroupement : Regroupez les alertes liées pour éviter les cascades de notifications.
Déduplication : Si la même alerte se déclenche 10 fois en 5 minutes, envoyez une seule notification.
Runbooks : Chaque alerte doit être associée à un runbook expliquant la marche à suivre.

On-call

Rotations

Un système d’on-call efficace comprend :

Rotations hebdomadaires : Répartir la charge sur l’ensemble de l’équipe.
Escalade : Si l’on-call principal ne répond pas dans un délai de X minutes, escalader vers le secondaire.
Compensation : L’on-call doit être compensé — il s’agit de travail en dehors des horaires.

Escalade

Définissez une chaîne d’escalade claire :

Niveau 1 : Ingénieur on-call de l’équipe propriétaire du service.
Niveau 2 : Tech lead ou ingénieur senior de l’équipe.
Niveau 3 : Incident commander / management.

Les délais d’escalade dépendent de la sévérité :

Critical : Escalader après 15 minutes sans réponse.
Warning : Escalader après 1 heure sans réponse.

Outils d’on-call

PagerDuty : Plateforme de référence pour la gestion des incidents et de l’on-call.
OpsGenie (Atlassian) : Alternative bien intégrée avec Jira.
Grafana OnCall : Solution open-source intégrée à Grafana.

Runbooks

Un runbook est un document décrivant les étapes à suivre lorsqu’une alerte spécifique se déclenche.

Structure d’un runbook

Description : Ce que signifie cette alerte.
Impact : Ce que vit l’utilisateur.
Diagnostic : Étapes pour investiguer la cause racine.
Mitigation : Actions immédiates pour restaurer le service.
Résolution : Étapes pour résoudre la cause racine.
Contacts : Vers qui escalader si le problème ne peut être résolu.

Automatisation des runbooks

Lorsqu’un runbook comporte des étapes répétitives et bien définies, envisagez de les automatiser :

Scripts de diagnostic qui collectent automatiquement les informations.
Actions de mitigation automatiques (restart du service, scaling).
Bots qui exécutent les premières étapes du runbook et notifient le résultat.

Bonnes pratiques

Commencez simple

N’essayez pas d’alerter sur tout dès le premier jour. Commencez par les métriques RED de chaque service critique et étendez progressivement.

Testez vos alertes

Les alertes sont du code — elles doivent être testées :

Vérifiez qu’elles se déclenchent lorsque la condition est remplie.
Vérifiez qu’elles ne se déclenchent pas lors de variations normales.
Simulez périodiquement des pannes pour valider l’ensemble de la chaîne.

Post-mortems

Après chaque incident significatif, réalisez un post-mortem :

L’alerte s’est-elle déclenchée à temps ?
Le runbook a-t-il été utile ?
Que peut-on améliorer ?

Utilisez les post-mortems pour améliorer continuellement le système d’alertes.

Résumé

Un système d’alertes efficace est le pont entre l’observabilité et l’action. Fondez vos alertes sur les SLO, privilégiez les symptômes plutôt que les causes, combattez activement la fatigue d’alerte et assurez-vous que chaque alerte est associée à un runbook. L’objectif n’est pas d’avoir plus d’alertes, mais d’avoir les bonnes alertes, celles qui permettent à l’équipe de maintenir le service en bonne santé.