L'exploitation réactive, c'est subir les incidents. L'exploitation SRE, c'est les anticiper. La différence entre un cluster qu'on surveille et un cluster qu'on subit, c'est la structuration : des rituels d'exploitation réguliers, des runbooks documentés et des indicateurs de fiabilité mesurables.
La démarche Site Reliability Engineering (SRE) appliquée à Kubernetes repose sur trois piliers : une routine d'exploitation qui couvre les vérifications essentielles, des runbooks qui capitalisent sur les incidents résolus, et des SLO/SLI qui rendent la fiabilité observable.
Les trois niveaux d'exploitation structurée
Section intitulée « Les trois niveaux d'exploitation structurée »Niveau 1, La routine d'exploitation
Section intitulée « Niveau 1, La routine d'exploitation »Des rituels réguliers pour détecter les dégradations avant qu'elles deviennent des incidents :
- Quotidien : état des nœuds, pods en erreur, consommation des ressources critiques, alertes actives
- Hebdomadaire : nettoyage des ressources orphelines, révision des événements, contrôle des certificats à expiration courte, audit des images obsolètes
- Mensuel : révision des quotas, audit RBAC, rotation des secrets, test de restauration
Niveau 2, Les runbooks
Section intitulée « Niveau 2, Les runbooks »Un runbook est une procédure documentée pour un type d'incident récurrent. Il répond à : Que faire si X arrive ?
Caractéristiques d'un bon runbook :
- Déclenché par une alerte ou un symptôme précis (pas générique)
- Actions dans l'ordre, avec les commandes exactes
- Critères de succès explicites
- Escalade documentée si la procédure échoue
Niveau 3, SLO et SLI
Section intitulée « Niveau 3, SLO et SLI »Un SLI (Service Level Indicator) mesure la fiabilité d'un service : taux d'erreur, latence p99, disponibilité.
Un SLO (Service Level Objective) fixe la cible : « 99,5% des requêtes répondent en moins de 500ms sur 30 jours ».
Le budget d'erreur (100% - SLO) définit la marge d'expérimentation acceptable avant de prioriser la fiabilité sur les nouvelles fonctionnalités.
Guides de cette section
Section intitulée « Guides de cette section »À retenir
Section intitulée « À retenir »- La réactivité est coûteuse : chaque incident non anticipé coûte plus que la routine qui l'aurait prévenu
- Les runbooks réduisent le MTTR (Mean Time To Recover) en éliminant l'improvisation sous stress
- Un SLO sans budget d'erreur n'est pas actionnable, le budget d'erreur est la mécanique qui rend les SLO utiles
- Commencez simple : une vérification matinale, un runbook pour CrashLoopBackOff, un SLI de disponibilité, puis itérez
- Kubernetes fournit les primitives (events, metrics-server, readiness probes), l'exploitation les exploite