SLO, SLI et SLA¶

Définir des indicateurs pertinents, fixer des objectifs realistes et gérer les error budgets.

Définitions et relations¶

graph TD
    SLI["SLI\nService Level Indicator\nMetrique mesuree"] --> SLO["SLO\nService Level Objective\nObjectif interne"]
    SLO --> SLA["SLA\nService Level Agreement\nContrat externe"]
    SLO --> EB["Error Budget\nMarge de tolerance"]

Terme	Définition	Exemple
SLI	Métrique qui mesure la qualité d'un service	Taux de requêtes HTTP < 500ms
SLO	Cible a atteindre sur un SLI sur une periode	99,5% des requêtes < 500ms sur 30 jours
SLA	Engagement contractuel avec pénalités	99% de disponibilité mensuelle garantie
Error Budget	Marge d'échec tolérée avant violation du SLO	0,5% des requêtes peuvent échouer

Choisir de bons SLI¶

Un bon SLI mesure ce que l'utilisateur ressent directement, pas ce qui est commode a mesurer.

Bons SLI¶

Taux de succès des requêtes (HTTP 2xx vs total)
Latence au percentile 95 ou 99
Disponibilité d'un parcours utilisateur critique
Fraicheur des données (âge du dernier batch traite)

Pieges a éviter¶

Anti-pattern	Problème
CPU moyen	Proxy indirect, pas ressenti utilisateur
Uptime du process	Un process peut tourner et ne rien servir
Métriques internes uniquement	Ne reflete pas l'expérience réelle
Trop de SLI	Dilution de l'attention, alerting confus

Partir de l'utilisateur

Demandez-vous : qu'est-ce qui ferait dire a un utilisateur que le service est dégradé ? C'est ca votre SLI.

Fixer des SLO realistes¶

Un SLO doit refléter la fiabilité réelle historique, pas un idéal.

Principes¶

Partir des données historiques des 90 derniers jours
Définir une cible atteignable, pas maximale
Impliquer le product owner : fiabilité a un coût
Réviser régulièrement (trimestriellement)

Niveaux typiques par type de service¶

Type de service	SLO disponibilité typique
API critique (paiement)	99,9%
API standard	99,5%
Service batch interne	99%
Dashboard analytique	95%

SLO a 100% interdit

Un SLO a 100% interdit tout changement : le moindre déploiement risque de le violer. Il n'existe pas de système a 100% fiable. Fixez 99,9% maximum pour les services les plus critiques.

Error budgets¶

L'error budget est la marge de dégradation tolérée avant violation du SLO.

Calcul¶

Pour un SLO de 99,5% sur 30 jours :

Fenêtre : \(30 \text{ jours} \times 24\text{h} \times 60\text{min} = 43\,200 \text{ minutes}\)
Budget d'indisponibilite : \(43\,200 \times 0{,}5\% = 216 \text{ minutes}\)

Cycle de décision¶

graph LR
    M["Mesure SLI"] --> C{"Budget\nconsomme ?"}
    C -- "< 50%" --> F["Deploiements\nlibres"]
    C -- "50-80%" --> R["Ralentir\nles releases"]
    C -- "> 80%" --> G["Freeze\nFocus fiabilite"]
    G --> M
    F --> M
    R --> M

Utilisation du budget¶

État du budget	Décision recommandee
Budget intact	Déploiements, experimentations autorisees
Budget a moitie consomme	Revue des risques avant chaque release
Budget presque épuisé	Freeze features, sprints fiabilité
Budget dépassé	Post-mortem obligatoire, plan de remediattion

SLA : quand formaliser¶

Le SLA est un contrat externe avec conséquences financieres ou juridiques.

SLA interne vs externe¶

Type	Usage	Pénalités
SLA externe	Client, partenaire	Credits, remboursements
SLA interne	Entre équipes (platform team)	Priorisation, escalade

Bonnes pratiques¶

Le SLA doit être inférieur au SLO (marge de sécurité)
Définir clairement les exclusions (maintenance planifiee, force majeure)
Ne formaliser un SLA que si vous pouvez le mesurer et le prouver

SLA sans mesure

Un SLA sans instrumentation est une promesse en l'air. Avant de signer, assurez-vous de pouvoir produire les rapports de conformité.