Qu'est-ce que le SRE ?
Site Reliability Engineering est une discipline qui applique les principes d'ingénierie logicielle aux problèmes d'infrastructure et d'opérations.
"SRE is what happens when you ask a software engineer to design an operations team."— Ben Treynor, VP of Engineering at Google (créateur du SRE)
Google a créé la discipline SRE en 2003 pour gérer ses services à très grande échelle. L'idée fondamentale : les problèmes d'opérations sont en fait des problèmes de logiciel et peuvent être résolus avec des techniques d'ingénierie logicielle.
Les 7 principes fondamentaux du SRE
Adopter le risque
100% de disponibilité n'est pas réaliste. On définit un niveau acceptable de risque via les SLO.
Service Level Objectives
Définir des objectifs mesurables de fiabilité qui guident les décisions.
Éliminer le Toil
Automatiser le travail répétitif et manuel pour libérer du temps pour l'amélioration.
Monitoring distribué
Observer les systèmes en profondeur pour détecter et diagnostiquer les problèmes.
Automatisation
Créer des systèmes qui se gèrent eux-mêmes autant que possible.
Release Engineering
Des processus de déploiement fiables, reproductibles et fréquents.
Simplicité
Réduire la complexité des systèmes pour améliorer la fiabilité.
SLI, SLO, SLA : Le cœur du SRE
Service Level Indicator
Une métrique quantitative qui mesure un aspect du service.
Exemples :
- Latence du 99e percentile
- Taux d'erreurs
- Throughput
- Disponibilité
Service Level Objective
L'objectif cible pour un SLI sur une période donnée.
Exemples :
- 99.9% des requêtes < 200ms
- < 0.1% d'erreurs par mois
- 99.95% de disponibilité
Service Level Agreement
Contrat avec les clients incluant les SLO et les pénalités.
Exemples :
- 99.9% uptime garanti
- Crédit si SLA non respecté
- Support 24/7 inclus
Error Budget : L'équilibre innovation/fiabilité
Error Budget = 100% - SLO
Si votre SLO est 99.9%, votre error budget est 0.1%
Budget disponible
Vous pouvez déployer des features risquées, expérimenter
Budget épuisé
Stop les déploiements risqués, focus sur la fiabilité
L'error budget crée un alignement naturel entre Dev (qui veut innover vite) et Ops (qui veut la stabilité). C'est un budget partagé à dépenser intelligemment.