Politique SRE et modèle d'alerte par Error Budget
Décision — Stack technique
Prometheus Operator (via le chart kube-prometheus-stack), Grafana et Loki sont déployés en GitOps, au même titre que tout autre composant du cluster. Les ressources allouées sont actuellement volontairement réduites pour tenir sur le nœud EC2 t4g.medium unique.
Décision — Modèle d'alerte
Le modèle de burn rate est retenu plutôt qu'un seuil de disponibilité brut :
- 🔴 Alerte "rapide" (severity HIGH) : le rythme actuel d'erreurs épuiserait l'error budget mensuel en moins de 2 jours
- 🟠 Alerte "lente" (severity MEDIUM) : consommation soutenue sur 1 heure
Ce modèle, standard dans la pratique SRE, évite de déclencher une alerte pour un incident isolé de quelques secondes tout en détectant rapidement une dégradation structurelle.
Fonctionnement du burn rate
Le budget d'erreur mensuel est de 0,5% (environ 3h36 d'indisponibilité autorisée par mois).
- Fast burn (14.4x) : si le taux d'erreur actuel persiste, le budget sera épuisé en < 2 jours → alerte immédiate
- Slow burn (6x) : si le taux d'erreur actuel persiste 1 heure, le budget est consommé anormalement → alerte
Décision — Cibles initiales
- ✅ Disponibilité vitrine : 99.5%
- ✅ Santé cluster : 99.9%
- Ces cibles seront relevées après bascule en Haute Disponibilité ultérieurement (Sprint 19).
Décision — Canal d'alerte unifié
Les alertes SRE (Alertmanager) transitent par le même topic SNS que les alertes de sécurité, évitant la prolifération de canaux distincts et centralisant la vigilance opérationnelle.
Conséquences
- ✅ Coût mensuel additionnel : ~8 $ (stockage EBS supplémentaire pour Prometheus/Loki)
- ⚠️ Risque assumé : rétention de métriques limitée à 48h en mono-nœud (espace disque contraint), suffisant pour le calcul de burn rate mais insuffisant pour une analyse historique longue — sera réévalué ultérieurement.