Métriques & KPIs SRE
Comment mesurer et maintenir la fiabilité des services avec SLI, SLO, et Error Budget.
📊 SLI, SLO, SLA: Les Fondamentaux
Service Level Indicator (SLI)
📈Métrique mesurable de la qualité du service
- 99.5% des requêtes HTTP < 200ms
- 99.9% des requêtes sans erreur 5xx
- 99.0% availability du service
- 95% de successful database queries
- Doit être mesurable automatiquement
- Pas de SLA sans SLI
- Une app = multiple SLIs (latency + errors + availability)
Service Level Objective (SLO)
🎯Cible d'excellence fixée pour chaque SLI
- SLO: 99.9% availability par mois
- SLO: p99 latency < 500ms
- SLO: < 0.1% error rate par day
- SLO: 99.95% success rate
- SLO < 100% (toujours buffer pour incidents)
- SLO = contrat moral avec utilisateurs
- Si SLO breached = priorité pause tout
Service Level Agreement (SLA)
📝Contrat légal avec conséquences financières
- 99.99% availability = 10% credit si breach
- 99.9% availability = 30% credit si breach
- 99.0% availability = 100% credit si breach
- SLA < SLO (buffer légal)
- Compensation = motivation pour ops
- Pas de compensation = pas de incentive
| Aspect | SLI | SLO | SLA |
|---|---|---|---|
| Nature | Métrique technique | Cible interne | Contrat légal |
| Audience | Engineers | Engineers + Customers | Customers + Legal |
| Breach = ? | Investigation | Pause all feature work | Pénalité financière |
| Exemple | 99.5% uptime | >= 99.95% uptime/mois | >= 99.9% = 10% refund |
💰 Error Budget: Le Secret de la Vélocité
Qu'est-ce que l'Error Budget ?
Temps total où votre service peut être down tout en respectant le SLO.
Exemples pour 1 mois (43,200 minutes)
💡 Comment utiliser l'Error Budget
Vous avez 50 minutes budget pour le mois. Vous déployez une feature risquée:
- ✅ Si vous utilisez 10 minutes = il vous reste 40 minutes (safe)
- ✅ Vous pouvez continuer à déployer
- ⚠️ Si vous avez déjà dépensé 40 minutes = Pause feature work
- ⚠️ Uniquement déploiements critiques (hotfixes)
Budget utilisé à 90% (45/50 minutes restantes):
- 🛑 Zero risky deployments
- 🛑 Seuls hotfixes critiques
- ✅ Focus sur stabilisation
- ✅ Root cause des incidents
🚨 Métriques d'Incidents & Réponse
⏰ Mean Time to Detect (MTTD)
Temps avant détection d'un problème
Cible : < 1 minute pour critical
Mesure : Alert generation - problem start
Amélioration : Better monitoring + alerts (not alerts on alerts)
📞 Mean Time to Acknowledge (MTTA)
Temps avant que quelqu'un réponde à l'alert
Cible : < 5 minutes
Mesure : Alert sent - Human ack
Amélioration : Good on-call rotation, pages non-silencieuses
🔧 Mean Time to Resolve (MTTR)
Temps total pour résoudre un incident
Cible : < 30 minutes pour P1
Mesure : Detection - System back normal
Amélioration : Runbooks, automation, incident commander
📊 Incident Severity Distribution
% P1 vs P2 vs P3 vs P4
Healthy : > 60% P3/P4 (small issues)
Unhealthy : > 20% P1 (big outages)
Action : If skewed to P1 = improve monitoring
🎓 Post-Incident Reviews (PIRs)
% d'incidents avec blameless post-mortem
Cible : 100% pour P1 + P2
Mesure : Action items créés et tracked
Métrique : % action items closed dans 30 jours
🔄 Incident Recurrence Rate
% même incident type 2x+ par trimestre
Cible : < 10%
> 30% = Post-mortems ineffective
Action : Review PIR process
🌙 Métriques de On-Call & Load
📱 Pages per On-Call
Nombre d'alertes/pages par shift
Healthy : < 5 pages par 8h shift
Alert fatigue : > 20 pages = too many false positives
Action : Tune alerts, deduplicate
⏰ Mean Duration per Incident
Combien de temps occupé par incident
Healthy : < 30 minutes avg (interruption courte)
Bad : > 1 hour = poor runbooks
Improvement : Automation, clear procedures
😴 On-Call Sleep Impact
Sondage: "How was your sleep during on-call?"
Target NPS : > 7/10
Sous 5/10 : Burnout risk, people quit
Amélioration : Better alerting, shadowing, light duties
🎭 Follow-the-Sun Rotation
% équipe à risk de burn-out (overcall)
Healthy : < 1 shift/week par person
Risk : > 2 shifts/week = burnout
Solution : Hire more SREs ou reduce on-call scope
📚 Runbook Compliance
% d'incidents resolved suivant runbook
Target : > 80%
Mesure : Post-mortem checklist "Was runbook used?"
Si < 50% : Runbooks not accurate or discoverable
⚡ Automation Coverage (Remediation)
% d'incidents auto-resolved sans human
Target : > 40% automated
Exemples : Restart service, scale up, clear cache
Impact : Reduce MTTR by 90%, improve sleep
⚡ Métriques de Performance Système
📊 Latency (p50, p95, p99)
Distribution des temps de réponse
p50 (median) : 50% des requêtes plus rapides
p95 : 95% des requêtes plus rapides (= tail latency start)
p99 : 99% plus rapides (= really bad users)
Exemple SLO : p99 < 500ms
🔴 Error Rate
% de requêtes avec erreur (5xx, timeouts)
Cible : < 0.1%
Mesure : Total errors / Total requests
Alerting : > 1% = page immediately
🎯 Availability (Uptime %)
% temps où service est up et responding
99.0% : 7.2h downtime/month (small service)
99.9% : 43 min downtime/month (web app)
99.99% : 4.3 min downtime/month (critical)
💾 Resource Saturation
CPU, Memory, Disk usage % vs capacity
Safe : < 75% utilization
Alert : > 85% = capacity planning needed
Critical : > 95% = imminent failure
🔄 Queue Depth
Nombre de requêtes en attente de traitement
Healthy : Queue depth < number of workers
Bad : Queue depth > 10x workers = overload
Action : Scale horizontally or optimize
🐞 Goroutine Leak / FD Leak
Memory/FD graduel exhaustion (bad code)
Metric : Trend of goroutines/FDs over time
Alert : If +100 per day = leak detected
Impact : If undetected = eventual OOM crash