Was macht ein Site Reliability Engineer?

Einleitung: Warum SREs heute gefragt sind

Digitale Produkte sind nur so gut wie ihre Zuverlässigkeit. Sekunden zählen, Ausfälle kosten – und trotzdem soll Entwicklung schnell liefern. Genau hier setzt Site Reliability Engineering (SRE) an: Es verbindet Software‑Engineering mit Betriebsverantwortung und übersetzt Geschäftsziele in messbare Zuverlässigkeit. Für Bewerber:innen eröffnet das ein klares Profil mit hoher Wirkung, aber auch mit spezifischen Trade‑offs wie On‑Call und hoher Kontextwechselrate.

These: SRE ist nicht „DevOps mit anderem Namen“. Es ist eine Rollen‑ und Methodikschärfung, die Produktverfügbarkeit, Geschwindigkeit und Risiko aktiv miteinander austariert – auf Basis klarer Metriken und Engineering‑Praxis.

Takeaway für Bewerber:innen: Betone in CV und Interview konkrete Zuverlässigkeits‑Outcomes (SLO‑Erfolge, Automatisierungen, reduzierte Pager‑Last).

Was ist Site Reliability Engineering? Grundbegriffe kompakt

SRE entstand in großen produktiven Umgebungen und ist heute gut dokumentiert – etwa im frei verfügbaren Google SRE Book (sre.google/sre-book) und dem praktischen Workbook. Der Kern: Probleme des Betriebs werden wie Softwareprobleme behandelt – mit Automatisierung, sauberem Design, Metriken und Lernschleifen.

SLIs, SLOs, SLAs: Service Level Indicators (SLIs) messen objektiv z. B. Verfügbarkeit, Latenz oder Fehlerraten. Daraus leiten Teams Service Level Objectives (SLOs) als Zielwerte ab; SLAs regeln vertragliche Zusagen. Das Workbook stellt dafür praktikable Vorgehensweisen bereit.
Fehlerbudget: Es quantifiziert akzeptiertes Risiko. Beispiel: Eine Verfügbarkeit von 99,999 % („Five Nines“) lässt monatlich nur rund 26 Sekunden Ausfall zu – das ist das Fehlerbudget, das Innovation und Zuverlässigkeit balanciert (vgl. Verfügbarkeits‑Tabelle im Google SRE Book, Appendix A). Wird das Budget aufgebraucht, priorisieren Teams Stabilität statt neuer Features.
50/50‑Regel: Viele SRE‑Teams teilen Zeit zwischen Incident‑Naharbeit (On‑Call, Eskalationen) und Engineering‑Arbeit zur Automatisierung und Zuverlässigkeitsverbesserung (vgl. IBM‑Einordnung: SRE kombiniert Dev‑ und Ops‑Kompetenz für Resilienz und Tempo).

Abgrenzung zu DevOps: DevOps ist ein Organisations‑ und Kulturansatz für gemeinsame Verantwortung entlang des SDLC. SRE konkretisiert die Verlässlichkeitsperspektive in Arbeitspraktiken: SLO‑getriebenes Arbeiten, Fehlerbudgets, Postmortems ohne Schuldzuweisung und ein klarer Fokus auf das Entfernen von „Toil“ (wiederkehrender, manueller Aufwand) – alles ausführlich im Google SRE Book beschrieben.

Takeaway für Bewerber:innen: Kenne die Begriffe SLI/SLO/Fehlerbudget und erkläre im Interview, wie du sie praktisch gemessen oder gestaltet hast.

Typische Aufgaben und Verantwortungen im SRE‑Alltag

SREs definieren, messen und verbessern Verlässlichkeit. Daraus ergeben sich wiederkehrende Tätigkeiten:

Monitoring, Alerting und Observability

SREs stellen sicher, dass Metriken, Logs und Traces den Servicezustand abbilden. Alerts orientieren sich an Benutzerwirkung (SLO‑basiert), nicht an rein internen Schwellen. Ziel ist ein lautes, aber präzises Alarmwesen: wenig Rauschen, klare Runbooks, schneller Pfad zur Ursache. Das Workbook führt in SLO‑basiertes Alerting und Alarm‑Tuning ein.

Takeaway für Bewerber:innen: Zeige Dashboards, SLIs und konkrete Alert‑Tuning‑Beispiele in deiner Bewerbung (z. B. vor/nach‑Effekt auf Pager‑Last).

Incident Response, On‑Call, Postmortems

SREs organisieren Bereitschaftsdienste mit klaren Eskalationsketten und Rollen, lösen Störungen, koordinieren Kommunikations‑ und Entscheidungswege und verankern Lernen: Postmortems sind konsequent „blameless“ und leiten konkrete Verbesserungsmaßnahmen ab (Google SRE Book/Workbook). Wichtig ist der Ausgleich: On‑Call darf Projektarbeit nicht verdrängen – sonst wächst technischer Schuldenberg und Pager‑Last.

Takeaway für Bewerber:innen: Beschreibe ein Incident‑Beispiel strukturiert: deine Rolle, Maßnahmen, Messgrößen vor/nach und die daraus abgeleiteten Actions.

Automatisierung und "Eliminating Toil"

Manuelle, wiederkehrende Arbeiten sind Fehlerquellen und Zeitfresser. SREs automatisieren Build/Deploy, Provisionierung, Rollbacks, Health Checks und Standard‑Eingriffe. Ziel ist, wiederkehrende Toil zu minimieren, damit Teams an anspruchsvolleren Problemen arbeiten (Workbook‑Leitidee). Infrastruktur‑als‑Code und wiederverwendbare Werkzeuge sind Standard; konkrete Toolauswahl variiert.

Takeaway für Bewerber:innen: Dokumentiere Automatisierungen mit messbaren Effekten (Zeitersparnis, Fehlerrate, Anzahl manueller Eingriffe reduziert).

Kapazitätsplanung, Performance‑ und Chaos‑Testing

SREs planen Kapazitäten vorausschauend, beobachten Lastprofile und testen Grenzfälle. Chaos‑Engineering hilft, Schwachstellen kontrolliert sichtbar zu machen (vgl. IBM). Ergänzend gehören Last‑ und Performance‑Tests dazu, die nicht nur SLO‑Einhaltung prüfen, sondern auch Bottlenecks zeigen – hier zahlt hohe Instrumentierung ein (ConSol‑Praxistipps).

Takeaway für Bewerber:innen: Nenne konkrete Tests oder Experimente (z. B. Chaos‑Drills, Lasttests) und welche Erkenntnisse oder Verbesserungen daraus entstanden.

Kollaboration mit Entwicklung und Produkt

SREs moderieren den Zielkonflikt „Zuverlässigkeit vs. Feature‑Tempo“ mit Fehlerbudgets und SLO‑Reviews. Sie beraten Architekturen (z. B. Einfachheit, Rückfallpfade) und bringen Produktionsdaten in die Roadmap ein. Viele Organisationen nutzen etablierte Engagement‑Modelle, von eingebetteten SREs in Produktteams bis zu zentralen Reliability‑Plattformen (vgl. Google Workbook zu Team‑Lifecycles und Engagement‑Modellen).

Takeaway für Bewerber:innen: Erläutere, wie du neben Technik auch Entscheidungen beeinflusst hast (z. B. SLO‑Review, Architekturentscheidungen, Stakeholder‑Kommunikation).

Welche Fähigkeiten und Tools werden erwartet?

SRE ist ein Engineering‑Job. Gefragt ist Breite mit Tiefe dort, wo man Verantwortung übernimmt.

Technische Kernskills: eine Programmiersprache produktiv einsetzen (z. B. für Tools, Automationen), solide Linux‑/Netzwerk‑Grundlagen, CI/CD‑Erfahrung, Container‑/Cloud‑Know‑how, Observability‑Praxis (Metriken, Logs, Traces). SLO‑Design und SLI‑Messung sind Basishandwerk (SRE Book/Workbook).
Kommunikations‑ und Metrikkompetenz: runbook‑taugliches Schreiben, klare Incident‑Kommunikation, saubere Postmortems, „Zahlen statt Bauchgefühl“ in Roadmaps. Fehlerbudget‑Politiken erklären und vertreten können.
Toolbeispiele: Monitoring/Visualisierung mit Prometheus/Grafana (ConSol), Log‑Analyse, automatisierte Deployments und Health Checks. Wichtiger als einzelne Produkte ist die Fähigkeit, Messbarkeit systematisch aufzubauen und Alarmierung SLO‑basiert zu gestalten (Workbook‑Guidance).

Takeaway für Bewerber:innen: Beschreibe konkrete Tools und wie du sie zur Messung/Automatisierung eingesetzt hast – idealerweise mit Links zu Demo‑Repos oder anonymisierten Artifacts.

Karrierepfad und Organisation in Deutschland

SRE‑Karrieren verlaufen häufig über Stufen wie Junior SRE, SRE, Senior/Staff/Principal – mit wachsender Systembreite, On‑Call‑Verantwortung, Design‑ und Mentoring‑Anteil. In Deutschland organisieren Unternehmen SREs unterschiedlich:

Zentral: Ein SRE‑Team betreut mehrere Produktteams als interne Plattform/Enablement‑Einheit. Vorteil: starke Standards, gebündeltes On‑Call; Nachteil: Distanz zu Features kann wachsen.
Eingebettet: SREs sitzen im Produktteam. Vorteil: hoher Produktkontext; Nachteil: Standards/Skaleneffekte schwerer.
Hybrid: zentrale Plattform plus eingebettete SRE‑Rollen – häufig in größeren Organisationen.

Gehaltsperspektive: Die Spannen variieren je nach Seniorität, Standort, Branche und Cloud‑/Skalenerfahrung. Einflussfaktoren sind u. a. On‑Call‑Anteil, Rufbereitschaftsregelungen, Verantwortungsumfang und die Komplexität der Produktionsumgebungen. Konkrete Zahlen unterscheiden sich stark nach Marktphase und Tariflage. Orientierung findest du zuverlässig, indem du systematisch benchmarkst:

10–15 aktuelle Stellenausschreibungen im Zielsegment (Region, Senioritätsstufe, On‑Call‑Modell) sammeln und angebotene Gehaltsbänder/OTE notieren.
On‑Call‑Zulagen, Bereitschaftszeiten und Schichtzuschläge separat erfassen und in ein Jahres‑Brutto umrechnen.
Brancheneffekte berücksichtigen (z. B. regulierte Industrien, SaaS, E‑Commerce) und mit deiner konkreten Tool-/Cloud‑Erfahrung abgleichen.

Takeaway für Bewerber:innen: Recherchiere marktnahe Stellenausschreibungen und bereite rationale Gehaltsargumente (On‑Call‑Zulagen, Verantwortung) für Verhandlungen vor.

Vorbereitung auf Bewerbung und Interview: praxisnahe Empfehlungen

Ziel ist, Zuverlässigkeit als messbares Produktmerkmal zu demonstrieren – mit konkreten Metriken, Vorher/Nachher‑Effekten und Lernkultur.

So wird die Bewerbung aussagekräftig

CV fokussieren: Projekte mit SLOs, messbaren Verbesserungen (z. B. „Pager‑Last um X% reduziert“, „Mean Time to Recovery verkürzt“) und Automatisierungen „vor“ und „nach“ darstellen. Wo Zahlen vertraulich sind, relative Effekte nennen.
Referenzen/Proof‑of‑Work: Beispiel‑Runbooks, anonymisierte Postmortem‑Ausschnitte oder SLO‑Definitionen zeigen (sofern freigabefähig). Alternativ: öffentliches Demo‑Repo mit kleinem Service, SLOs, Synthetics, Load‑Tests und Dashboards.
On‑Call‑Reife: kurz erklären, wie du Belastung steuerst (Alert‑Hygiene, Runbooks, Rotations, Hand‑off‑Routinen).

Takeaway für Bewerber:innen: Baue ein kleines, öffentliches demo‑Projekt oder anonymisierte Artefakte, die deine SRE‑Praxis belegen.

Typische Interviewfragen – und wie du sie beantwortest

SLO‑Design: „Wie definierst du SLOs für einen API‑Service?“ Antworte von Nutzerwirkung her: SLIs (Verfügbarkeit, Latenz P‑Werte), Zielwerte pro Nutzerpfad, Messfenster, Fehlerbudget und Policy, Abhängigkeiten/Downtime‑Klassen. Workbook‑Gedanken zu SLO‑Implementierung stützen das Vorgehen.
Incident‑Szenario: „Dein Pager geht – was tust du?“ Struktur: Safety first, Vorfall deklarieren, Rollen klären, Hypothesen eng führen, bekannte Runbooks anwenden, Kommunikation takten, Workarounds, saubere Übergabe ins Postmortem mit klaren Action Items (vgl. SRE Book: Emergency Response, Postmortem Culture).
Alert‑Tuning: „Wir haben zu viel Rauschen – was änderst du?“ Ansatz: SLO‑basiertes Alerting, Burn‑Rate‑Alarme über mehrere Fenster, Unterdrückung irrelevanter Symptome, Playbook‑Automationen, Metrik‑Lücken schließen (Workbook: Alerting on SLOs, On‑Call‑Pager‑Load).
Automatisierung: „Welche Toil‑Arbeit automatisierst du zuerst?“ Kriterien: Priorisiere Aufgaben danach, wie oft sie auftreten, wie lange sie dauern, wie fehleranfällig sie sind und welche Wirkung sie auf Nutzer haben. Beginne mit Lösungen, die Anwendern zuerst helfen (z. B. human‑backed Interfaces), und baue anschließend vollständig automatisierte Abläufe mit Feedback‑Schleifen und Sicherheitsüberprüfungen aus (Workbook: Eliminating Toil).

Takeaway für Bewerber:innen: Übe strukturierte Antworten mit konkreten Beispielen und messbaren Outcomes; bereite ein kurzes Postmortem‑Beispiel vor.

Häufige Fehler – und wie du sie vermeidest

Metriklosigkeit: über Features sprechen, ohne Nutzerwirkung zu messen. Besser: SLIs/SLOs pro Pfad definieren und visualisieren.
Tool‑Fixierung ohne Prinzipien: „Wir nutzen Tool X, also sind wir SRE.“ Besser: Prinzipien (SLO, Fehlerbudget, Toil‑Elimination) belegen – Tools sind Mittel zum Zweck.
Kein Lerneffekt nach Incidents: Postmortems ohne klare Maßnahmen oder Schuldzuweisungen bremsen Kultur und Zuverlässigkeit. Besser: blameless, konkrete Action Items mit Nachverfolgung.

Takeaway für Bewerber:innen: Spreche Prinzipien zuerst an, Tools sekundär; belege Aussagen mit Metriken oder Artefakten.

Entscheidungshilfe: Passt die SRE‑Rolle zu mir?

Pro: Du hast direkten Einfluss auf Nutzererlebnisse und Geschäftserfolg, lernst an realen Systemgrenzen, arbeitest breit über Stack‑Schichten und baust wiederverwendbare Lösungen.

Kontra: On‑Call kann belasten; Prioritäten wechseln schnell; du balancierst Feature‑Tempo gegen Stabilität. Freude an Diagnose, Systematik und Kommunikation ist entscheidend.

Ein alltagstaugliches Selbst‑Assessment:

Magst du es, unter Unsicherheit strukturierte Entscheidungen zu treffen?
Reizt dich das Bauen von Messbarkeit (SLIs) mehr als „nur“ Featureentwicklung?
Bist du bereit, Runbooks, Postmortems und SLO‑Reviews als wiederkehrende Rituale zu tragen?

Takeaway für Bewerber:innen: Nutze dieses Selbst‑Assessment, um im Gespräch klar zu begründen, warum SRE zu deinen Stärken und Präferenzen passt.

Schluss: Konkrete nächste Schritte für Bewerber:innen

Lernpfad 30/60/90 Tage:
0–30: Grundlagen vertiefen – SLOs/Fehlerbudgets, Incident‑Basics, Alert‑Hygiene. Lies gezielt im Google SRE Book (z. B. „Service Level Objectives“, „Being On‑Call“, „Postmortem Culture“) und dem Workbook zu „Implementing SLOs“ und „Alerting on SLOs“.
31–60: Mini‑Projekt: Baue einen kleinen Dienst mit SLIs/SLOs, Synthetics, Dashboards, SLO‑basierten Alerts. Übe Incident‑Drills und schreibe ein Beispiel‑Postmortem.
61–90: Skaliere: Füge Abhängigkeiten, Load‑Tests und eine Fehlerbudget‑Policy hinzu. Dokumentiere Entscheidungen und Trade‑offs.
Proof‑of‑Work‑Ideen:
SLO‑Playbook für einen Sample‑Service (inkl. User Journeys, SLIs, Burn‑Rate‑Alarmen, Runbooks).
„Toil Tracker“ mit Priorisierungsmatrix und ersten Automationen.
Postmortem‑Beispiel mit klaren Action Items und Nachverfolgung.

Takeaway für Bewerber:innen: Setze ein nachprüfbares Proof‑of‑Work um, das SLO‑Messung, Alerts und ein Postmortem enthält.

Weiterführende Primärquellen für Vertiefung:

Google SRE Book (Kapitel zu SLOs, On‑Call, Postmortems): sre.google/sre-book
Site Reliability Workbook (Implementing SLOs, Alerting on SLOs, On‑Call): sre.google/workbook
Verfügbarkeits‑Tabelle mit Downtime pro SLO‑Ziel (z. B. Five Nines ≈ 26 s/Monat): Google SRE Book – Appendix A
Kompakte Einführung und Konzepterklärung inkl. 50/50‑Regel und Fehlerbudget‑Beispiel: IBM: Was ist SRE?

Fazit: SRE ist die Ingenieursdisziplin, die Zuverlässigkeit als Produktmerkmal messbar macht. Wer gerne systematisch arbeitet, automatisiert und aus Vorfällen lernende Organisationen baut, findet hier eine Rolle mit hohem Impact – nah an Nutzer:innen, Technologie und Geschäft.

Takeaway: In Bewerbung und Interview gewinnt, wer messbare Erfolge, Automatisierungs‑Artefakte und strukturierte Incident‑Erfahrungen liefern kann.