Pratiques SRE¶
Error budgets en équipe, SLO reviews, production readiness et launch checklist.
Error budgets en équipe¶
L'error budget est le "budget d'indisponibilite" autorise par un SLO. Si le SLO est de 99,9%, l'error budget est de 0,1% du temps, soit environ 43 minutes par mois.
Outil de décision feature vs fiabilité¶
L'error budget transforme le debat dev/ops en question objective :
- Budget intact ou en avance : l'équipe peut accélérer les déploiements, prendre plus de risques
- Budget consomme a 50% : prudence, ralentir les changements risques
- Budget presque consomme : pause des nouvelles features, investissement fiabilité obligatoire
- Budget dépassé : freeze features, tout le sprint va à la fiabilité
Error budget consomme = freeze features, investir fiabilité
Ce mécanisme est intentionnel : il créé une incitation économique pour les équipes dev a investir dans la fiabilité. La fiabilité n'est plus "le problème des ops", elle impacte directement la velocite feature.
Gouvernance de l'error budget¶
| Acteur | Rôle |
|---|---|
| SRE / ops | Mesurer et rendre visible la consommation |
| Product owner | Arbitrer feature vs fiabilité en fonction du budget |
| Tech lead | Proposer les investissements fiabilité prioritaires |
| Management | Soutenir les freezes features quand le budget l'exige |
SLO reviews¶
La SLO review est une réunion périodique (mensuelle en général) ou l'équipe examine l'état de ses engagements de fiabilité.
Agenda type d'une SLO review¶
- Consommation d'error budget par service : graphe sur 30 jours
- Services proches du seuil : analyse des causes, actions proposees
- Incidents ayant consomme significativement : lien postmortems
- Ajustement des SLO : certains sont-ils trop ambitieux ou trop lâches ?
- Roadmap fiabilité : avancement des actions correctives des reviews précédentes
Ajustements des SLO¶
Un SLO n'est pas grave dans le marbre. Il doit être révisé si :
- Il est constamment dépassé sans effort : le seuil est peut-être trop ambitieux
- Il n'est jamais approche : le seuil est peut-être trop lâche, masquant des dégradations réelles
- Le comportement utilisateur a change : les attentes ont évolue
Production readiness review¶
La production readiness review (PRR) est un processus de validation avant qu'un service ou une feature majeure ne parte en production. Elle evite les incidents "évidemment evitables" par un checklist systematique.
Checklist de production readiness¶
| Critère | Questions clés |
|---|---|
| Monitoring | Les métriques critiques sont-elles instrumentees ? Les dashboards existent-ils ? |
| Alerting | Les alertes couvrent-elles les modes de défaillance connus ? Les seuils sont-ils calibres ? |
| Runbooks | Existe-t-il un runbook pour chaque alerte ? Est-il à jour et teste ? |
| Disaster recovery | Le RTO/RPO est-il défini ? La procédure de restauration est-elle testée ? |
| On-call | Qui est on-call pour ce service ? La rotation est-elle en place ? |
| SLO | Le SLO du service est-il défini et mesure ? L'error budget est-il calcule ? |
| Capacité | La capacité a été-t-elle estimée pour les 3 prochains mois ? |
| Dépendances | Les dépendances critiques sont-elles identifiées et leur fiabilité évaluée ? |
Launch checklist¶
La launch checklist est le processus séquentiel qui garantit qu'un nouveau service ou une release majeure est pret pour la production.
graph LR
A["Design\nreview"] --> B["Capacity\nplanning"]
B --> C["Monitoring\n& alerting"]
C --> D["Runbooks\necrits"]
D --> E["DR teste"]
E --> F["On-call\nconfigure"]
F --> G["PRR\nvalidee"]
G --> H["Go-live"]
H --> I["Hypercare\n(48-72h)"]Phase hypercare¶
Après le go-live, une periode d'hypercare de 48 a 72 heures implique :
- Surveillance renforcee avec seuils plus bas
- Team disponible rapidement (pas necessairement d'astreinte formelle)
- Revue quotidienne des métriques les premiers jours
- Critères de rollback clairement définis avant le lancement
Capacity planning collaboratif¶
Le capacity planning est trop souvent fait en silo par les ops. Associer les devs amélioré la précision et la responsabilité.
Inputs nécessaires¶
| Source | Information |
|---|---|
| Product / marketing | Prévisions de croissance, campagnes planifiees |
| Dev | Changements architecturaux impactant les ressources |
| Ops / SRE | Tendances historiques de consommation, headroom actuel |
| Finance | Budget infrastructure disponible |
Cadence recommandee¶
- Mensuel : revue de la consommation vs prévisions
- Trimestriel : projection 3-6 mois, commandes si nécessaire
- Annuel : plan capacité pour le budget N+1
Capacity planning = prévenir, pas reagir
Atteindre 80% de capacité sans plan est un incident en préparation. La plupart des incidents de saturation sont predictibles plusieurs semaines à l'avance avec un suivi minimal des tendances.