So stellen Sie 2026 einen Site Reliability Engineer (SRE) ein

Um einen Site Reliability Engineer einzustellen, definieren Sie die Systeme und SLOs, für die die Rolle verantwortlich sein wird, schreiben Sie eine auf Zuverlässigkeit zugeschnittene Stellenanzeige (keine umbenannte Ops-Ausschreibung), prüfen Sie, wie Kandidaten bei Incidents entscheiden, statt ihre Coding-Geschwindigkeit zu messen, führen Sie ein Interview entlang eines Produktionsszenarios rund um eine Error-Budget-Entscheidung und schließen Sie innerhalb von 48 Stunden ab, weil starke Kandidaten an mehreren Bewerbungsverfahren gleichzeitig teilnehmen. Ein SRE wendet Softwareentwicklung auf den Betrieb an: Er verantwortet Service Level Objectives, sichert sie mit Error Budgets ab und übernimmt den Bereitschaftsdienst. Daran sollten Sie Ihre Einstellungskriterien ausrichten. Wenn ein Kandidat nicht erklären kann, wie er mit einem schnell aufgebrauchten Error Budget umgeht, passt er nicht zu dieser Rolle.

Was macht ein Site Reliability Engineer?

Ein Site Reliability Engineer hält Produktionssysteme zuverlässig, indem er den Betrieb als Softwareproblem behandelt. Die Rolle baut auf vier Konzepten auf, die bei Google entstanden sind, wo SRE erfunden wurde, und die zugleich als Ihre Screening-Checkliste dienen.

Die kanonische Referenz ist Googles SRE-Buch, dessen Begriffe ein SRE-Kandidat sicher anwenden können sollte:

• SLI (Service Level Indicator): ein quantitatives Maß für einen Aspekt eines Dienstes, etwa Request-Latenz, Fehlerrate oder Verfügbarkeit.
• SLO (Service Level Objective): ein Zielwert oder -bereich für einen SLI, zum Beispiel „99 % der GET-Requests werden in unter 100 ms abgeschlossen.“ Das SLO ist das Versprechen, das das System gibt.
• Error Budget: die zulässige Rate, mit der ein SLO verfehlt werden darf. Wenn Ihr Verfügbarkeits-SLO bei 99,9 % liegt, sind die verbleibenden 0,1 % das Budget. Solange das Budget Spielraum hat, liefert das Team Features schneller aus. Ist es aufgebraucht, verlangsamen sich Releases und Zuverlässigkeitsarbeit erhält Vorrang. Das Error Budget ist der Steuermechanismus, der Tempo gegen Stabilität ausbalanciert, und es ist das aussagekräftigste Thema in jedem SRE-Interview überhaupt.
• Toil: repetitive manuelle Arbeit, die linear mit dem System skaliert und keinen bleibenden Wert schafft. Der SRE-Auftrag lautet, Toil wegzuautomatisieren, nicht ihn zu absorbieren. Ein Engineer, der jede Nacht einen Dienst von Hand neu startet, leistet Toil; ein SRE schreibt die Automatisierung, die den Neustart überflüssig macht.

Hinzu kommen die vier goldenen Signale: Latenz, Traffic, Fehler und Sättigung. Ein kompetenter SRE misst die Latenz bei p50, p95 und p99 und richtet Alarme an den langsamen Requests bei p99 und am SLO aus. Der Median allein kann schlechte Antwortzeiten am Rand der Verteilung verdecken. Welche Alarme sinnvoll sind, hängt vom SLO des Dienstes und davon ab, wie schnell das Error Budget aufgebraucht wird.

Die Nachfrage nach SREs wächst. SRE fällt in den Cluster des U.S. Bureau of Labor Statistics für Softwareentwickler, QA-Analysten und Tester, für den das BLS von 2024 bis 2034 ein Wachstum von 15 % prognostiziert – deutlich schneller als der Durchschnitt aller Berufe, mit rund 288.000 zusätzlichen Stellen für Softwareentwickler. Es gibt keinen eigenen BLS-Code für „Site Reliability Engineer“; die Rolle wird unter Softwareentwicklern (SOC 15-1252) erfasst, mit einem Mediangehalt für Softwareentwickler von 133.080 $ (Stand Mai 2024). Die Nachfrage konzentriert sich überall dort, wo Ausfallzeit Geld kostet.

SRE vs. DevOps vs. Platform Engineering: Welche Rolle brauchen Sie wirklich?

Diese drei Rollen werden austauschbar ausgeschrieben, und diese Verwechslung ist der teuerste Fehler beim Einstellen für Zuverlässigkeit. DevOps ist eine Kultur, Platform Engineering baut die interne Entwicklerplattform, und SRE verantwortet, ob das System läuft. Sie sind keine Synonyme.

Der praktische Test ist die Verantwortung. Wenn Sie jemanden brauchen, der formal SLOs verantwortet, ein Error Budget verantwortet und den Bereitschaftsdienst übernimmt, brauchen Sie einen SRE. Wenn Sie interne Werkzeuge und Self-Service-Angebote für Entwickler brauchen, wollen Sie einen Platform Engineer. Wenn Sie eine schnellere Release-Kultur in der gesamten Organisation wollen, ist das eine DevOps-Praxis, keine einzelne Einstellung. Eine falsche Bezeichnung hier erzeugt eine Stellenanzeige, die die falschen Bewerber anzieht, und eine Einstellung, die kündigt, wenn die tatsächliche Arbeit nicht der ausgeschriebenen entspricht. (Abgrenzungen synthetisiert aus Splunk, InfoWorld und FireHydrant.)

Wann sollten Sie Ihren ersten SRE einstellen?

Stellen Sie einen SRE ein, wenn Zuverlässigkeit zum unfreiwilligen Zweitjob von jemandem geworden ist und niemand sie formal verantwortet. Meist zeigt sich der Bedarf durch wiederkehrende Probleme im Betrieb.

Achten Sie auf diese Signale:

• Incidents nehmen zu und niemand verantwortet Zuverlässigkeit. Ausfälle behebt, wer sie zuerst bemerkt, und Postmortems finden entweder nicht statt oder ändern nichts.
• Sie haben Kunden-SLAs, aber keine internen SLOs. Sie haben vertraglich Verfügbarkeit zugesagt, ohne interne Ziele oder ein Error Budget für deren Absicherung. So können Ausfälle Umsatz kosten.
• Der Bereitschaftsdienst ist informell, unvergütet und überlastet erfahrene Engineers. Ihre besten Engineers reagieren in einer Zweier-Rotation um 2 Uhr nachts auf Alarme, ohne geregelte Vergütung. Das ist ein Abwanderungsrisiko, bevor es ein Zuverlässigkeitsrisiko ist.
• Sie haben gerade eine Skalierungsschwelle überschritten. Eine Finanzierungsrunde, ein unterzeichneter Enterprise-Kunde oder ein Traffic-Meilenstein hat Ausfallzeit teuer genug gemacht, um einen dedizierten Verantwortlichen zu rechtfertigen.

Eine Warnung: Stellen Sie keinen SRE ein, um Betriebsprobleme dauerhaft abzufangen, deren Ursachen Sie nicht beheben wollen. Wenn SLOs, ein tragbarer Bereitschaftsdienst und Zuverlässigkeitsarbeit keine Priorität haben, bleibt dem Reliability Engineer nur das Abarbeiten von Tickets. Starke Kandidaten spüren das im Interview und sagen ab.

Wie viel kostet ein SRE 2026?

Die US-Grundgehälter für Site Reliability Engineers liegen um die 130.000 bis 150.000 $, wobei Senior-SREs in großen Hubs in der Gesamtvergütung häufig 180.000 bis 280.000 $ erreichen. Die Zahlen schwanken je nach Quelle stark, weil manche nur das Grundgehalt ausweisen und andere Aktien und Bonus einrechnen – prüfen Sie also stets, was eine Zahl misst, bevor Sie sich darauf festlegen.

Die Angaben der Quellen sind nicht ohne Weiteres vergleichbar. Prüfen Sie auch bei einem „Durchschnitt von 170 Tsd. $“, welche Vergütungsbestandteile die Quelle erfasst, bevor Sie ihn mit einem Grundgehalt vergleichen. Auch die Seniorität beeinflusst die Vergütung:

• Einstiegs-/Junior-SRE: grob 110 Tsd. bis 135 Tsd. $ Grundgehalt.
• Mid-SRE (3 bis 6 Jahre): 140 Tsd. bis 165 Tsd. $ Grundgehalt; ab sieben Jahren im Schnitt rund 162.756 $ (Built In).
• Senior-SRE: häufig 160 Tsd. bis 200 Tsd. $+ Grundgehalt; in San Francisco und New York werden 180 Tsd. bis 280 Tsd. $ Gesamtvergütung gemeldet.
• Principal-/Staff-SRE: 200 Tsd. bis 308 Tsd. $, laut dem KORE1-Gehaltsleitfaden 2026.

Auch der Standort beeinflusst die Vergütung. Built In verortet San Francisco bei rund 183.286 $, etwa 31 % über dem nationalen Durchschnitt, mit Austin bei rund 158.681 $ und Remote-Rollen bei rund 163.969 $. Zwei häufig übersehene Kostenfaktoren: Bereitschaftsvergütung ist heute Teil des Pakets, und die SRE-Vergütung überlappt sich stark mit der von Senior-Softwareentwicklern, weil der Job Softwareentwicklung ist. Kalkulieren Sie entsprechend, oder verlieren Sie Kandidaten an Produktteams, die dasselbe für weniger Bereitschaftseinsätze zahlen.

Wie schreiben Sie eine SRE-Stellenanzeige, die die richtigen Leute anzieht?

Eine gute SRE-Stellenanzeige beschreibt die Systeme und die Verantwortung für deren Zuverlässigkeit, nicht eine Liste von Tools. Generische Ausschreibungen ziehen Generalisten an; spezifische ziehen Engineers an, die Produktion verantworten wollen. Der schnellste Weg, einen starken Kandidaten abzuschrecken, ist eine Stellenanzeige, die sich wie eine Sysadmin-Ausschreibung mit obendrauf geklebtem „SRE“ liest.

Machen Sie diese Punkte in der Ausschreibung konkret:

• Das SLO-Framework. Was bedeutet Zuverlässigkeit hier, und wie steht das Team heute zu SLOs und Error Budgets? „Unsere ersten SLOs aufbauen“ und „ein SLO-Programm für 30 Dienste weiterentwickeln“ ziehen unterschiedliche Leute an.
• Der primäre Stack. Nennen Sie die Cloud (AWS, GCP, Azure), die Orchestrierungsschicht (Kubernetes ist nahezu Grundausstattung) sowie das Observability- und Incident-Tooling.
• Der tatsächliche Schwerpunkt. Seien Sie ehrlich, ob die ersten sechs Monate Toil-Reduktion, Stabilisierung der Bereitschaft oder Plattform-nahe Arbeit bedeuten. Kandidaten entscheiden danach.
• Die Bereitschaftsrealität. Rotationsgröße, Takt und Vergütung. Eine gesunde Rotation umfasst typischerweise sechs oder mehr Personen. Das anzugeben signalisiert Reife; es wegzulassen signalisiert, dass Sie nicht darüber nachgedacht haben.

Das stärkste Signal, das Sie senden können, ist, dass Sie den Unterschied zwischen einem SRE und einem Ops-Engineer verstehen. Formulieren Sie Anforderungen an Entscheidungen zur Zuverlässigkeit (SLO-Design, Incident-Command, Automatisierung, die Toil beseitigt) statt als Aufzählung von Zertifikaten und Ticketsystemen.

Wie prüfen Sie im Interview die Entscheidungen eines SRE?

Besprechen Sie mit einem SRE-Kandidaten Produktionsszenarien statt LeetCode-Aufgaben. Im Beruf muss er unter Druck mit Fehlern umgehen; das Interview sollte zeigen, wie er dabei entscheidet. Rätsel zur Coding-Geschwindigkeit sagen darüber wenig aus.

Begrenzen Sie den Interviewprozess auf drei Runden inklusive Finale, denn Senior-SREs nehmen parallel an mehreren Bewerbungsverfahren teil und springen nach dem dritten Interview ab. Testen Sie innerhalb dieses Interviewprozesses diese Punkte in etwa dieser Prioritätsreihenfolge:

1. Error-Budget-Entscheidungen. Stellen Sie ein Budget-Burn-Szenario vor: Ein Release frisst mitten im Quartal das Budget auf. Wägt der Kandidat einen Release-Stopp, einen Rollback, ein Feature-Flag und einen gezielten Fix gegeneinander ab, und bezieht er sich auf Burn-Rate-Alarme? Das ist die aussagekräftigste Frage überhaupt. Ein Kandidat, der direkt zu „alles zurückrollen“ springt, ohne den Budgetstand zu berücksichtigen, denkt nicht wie ein SRE.
2. SLI/SLO-Design. Kann der Kandidat einen aussagekräftigen SLI für einen gegebenen Dienst definieren und ein begründbares SLO festlegen, und unterscheidet er korrekt SLI von SLO von SLA?
3. Goldene Signale und Observability. Hinterfragen Sie das Denken zu p50/p95/p99-Latenz, Alarmierung auf den Tail und wie der Kandidat Alarm-Müdigkeit vermeidet.
4. Toil-Identifikation. Geben Sie ihm eine repetitive Betriebsaufgabe und beobachten Sie, ob er sie automatisieren möchte oder als dauerhafte manuelle Aufgabe einplant.
5. Incident-Command und schuldfreie Postmortems. Hat der Kandidat tatsächlich Incident-Response geleitet und ein Postmortem verantwortet, das das System verändert hat?
6. Softwareentwicklungstiefe. SRE ist Sysadmin-Können plus echte Softwareentwicklung, meist in Python oder Go. Bitten Sie um Code, den der Kandidat geschrieben hat und der Betriebsarbeit beseitigt hat. Wenn die Antwort nur Shell-Skripte sind, wägen Sie das gegen die Seniorität ab, die Sie bezahlen.

Achten Sie auf die Fragen, die der Kandidat Ihnen stellt. Starke SREs prüfen auch, wie Ihr Unternehmen mit Zuverlässigkeit umgeht: Sie fragen nach Rotationsgröße, Erwartungen an die Reaktionszeit bei Alarmen, Bereitschaftsvergütung und dem Verhältnis von handlungsrelevanten zu nicht handlungsrelevanten Alarmen. Diese Fragen zeigen, dass Kandidaten auf langfristig tragbare Arbeitsbedingungen achten. (Fragenset adaptiert aus KORE1s SRE-Interviewleitfaden.)

Der schwierige Teil ist Konsistenz. Wenn sechs Interviewer jeweils ihre eigenen Fragen nach eigenem Ermessen stellen, können Sie Kandidaten nicht vergleichen, und die Bewertung ihrer Entscheidungen wird zum Bauchgefühl. Mit Kit können Sie deshalb die SRE-spezifischen Kriterien (Error-Budget-Denken, SLO-Design, Incident-Verantwortung, Toil-Reduktion) in einer strukturierten Scorecard festhalten, sodass jeder Interviewer dieselben Dimensionen bewertet und Sie nebeneinander sehen, wer tatsächlich wie ein SRE denkt. Für das technische Screening selbst sind Kits Code-Aufgaben GitHub-integriert, sodass Sie Kandidaten eine realistische Automatisierungs- oder Instrumentierungsaufgabe geben können statt eines Algorithmus-Rätsels, das Ihnen nichts über Entscheidungen im Produktionsbetrieb verrät.

Was ist mit Zertifikaten und Qualifikationen?

Es gibt keine Lizenz für SRE, und Zertifikate können bei gleichwertigen Kandidaten den Ausschlag geben, sollten aber keine Zugangsvoraussetzung sein. Anders als in der Medizin oder im Recht gibt es im Reliability Engineering keine vorgeschriebene Qualifikation. Laut Googles Leiterin der SRE-Ausbildung, Jennifer Petoff, gilt: „Großartige SREs werden nicht eingestellt, sondern tatsächlich ausgebildet.“ Erfahrung schlägt Papier.

Zertifikate zeigen Grundkenntnisse und Eigeninitiative, ersetzen aber keinen Nachweis praktischer Fähigkeiten:

• CKA (Certified Kubernetes Administrator): das relevanteste Infra-Zertifikat, da Kubernetes für die Rolle nahezu Grundausstattung ist.
• Google Cloud Professional DevOps Engineer: deckt explizit SRE-Prinzipien ab und ist das am ehesten „SRE-geprägte“ Cloud-Zertifikat.
• AWS Certified DevOps Engineer (Professional) oder Azure-Äquivalente: relevant, wenn der Stack passt.

Anbieter-Zertifikate vom Typ „SRE Foundation“ existieren, aber sie sind Wissens-Checks statt Fähigkeitsbeweise. Gewichten Sie nachgewiesene Incident- und Automatisierungsarbeit weit höher als jedes Abzeichen. Ein Kandidat, der Sie durch ein von ihm verantwortetes Postmortem und die daraus entstandene Automatisierung führen kann, sagt Ihnen mehr als eine Wand voller Zertifikate.

Was sind die häufigsten Fehler beim Einstellen von SREs?

Die häufigsten Fehler entstehen durch unklare Rollenbezeichnungen oder Interviewfragen, die an der tatsächlichen Aufgabe vorbeigehen. Klare Zuständigkeiten und passende Fragen vermeiden viele Fehlbesetzungen.

1. Eine Ops-Rolle fälschlich als „SRE“ bezeichnen. Der meistgenannte Fehler. Wenn Bereitschaft, SLOs und Zuverlässigkeit keine echten Prioritäten sind, brauchen Sie keinen SRE, und gute Kandidaten durchschauen die Stellenanzeige.
2. Eine vage Stellenanzeige schreiben. Generische Ausschreibungen ziehen Generalisten an. Auf Zuverlässigkeit zugeschnittene ziehen echte SREs an.
3. Im Interview Coding-Geschwindigkeit statt Entscheidungen zur Zuverlässigkeit prüfen. LeetCode verfehlt Error-Budget-Denken, Alarm-Hygiene und Incident-Command – also den tatsächlichen Job.
4. Zu viele Runden und langsame Angebote. Senior-SREs nehmen parallel an mehreren Bewerbungsverfahren teil und erwarten ein Angebotsfenster von 24 bis 48 Stunden. Top-Kandidaten springen nach dem dritten Interview ab. Begrenzen Sie den Interviewprozess und handeln Sie schnell.
5. Keine Bereitschaftsvergütung oder eine ungesunde Rotation. Einen SRE in eine unvergütete Zweier-Rotation voller Alarmstürme einzustellen, garantiert Abwanderung.
6. SRE mit Platform Engineering verwechseln. Wenn Sie jemanden für den Aufbau einer internen Entwicklerplattform brauchen, stellen Sie einen Platform Engineer ein. SRE verantwortet Zuverlässigkeit und Incidents.

Zu viele Runden und langsame Angebote kosten oft die besten Kandidaten. Ein langsamer, ausufernder Interviewprozess ist für Sie unsichtbar und für einen Kandidaten mit drei Angeboten offensichtlich. Das hängt mit einem breiteren Muster zusammen, über das wir geschrieben haben in warum zu viele Interviewrunden Ihre besten Kandidaten kosten: Ein zu langer Prozess kostet Sie Kandidaten, die sich nicht mehr zurückmelden. Die Lösung ist ein straffer, begründbarer Interviewprozess, in dem alle dieselben Dinge bewerten und die Entscheidung schnell fällt.

Häufig gestellte Fragen zum Einstellen eines SRE

Kurze Antworten auf die Fragen, die Personalverantwortliche am häufigsten stellen, wenn sie eine SRE-Suche beginnen.

Was ist der Unterschied zwischen einem SRE und einem DevOps-Engineer? DevOps ist eine Kultur, um die Mauer zwischen Dev und Ops abzubauen und schneller auszuliefern, während ein SRE Zuverlässigkeit formal verantwortet: Er definiert SLOs, verantwortet ein Error Budget und übernimmt den Bereitschaftsdienst. Wenn Sie jemanden brauchen, der dafür geradesteht, ob das System läuft, brauchen Sie einen SRE, keine DevOps-Praxis.

Wie viel kostet ein Site Reliability Engineer 2026? Die US-Grundgehälter liegen um die 130.000 bis 150.000 $, wobei Senior-SREs in großen Hubs in der Gesamtvergütung häufig 180.000 bis 280.000 $ erreichen. Die SRE-Vergütung überlappt sich stark mit der von Senior-Softwareentwicklern, weil der Job Softwareentwicklung ist, und die Bereitschaftsvergütung ist heute Teil des Pakets.

Brauchen SREs Zertifikate? Nein. Es gibt keine Lizenz für SRE, und Zertifikate wie der CKA oder der Google Cloud Professional DevOps Engineer können bei gleichwertigen Kandidaten entscheiden, sollten aber keine Zugangsvoraussetzung sein. Nachgewiesene Incident-Response- und Automatisierungsarbeit wiegt schwerer als jedes Abzeichen.

Welche Interviewfragen sollte ich einem SRE stellen? Beginnen Sie mit einem Error-Budget-Burn-Szenario (Freeze versus Rollback versus Feature-Flag), dann SLI/SLO-Design, Denken zu goldenen Signalen und Alarmierung, Toil-Identifikation und ein echtes, von ihm verantwortetes Postmortem. Zuverlässigkeitsurteil zählt weit mehr als Coding-Geschwindigkeit.

Wie lange sollte der SRE-Interviewprozess dauern? Begrenzen Sie den Interviewprozess auf drei Runden und streben Sie ein Angebotsfenster von 24 bis 48 Stunden an. Senior-SREs nehmen parallel an mehreren Bewerbungsverfahren teil und springen nach dem dritten Interview ab, sodass ein langsamer Interviewprozess still Ihre stärksten Kandidaten kostet.

Stellen Sie SREs schneller ein mit Kit

Bei der Einstellung eines Site Reliability Engineers müssen Sie sorgfältige Prüfung und schnelle Entscheidungen verbinden. Prüfen Sie, wie Kandidaten die Zuverlässigkeit von Systemen beurteilen, und handeln Sie zügig, wenn ein passender Kandidat weitere Angebote hat. Ein langsamer Prozess verliert Kandidaten; eine oberflächliche Prüfung kann zu einer Fehlbesetzung führen.

Kit ist ein KI-natives Applicant-Tracking-System, gebaut für Startups, die beides brauchen. Zuverlässigkeitsorientierte Rollenvorlagen geben Ihnen eine vorkonfigurierte Pipeline mit bereits eingerichteter SRE-spezifischer Scorecard, sodass das Panel SLO-Entscheidungen und den Umgang mit Incidents bewertet, statt nach eigenem Ermessen vorzugehen. Code-Aufgaben sind GitHub-integriert für realistische Automatisierungsaufgaben, Interviewplanung und Team-Abstimmungen halten den Interviewprozess straff, und weil Kit seine Pipeline über MCP zugänglich macht, können Sie einen KI-Assistenten Outreach entwerfen, Kandidaten zusammenfassen und die ausstehende Entscheidung aufspüren lassen, die Ihr 48-Stunden-Angebot blockiert. Bei der Abrechnung pro Platz kalkulieren Sie die Zugänge für alle Mitglieder Ihres Recruiting-Teams.

Entscheidend ist ein klarer Ablauf. Definieren Sie die Verantwortung für Systeme und SLOs, schreiben Sie die echte Stellenanzeige, prüfen Sie auf das Error-Budget-Szenario und schließen Sie ab, bevor es Ihre Wettbewerber tun. Wenn Sie sehen wollen, wie die zuverlässigkeitsorientierte Pipeline zusammenpasst, starten Sie eine kostenlose Testphase und bauen Sie die Scorecard, bevor Ihr nächster Ausfall die Entscheidung für Sie trifft.

Weitere Leitfäden für die Besetzung einzelner Rollen finden Sie in unseren Leitfäden zu wie Sie einen Backend-Engineer einstellen und wie Sie einen Forward-Deployed Engineer einstellen.