1. Choisir les SLO #
Peu, mais significatifs.
Principes #
- Partir des parcours utilisateurs critiques (se connecter, payer, rechercher), pas des composants techniques.
- Deux ou trois SLO par service : disponibilité et latence suffisent souvent.
- Fixer l'objectif à partir de l'historique mesuré, puis le resserrer si besoin.
- Un SLO interne plus strict que le SLA contractuel.
2. Les faire vivre #
Un SLO non revu est un SLO mort.
Rituels #
- Politique de budget d'erreur écrite et signée par le produit.
- Alertes burn rate à la place des alertes à seuil pour l'astreinte.
- Revue mensuelle : budget consommé, incidents, objectif à ajuster ?
- SLO et règles générés depuis Git (Sloth ou Pyrra), revus en pull request.
- Post-mortem sans recherche de coupable dès qu'un incident consomme plus de 20 % du budget.
3. Pièges #
Ce qui fait échouer les démarches SLO.
À éviter #
| Piège | Conséquence |
|---|---|
| Viser 99,99 % partout | Coût énorme, budget toujours épuisé, SLO ignorés |
| Mesurer côté serveur uniquement | Les pannes du load balancer ou du DNS sont invisibles |
| Pas de politique de budget | Les SLO deviennent un simple dashboard |
| Trop de SLO | Personne ne les suit |
Schéma de référence et vérification rapide #
Check-list.
Check-list #
- Parcours critiques identifiés
- SLI mesurés au plus près de l'utilisateur
- SLO générés depuis Git
- Alertes burn rate routées vers l'astreinte
- Politique de budget validée
- Revue mensuelle planifiée
