Le Site Reliability Engineer (SRE) garantit la fiabilité et la disponibilité des systèmes en production. Discipline créée par Google en 2003, le SRE applique les méthodes de l’ingénierie logicielle aux problèmes d’exploitation.
La définition de Google est limpide :
“SRE is what happens when you ask a software engineer to design an operations function.”
Qu’est-ce qu’un SRE ?
Section intitulée « Qu’est-ce qu’un SRE ? »Le SRE n’est pas un administrateur système amélioré. C’est un ingénieur logiciel qui consacre son temps à rendre les systèmes plus fiables, scalables et efficaces. La différence fondamentale : là où l’ops traditionnel réagit aux incidents, le SRE les prévient en automatisant et en concevant des systèmes résilients.
Rôle et responsabilités
Section intitulée « Rôle et responsabilités »Définir et piloter les SLO
Section intitulée « Définir et piloter les SLO »Les Service Level Objectives (SLO) sont au cœur du travail du SRE :
| Concept | Description | Exemple |
|---|---|---|
| SLI | Service Level Indicator — métrique mesurable | Taux de requêtes réussies |
| SLO | Service Level Objective — cible à atteindre | 99.9% de requêtes réussies |
| SLA | Service Level Agreement — engagement contractuel | Remboursement si < 99.5% |
| Error Budget | Marge d’erreur acceptable | 0.1% = 43 min de downtime/mois |
Le SRE définit ces métriques avec les équipes produit et s’assure qu’elles sont respectées.
Gérer les Error Budgets
Section intitulée « Gérer les Error Budgets »L’Error Budget est un concept révolutionnaire : au lieu de viser “zéro incident”, on accepte une marge d’erreur calculée.
Si le SLO est 99.9%, l’Error Budget est 0.1%. Tant qu’il reste du budget :
- Les équipes peuvent prendre des risques (nouvelles features, expérimentations)
- Les déploiements continuent normalement
Si le budget est épuisé :
- Priorité absolue à la stabilité
- Gel des features, focus sur la fiabilité
Éliminer le toil
Section intitulée « Éliminer le toil »Le toil est le travail opérationnel manuel et répétitif :
- Intervention manuelle sur des alertes
- Tâches qui pourraient être automatisées
- Travail sans valeur durable
L’objectif du SRE : automatiser pour réduire le toil à moins de 50% du temps. Le reste est consacré à l’amélioration des systèmes.
Gérer les incidents
Section intitulée « Gérer les incidents »Quand un incident survient, le SRE :
- Détecte rapidement grâce à l’observabilité mise en place
- Mitigue pour restaurer le service au plus vite
- Résout la cause racine
- Documente via un post-mortem sans blâme
Le post-mortem est essentiel : comprendre ce qui s’est passé pour éviter que ça se reproduise, sans chercher de coupable.
Construire l’observabilité
Section intitulée « Construire l’observabilité »Le SRE met en place les trois piliers de l’observabilité :
| Pilier | Usage | Outils courants |
|---|---|---|
| Métriques | Quantifier le comportement | Prometheus, Datadog |
| Logs | Comprendre ce qui s’est passé | Loki, ELK, Splunk |
| Traces | Suivre les requêtes distribuées | Jaeger, Tempo, Zipkin |
Participer aux astreintes
Section intitulée « Participer aux astreintes »L’on-call (astreinte) fait partie du quotidien SRE :
- Rotation équitable entre les membres de l’équipe
- Alertes configurées pour minimiser les faux positifs
- Runbooks documentés pour chaque type d’incident
- Compensation et repos après les astreintes
Qualités humaines requises
Section intitulée « Qualités humaines requises »Résolution de problèmes sous pression
Section intitulée « Résolution de problèmes sous pression »Les incidents de production impactent les utilisateurs. Le SRE doit :
- Rester calme quand tout brûle
- Analyser méthodiquement sans céder à la panique
- Prendre des décisions rapides avec des informations incomplètes
Pensée systémique
Section intitulée « Pensée systémique »Un système distribué est complexe. Le SRE doit :
- Comprendre les interactions entre composants
- Anticiper les effets de cascade
- Voir le système comme un tout, pas comme des pièces isolées
Communication claire
Section intitulée « Communication claire »Pendant un incident :
- Informer les parties prenantes régulièrement
- Documenter les actions prises
- Rédiger des post-mortems lisibles par tous
Collaboration avec les développeurs
Section intitulée « Collaboration avec les développeurs »Le SRE n’est pas le “gardien de la production” qui dit non :
- Travailler ensemble sur la fiabilité dès la conception
- Partager la connaissance des systèmes
- Aider les devs à comprendre l’impact de leurs choix
Compétences techniques
Section intitulée « Compétences techniques »Programmation
Section intitulée « Programmation »Le SRE écrit du code quotidiennement :
| Langage | Usage |
|---|---|
| Python | Automatisation, scripts, outils internes |
| Go | Outils système performants |
| Bash | Scripts rapides, glue |
Infrastructure et orchestration
Section intitulée « Infrastructure et orchestration »| Domaine | Technologies |
|---|---|
| Conteneurs | Docker, containerd, OCI |
| Orchestration | Kubernetes en profondeur |
| Cloud | AWS/Azure/GCP, IaC (Terraform) |
| Networking | TCP/IP, DNS, load balancing |
Observabilité
Section intitulée « Observabilité »| Catégorie | Outils |
|---|---|
| Métriques | Prometheus, Grafana, Datadog |
| Logs | Loki, ELK Stack, Splunk |
| Traces | Jaeger, Tempo, Zipkin |
| Alerting | Alertmanager, PagerDuty, Opsgenie |
Pratiques avancées
Section intitulée « Pratiques avancées »- Chaos Engineering : tester la résilience (Chaos Monkey, Litmus)
- Capacity Planning : prévoir les besoins futurs
- Performance Engineering : optimisation, profiling
Parcours et évolution
Section intitulée « Parcours et évolution »Comment devenir SRE
Section intitulée « Comment devenir SRE »-
Maîtriser les fondamentaux
Linux, networking, scripting. Ces bases sont non négociables.
-
Apprendre à programmer vraiment
Python ou Go. Pas juste des scripts, mais des outils maintenables.
-
Pratiquer Kubernetes
Déployer, débugger, comprendre les composants internes.
-
Mettre en place l’observabilité
Prometheus, Grafana, alerting sur un projet personnel ou professionnel.
-
Lire le livre Google SRE
“Site Reliability Engineering” est la bible du domaine. Disponible gratuitement en ligne.
-
Chercher un rôle SRE junior ou DevOps
L’expérience terrain est irremplaçable.
Lectures recommandées
Section intitulée « Lectures recommandées »| Livre | Auteur | Focus |
|---|---|---|
| Site Reliability Engineering | Principes fondateurs | |
| The Site Reliability Workbook | Mise en pratique | |
| Seeking SRE | David Blank-Edelman | Perspectives variées |
Certifications utiles
Section intitulée « Certifications utiles »| Certification | Focus |
|---|---|
| CKA | Certified Kubernetes Administrator |
| CKS | Certified Kubernetes Security Specialist |
| AWS/Azure/GCP | Certifications cloud |
Évolutions possibles
Section intitulée « Évolutions possibles »| Orientation | Rôle suivant |
|---|---|
| Senior IC | Staff SRE, Principal SRE |
| Plateforme | Platform Engineer, Staff Platform |
| Management | Engineering Manager, Director SRE |
| Architecture | Architecte DevOps, Cloud Architect |
SRE selon la taille de l’entreprise
Section intitulée « SRE selon la taille de l’entreprise »Pas de SRE dédié. Les développeurs gèrent eux-mêmes la production. L’important :
- Mettre en place une observabilité basique dès le début
- Automatiser les déploiements
- Définir des SLO simples
Scale-up
Section intitulée « Scale-up »Premier SRE ou équipe SRE. Focus :
- Structurer les astreintes
- Formaliser les SLO/Error Budgets
- Créer les premiers runbooks
Grande entreprise
Section intitulée « Grande entreprise »Équipes SRE par domaine métier. Pratiques avancées :
- Embedded SRE : SRE intégré dans les équipes produit
- SRE as a Service : équipe centrale qui accompagne
- Chaos Engineering, game days
À retenir
Section intitulée « À retenir »- Le SRE applique l’ingénierie logicielle aux problèmes d’exploitation
- Les SLO et Error Budgets sont les outils clés de pilotage
- L’objectif est d’automatiser pour éliminer le toil (travail répétitif)
- Les post-mortems sans blâme permettent d’apprendre des incidents
- L’observabilité (métriques, logs, traces) est le fondement du travail
- Le SRE code : Python, Go, Bash font partie du quotidien
- C’est un rôle qui demande calme sous pression et pensée systémique
Pour approfondir
Section intitulée « Pour approfondir »- Guide des métiers DevOps — Vue d’ensemble de tous les rôles
- Rôles × Team Topologies — Où placer le SRE selon le contexte
- Fondamentaux DevOps — Culture et principes
- Observabilité — Métriques, logs, traces
- Site Reliability Engineering (Google) — Le livre fondateur