Interviewfragen für Site Reliability Engineers, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Antworte mit einem echten Dienst: seinen Nutzern, seinem Ziel, der schlimmsten Störung, die du erlebt hast, was du gemessen und was du geändert hast, damit es nicht wieder passiert. Interviewer hören auf Zahlen und auf die Begründung hinter einer Abwägung, nicht auf Namen von Werkzeugen.

Was ein Site Reliability Engineer können muss

• Ziele: Service Level Objectives und Indikatoren für Verfügbarkeit und Latenz, Error Budgets und wie sie Entscheidungen über Releases lenken.
• Observability: Metriken, Logs und Traces mit PrometheusIn 25 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Metriken und Alarmregeln, die dem folgen, was Nutzer spüren; Grafana-Dashboards darauf zählen hier mit. oder einem anderen Werkzeug, Alarme auf die Wirkung bei Nutzern und Dashboards, die Fragen beantworten.
• Betrieb: LinuxIn 67 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Einen kränkelnden Server von der Shell aus lesen: Prozesse, Speicher, Platten, das Netz und die Logs des Kernels., KubernetesIn 33 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Produktive Cluster betreiben: Scheduling, Health Checks, Autoscaling, Upgrades und was ausfällt, wenn ein Node stirbt., Netze, Kapazität und Last auf AWSIn 25 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Regionen und Zonen, Load Balancer, verwaltete Datenbanken und die Limits, die bei einer Störung zuschlagen. je nach Anbieter, AzureIn 33 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Regionen und Zonen, die verwalteten Dienste der Teams und die eigenen Werkzeuge des Anbieters für Status und Monitoring. je nach Anbieter oder Google CloudIn 17 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Regionen und Zonen, verwaltetes Kubernetes und das Monitoring und Logging des Anbieters. je nach Anbieter.
• Änderung und Automatisierung: sichere Releases über CI/CDIn 67 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Pipelines mit eingebauten sicheren Releases: schrittweise Rollouts, automatische Prüfungen und ein schneller Weg zurück., Rollback, Runbooks und Code in PythonIn 67 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Werkzeuge, die wiederkehrende Arbeit abnehmen: Prüfungen, Aufräumarbeiten, Berichte und kleine Dienste, die Dinge selbst reparieren. oder GoViele Werkzeuge und Operatoren für Zuverlässigkeit sind in Go geschrieben; sie lesen und kleine Dienste darin schreiben., der Handarbeit abnimmt.
• Menschen: Incident ManagementIn 25 % der Anzeigen für Site Reliability Engineer gefragt (Stand 05.11.2026).Eine Störung leiten: Rollen, Updates, eine Zeitleiste, der Weg zurück zum Betrieb und das Review danach., Rufbereitschaft und Reviews ohne Schuldzuweisung.

Ziele, Error Budgets und was du misst

Was ist ein SLO, und wie wählst du die SLIs für einen Dienst?

Worauf sie achten: dass Ziele bei den Nutzern beginnen, nicht bei dem, was leicht zu messen ist.

Kurze Antwort: „Ein Service Level Indicator misst, was Nutzer spüren, etwa den Anteil der Anfragen, die gelingen oder innerhalb einer festen Zeit antworten. Ein Service Level Objective ist das Ziel dafür über ein Zeitfenster, zum Beispiel, dass 99,9 % der Anfragen über dreißig Tage gelingen. Ein Service Level Agreement ist das Versprechen an einen Kunden, mit Folgen, und wird lockerer angesetzt als das SLO.“

Die ausführliche Antwort: Wähle für jeden Dienst wenige Indikatoren entlang des Wegs der Nutzer: Können sie sich anmelden, können sie bezahlen, wie lange dauert eine Suche? Miss so nah am Nutzer wie möglich, am Load Balancer oder im Client. Setz das Ziel nach dem, was Nutzer und das Geschäft brauchen, nicht auf Perfektion, denn jede weitere Neun kostet viel mehr als die letzte.

Schwache Antwort: „Unser SLO ist hundert Prozent Verfügbarkeit.“ Nachfrage: „Die Server sind in Ordnung, aber die Nutzer beschweren sich.“ Erkläre, warum der Indikator von der Seite der Nutzer aus gemessen werden sollte.

Was ist ein Error Budget, und was tut das Team, wenn es aufgebraucht ist?

Worauf sie achten: dass du das Budget nutzen kannst, um Tempo und Zuverlässigkeit auszubalancieren, mit Zustimmung aller.

Kurze Antwort: „Das Error Budget ist die Unzuverlässigkeit, die das SLO erlaubt: bei einem Ziel von 99,9 % die eine von tausend Anfragen, die fehlschlagen darf. Solange Budget übrig ist, liefert das Team frei aus. Ist es aufgebraucht, greift die vereinbarte Regel: Riskante Releases pausieren, und das Team arbeitet an der Zuverlässigkeit, bis der Dienst wieder im Ziel liegt.“

Die ausführliche Antwort: Die Regel muss vereinbart sein, bevor sie gebraucht wird, vom Product Owner und vom Engineering, sonst wird beim ersten Einfrieren daraus ein Streit. Schau, was das Budget verbraucht hat: Eine große Störung braucht eine Korrektur, viele kleine Ausfälle brauchen vielleicht einen besseren Release-Prozess. Ein Budget, das nie genutzt wird, kann heißen, dass das Ziel zu streng und das Team zu langsam ist.

Schwache Antwort: „Das SRE-Team blockiert alle Releases.“ Nachfrage: „Der Product Owner will während des Einfrierens noch ein Feature ausliefern.“ Erkläre, wer entscheidet und auf welcher Datengrundlage.

Wie misst du Latenz, und warum kann ein Durchschnitt täuschen?

Worauf sie achten: Perzentile und dass langsame Anfragen zählen, auch wenn es wenige sind.

Kurze Antwort: „Ich messe Latenz als Perzentile, etwa das 95. und das 99., getrennt für erfolgreiche und fehlgeschlagene Anfragen. Ein Durchschnitt versteckt das langsame Ende: Wenn die meisten Anfragen schnell sind und ein paar zehn Sekunden dauern, sieht der Durchschnitt gut aus, während manche Nutzer warten. Ein langsamer Fehler und ein schneller Fehler bedeuten außerdem verschiedene Dinge.“

Die ausführliche Antwort: Eine Seite macht oft viele Aufrufe, also erreicht ein langsames Ende bei einem einzigen Dienst die meisten Nutzer. Miss nah am Nutzer und schau dir die Werte pro Region und pro Art von Anfrage an. Setz das Ziel für die Latenz genauso wie das Ziel für den Erfolg, mit einem eigenen Zeitfenster.

Schwache Antwort: „Die durchschnittliche Antwortzeit liegt unter zweihundert Millisekunden, also ist alles gut.“ Nachfrage: „Das 99. Perzentil hat sich nach einem Release verdoppelt.“ Erkläre, wie du herausfindest, welche Anfragen langsamer geworden sind.

Observability, Alarme, Rufbereitschaft und Störungen

Wie baust du Observability für einen Dienst auf: Metriken, Logs und Traces?

Worauf sie achten: dass du eine neue Frage zu einem System beantworten kannst, ohne neuen Code auszuliefern.

Kurze Antwort: „Metriken zeigen den Verlauf über die Zeit, etwa Anfragerate, Fehler, Latenz und Auslastung; Logs erzählen, was in einer einzelnen Anfrage passiert ist; Traces folgen einer Anfrage über mehrere Dienste. Ich verbinde sie über gemeinsame Request-IDs, damit eine Spitze auf einem Dashboard zu den Traces und Logs dahinter führt.“

Die ausführliche Antwort: Die Werkzeuge stehen in den meisten Firmen nebeneinander: Prometheus mit Grafana, Datadog, Dynatrace, New Relic, Splunk oder die eigenen der Cloud, oft gesammelt mit OpenTelemetry, damit sich die Wahl später ändern lässt. Achte auf die Kosten, denn Logs und sehr detaillierte Metriken wachsen schnell; behalte, was Fragen beantwortet, und verwirf den Rest. Observability ist auch eine Gewohnheit: Teams fügen die Signale hinzu, wenn sie ein Feature bauen.

Schwache Antwort: „Wir loggen alles und suchen, wenn etwas kaputtgeht.“ Nachfrage: „Die Rechnung für das Monitoring ist stark gestiegen.“ Erkläre, was du behalten, stichprobenartig erfassen oder verwerfen würdest.

Was macht einen guten Alarm aus, und wie verringerst du den Lärm der Alarme für die Person in Rufbereitschaft?

Worauf sie achten: Alarme, die an die Wirkung bei Nutzern und an eine Handlung geknüpft sind, und Sorge für die Menschen in Rufbereitschaft.

Kurze Antwort: „Ein guter Alarm heißt, dass Nutzern geschadet wird oder bald geschadet wird und jemand jetzt handeln muss. Ich alarmiere, wenn das Error Budget zu schnell verbrennt, statt bei der CPU, schicke alles, was warten kann, in ein Ticket und gebe jedem Alarm einen Verantwortlichen und ein Runbook. Jeder Alarm, der jemanden umsonst geweckt hat, wird korrigiert oder gelöscht.“

Die ausführliche Antwort: Zähl die Alarme pro Schicht und geh sie jede Woche durch; ein Dienstplan, bei dem Menschen oft geweckt werden, brennt sie aus. Alarmiere auf Symptome, die Nutzer spüren, und behalte Dashboards zu den Ursachen für die Untersuchung. Eine faire Rufbereitschaft hat genug Leute, Übergaben und Ruhe nach einem Einsatz in der Nacht.

Schwache Antwort: „Mehr Alarme sind sicherer.“ Nachfrage: „Die Rufbereitschaft der letzten Woche hatte vierzig Alarme.“ Erkläre, wie du sie sortieren und verringern würdest.

Ein großer Ausfall beginnt. Führ uns durch, wie du die Störung leitest.

Worauf sie achten: Rollen, ruhige Ordnung und den Dienst wiederherstellen, bevor die Ursache gefunden ist.

Kurze Antwort: „Ich rufe die Störung aus, benenne einen Incident Lead, eine Person für die Kommunikation und die Leute, die beheben, und eröffne einen Kanal und eine Zeitleiste. Zuerst stellen wir den Dienst wieder her, oft durch Zurückrollen der letzten Änderung oder Umleiten des Traffics, dann suchen wir die Ursache. Updates gehen in einem festen Rhythmus hinaus, auch wenn es nichts Neues gibt.“

Die ausführliche Antwort: Prüf zuerst, was sich geändert hat: Releases, Konfiguration, Traffic, der Status des Anbieters. Vermeide, dass mehrere Leute gleichzeitig etwas ändern. Miss die Zeit bis zur Erkennung und die Zeit bis zur Wiederherstellung, denn sie zeigen, wo sich der Prozess verbessern lässt. Schließ die Störung, wenn es den Nutzern gut geht, nicht wenn die Ursache bekannt ist.

Schwache Antwort: „Alle springen ein und beheben, was sie können.“ Nachfrage: „Der Rollback hilft nicht.“ Erkläre, was du als Nächstes versuchen und wen du hinzuziehen würdest.

Wie schreibst du ein Postmortem ohne Schuldzuweisung, das wirklich zu Veränderung führt?

Worauf sie achten: aus Ausfällen lernen, ohne Schuld zuzuweisen, und Maßnahmen, die erledigt werden.

Kurze Antwort: „Ein Postmortem ohne Schuldzuweisung beschreibt, was passiert ist, die Auswirkung, die Zeitleiste, was geholfen und was im Weg gestanden hat und warum die Handlungen den Beteiligten in dem Moment sinnvoll erschienen. Es endet mit wenigen Maßnahmen, jede mit einem Verantwortlichen und einem Datum, verfolgt wie jede andere Arbeit.“

Die ausführliche Antwort: Schuld bringt Menschen bei, Fehler zu verstecken, also fragt das Review, wie das System den Fehler zugelassen hat, nicht, wer ihn gemacht hat. Such nach mehreren Ursachen, nicht nach einer einzigen Wurzel. Teile das Review breit und prüf nach einem Monat, ob die Maßnahmen erledigt sind; ein Postmortem mit offenen Maßnahmen ist ein Warnzeichen.

Schwache Antwort: „Der Engineer, der die Änderung gemacht hat, bekommt mehr Schulung.“ Nachfrage: „Dieselbe Störung passiert noch einmal.“ Erkläre, wie du die früheren Maßnahmen prüfen würdest.

Toil, Automatisierung, Kapazität und sichere Änderungen

Wann reicht ein Runbook, und wann sollte daraus Automatisierung werden?

Worauf sie achten: dass du Runbooks schreibst und weißt, wann du sie durch Code ersetzt.

Kurze Antwort: „Ein Runbook ist eine schriftliche Anleitung für ein bekanntes Problem, damit jeder in Rufbereitschaft handeln kann. Wenn dasselbe Runbook oft befolgt wird, seine Schritte sich nie ändern und sie ohne Urteilsvermögen sicher ablaufen, mache ich daraus Automatisierung, zuerst als Werkzeug, das ein Mensch startet, dann als Korrektur, die von selbst mit einer Prüfung läuft.“

Die ausführliche Antwort: Automatisierung, die still fehlschlägt, ist schlimmer als ein Runbook, also braucht sie Logging, Grenzen und einen Weg, sie zu stoppen. Behalte das Runbook für die Fälle, die die Automatisierung nicht abdeckt. Miss, wie oft jedes Runbook genutzt wird; diese Liste ist dein Backlog für Automatisierung.

Schwache Antwort: „Wir automatisieren von Anfang an alles.“ Nachfrage: „Die automatische Korrektur hat den ganzen Cluster neu gestartet.“ Erkläre, welche Grenzen du einbauen würdest.

Was ist Toil, und wie verringerst du ihn?

Worauf sie achten: dass du wiederholte Handarbeit benennen und Platz schaffen kannst, um sie abzuschaffen.

Kurze Antwort: „Toil ist manuelle, wiederholte Arbeit, die mit dem Dienst wächst und keinen bleibenden Wert hinterlässt: einen Dienst von Hand neu starten, Zugänge vergeben, Platten aufräumen. SRE-Teams begrenzen ihn, oft auf die Hälfte ihrer Zeit, und verwenden den Rest auf Engineering, das ihn abschafft.“

Die ausführliche Antwort: Miss den Toil ein paar Wochen lang: was, wie oft, wie lange. Dann beseitige die größten Posten durch Automatisierung, Self-Service oder eine Korrektur im Produkt. Manches geht zurück an das Team, das es verursacht. Wenn der Toil weiter steigt, ist das ein Problem der Besetzung oder des Designs, das du bei der Leitung ansprichst.

Schwache Antwort: „Toil gehört eben zum Betrieb.“ Nachfrage: „Das Team hat keine Zeit zum Automatisieren.“ Erkläre, wie du die Argumente vorbringen und die Zeit gewinnen würdest.

Wie planst du Kapazität und testest die Last vor einer großen Spitze?

Worauf sie achten: Prognosen, Lasttests und Reserve, mit den Kosten im Blick.

Kurze Antwort: „Ich gehe von der Prognose des Geschäfts aus, übersetze sie in Anfragen pro Sekunde für jeden Dienst und lasse Lasttests in einer produktionsnahen Umgebung laufen, um zu finden, wo jeder Teil bricht. Dann plane ich Reserve ein, prüfe Quoten und Limits beim Cloud-Anbieter und lege fest, was abgeschaltet wird, wenn die Last über den Plan hinausgeht.“

Die ausführliche Antwort: Der Engpass liegt oft nicht dort, wo man ihn erwartet: ein Limit für Datenbankverbindungen, ein Dienst eines Dritten, eine Quote. Autoscaling hilft, hat aber eigene Verzögerungen und Grenzen. Vergleiche nach der Spitze die Prognose mit dem, was passiert ist, und skaliere wieder herunter, denn freie Kapazität kostet jede Stunde Geld.

Schwache Antwort: „Das Autoscaling erledigt das.“ Nachfrage: „Der Traffic ist dreimal so hoch wie die Prognose.“ Erkläre, wie der Dienst kontrolliert an Leistung verliert, statt auszufallen.

Wie lieferst du Änderungen sicher aus: Canary, Feature Flags und Rollback?

Worauf sie achten: ein Release-Prozess, der den Schaden einer schlechten Änderung begrenzt.

Kurze Antwort: „Ein Canary Release schickt einen kleinen Teil des Traffics auf die neue Version und vergleicht ihre Fehler und ihre Latenz mit der alten; sehen sie schlechter aus, stoppt das Release und rollt automatisch zurück. Feature Flags trennen das Ausliefern von Code vom Einschalten eines Features. Jedes Release muss sich leicht rückgängig machen lassen, auch Datenbankänderungen.“

Die ausführliche Antwort: Die meisten Störungen folgen auf eine Änderung, also lohnt sich SRE-Arbeit hier am meisten. Roll Region für Region aus, halte Releases klein und häufig und vermeide Releases am Ende des Tages vor einem Wochenende. Datenbankänderungen erfolgen in Schritten, die die alte und die neue Version beide akzeptieren, damit der Rollback möglich bleibt.

Schwache Antwort: „Wir testen gut, also liefern wir an alle gleichzeitig aus.“ Nachfrage: „Der Canary sieht gut aus, aber bei einem Kunden ist etwas kaputt.“ Sprich darüber, was deine Prüfungen übersehen haben.

Wie würdest du Chaos Engineering sicher in der Produktion betreiben?

Worauf sie achten: kontrollierte Experimente mit klarer Hypothese und einem Knopf zum Stoppen.

Kurze Antwort: „Chaos Engineering heißt, absichtlich Ausfälle herbeizuführen, um zu lernen, wie sich das System verhält: einen Server stoppen, eine Abhängigkeit verzögern, eine Zone abtrennen. Ich fange in einer Testumgebung an, mit einer aufgeschriebenen Hypothese, einem kleinen Wirkungsbereich und einem Weg, sofort zu stoppen, und gehe erst in die Produktion, wenn die Grundlagen halten, zu einer ruhigen Stunde, während das Team zuschaut.“

Die ausführliche Antwort: Jedes Experiment sollte mit einer Erkenntnis enden: ein Alarm, der nicht ausgelöst hat, ein Timeout, der zu lang war, ein Runbook, das falsch war. Game Days, an denen das Team gemeinsam eine Störung übt, sind ein sanfterer Einstieg und trainieren Menschen ebenso wie Systeme.

Schwache Antwort: „Wir schalten zufällig Server ab, um zu sehen, was passiert.“ Nachfrage: „Das Experiment hat einen echten Ausfall verursacht.“ Erkläre, was deine Regel zum Stoppen hätte sein sollen.

Eine Abhängigkeit, auf die sich dein Dienst verlässt, wird langsam. Wie schützt du deinen Dienst?

Worauf sie achten: Timeouts, Retries, Circuit Breaker und kontrollierter Leistungsabbau.

Kurze Antwort: „Jeder Aufruf einer Abhängigkeit bekommt einen Timeout, der kürzer ist als mein eigenes Ziel, eine begrenzte Zahl von Retries mit wachsenden Wartezeiten und einen Circuit Breaker, der aufhört, eine Abhängigkeit aufzurufen, die immer wieder fehlschlägt. Wo es geht, verliert der Dienst kontrolliert an Funktion, zum Beispiel indem er Daten aus dem Cache zeigt, statt die Seite scheitern zu lassen.“

Die ausführliche Antwort: Unbegrenzte Retries können aus einer langsamen Abhängigkeit einen kompletten Ausfall machen, also brauchen auch Retries ein Budget. Erfasse die Abhängigkeiten eines Dienstes und welche davon kritisch sind; vereinbare Ziele mit ihren Verantwortlichen. Teste, was passiert, wenn jede einzelne langsam ist, nicht nur, wenn sie ausfällt.

Schwache Antwort: „Wir versuchen es so lange, bis es klappt.“ Nachfrage: „Die Abhängigkeit ist ein Zahlungsanbieter.“ Sprich darüber, was eingeschränkt werden darf und was nicht.

Wie hältst du eine Kubernetes-Plattform bei Upgrades und ausfallenden Nodes zuverlässig?

Worauf sie achten: praktischen Betrieb von Clustern, nicht nur ihre Theorie.

Kurze Antwort: „Ich verteile die Workloads über Zonen, setze Requests und Limits, damit der Scheduler sie platzieren kann, nutze Disruption Budgets, damit ein Upgrade nie zu viele Kopien gleichzeitig abschaltet, und Health Checks, die neu starten, was hängt. Upgrades gehen zuerst auf einen Testcluster und dann Node-Pool für Node-Pool, mit zusätzlicher Kapazität, bevor alte Nodes geleert werden.“

Die ausführliche Antwort: Halte den Cluster nah an der unterstützten Version, denn übersprungene Upgrades häufen Risiko an. Beobachte die Control Plane, DNS und das Netz innerhalb des Clusters, die viele schwierige Störungen verursachen. Übe den Verlust eines Nodes und einer Zone und schreib auf, wie lange die Wiederherstellung dauert.

Schwache Antwort: „Kubernetes heilt sich selbst.“ Nachfrage: „Nach einem Upgrade werden manche Pods nie bereit.“ Geh durch, was du prüfen würdest.

Die Senior-Stufen

Wie würdest du als Staff Site Reliability Engineer oder SRE Manager SRE-Praktiken in Teams bringen, die keine haben?

Worauf sie achten: Einfluss ohne Weisungsbefugnis und Einführung Schritt für Schritt.

Kurze Antwort: „Ich fange mit einem Team an, das will, und mit seinem schmerzhaftesten Dienst, helfe ihm, ein SLO zu setzen, seine Alarme aufzuräumen und ein Review ohne Schuldzuweisung zu führen, und zeige das Ergebnis in Zahlen. Dann mache ich aus dem, was funktioniert hat, Vorlagen, Schulungen und einen schlanken Standard, damit die nächsten Teams es selbst übernehmen. SRE soll Teams helfen, ihre Zuverlässigkeit selbst zu verantworten, nicht sie ihnen abnehmen.“

Die ausführliche Antwort: Auf der Stufe von Staff und Principal Site Reliability Engineer besteht die Arbeit aus Standards über viele Teams und den schwierigsten Störungen über Teams hinweg; als SRE Manager sind es das Team, das Modell der Rufbereitschaft, Einstellungen und das Budget. Beide brauchen einen Blick auf Zuverlässigkeit in Geld: was eine Stunde Ausfall kostet und was es kosten würde, die nächste Neun zu erreichen.

Schwache Antwort: „Teams müssen die SRE-Regeln befolgen, oder sie verlieren den Zugang zur Produktion.“ Nachfrage: „Ein Team sagt, SLOs bremsen es.“ Erkläre, was du messen und ändern würdest.

Dein Lebenslauf für diese Fragen

Jeder Dienst in deinem Lebenslauf lädt zu den Fragen oben ein: Was war sein Ziel, wie ist er ausgefallen, was hast du geändert, und welche Zahl hat sich bewegt? Schreib jedes davon als eine Zeile unter die Stelle, zu der es gehört, damit die Geschichte da ist, wenn danach gefragt wird:

Prüf deinen Lebenslauf an einem SRE-Job, den du anstrebst: Was die Prüfung als fehlend findet, kommt wahrscheinlich zur Sprache, also übe zuerst die Störungen und Änderungen dazu.