SRE: Markt

Stelle

eine offene Stelle, die das Qualitäts-Gate passiert hat und mindestens zwei Technologien nennt

Beobachteter Kandidat

ein Kandidat, dessen Stack diese Technologie enthält; ein Aggregat — kein einziger Datensatz verlässt den Perimeter

Matchbarer Kandidat

noch nicht gezählt

Fenster

Stellen, die zum Zeitpunkt der Erstellung des Snapshots offen waren

Junior SRE — selten (typischer Einstieg: DevOps Middle / Backend Middle + Interesse an Zuverlässigkeit). Der Sprung Junior → Middle — nach der ersten Lösung eines Produktionsvorfalls + dem ersten SLO-Setup für einen Service. Middle → Senior — Verantwortung für SLOs mehrerer Services + Beherrschung der Rufbereitschaft (Verantwortung für die Kennzahlen Mean Time to Detect / Recovery) + Automatisierung auf Backend-Middle/Senior-Niveau. Senior → Staff / Principal — organisationsweite Zuverlässigkeitsstrategie + Führung der Production-Engineering-Kultur + technisches Mentoring. Karriereweg: DevOps Middle (2-3 Jahre) → SRE Junior / Middle (1-2 Jahre) → Senior → entweder Staff / Principal SRE, Engineering Manager (SRE), Wechsel zu Backend Distributed Systems Senior oder Spezialisierung auf Chaos Engineering oder Performance Engineering.

Googles ursprüngliche Unterscheidung (Buch Site Reliability Engineering): DevOps — eine Kultur / Philosophie („Silos zwischen Dev und Ops aufbrechen“). SRE — eine konkrete Umsetzung der DevOps-Philosophie durch bestimmte Praktiken: SLI / SLO / Error Budgets + Reduzierung von Toil + Automation-first + 50% der Zeit für Engineering statt Betriebsarbeit + schuldfreie Post-Mortems. SRE = „was passiert, wenn man einen Softwareingenieur bittet, ein Betriebsteam zu entwerfen“. Praktische Realität 2026: 70% Überschneidung auf Stack-Ebene (beide nutzen K8s + Terraform + Prometheus + Grafana). Unterschiede, die in Produktunternehmen sichtbar sind: 1) Programmiertiefe — SRE schreibt mehr eigene Go- / Python-Tools (Autoscaling-Logik, Deployment-Automatisierung, Algorithmen zur Kapazitätsplanung). Ein DevOps Engineer konfiguriert häufiger vorhandene Tools. 2) SLI- / SLO-Disziplin — SRE verantwortet die SLO-Architektur (Pyrra / OpenSLO / Sloth), die Durchsetzung der Error-Budget-Policy, Alerting abgestimmt auf SLO-Burn-Rates. DevOps richtet Monitoring oft ohne formale SLOs ein. 3) Meisterschaft in der Rufbereitschaft — SRE in regelmäßiger On-Call-Rotation (24×7 für kritische Services), stärker in Incident Command + Moderation von Post-Mortems. Ein DevOps Engineer hat meist nur für das eigene Produkt Rufbereitschaft. 4) 50%-Engineering-Regel — Google-Policy: Ein SRE soll nicht mehr als 50% der Zeit mit Betriebsarbeit verbringen, der Rest ist Engineering-Automatisierung. Ein DevOps Engineer hat keine solche Schutzregel. 5) Theorie verteilter Systeme — SRE-Interviews enthalten oft CAP-Theorem / Konsensalgorithmen / Konsistenzmodelle / Analyse von Fehlermodi. DevOps-Interviews — mehr praktische Tools. In Startups verschwimmt diese Unterscheidung oft (eine Person = DevOps und SRE zugleich).

SLI (Service Level Indicator) — eine messbare Kennzahl für die Gesundheit eines Service (Verfügbarkeit / Latenz / Fehlerrate / Durchsatz). SLO (Service Level Objective) — ein Zielwert für einen SLI (z. B. 99.9% Verfügbarkeit über 30 Tage). SLA (Service Level Agreement) — eine vertragliche Zusage an Kunden (meist schwächer als das SLO, z. B. 99.5%, wenn das SLO 99.9% beträgt, um einen Sicherheitspuffer zu behalten). Error Budget = 100% − SLO. Liegt das SLO bei 99.9% über 30 Tage → Error Budget = 0.1% = 43 Minuten Ausfallzeit/Monat. Wenn das Error Budget schnell verbraucht wird → Deployments neuer Features einfrieren, das Team auf Zuverlässigkeitsarbeit konzentrieren. Wenn das Error Budget gesund ist → Features offensiv ausliefern. Praktische Einrichtung des Frameworks (12 Schritte): 1) Kundenrelevante kritische User Journeys (CUJs) identifizieren. 2) SLIs für jede CUJ wählen (typischerweise Verfügbarkeit + Latenz für synchrone, Durchsatz + Aktualität für asynchrone Abläufe). 3) Das initiale SLO-Ziel wählen (Regel: etwas unter der aktuellen Leistung). 4) SLI-Messung einrichten (Prometheus + Grafana oder verwaltet). 5) Burn-Rate-Alerts konfigurieren (Multi-Window: schneller Verbrauch 1h 14.4× Rate, langsamer Verbrauch 6h 6× Rate — Google-Formel). 6) SLO-as-Code einrichten (Pyrra / OpenSLO / Sloth) für die Versionskontrolle. 7) Die Error-Budget-Richtlinie dokumentieren (was bei Erschöpfung passiert — Feature Freeze? Incident Review?). 8) Vierteljährliche SLO-Überprüfung (Zielanpassung auf Basis der tatsächlichen Leistung + Auswirkung auf Kunden). 9) Erfassung von Toil + Roadmap zu dessen Reduzierung (Ziel: <50% der Zeit für Toil). 10) Post-Mortem-Kultur — schuldfrei, Fokus auf Maßnahmen. 11) Integration von Chaos Engineering (Gremlin / Chaos Mesh — SLO unter Ausfällen vorab testen). 12) Dashboard für Kundenvertrauen (öffentliche Statusseite — Statuspage / Atlassian / Better Uptime).

Linux / Systeme in der Tiefe: Prozesse, Namespaces, cgroups, Netzwerke (TCP/IP, DNS, Load Balancing), Performance-Debugging (strace / perf / eBPF). Observability-Stack: Prometheus + Grafana (PromQL in der Tiefe), Distributed Tracing (Tempo / Jaeger / OpenTelemetry), Logs (Loki / ELK), verwaltetes APM (Datadog / Grafana Cloud / Honeycomb) — der SRE „sieht“ das System über Metriken. SLO-Praxis: SLI / SLO / Error Budget (siehe separate Frage), Burn-Rate-Alerts, SLO as Code. Incident Response + Rufbereitschaft: PagerDuty / Opsgenie, Runbooks, schuldfreie Post-Mortems, Bewertung des Schweregrads. Kubernetes: Produktionsbetrieb (CKA-Niveau) — Workloads, Netzwerke, Fehlerbehebung. IaC + Automatisierung: Terraform / OpenTofu, Ansible; die zentrale SRE-Fähigkeit ist die Reduzierung von Toil (manueller, sich wiederholender Arbeit) durch Automatisierung, Ziel <50% der Zeit für Toil. CI/CD: sichere Deploys — Canary, Blue-Green, Progressive Delivery, Rollback. Programmierung: Python und / oder Go auf dem Niveau, wartbare Automatisierungstools zu schreiben, nicht „Skripte“. Verteilte Systeme: Fehlermodi, Retry / Timeout / Circuit Breaker, Idempotenz, Konsistenz — die Grundlage für Kapazitätsplanung und DR. Chaos Engineering: Gremlin / Chaos Mesh — Zuverlässigkeit vor dem Incident prüfen. Das Wichtigste: SRE behandelt Zuverlässigkeit als Produkt — misst sie (SLO), automatisiert Routine und beseitigt systematisch die Ursachen von Incidents, statt sie von Hand zu löschen. Englisch ist Pflicht — die SRE-Literatur (Google SRE Book) und die Community sind englischsprachig.

Ja, 41% der SRE-Stellen sind vollständig remote oder hybrid. SRE-Arbeit — cloudbasiert + Monitoring-Dashboards. Outsourcer — fast immer remote. Russische Produktunternehmen — hybrid oder remote nach der Probezeit. Russische Banken — hybrid/Büro wegen Security-Compliance. Internationale Tech-Unternehmen — vollständig remote als Standard. Einschränkung speziell für SRE: On-Call-Rotation — erfordert zuverlässiges Internet + Notstromversorgung + einen ruhigen Raum für nächtliche Notfalleinsätze. Manche Unternehmen verlangen vor einem Remote-Angebot für SRE eine Prüfung des Homeoffice-Setups. Zeitzone — SRE-Rollen verlangen meist eine Überschneidung mit der Hauptzeitzone des Teams (US-Unternehmen wollen oft 4+ Stunden Überschneidung mit PT/ET). Relokations-Hubs: Polen / Deutschland / Kanada / Serbien / Georgien. Englisch für internationale SRE-Remote-Arbeit — Pflicht (Incident Command per Zoom auf Englisch unter Stress).

Production Engineer (PE) — der Begriff von Facebook / Meta für SRE. Dieselbe Disziplin, nahezu identische Aufgaben — Fokus auf Zuverlässigkeit + Automatisierung + Rufbereitschaft + Kapazitätsplanung + verteilte Systeme. Der Unterschied ist historisch philosophischer Natur: Google SRE — „ein Softwareingenieur, der zufällig Betrieb macht“, Facebook PE — „ein Ingenieur, der für die Zuverlässigkeit in ein Produktteam eingebettet ist“. In der Praxis 2026 — fast vollständig deckungsgleich. Andere gleichwertige Titel: Reliability Engineer (LinkedIn), Infrastructure Engineer (überschneidet sich oft mit SRE), Production Operations Engineer (Legacy-Begriff). Wie man Stellenanzeigen liest 2026: Achten Sie auf Signale in der Stellenbeschreibung — wenn „SLI/SLO“, „Error Budgets“, „Reduzierung von Toil“, „50% Engineering-Zeit“, „schuldfreie Post-Mortems“, „On-Call-Rotation“ erwähnt werden — ist es unabhängig vom Titel eine Rolle im SRE-Stil. Wenn „Einrichtung von CI/CD“, „Cloud-Migration“, „Infrastructure as Code“ erwähnt werden, aber OHNE SLOs — ist es allgemeines DevOps.

Roadmap: 1) Solide DevOps-Basis — Linux beherrschen + Docker + Kubernetes (CKA) + eine Cloud-Plattform in der Tiefe + IaC (Terraform). Ohne diese Basis hat der Weg ins SRE keinen Sinn. 2) Programmieren auf Backend-Middle-Niveau — Go (Standard für SRE — Kubernetes / Prometheus / die meisten SRE-Tools sind in Go) oder Python in der Tiefe (Datenanalyse + Skripte). Bücher: „The Go Programming Language“ von Donovan / Kernighan, „Fluent Python“ von Ramalho. 3) Das Google-Buch „Site Reliability Engineering“ (kostenloses PDF) — Pflichtlektüre, zweimal lesen. 4) „The Site Reliability Workbook“ von Google — praktische Ergänzung (Fallstudien + Übungen). 5) SLI / SLO beherrschen — SLO-as-Code (Sloth / Pyrra / OpenSLO) für einen echten Dienst einrichten, Burn-Rate-Alerts konfigurieren (Multi-Window: schnell 1 h 14.4×, langsam 6 h 6×). 6) Theorie verteilter Systeme — CAP-Theorem, Konsistenzmodelle (Linearisierbarkeit / sequenziell / kausal / eventual), Konsens (Grundlagen von Paxos / Raft), Analyse von Fehlermodi. Bücher: „Designing Data-Intensive Applications“ von Martin Kleppmann (Pflichtlektüre 2026), „Database Internals“ von Petrov. 7) Chaos Engineering — Chaos Mesh / Gremlin / LitmusChaos. Chaos-Experimente auf dem eigenen K8s-Cluster aufsetzen. Buch: „Chaos Engineering“ von Nora Jones / Casey Rosenthal. 8) Lasttests beherrschen — k6 (modern, JS-basiert, im Aufwind) oder Gatling (Scala-DSL) oder Locust (Python). In die CI integrierte Lasttests einrichten. 9) Observability in der Tiefe: Prometheus für Fortgeschrittene (PromQL beherrschen + Recording Rules + Federation), Grafana für Fortgeschrittene (Templating + Alerting), Loki + Tempo + OpenTelemetry. Anwendungsfall: verteiltes Tracing über Microservices hinweg. 10) Training zur Incident Response — Grundlagen des Incident Command, Framework für schuldfreie Post-Mortems, Kommunikation während Vorfällen. Ressourcen: „Incident Response & Computer Forensics“ von Luttgens / Pepe / Mandia, das Incident-Management-Training von Google. 11) Pet-Projekt: eine verteilte App auf K8s mit vollständigem SLO-Aufbau + Chaos-Experimenten + simulierter Rufbereitschaft deployen. Als produktionsreifes System dokumentieren. Kurse (RU): Slurm SRE, Otus „SRE“, Karpov.Courses SRE Track. International (EN): „Database Reliability Engineering“ von Campbell / Majors, Vorträge der USENIX SREcon (kostenlos auf YouTube), Google Cloud SRE Certification Path. DevOps Middle + Interesse → SRE Junior — 4-10 Monate (Programmieren + Theorie verteilter Systeme müssen gestärkt werden).

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).

Ein Senior SRE verantwortet den gesamten Zyklus des Reliability Engineering + technische Führung. Programmierung auf Backend-Niveau Middle+: Beherrschung von Go (Standard für SRE-Automatisierung) oder Python in der Tiefe — auf dem Niveau „kann produktionsreife Autoscaling-Logik / Algorithmen zur Kapazitätsplanung / eigene K8s-Operatoren schreiben“. Beherrschung von Kubernetes in der Tiefe: Produktionsmaßstab (Nodes), Operatoren (Kubebuilder / Operator SDK), eigene CRDs, Muster für Mandantenfähigkeit. Theorie verteilter Systeme: tiefes Verständnis des CAP-Theorems, Konsistenzmodelle (Linearisierbarkeit / sequenziell / kausal / eventual), Konsensalgorithmen (Paxos / Raft), Taxonomie der Ausfallarten, Muster für den Umgang mit Netzwerkpartitionen. Beherrschung der Observability: Prometheus fortgeschritten (Beherrschung von PromQL + Recording Rules + Föderation + remote_write), Grafana fortgeschritten (Templating + Transformationen + Alerting), Beherrschung der Integration von Loki + Tempo + OpenTelemetry, Distributed Tracing über Microservices hinweg. Beherrschung der SLI- / SLO-Architektur: SLO-as-Code (Pyrra / OpenSLO / Sloth), Entwurf von Error-Budget-Richtlinien + Automatisierung ihrer Durchsetzung, Tuning von Multi-Window-Burn-Rate-Alerts (Alert Fatigue vermeiden). Beherrschung des Incident Command: die Reaktion auf Vorfälle unter Stress leiten, Moderation von Post-Mortems ohne Schuldzuweisung, Analyse beitragender Faktoren (nicht Root Cause — modernes Denken), Priorisierung von Maßnahmen. Beherrschung des Chaos Engineering: Chaos Mesh / Gremlin / LitmusChaos — Chaos-Experimente entwerfen, GameDays moderieren. Beherrschung der Kapazitätsplanung: Methodik für Lasttests (k6 / Gatling / Locust), Modelle zur Ressourcenprognose, Headroom-Analyse, Umgang mit Spitzenlasten. Performance Engineering: profilgesteuerte Optimierung (perf / bpftrace / Flamegraphs), Diagnose von Speicherlecks, GC-Tuning, Analyse der Netzwerkperformance. Service Mesh in der Tiefe: Istio / Linkerd / Cilium — Traffic Management, Retry-Richtlinien, Circuit Breaker, Fault Injection. Systementwurf für Zuverlässigkeit: Hochverfügbarkeit über mehrere Regionen und AZs am Whiteboard entwerfen, RPO- / RTO-Planung, DR-Strategien, zellbasierte Architektur zur Begrenzung des Blast Radius. Soft Skills: Verfassen von ADRs, Kommunikation bei Vorfällen (Updates der Statusseite + Gespräche mit Stakeholdern in der Krise), Disziplin in der Rufbereitschaft, teamübergreifende Zusammenarbeit (Backend- / DevOps- / Platform- / Security-Teams), Mentoring von Middle SREs. Englisch ab Senior+ PFLICHT — SRE ist intensiv teamübergreifend + die Community ist englischsprachig (USENIX SREcon, Papers).