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.
Mon suivi
Connectez-vous pour suivre votre progression et prendre des notes. Se connecter
💬 Discussions récentes de la formation
- Alerter sur un SLO de 99,9 % sans être réveillé pour rien✓ résolu · 1 réponse(s)
Poser une question sur cette leçon →Voir toutes les discussions de la formation
Articles recommandés
Les SLO dans Dynatrace : objectifs, budget d’erreur et burn rate
SLI, SLO et SLA, budget d'erreur et taux de consommation : définir un SLO de disponibilité ou de ...
Mesurer des SLI avec Prometheus
Implémenter des SLI de disponibilité et de latence avec Prometheus : métriques nécessaires, requê...
Chaos engineering : principes, outils et mise en pratique avec les SLO
Guide complet du chaos engineering : principes, régime permanent et hypothèse, rayon d'impact, li...
Le budget d'erreur : décider avec les SLO
Calculer et suivre un budget d'erreur, rédiger une politique de budget d'erreur et l'utiliser pou...
Bonnes pratiques SRE : SLO utiles et budgets respectés
Check-list pour mettre en place des SLO qui servent : choix des parcours utilisateurs, objectifs ...
Piloter ses SLO avec Pyrra
Pyrra : définir des SLO de disponibilité et de latence en CRD Kubernetes ou en fichiers, générer ...
Alertes sur le taux de consommation du budget (burn rate multi-fenêtres)
Pourquoi alerter sur le burn rate plutôt que sur un seuil, et comment construire les alertes mult...
Générer ses SLO Prometheus avec Sloth
Décrire un SLO en quelques lignes avec Sloth et générer automatiquement règles d'enregistrement m...
Observabilité, SRE et gestion des incidents pour les équipes DevOps
Exploiter ce que l'on livre : métriques, logs et traces, golden signals, SLI, SLO et budgets d'er...