1. Pourquoi le SRE ? #
Mesurer la fiabilité du point de vue de l'utilisateur.
L'idée centrale #
Le SRE (Site Reliability Engineering), formalisé par Google, part d'un constat : 100 % de fiabilité n'est ni possible ni souhaitable. Chaque neuf supplémentaire coûte très cher et ralentit les livraisons, alors que l'utilisateur ne perçoit pas la différence entre 99,99 % et 100 % (son propre réseau est moins fiable).
On fixe donc un objectif de fiabilité explicite, mesuré du point de vue de l'utilisateur, et on accepte la marge restante comme un budget à dépenser (déploiements, expériences, incidents).
2. SLI, SLO, SLA #
Trois sigles à ne pas confondre.
Définitions #
| Terme | Définition | Exemple |
|---|---|---|
| SLI (indicateur) | Une mesure de la qualité de service, en général un ratio d'événements bons sur le total | Part des requêtes HTTP sans erreur 5xx et servies en moins de 300 ms |
| SLO (objectif) | La valeur cible du SLI sur une fenêtre de temps | 99,9 % sur 30 jours glissants |
| SLA (accord) | Un engagement contractuel avec des conséquences | 99,5 % par mois, sinon 10 % de remise |
Les SLI les plus courants #
| Type de service | SLI recommandé |
|---|---|
| API, site web | Disponibilité (réponses non 5xx) et latence (part des requêtes sous un seuil) |
| Traitement par lots | Fraîcheur (âge de la dernière exécution réussie), couverture |
| Pipeline de données | Fraîcheur, exactitude |
| Stockage | Durabilité, débit |
Bonne Pratique : Exprimez la latence comme un ratio (« 99 % des requêtes en moins de 300 ms ») plutôt qu'une moyenne ou un percentile instantané : le ratio se cumule sur la fenêtre et se calcule exactement avec les buckets d'un histogramme.
3. Combien de neuf ? #
L'objectif fixe le budget.
Indisponibilité autorisée #
| SLO | Par 30 jours | Par an |
|---|---|---|
| 99 % | 7 h 12 min | 3 j 15 h |
| 99,5 % | 3 h 36 min | 1 j 19 h |
| 99,9 % | 43 min | 8 h 46 min |
| 99,95 % | 21 min 36 s | 4 h 23 min |
| 99,99 % | 4 min 19 s | 52 min |
Erreur Courante : Un SLO plus strict que la fiabilité des dépendances est intenable : un service qui dépend d'une base à 99,9 % ne peut pas viser 99,99 % sans redondance.
