SRE en bref
Le Site Reliability Engineering (SRE) est l'approche de Google pour les opérations. La devise :
"SRE is what happens when you ask a software engineer to design an operations function." — Ben Treynor Sloss
SLI, SLO, SLA
SLI (Service Level Indicator)
Métrique quantitative de la qualité du service.
| Type | Exemple | Mesure |
|---|---|---|
| Disponibilité | % de requêtes réussies | (requetes 2xx) / (total requetes) |
| Latence | Temps de réponse p99 | p99 < 200ms |
| Throughput | Requêtes par seconde | > 1000 req/s |
| Error rate | % d'erreurs | < 0.1% erreurs 5xx |
SLO (Service Level Objective)
Cible interne pour un SLI. Exemple : 99.9% de disponibilité sur 30 jours glissants.
Budget = 30 jours × 24h × 60min × (1 - 0.999) = 43.2 minutes de downtime autorisé
SLA (Service Level Agreement)
Contrat avec les clients. Toujours moins ambitieux que le SLO (marge de sécurité).
SLA ≤ SLO ≤ réalité mesurée
Exemple : SLA 99.5% < SLO 99.9% < mesure réelle 99.95%
Error Budget
L'error budget est la différence entre 100% et votre SLO. C'est la quantité de fiabilité que vous pouvez "dépenser" pour aller plus vite.
| SLO | Error Budget (30 jours) |
|---|---|
| 99% | 7h 12min |
| 99.5% | 3h 36min |
| 99.9% | 43min 12s |
| 99.95% | 21min 36s |
| 99.99% | 4min 19s |
Politique d'error budget :
- Budget restant > 50% → déploiements normaux, expérimentation autorisée
- Budget restant 10-50% → déploiements prudents, revues supplémentaires
- Budget épuisé → gel des déploiements, focus fiabilité
Toil — le travail à éliminer
Le toil est le travail opérationnel manuel, répétitif, automatisable et sans valeur durable.
Caractéristiques du toil
- Manuel : un humain doit intervenir
- Répétitif : même tâche encore et encore
- Automatisable : un script pourrait le faire
- Réactif : déclenché par un événement, pas proactif
- Sans valeur durable : pas d'amélioration permanente du service
Règle des 50%
Un SRE ne devrait pas passer plus de 50% de son temps sur le toil. Le reste est consacré à l'ingénierie : automatisation, amélioration des outils, projets de fiabilité.
Incident Management
Sévérités
| Niveau | Impact | Response |
|---|---|---|
| SEV-1 | Service complètement down | Page immédiate, war room |
| SEV-2 | Dégradation significative | Page, investigation prioritaire |
| SEV-3 | Impact mineur | Notification, traitement heures ouvrables |
| SEV-4 | Cosmetic, non urgent | Ticket, backlog |
Roles en incident
- Incident Commander (IC) : coordonne la réponse
- Communication Lead : informe les stakeholders
- Operations Lead : exécute les actions techniques
- Subject Matter Experts : expertise spécifique au problème
Post-mortem blameless
- Timeline : chronologie des événements
- Impact : métriques affectées, durée, utilisateurs touchés
- Root cause : analyse des causes profondes (5 Whys)
- Action items : correctifs concrets avec owners et deadlines
- Lessons learned : ce qu'on a appris
On-call
Bonnes pratiques
- Rotations de 1-2 semaines maximum
- Pas plus de 2 incidents par shift de 12h (objectif)
- Playbooks documentés pour les alertes communes
- Handoff structuré entre shifts
- Compensation adéquate (temps libre, prime)
Pyramide d'alerting
▲ PAGE (réveille quelqu'un)
/ \ → symptômes utilisateur, SLO en danger
/ \
/ TICKET \ → dégradation non urgente
/ \
/ DASHBOARD \ → métriques de surveillance
/ \
/ LOGS \ → debug, investigation
/ \