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

Um einen Site Reliability Engineer einzustellen, definieren Sie die SLO-Fläche, die die Rolle verantworten wird, schreiben Sie eine auf Zuverlässigkeit zugeschnittene Stellenanzeige (keine umbenannte Ops-Ausschreibung), screenen Sie auf Incident-Urteilsvermögen statt auf Coding-Geschwindigkeit, 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 mehrere Prozesse parallel laufen haben. Ein SRE wendet Softwareentwicklung auf den Betrieb an: Er verantwortet Service Level Objectives, verteidigt sie mit Error Budgets und trägt den Pager. Dieser letzte Satz ist die gesamte Einstellungslatte. Wenn ein Kandidat nicht über einen Error-Budget-Burn nachdenken kann, führen Sie ein Interview für den falschen Job.

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, und jeder ernstzunehmende SRE-Kandidat spricht dessen Vokabular fließend:

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

Darüber liegen die vier goldenen Signale: Latenz, Traffic, Fehler und Sättigung. Ein kompetenter SRE instrumentiert Latenz bei p50, p95 und p99 und alarmiert auf den p99-Tail gegen das SLO statt auf den Median, denn Alarmierung auf p50 begräbt das Team unter Rauschen, während der echte Nutzerschmerz im Tail steckt.

Die Rolle reitet auf einer gesunden Nachfragekurve. 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 befestigte Straße, 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 verteidigt und den Pager trägt, brauchen Sie einen SRE. Wenn Sie internes Tooling und eine Self-Service-Entwicklererfahrung wollen, 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. Der Auslöser ist selten eine saubere Entscheidung; meist kommt er als ein Muster von Schmerz daher.

Achten Sie auf diese Signale:

• Incidents nehmen zu und niemand verantwortet Zuverlässigkeit. Ausfälle werden von dem gelöscht, der sie zuerst bemerkt, und Postmortems finden entweder nicht statt oder ändern nichts.
• Sie haben Kunden-SLAs, aber keine internen SLOs. Sie haben vertraglich Uptime zugesagt, ohne ein internes Ziel oder Budget, um das Versprechen zu verteidigen. In dieser Lücke leben umsatzkostende Ausfälle.
• Bereitschaft ist informell, unvergütet und brennt Senioren aus. Ihre besten Engineers beantworten in einer Zweier-Rotation um 2 Uhr nachts Pages, ohne Vergütungsstruktur. 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 Schmerz zu absorbieren, den Sie nicht zu beheben gewillt sind. Wenn SLOs, die Gesundheit der Bereitschaft und Zuverlässigkeitsarbeit keine echten Prioritäten werden, stellen Sie einen Reliability Engineer ein und drücken ihm eine Ticket-Queue in die Hand. Starke Kandidaten spüren das im Interview und sagen ab.

Wie viel kostet ein SRE 2026?

Die nationalen 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.

Selbst gemeldete Aggregatoren wie Indeed liegen hoch, behandeln Sie also jeden “Durchschnitt von 170 Tsd. $” als gesamtvergütungslastig statt als Grundgehalt. Die Seniorität ist der größere Hebel:

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

Die Geografie verstärkt das Ganze. 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 ehrliche Kostenfaktoren, die Leute vergessen: 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 Pages zahlen.

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

Eine gute SRE-Stellenanzeige beschreibt die Zuverlässigkeitsfläche, 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 30-Dienste-SLO-Programm reifen lassen” 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 die Anforderungen rund um Zuverlässigkeitsurteil (SLO-Design, Incident-Command, Automatisierung, die Toil beseitigt) statt als Aufzählung von Zertifikaten und Ticketsystemen.

Wie interviewen Sie einen SRE auf Zuverlässigkeitsurteil?

Interviewen Sie einen SRE entlang von Produktionsszenarien, nicht LeetCode. Der Job besteht darin, unter Druck über Fehler nachzudenken, also sollte das Interview den Kandidaten über Fehler nachdenken lassen. Rätsel zur Coding-Geschwindigkeit verfehlen das gesamte Signal.

Begrenzen Sie die Schleife auf drei Runden inklusive Finale, denn Senior-SREs laufen parallele Prozesse und springen nach dem dritten Interview ab. Testen Sie innerhalb dieser Schleife 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. Argumentiert der Kandidat durch Freeze versus Rollback versus Feature-Flag versus gezielten Fix, 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 verteidigbares SLO setzen, 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 instinktiv danach greift, sie zu automatisieren, statt sie zu planen.
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 interviewen Ihre Zuverlässigkeitsreife: Sie fragen nach Rotationsgröße, Erwartungen an die Page-Reaktionszeit, Bereitschaftsvergütung und dem Verhältnis von handlungsrelevanten zu nicht handlungsrelevanten Alarmen. Diese Fragen sind ein Retention-Signal, keine Arroganz. (Fragenset adaptiert aus KORE1s SRE-Interviewleitfaden.)

Der schwierige Teil ist Konsistenz. Wenn sechs Interviewer jeweils ihre eigenen Fragen frei Schnauze stellen, können Sie Kandidaten nicht vergleichen, und das Zuverlässigkeitsurteil verwässert zu Bauchgefühl. Genau deshalb lässt Kit Sie die SRE-spezifischen Signale (Error-Budget-Denken, SLO-Design, Incident-Verantwortung, Toil-Reduktion) in eine strukturierte Scorecard kodieren, 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 Produktionsurteil verrät.

Was ist mit Zertifikaten und Qualifikationen?

Es gibt keine Lizenz für SRE, und Zertifikate sind ein Tiebreaker, niemals eine Hürde. 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 signalisieren Grundkompetenz und Eigeninitiative, keinen Fähigkeitsbeweis:

• 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 Fehlermodi sind vorhersehbar, und die meisten lassen sich auf Titelverwirrung oder das Interviewen für das Falsche zurückführen. Sie zu vermeiden ist der Großteil der Schlacht.

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. Auf Coding-Geschwindigkeit statt Zuverlässigkeitsurteil interviewen. LeetCode verfehlt Error-Budget-Denken, Alarm-Hygiene und Incident-Command — also den tatsächlichen Job.
4. Zu viele Runden und langsame Angebote. Senior-SREs laufen parallele Prozesse und erwarten ein Angebotsfenster von 24 bis 48 Stunden. Top-Kandidaten springen nach dem dritten Interview ab. Begrenzen Sie die Schleife 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 einen Befestiger der goldenen Straße wollen, stellen Sie einen Platform Engineer ein. SRE verantwortet Zuverlässigkeit und Incidents.

Fehler vier ist der, der still die besten Leute kostet. Eine langsame, ausufernde Schleife 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: Der Preis eines sorgfältigen Prozesses sind die Kandidaten, von denen Sie nie wieder hören. Die Lösung ist eine straffe, verteidigbare Schleife, in der alle dieselben Dinge bewerten und die Entscheidung schnell fällt.

Häufig gestellte Fragen zum Einstellen eines SRE

Kurze Antworten auf die Fragen, die Hiring-Manager 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, verteidigt ein Error Budget und trägt den Pager. 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 nationalen 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 sind Tiebreaker, keine Hürden. 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 die Schleife auf drei Runden und streben Sie ein Angebotsfenster von 24 bis 48 Stunden an. Senior-SREs laufen parallele Prozesse und springen nach dem dritten Interview ab, sodass eine langsame Schleife still Ihre stärksten Kandidaten kostet.

Stellen Sie SREs schneller ein mit Kit

Einen Site Reliability Engineer einzustellen läuft auf zwei Disziplinen hinaus, die gegeneinander ziehen: rigoros auf Zuverlässigkeitsurteil screenen und schnell genug handeln, um einen Kandidaten abzuschließen, der andere Angebote hat. Die meisten Teams sind in dem einen gut und in dem anderen schlecht. Die langsamen Teams verlieren Kandidaten; die schnellen Teams stellen umbenannte Sysadmins ein.

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-Denken und Incident-Urteil bewertet, statt frei Schnauze vorzugehen. Code-Aufgaben sind GitHub-integriert für realistische Automatisierungsaufgaben, Interview-Terminierung und Team-Voting halten die Schleife 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. Mit Pro-Sitz-Preisen kann das gesamte Hiring-Team mitwirken, ohne Aufpreis pro Recruiter.

Die Struktur ist der Punkt. Definieren Sie die SLO-Fläche, schreiben Sie die echte Stellenanzeige, screenen 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 rollenspezifische Hiring-Playbooks finden Sie in unseren Leitfäden zu wie Sie einen Backend-Engineer einstellen und wie Sie einen Forward-Deployed Engineer einstellen.