Stratégie d'alerting¶

Concevoir des alertes actionnables, gérer la sévérité, le routing et éviter la fatigue.

Alertes actionnables¶

Une alerte doit toujours déclencher une action humaine spécifique. Sinon, c'est du bruit.

Critère fondamental¶

Avant de créer une alerte, posez-vous la question : quelle action précisé cette alerte demande-t-elle ?

Si vous ne savez pas quoi faire : pas une alerte, c'est une métrique de monitoring
Si l'action peut être automatisee : pas une alerte, c'est un remédiation automatique
Si ce n'est pas urgent : pas une alerte de nuit, c'est un ticket le matin

Caractéristiques d'une bonne alerte¶

Critère	Description
Actionnabilite	L'on-call sait exactement quoi faire
Contexte	L'alerte embarque les infos pour diagnostiquer
Pertinence	Elle ne se déclenché que quand c'est nécessaire
Urgence adaptée	Critical = reveille, Warning = notification diurne

Niveaux de sévérité¶

Niveau	Définition	Canal	Exemple
Critical	Impact utilisateurs en cours, action immédiate	PagerDuty / appel	API paiement down
Warning	Dégradation potentielle, action sous 4h	Slack	CPU > 80% depuis 10min
Info	Signal informatif, pas d'action requise	Log / dashboard	Déploiement réussi

Inflation des criticals

Trop d'alertes Critical entrainera une desensibilisation. Reservez Critical aux pannes avec impact utilisateur avéré. Tout le reste est Warning ou Info.

Flux d'une alerte¶

graph TD
    A["Metrique franchit\nun seuil"] --> B["Alerte generee\n(Alertmanager / rule)"]
    B --> C["Deduplication\n& grouping"]
    C --> D{"Routing\n(equipe, horaire)"}
    D --> E["Notification\n(Slack, PagerDuty, email)"]
    E --> F{"Acquittement\nde l'on-call"}
    F -- "Acquitte" --> G["Remediation"]
    F -- "Pas de reponse\n(timeout)" --> H["Escalade\nNiveau suivant"]
    H --> F

Routing et escalade¶

Principes du routing¶

Chaque alerte doit avoir un propriétaire clair
Le routing tient compte des horaires (heures ouvrables vs astreinte)
Une équipe platform peut recevoir les alertes infra, une équipe produit les alertes applicatives

Configuration type¶

Critère	Destination
Équipe infra, nuit	PagerDuty astreinte infra
Équipe produit, journée	Canal Slack #alerts-prod
SLO en danger	Manager + lead tech
Alertes batch	Email digest quotidien

Escalade automatique¶

Definissez des délais d'escalade clairs : si aucun acquittement sous N minutes, l'alerte remonte automatiquement au niveau supérieur. Evitez les escalades trop rapides (bruit) ou trop lentes (incident non traite).

Fatigue d'alerte¶

La fatigue d'alerte survient quand le volume ou la fréquence des alertes dépassé la capacité de réaction de l'équipe.

Causes principales¶

Cause	Solution
Seuils trop bas	Ajuster ou ajouter une durée minimale
Alertes non actionnables	Supprimer ou dégrader en Info
Duplication d'alertes	Activer deduplication et grouping
Alertes connues temporaires	Utiliser les silences planifies
Trop de Critical	Requalifier en Warning

Quand l'équipe ignore les alertes

Si l'équipe commence à ignorer ou acquitter sans lire les alertes, le problème n'est pas l'équipe. C'est la qualité de l'alerting. Auditez et nettoyez régulièrement.

On-call et escalade¶

Bonnes pratiques on-call¶

Rotation equitable et documentee (pas toujours les mêmes)
Runbooks accessibles depuis l'alerte (lien direct)
Debriefing post-incident systematique
Limite de perturbations nocturnes (objectif : < 2 reveils/nuit)

Lien avec la collaboration¶

La gestion on-call est étroitement liee aux pratiques d'équipe (post-mortems, runbooks, documentation). Consultez le chapitre Collaborer pour les aspects organisationnels.

Outils¶

Outil	Usage
Alertmanager	Routing, deduplication, silences (écosystème Prometheus)
PagerDuty	Gestion on-call, escalade, rotations
OpsGenie	Alternative PagerDuty, intégration Atlassian
Grafana Alerting	Alertes unifiees multi-datasources
VictorOps (Splunk)	On-call et incident management