SRE : marché

Offre

une offre ouverte ayant passé le contrôle qualité et citant au moins deux technologies

Candidat observé

un candidat dont la stack contient cette technologie ; un agrégat — aucune fiche individuelle ne sort du périmètre

Candidat correspondant

pas encore compté

Fenêtre

offres ouvertes au moment de la création de l'instantané

SRE Junior — rare (entrée typique : DevOps Middle / Backend Middle + intérêt pour la fiabilité). Le saut Junior → Middle — après la résolution du premier incident en production + la première mise en place de SLO pour un service. Middle → Senior — responsabilité des SLO de plusieurs services + maîtrise des astreintes (responsabilité des métriques Mean Time to Detect / Recovery) + programmation d'automatisation au niveau Backend Middle/Senior. Senior → Staff / Principal — stratégie de fiabilité à l'échelle de l'organisation + leadership de la culture de production engineering + mentorat technique. Parcours de carrière : DevOps Middle (2-3 ans) → SRE Junior / Middle (1-2 ans) → Senior → soit SRE Staff / Principal, soit Engineering Manager (SRE), soit passage à Backend systèmes distribués Senior, soit spécialisation en Chaos Engineering ou Performance Engineering.

La distinction originale de Google (livre Site Reliability Engineering) : le DevOps — une culture / philosophie (« abattre les silos entre Dev et Ops »). Le SRE — une mise en œuvre concrète de la philosophie DevOps via des pratiques précises : SLI / SLO / error budgets + réduction du toil + automatisation d'abord + 50 % du temps consacré à l'ingénierie plutôt qu'à l'exploitation + post-mortems sans recherche de coupable. SRE = « ce qui arrive quand on demande à un ingénieur logiciel de concevoir une équipe d'exploitation ». Réalité pratique 2026 : 70 % de recoupement au niveau de la stack (les deux utilisent K8s + Terraform + Prometheus + Grafana). Différences observables dans les entreprises produit : 1) Profondeur en programmation — le SRE écrit plus d'outillage sur mesure en Go / Python (logique d'autoscaling, automatisation des déploiements, algorithmes de planification de capacité). L'Ingénieur DevOps configure plus souvent des outils existants. 2) Discipline SLI / SLO — le SRE est responsable de l'architecture des SLO (Pyrra / OpenSLO / Sloth), de l'application de la politique d'error budget, des alertes calées sur les burn rates des SLO. Le DevOps met souvent en place le monitoring sans SLO formels. 3) Maîtrise de l'astreinte — le SRE est en rotation d'astreinte régulière (24×7 pour les services critiques), plus fort en pilotage d'incident + animation de post-mortems. L'Ingénieur DevOps est généralement d'astreinte uniquement pour son propre produit. 4) Règle des 50 % d'ingénierie — politique de Google : un SRE ne doit pas consacrer plus de 50 % de son temps à l'exploitation, le reste est de l'automatisation. L'Ingénieur DevOps n'a pas ce garde-fou. 5) Théorie des systèmes distribués — les entretiens SRE incluent souvent le théorème CAP / les algorithmes de consensus / les modèles de cohérence / l'analyse des modes de défaillance. Les entretiens DevOps — plus d'outillage pratique. Dans les startups, cette distinction est souvent floue (une seule personne = DevOps et SRE à la fois).

SLI (Service Level Indicator) — une métrique mesurable de la santé du service (disponibilité / latence / taux d'erreurs / débit). SLO (Service Level Objective) — une valeur cible pour un SLI (p. ex. 99.9 % de disponibilité sur 30 jours). SLA (Service Level Agreement) — un engagement contractuel envers les clients (généralement plus faible que le SLO, p. ex. 99.5 % si le SLO est de 99.9 %, pour garder une marge de sécurité). Error budget = 100 % − SLO. Si le SLO est de 99.9 % sur 30 jours → error budget = 0.1 % = 43 minutes d'indisponibilité/mois. Quand l'error budget se consume vite → gel des déploiements de nouvelles fonctionnalités, l'équipe se concentre sur la fiabilité. Quand l'error budget est sain → livrer les fonctionnalités de manière offensive. Mise en place pratique du cadre (12 étapes) : 1) Identifier les parcours utilisateurs critiques côté client (CUJ). 2) Choisir les SLI pour chaque CUJ (généralement disponibilité + latence pour le synchrone, débit + fraîcheur pour l'asynchrone). 3) Choisir la cible de SLO initiale (règle : légèrement en dessous des performances actuelles). 4) Mettre en place la mesure des SLI (Prometheus + Grafana ou service managé). 5) Configurer les alertes sur le burn rate (multi-fenêtres : consommation rapide 1 h à 14.4× le rythme, consommation lente 6 h à 6× le rythme — formule de Google). 6) Mettre en place le SLO-as-code (Pyrra / OpenSLO / Sloth) pour le contrôle de version. 7) Documenter la politique d'error budget (que se passe-t-il à l'épuisement — gel des fonctionnalités ? revue d'incident ?). 8) Revue trimestrielle des SLO (ajustement des cibles selon les performances réelles + l'impact client). 9) Suivi du toil + feuille de route de réduction (objectif : <50 % du temps consacré au toil). 10) Culture du post-mortem — sans recherche de coupable, centrée sur les actions correctives. 11) Intégration du chaos engineering (Gremlin / Chaos Mesh — tester le SLO en conditions de défaillance au préalable). 12) Tableau de bord de confiance client (page de statut publique — Statuspage / Atlassian / Better Uptime).

Linux / systèmes en profondeur : processus, namespaces, cgroups, réseau (TCP/IP, DNS, répartition de charge), débogage des performances (strace / perf / eBPF). Stack d'observabilité : Prometheus + Grafana (PromQL en profondeur), traçage distribué (Tempo / Jaeger / OpenTelemetry), logs (Loki / ELK), APM managé (Datadog / Grafana Cloud / Honeycomb) — le SRE « voit » le système à travers les métriques. Pratique des SLO : SLI / SLO / error budget (voir la question dédiée), alertes sur le burn rate, SLO-as-code. Réponse aux incidents + astreinte : PagerDuty / Opsgenie, runbooks, post-mortems sans recherche de coupable, évaluation de la gravité. Kubernetes : exploitation en production (niveau CKA) — workloads, réseau, dépannage. IaC + automatisation : Terraform / OpenTofu, Ansible ; la compétence SRE clé est de réduire le toil (travail manuel répétitif) par l'automatisation, objectif <50 % du temps consacré au toil. CI/CD : déploiements sûrs — canary, blue-green, progressive delivery, rollback. Programmation : Python et / ou Go à un niveau permettant d'écrire des outils d'automatisation maintenables, pas des « scripts ». Systèmes distribués : modes de défaillance, retry / timeout / circuit breaker, idempotence, cohérence — la base de la planification de capacité et du PRA. Chaos engineering : Gremlin / Chaos Mesh — vérifier la fiabilité avant l'incident. L'essentiel : le SRE traite la fiabilité comme un produit — il la mesure (SLO), automatise la routine et élimine méthodiquement les causes d'incidents au lieu de les éteindre à la main. L'anglais est obligatoire — la littérature SRE (livre SRE de Google) et la communauté sont anglophones.

Oui, 41 % des offres SRE sont entièrement à distance ou hybrides. Le travail SRE — dans le cloud + tableaux de bord de monitoring. Prestataires — presque toujours à distance. Entreprises produit russes — hybride ou à distance après la période d'essai. Banques russes — hybride/bureau pour la conformité de sécurité. Entreprises tech internationales — tout à distance standard. Réserve propre au SRE : la rotation d'astreinte — exige une connexion internet fiable + une alimentation de secours + un espace calme pour répondre aux urgences de nuit. Certaines entreprises exigent un audit de l'installation du bureau à domicile avant une offre SRE à distance. Fuseau horaire — les postes SRE exigent généralement un chevauchement avec le fuseau principal de l'équipe (les entreprises américaines veulent souvent 4+ heures de chevauchement avec PT/ET). Pôles d'expatriation : Pologne / Allemagne / Canada / Serbie / Géorgie. L'anglais pour le télétravail SRE international — indispensable (commandement d'incident sur Zoom en anglais sous pression).

Production Engineer (PE) — le terme de Facebook / Meta pour le SRE. Même discipline, responsabilités presque identiques — fiabilité + automatisation + astreinte + planification de capacité + systèmes distribués. La différence est historiquement philosophique : SRE chez Google — « un ingénieur logiciel qui se trouve faire de l'exploitation », PE chez Facebook — « un ingénieur intégré à une équipe produit pour la fiabilité ». Dans la pratique 2026 — recoupement presque total. Autres intitulés équivalents : Reliability Engineer (LinkedIn), Ingénieur Infrastructure (recoupe souvent le SRE), Production Operations Engineer (terme historique). Comment lire les offres d'emploi 2026 : cherchez des signaux dans la fiche de poste — si elle mentionne « SLI/SLO », « error budgets », « réduction du toil », « 50 % du temps en ingénierie », « post-mortems sans recherche de coupable », « rotation d'astreinte », c'est un rôle de type SRE quel que soit l'intitulé. Si elle mentionne « mise en place du CI/CD », « migration vers le cloud », « infrastructure as code » mais SANS parler de SLO, c'est du DevOps généraliste.

Feuille de route : 1) Socle DevOps solide — maîtrise de Linux + Docker + Kubernetes (CKA) + une plateforme cloud en profondeur + IaC (Terraform). Sans ce socle, inutile d'aller vers le SRE. 2) Programmation au niveau Backend Middle — Go (le standard du SRE — Kubernetes / Prometheus / la plupart des outils SRE sont en Go) ou Python en profondeur (analyse de données + scripting). Livres : « The Go Programming Language » de Donovan / Kernighan, « Fluent Python » de Ramalho. 3) Le livre « Site Reliability Engineering » de Google (PDF gratuit) — à lire absolument, et deux fois. 4) « The Site Reliability Workbook » de Google — complément pratique (études de cas + exercices). 5) Maîtrise des SLI / SLO — mettre en place des SLO-as-code (Sloth / Pyrra / OpenSLO) pour un vrai service, configurer des alertes de burn rate (multi-fenêtres : rapide 1 h 14.4×, lente 6 h 6×). 6) Théorie des systèmes distribués — théorème CAP, modèles de cohérence (linéarisabilité / séquentielle / causale / à terme), consensus (bases de Paxos / Raft), analyse des modes de défaillance. Livres : « Designing Data-Intensive Applications » de Martin Kleppmann (à lire absolument 2026), « Database Internals » de Petrov. 7) Chaos engineering — Chaos Mesh / Gremlin / LitmusChaos. Mettre en place des expériences de chaos sur votre propre cluster K8s. Livre : « Chaos Engineering » de Nora Jones / Casey Rosenthal. 8) Maîtrise des tests de charge — k6 (moderne, basé sur JS, en croissance) ou Gatling (DSL Scala) ou Locust (Python). Mettre en place des tests de charge intégrés au CI. 9) Observabilité en profondeur : Prometheus avancé (maîtrise de PromQL + recording rules + fédération), Grafana avancé (templating + alertes), Loki + Tempo + OpenTelemetry. Cas d'usage : traçage distribué entre microservices. 10) Formation à la réponse aux incidents — bases du commandement d'incident, cadre des post-mortems sans recherche de coupable, communication pendant les incidents. Ressources : « Incident Response & Computer Forensics » de Luttgens / Pepe / Mandia, formation de Google à la gestion des incidents. 11) Projet personnel : déployer une application distribuée sur K8s avec une configuration SLO complète + des expériences de chaos + une simulation d'astreinte. Documenter comme un système prêt pour la production. Formations russes : Slurm SRE, Otus « SRE », Karpov.Courses SRE Track. International (EN) : « Database Reliability Engineering » de Campbell / Majors, conférences USENIX SREcon (gratuites sur YouTube), Google Cloud SRE Certification Path. DevOps Middle + intérêt → SRE Junior — 4-10 mois (il faut renforcer la programmation + la théorie des systèmes distribués).

701 active open SRE positions — premium segment of the DevOps direction. Geography: the US, India, the UK. The real market is broader thanks to a huge international remote segment. Time to close a Senior SRE role — 6-12 weeks (longer than general DevOps due to rare-skill requirements: programming + distributed systems + on-call mastery combination).

Un SRE Senior prend en charge le cycle complet d'ingénierie de la fiabilité + le leadership technique. Programmation au niveau Backend Middle+ : maîtrise de Go (standard pour l'automatisation SRE) ou Python en profondeur — au niveau « sait écrire une logique d'autoscaling / des algorithmes de planification de capacité / des operators K8s personnalisés de qualité production ». Maîtrise approfondie de Kubernetes : à l'échelle de la production (nœuds), Operators (Kubebuilder / Operator SDK), CRD personnalisés, patterns multi-tenant. Théorie des systèmes distribués : compréhension approfondie du théorème CAP, modèles de cohérence (linéarisabilité / séquentielle / causale / éventuelle), algorithmes de consensus (Paxos / Raft), taxonomie des modes de défaillance, patterns de gestion des partitions réseau. Maîtrise de l'observabilité : Prometheus avancé (maîtrise de PromQL + recording rules + fédération + remote_write), Grafana avancé (templating + transformations + alerting), maîtrise de l'intégration Loki + Tempo + OpenTelemetry, traçage distribué à travers les microservices. Maîtrise de l'architecture SLI / SLO : SLO-as-code (Pyrra / OpenSLO / Sloth), conception de politiques d'error budget + automatisation de leur application, réglage des alertes de burn rate multi-fenêtres (éviter la fatigue d'alerte). Maîtrise du commandement d'incident : piloter la réponse aux incidents sous pression, animer des post-mortems sans blâme, analyse des facteurs contributifs (pas de cause racine — approche moderne), priorisation des actions. Maîtrise du chaos engineering : Chaos Mesh / Gremlin / LitmusChaos — concevoir des expériences de chaos, animer des GameDays. Maîtrise de la planification de capacité : méthodologie des tests de charge (k6 / Gatling / Locust), modèles de prévision des ressources, analyse de la marge, gestion des pics de charge. Ingénierie de la performance : optimisation guidée par le profilage (perf / bpftrace / flamegraphs), diagnostic des fuites mémoire, réglage du GC, analyse des performances réseau. Service mesh en profondeur : Istio / Linkerd / Cilium — gestion du trafic, politiques de relance, circuit breakers, injection de fautes. Conception de systèmes pour la fiabilité : concevoir au tableau blanc une HA multi-région multi-AZ, planification RPO / RTO, stratégies de reprise, architecture cellulaire pour limiter le rayon d'impact. Soft skills : rédaction d'ADR, communication en incident (mises à jour de la page de statut + appels avec les parties prenantes en crise), discipline de la rotation d'astreinte, collaboration inter-équipes (équipes Backend / DevOps / Plateforme / Sécurité), mentorat de SRE Middle. Anglais INDISPENSABLE pour Senior+ — le SRE est très inter-équipes + la communauté est anglophone (USENIX SREcon, articles).