⚙️ SRE & Fiabilité
Site Reliability Engineering
🚦 Analogie : Le Permis à Points (Error Budget)
L'Error Budget est comme un permis de conduire à points. Chaque panne ou ralentissement de votre application vous fait perdre des points.
Tant qu'il vous reste des points, les développeurs peuvent rouler vite et déployer plein de nouveautés. Si vous perdez tous vos points, on vous retire le permis : gel des déploiements, toute l'équipe doit réparer et stabiliser le moteur avant de pouvoir repartir en prod.
⚠️ Rappel : Le Mythe du 100%
Viser 100% de fiabilité est une erreur (et mathématiquement impossible sur Internet). Passer de 99.9% à 99.99% coûte exponentiellement plus cher en ingénierie et serveurs redondants, pour un bénéfice que l'utilisateur final ne remarquera probablement même pas (sa propre connexion 4G/Wifi lâchera avant). Calibrez votre SLO sur les attentes réelles du business.
📖 SRE : L'Ingénierie de la Fiabilité
Le Site Reliability Engineering (SRE) est une discipline qui intègre des aspects du génie logiciel et les applique aux problèmes d'exploitation. Comme le dit Google : "class SRE implements Interface DevOps".
L'objectif du SRE est de créer des systèmes logiciels ultra-scalables et hautement fiables. Contrairement au SysAdmin traditionnel, le SRE passe au moins 50% de son temps à coder pour automatiser les tâches d'exploitation (réduire le Toil).
💡 Le saviez-vous ? La naissance du SRE
Le terme a été inventé par Ben Treynor Sloss chez Google en 2003. Il a constitué une équipe de software engineers pour gérer l'exploitation du moteur de recherche. Sa règle d'or : si une tâche doit être faite manuellement plus de deux fois, elle doit être automatisée.
Aujourd'hui, le livre "Google SRE Book" est considéré comme la bible du domaine.
📊 A. La Chaîne SLI → SLO → SLA
🧮 Calculateur SLO
Combien de downtime autorisé (Error Budget) ?
📋 Exemples SLOs Réels
| Service | SLI | SLO |
|---|---|---|
| API | Latency P99 | < 200ms |
| Web | Availability | 99.9% |
| DB | Error Rate | < 0.1% |
📡 B. The 4 Golden Signals
Si vous ne devez mesurer que 4 choses, mesurez celles-ci (Google SRE Book).
Latency
Le temps pour servir une requête (ms).
Distinguerez succès (200) et erreurs (500).
Traffic
La demande sur votre système.
RPM (Req/min) ou I/O par sec.
Errors
Le taux d'échec.
500, mais aussi 200 avec mauvais contenu !
Saturation
Le niveau de "remplissage".
CPU, RAM, Disque, Thread Pool.
🚒 C. Incident Command System (ICS)
Inspiré des pompiers 🇺🇸. Lors d'une panne majeure, la démocratie ne fonctionne pas. Il faut une hiérarchie claire.
- 👑 Commander : Chef d'orchestre. Ne touche PAS au clavier. Prend les décisions.
- ✍️ Scribe : Note TOUT (Time, Action, Result) pour le post-mortem.
- 🛠️ Ops Lead : Dirige les techniciens qui réparent.
- 📣 Comms : Parle aux clients/stakeholders.
🛑 Troubleshooting : "C'est le chaos absolu pendant notre panne !"
- Symptôme : Un service critique est down. 15 personnes parlent en même temps sur Slack/Teams, 3 devs essaient des correctifs différents sur la prod sans se concerter, et le client appelle toutes les 2 minutes pour savoir où ça en est. (Durée de panne rallongée).
- Diagnostic : Vous subissez le syndrome de "l'attroupement" sans leadership défini. La communication tue la résolution.
- Remède Immédiat :
1. Stoppez tout ("Stop the bleeding").
2. Établissez instantanément un Commander (celui qui prend les décisions). Tout le monde doit le mentionner avant de taper une commande.
3. Créez un canal War Room séparé dédié uniquement aux techniciens avec zéro bruit de la hiérarchie.
🐒 D. Chaos Engineering
L'Antifragilité
"Ce qui ne me tue pas me rend plus fort". Le Chaos Engineering consiste à injecter des pannes en prod pour vérifier que le système tient le coup.
Outils du Chaos
- Chaos Monkey (Netflix) : Tue des instances EC2 au hasard.
- Gremlin : SaaS pour simuler latence, perte de paquets, CPU spike...
- Chaos Mesh (K8s) : Pod Kill, Network Partition dans Kubernetes.
⚡ Réduire le Toil
Toil = Travail manuel répétitif sans valeur
- Automatiser les tâches > 2 fois
- Self-service pour les devs
- Objectif : <50% du temps en Toil
📊 SRE vs DevOps vs SysAdmin
👴 SysAdmin (Classique)
- Focus : Maintenir les serveurs en vie ("Keep the lights on").
- Méthode : Ticket d'incident, interventions manuelles.
- Échec : Mauvais, signe de faiblesse.
- Automatisation : Minimale, scripts bash ad-hoc.
🔄 DevOps (Collaboratif)
- Focus : Casser les silos Dev/Ops ("You build it, you run it").
- Méthode : CI/CD, Infrastructure as Code, feedback loops.
- Échec : Opportunité d'amélioration continue.
- Automatisation : Pipelines, déploiements automatisés.
🛠️ SRE (Moderne)
- Focus : Automatiser l'exploitation ("Engineer away the toil").
- Méthode : Code, Error Budgets, Post-mortems.
- Échec : Opportunité d'apprentissage, géré par le budget d'erreur.
- Automatisation : Tout est code, 50% du temps minimum sur l'engineering.
📊 Cas d'étude : Google - La culture du "Blameless Post-Mortem"
Contexte : Chez Google, quand un service tombe, on ne cherche pas "qui" a fait l'erreur, mais "pourquoi" le système a permis à cette erreur d'arriver.
Transformation :
- Blameless Culture : Un post-mortem n'inclut jamais de noms de personnes. Il se concentre sur les défaillances techniques ou de process.
- Error Budget enforcement : Si le budget d'erreur d'un mois est consommé, les releases sont bloquées. Point final. Isso force les Devs à s'intéresser à la stabilité.
- Burnout prevention : Les SRE ont le droit de renvoyer l'exploitation aux Devs si le Toil dépasse les 50%.
Résultat : Une fiabilité légendaire malgré une complexité et un trafic quasi infinis.
🔄 À Retenir - SRE Mastery
- L'erreur est inévitable : Ne visez pas 100% de fiabilité (personne n'en a besoin, et c'est trop cher).
- Error Budget : C'est le contrat qui aligne Devs (vitesse) et SRE (stabilité).
- Post-Mortem : Toujours documenter les pannes pour ne plus jamais qu'elles ne se reproduisent.
- Automatisez le Toil : Si vous faites la même chose manuellement tous les jours, vous n'êtes pas SRE.