Fragen im Vorstellungsgespräch für Site Reliability Engineer — Über 30 Fragen und Expertenantworten

Glassdoor berichtet von einem durchschnittlichen SRE-Gehalt von 169.680 US-Dollar, wobei das 75. Perzentil jährlich 213.000 US-Dollar übersteigt [1]. Die Rolle — 2003 bei Google entstanden und mittlerweile von jedem großen Technologieunternehmen übernommen — befindet sich an der Schnittstelle von Softwareentwicklung und Systembetrieb, und der Interviewprozess spiegelt diese Dualität wider [2]. SRE-Vorstellungsgespräche prüfen Systemdesign unter Zuverlässigkeitsanforderungen, Programmierung zur Automatisierung, Incident-Management unter Druck und die spezifische Denkweise, Zuverlässigkeit durch SLOs und Error Budgets zu quantifizieren. Dieser Leitfaden behandelt die verhaltensbasierten, technischen und situativen Fragen, denen Sie begegnen werden, mit Antworten, die auf die Tiefe kalibriert sind, die Spitzenunternehmen erwarten.

Wichtigste Erkenntnisse

• SRE-Vorstellungsgespräche umfassen typischerweise vier bis sechs Runden: Programmierung, Systemdesign, Fehlerbehebung, Incident-Management und Verhaltensfragen — verteilt über einen ganzen Tag oder mehrere Sitzungen [3].
• Das zentrale Unterscheidungsmerkmal bei SRE-Vorstellungsgesprächen ist zuverlässigkeitsorientiertes Systemdesign — Sie müssen Systeme entwerfen, die graceful degradieren, nicht nur Systeme, die skalieren [2].
• SLOs, SLIs, Error Budgets und Toil-Reduktion sind SRE-spezifisches Vokabular, das Interviewer fließend von Ihnen erwarten.
• Programmieraufgaben für SRE-Positionen betonen Automatisierung, Infrastruktur-Tooling und operatives Scripting statt rein algorithmischer Aufgaben [3].

Verhaltensbasierte Fragen

1. Erzählen Sie mir von dem wirkungsvollsten Vorfall, den Sie gemanagt haben. Was war Ihre Rolle, und was hat die Nachbetrachtung ergeben?

Expertenantwort: „Ich war der Incident Commander bei einem kaskadierenden Ausfall, der unseren primären Authentifizierungsdienst lahmlegte und 2,3 Millionen aktive Nutzer für 47 Minuten betraf. Eine routinemäßige Konfigurationsänderung an unserem Rate Limiter hatte versehentlich den Schwellenwert auf 10 Anfragen pro Sekunde statt 10.000 gesetzt. Der Auth-Dienst erreichte das Limit, gab 429er-Fehler zurück, und der Retry-Sturm der Clients verstärkte die Last um das 50-Fache. Ich erklärte einen P1, richtete den Incident-Kanal ein, wies Rollen zu (Kommunikationsleitung, technische Leitung für Auth und Infrastruktur) und koordinierte die Reaktion. Die Lösung bestand im Zurücksetzen der Konfigurationsänderung, aber wir mussten auch den Retry-Rückstau abbauen, indem wir die Kapazität vorübergehend erhöhten. Die Nachbetrachtung identifizierte drei Grundursachen: keine Validierung der Rate-Limiter-Konfigurationswerte, kein Canary-Deployment für Konfigurationsänderungen und kein Circuit Breaker bei Client-Retries. Wir implementierten alle drei Korrekturen und fügten einen synthetischen Canary hinzu, der den Auth-Flow alle 30 Sekunden testet. Der Vorfall verbrauchte 40 % unseres vierteljährlichen Error Budgets, was einen Entwicklungsstopp für neue Features auslöste, bis Zuverlässigkeitsverbesserungen ausgeliefert waren."

2. Beschreiben Sie eine Situation, in der Sie eine signifikante Quelle von Toil eliminiert haben.

Expertenantwort: „Unsere Bereitschaftsingenieure verbrachten durchschnittlich 6 Stunden pro Woche damit, Datenbank-Read-Replicas während Verkehrsspitzen manuell zu skalieren — sie beobachteten Dashboards, verbanden sich per SSH mit Instanzen und führten Skalierungsskripte aus. Dies war lehrbuchmäßiger Toil: manuell, repetitiv, automatisierbar und linear mit dem Dienstwachstum skalierend. Ich baute einen Auto-Scaling-Controller mit einem benutzerdefinierten Kubernetes Operator, der CPU- und Abfragelatenzkennzahlen überwachte, die erforderliche Replica-Anzahl anhand eines prädiktiven Modells basierend auf historischen Verkehrsmustern berechnete und Replicas automatisch hoch-/herunterfuhr. Ich fügte Schutzmaßnahmen hinzu: minimale und maximale Replica-Anzahlen, Abkühlungsperioden zur Vermeidung von Flapping und PagerDuty-Benachrichtigungen, wenn Auto-Scaling 80 % der maximalen Kapazität erreichte (was organisches Wachstum signalisierte, das Infrastrukturinvestitionen erforderte). Nach der Bereitstellung sanken die manuellen Skalierungseingriffe von 6 Stunden/Woche auf 0, und unsere Bereitschaftsbelastung verringerte sich um 30 %. Das Projekt verbesserte auch unsere P99-Abfragelatenz um 15 %, weil die automatisierte Skalierung schneller reagierte als Menschen."

3. Nennen Sie ein Beispiel, wie Sie gegen eine Zuverlässigkeitsanforderung argumentiert haben, die Sie für zu aggressiv hielten.

Expertenantwort: „Ein Produktteam forderte 99,999 % Verfügbarkeit (Five Nines) für einen neuen Benachrichtigungsdienst. Ich berechnete, was Five Nines tatsächlich bedeutet: 5,26 Minuten Ausfallzeit pro Jahr, was eine Multi-Region Active-Active-Bereitstellung, automatisiertes Failover unter 30 Sekunden und im Wesentlichen Null-Toleranz für Konfigurationsänderungen ohne Canary-Deployments erfordern würde. Die Engineering-Kosten wurden auf 6 Monate und 400.000 US-Dollar zusätzliche Infrastruktur geschätzt. Dann fragte ich das Produktteam: ‚Was passiert mit den Nutzern, wenn Benachrichtigungen um 5 Minuten verzögert werden?' Die Antwort war ‚nichts — Benachrichtigungen sind nicht zeitkritisch.' Ich schlug 99,9 % Verfügbarkeit vor (8,76 Stunden Ausfallzeit pro Jahr), was unsere bestehende Infrastruktur mit geringfügigen Verbesserungen erreichen konnte. Das Produktteam stimmte zu, nachdem es die Kosten-Zuverlässigkeits-Kurve gesehen hatte. Das ist die SRE-Disziplin: Zuverlässigkeit ist ein Feature, und wie alle Features hat sie Kosten, die durch die Auswirkung auf die Nutzer gerechtfertigt sein müssen [2]."

4. Erzählen Sie mir von einer Situation, in der Sie das Monitoring oder die Observability eines kritischen Dienstes verbessert haben.

Expertenantwort: „Unser Zahlungsdienst hatte ein Monitoring, das nur grundlegende Gesundheitschecks verfolgte — HTTP-200-Antworten und CPU-Auslastung. Nach einem stillen Fehler, bei dem der Dienst 3 Stunden lang 200er-Antworten mit veralteten Cache-Daten zurückgab, gestaltete ich unseren Observability-Stack neu. Ich definierte SLIs, die an die Benutzererfahrung gekoppelt waren: erfolgreiche Zahlungsabschlussrate (Ziel 99,95 %), Zahlungsverarbeitungslatenz bei P99 (Ziel 2 Sekunden) und Datenaktualität (Cache-Veralterung unter 60 Sekunden). Ich implementierte diese als Prometheus-Metriken, erstellte Grafana-Dashboards mit SLO-Burn-Rate-Alerts (Multi-Window: 5 Minuten für schnelle Burns, 1 Stunde für langsame Burns) und fügte verteiltes Tracing mit Jaeger hinzu, um Zahlungsflüsse über 7 Microservices zu verfolgen. Der Multi-Window-Alerting-Ansatz reduzierte False-Positive-Bereitschaftsrufe um 60 %, während er die Art von stillem Fehler erkannte, die das Projekt ursprünglich motiviert hatte. Wir gingen von ‚Ist der Dienst verfügbar?' zu ‚Liefert der Dienst den Nutzern Mehrwert?'"

5. Beschreiben Sie, wie Sie die Feature-Entwicklungsgeschwindigkeit mit Zuverlässigkeitsarbeit in Einklang gebracht haben.

Expertenantwort: „Ich implementierte eine Error-Budget-Richtlinie, bei der Zuverlässigkeitsarbeit und Feature-Entwicklung von derselben Metrik gesteuert wurden. Wenn unser monatliches Error Budget über 50 % lag, hatte das Entwicklungsteam volle Geschwindigkeit bei Features. Wenn es unter 50 % fiel, teilten wir 50/50 zwischen Features und Zuverlässigkeitsverbesserungen auf. Unter 25 % verlagerte sich der gesamte Engineering-Aufwand auf Zuverlässigkeit, bis sich das Budget erholte. Dies war keine starre Regel — es war eine ausgehandelte Vereinbarung zwischen SRE und dem Produktteam, dokumentiert in unserem Team-Charter. Die zentrale Erkenntnis ist, dass Error Budgets Zuverlässigkeit konkret machen: Anstatt darüber zu streiten, ob Zuverlässigkeit ‚wichtig ist', konnten wir auf Daten verweisen, die zeigten, dass wir 80 % unseres Error Budgets verbraucht hatten und in Stabilität investieren mussten. Über ein Jahr hinweg reduzierte dieser Ansatz unsere P1-Vorfallrate um 45 %, während das Produktteam 12 % mehr Features auslieferte als im Vorjahr — weil es weniger Zeit für Incident Response und Hotfixes aufwenden musste."

6. Wie gehen Sie an Bereitschaftsrotationen heran, und wie haben Sie die Bereitschaftserfahrung für Ihr Team verbessert?

Expertenantwort: „Ich betrachte Bereitschaft als ein Engineering-Problem, nicht als ein Personalbesetzungsproblem. Als ich zum Team kam, wurden Bereitschaftsingenieure durchschnittlich 14 Mal pro Woche alarmiert, wobei 40 % der Alarme nicht handlungsrelevant oder Duplikate waren. Ich implementierte drei Änderungen. Erstens, Alert-Tuning: Ich überprüfte jeden Alert über 30 Tage, löschte Alerts, die nicht ausgelöst hatten oder durchgängig nicht handlungsrelevant waren, und konsolidierte doppelte Alerts mithilfe von Alert-Grouping in PagerDuty. Zweitens, Runbook-Automatisierung: Für die Top 5 der häufigsten handlungsrelevanten Alerts schrieb ich automatisierte Behebungsskripte (ausgelöst durch PagerDuty-Webhooks), die die Erstreaktion übernahmen und nur dann einen Menschen alarmierten, wenn die automatische Behebung fehlschlug. Drittens, Verbesserungen der Bereitschaftsübergabe: Ich führte ein strukturiertes Übergabedokument ein (offene Vorfälle, kürzliche Änderungen, bekannte Risiken) und ein 15-minütiges synchrones Übergabegespräch zwischen dem abtretenden und dem antretenden Bereitschaftsingenieur. Alarme sanken von 14/Woche auf 4/Woche, und der Zufriedenheitswert in der Bereitschaftsumfrage verbesserte sich von 2,1/5 auf 4,3/5."

Technische Fragen

1. Erklären Sie SLOs, SLIs und Error Budgets. Wie hängen sie zusammen?

Expertenantwort: „Ein SLI (Service Level Indicator) ist eine quantitative Metrik, die einen bestimmten Aspekt der Dienstqualität misst — zum Beispiel den Anteil der HTTP-Anfragen, die innerhalb von 200 ms erfolgreich zurückkehren. Ein SLO (Service Level Objective) ist ein Zielwert für einen SLI — zum Beispiel sollten 99,9 % der Anfragen innerhalb von 200 ms über ein rollierendes 30-Tage-Fenster erfolgreich sein. Das Error Budget ist die Umkehrung des SLO: Wenn Ihr SLO bei 99,9 % liegt, beträgt Ihr Error Budget 0,1 % — Sie können 0,1 % Fehler über das Messfenster tolerieren. Für einen Dienst, der 1 Million Anfragen pro Tag verarbeitet, bedeutet ein SLO von 99,9 %, dass Sie sich 1.000 Fehler pro Tag leisten können. Das Error Budget schafft eine gemeinsame Sprache zwischen SRE und Produktteams: Solange Sie im Budget sind, liefern Sie Features aggressiv aus. Wenn das Budget aufgebraucht ist, investieren Sie in Zuverlässigkeit. Dies ersetzt subjektive Argumente über Zuverlässigkeit durch objektive, datengesteuerte Entscheidungen [2]."

2. Entwerfen Sie ein Monitoring- und Alerting-System für eine Microservices-Architektur mit 50 Diensten.

Expertenantwort: „Ich würde das System in drei Schichten aufbauen. Datenerfassung: Jeden Dienst mit Prometheus-Client-Bibliotheken instrumentieren, die RED-Metriken (Rate, Errors, Duration) plus benutzerdefinierte Geschäftsmetriken exportieren. Eine Prometheus-Föderationshierarchie verwenden — Prometheus-Instanzen pro Cluster, die eine zentrale Thanos- oder Mimir-Instanz für Langzeitspeicherung und clusterübergreifende Abfragen speisen. Log-Aggregation über Loki oder Elasticsearch für strukturiertes Logging. Verteiltes Tracing über Jaeger oder Tempo mit Kontextpropagierung über alle 50 Dienste. Alerting: SLOs für die kritischen User Journeys jedes Dienstes definieren, nicht nur für einzelne Endpunkte. Multi-Window-Burn-Rate-Alerting implementieren: Ein 5-Minuten-Fenster über einem 1-Stunden-Schwellenwert fängt schnelle Burns ab; ein 30-Minuten-Fenster über einem 6-Stunden-Schwellenwert fängt langsame Burns ab. Alerts durch PagerDuty mit teambasiertem Routing und Eskalationsrichtlinien weiterleiten. Dashboards: Golden-Signal-Dashboards pro Dienst erstellen (Latenz, Traffic, Fehler, Sättigung), ein übergeordnetes SLO-Dashboard, das den Budget-Verbrauch aller 50 Dienste zeigt, und Service-Abhängigkeitskarten, die aus Tracing-Daten generiert werden. Kritische Designprinzipien: Bei Symptomen alarmieren (Nutzerauswirkung), nicht bei Ursachen (CPU hoch), und sicherstellen, dass jeder Alert ein Runbook hat, das in den Alert-Metadaten verlinkt ist."

3. Ein Dienst reagiert langsam. Führen Sie mich durch Ihren Fehlerbehebungsansatz.

Expertenantwort: „Ich beginne mit der Nutzerauswirkung: Wie hoch ist die P50/P99-Latenz im Vergleich zum Normalwert, und welcher Prozentsatz der Nutzer ist betroffen? Dann folge ich systematisch der USE-Methode (Utilization, Saturation, Errors) und der RED-Methode (Rate, Errors, Duration). Erstens, den Dienst selbst prüfen: CPU, Arbeitsspeicher, GC-Pausen (bei JVM-Diensten), Thread-Pool-Sättigung, Connection-Pool-Erschöpfung. Zweitens, nachgelagerte Abhängigkeiten prüfen: Datenbankabfragelatenz (langsame Abfragen? Lock-Contention? Fehlender Index?), Cache-Trefferrate (hat der Cache kalt gestartet oder Hot Keys verdrängt?), externe API-Latenz (ist ein Drittanbieterdienst beeinträchtigt?). Drittens, das Netzwerk prüfen: Gibt es Paketverluste, DNS-Auflösungsverzögerungen oder TLS-Handshake-Overhead? Ich verwende verteiltes Tracing, um zu identifizieren, welcher Span im Anfragepfad die meiste Latenz beiträgt — dies lokalisiert den Engpass im verteilten System. Wenn es eine graduelle Verschlechterung ist, prüfe ich auf Ressourcenlecks (Arbeitsspeicher, Verbindungen, Dateideskriptoren) oder Verkehrswachstum, das die Kapazität übersteigt. Wenn es plötzlich ist, prüfe ich auf kürzliche Deployments, Konfigurationsänderungen oder Änderungen der Upstream-Verkehrsmuster."

4. Wie würden Sie ein System entwerfen, das 99,99 % Verfügbarkeit über mehrere Regionen hinweg erreicht?

Expertenantwort: „99,99 % Verfügbarkeit erlaubt 52,6 Minuten Ausfallzeit pro Jahr, was bedeutet, dass jede Komponente entweder redundant sein muss oder unabhängig ausfallen muss. Architektur: Active-Active-Deployment über mindestens 3 Regionen (nicht Active-Passive, das Kapazität verschwendet und Failover-Risiken einführt). Globales Load Balancing (Cloudflare, AWS Global Accelerator) mit gesundheitsprüfungsgesteuerter Verkehrsumleitung — wenn eine Region Gesundheitschecks nicht besteht, wird der Verkehr innerhalb von 30 Sekunden automatisch zu gesunden Regionen geleitet. Datenschicht: Synchrone Replikation innerhalb von Regionen für Konsistenz, asynchrone Replikation über Regionen hinweg mit Konfliktauflösung (CRDTs oder Last-Writer-Wins je nach Datenmodell). Akzeptieren, dass regionsübergreifende Schreibvorgänge Latenz-Overhead haben. Deployment: Canary-Deployments pro Region — in eine Region deployen, 30 Minuten beobachten, dann in die verbleibenden Regionen ausrollen. Dies verhindert, dass ein fehlerhaftes Deployment alle Regionen gleichzeitig lahmlegt. Zu berücksichtigende Fehlermodi: Einzelregionsausfall, Datenbank-Primary-Failover, DNS-Propagierungsverzögerungen, Zertifikatsablauf und Abhängigkeitsausfälle. Testen: Regelmäßiges Chaos Engineering — monatliche Fehlerinjektionen mit Tools wie Gremlin oder Litmus, um zu überprüfen, dass Failover wie vorgesehen funktioniert, nicht nur wie dokumentiert."

5. Was ist der Unterschied zwischen horizontaler und vertikaler Skalierung, und wann bevorzugen Sie welche?

Expertenantwort: „Vertikale Skalierung erhöht die Ressourcen einer einzelnen Instanz (mehr CPU, RAM, schnellere Festplatte). Horizontale Skalierung fügt mehr Instanzen hinter einem Load Balancer hinzu. Ich bevorzuge horizontale Skalierung für zustandslose Dienste (Webserver, API-Server, Worker), weil sie lineares Kapazitätswachstum, Fehlertoleranz (der Verlust einer Instanz ist gering) und Übereinstimmung mit Cloud-Infrastrukturmustern bietet. Ich verwende vertikale Skalierung für zustandsbehaftete Komponenten, bei denen horizontale Skalierung Komplexität einführt — ein Datenbank-Primary, der mehr Arbeitsspeicher für seinen Working Set benötigt, oder eine Single-Threaded-Verarbeitungspipeline, die CPU-gebunden ist. Die praktische Entscheidung hängt von drei Faktoren ab: Zustandsverwaltung (zustandsbehaftete Dienste sind schwieriger horizontal zu skalieren), Kosteneffizienz (vertikale Skalierung stößt an abnehmende Erträge und Hardware-Grenzen) und Fehler-Blast-Radius (der Ausfall einer großen Instanz ist katastrophal; der Ausfall einer von zwanzig kleinen Instanzen ist handhabbar). In der Produktion kombiniere ich typischerweise beides: die Datenbank auf die größte praktikable Instanz vertikal skalieren, dann mit Read Replicas für leselastige Workloads horizontal skalieren."

6. Erklären Sie Infrastructure as Code (IaC) und wie Sie es zur Verbesserung der Zuverlässigkeit eingesetzt haben.

Expertenantwort: „Infrastructure as Code behandelt Infrastrukturkonfiguration als Software: versionskontrolliert, reviewed, getestet und reproduzierbar. Ich verwende Terraform für die Cloud-Ressourcenbereitstellung (VPCs, Datenbanken, Load Balancer, IAM-Richtlinien) und Ansible oder Puppet für die Konfigurationsverwaltung innerhalb von Instanzen. Zuverlässigkeitsvorteile: Reproduzierbarkeit (ich kann jede Umgebung in Minuten aus Code neu aufbauen und Snowflake-Server eliminieren), Nachvollziehbarkeit (git log zeigt, wer was wann und warum geändert hat) und Testbarkeit (ich führe terraform plan in der CI aus, um Breaking Changes vor dem Apply zu erkennen, und verwende Terratest für Integrationstests von Infrastrukturmodulen). Ein konkretes Beispiel: Als unsere Staging-Umgebung von der Produktion abwich und eine staging-getestete Änderung einen Produktionsausfall verursachte, baute ich beide Umgebungen aus denselben Terraform-Modulen mit umgebungsspezifischen Variablen neu auf. Drift wurde unmöglich, weil der Code die einzige Quelle der Wahrheit ist. Ich implementierte auch Sentinel-Richtlinien in Terraform Cloud, um Sicherheitsleitplanken durchzusetzen — keine öffentlichen S3-Buckets, keine Security Groups mit 0.0.0.0/0-Ingress."

7. Wie gehen Sie an die Kapazitätsplanung für einen Dienst mit schnellem Wachstum heran?

Expertenantwort: „Ich verwende ein vierstufiges Framework. Erstens, ein Lastmodell erstellen: die wichtigsten Ressourcentreiber identifizieren (Anfragen pro Sekunde, gleichzeitige Verbindungen, Datenvolumen) und sie mit Infrastrukturmetriken korrelieren (CPU, Arbeitsspeicher, Festplatten-I/O, Netzwerkbandbreite). Das ergibt Kosten pro ‚Arbeitseinheit' — zum Beispiel: ‚Jede API-Anfrage verbraucht 2 ms CPU und 0,5 MB Arbeitsspeicher.' Zweitens, Wachstum modellieren: historische Daten zur Projektion des Verkehrswachstums verwenden (linear, exponentiell, saisonal). Für einen schnell wachsenden Dienst projiziere ich mindestens 6 Monate voraus und wende einen 2x-Sicherheitsfaktor an. Drittens, Engpassressourcen identifizieren: Die Ressource, die zuerst die Kapazität erreicht, bestimmt Ihren Skalierungsauslöser — es könnte CPU auf Compute-Knoten sein, IOPS auf der Datenbank oder Bandbreite im Netzwerk. Viertens, Reaktion automatisieren: Auto-Scaling für elastische Ressourcen implementieren (Compute, Caches) und vorlaufzeitbewusste Beschaffung für nicht-elastische Ressourcen einrichten (Datenbank-Instanz-Upgrades, reservierte Kapazität). Ich überprüfe Kapazitätspläne monatlich, vergleiche Projektionen mit tatsächlichen Werten und passe das Modell an, wenn das tatsächliche Wachstum um mehr als 20 % von der Projektion abweicht."

Situative Fragen

1. Das Error Budget Ihres Dienstes ist aufgebraucht, und es sind noch zwei Wochen im Quartal übrig. Das Produktteam möchte ein großes Feature ausliefern. Was tun Sie?

Expertenantwort: „Gemäß unserer Error-Budget-Richtlinie löst die Erschöpfung des Budgets einen Zuverlässigkeits-Freeze aus — keine Feature-Deployments, bis sich das Budget erholt oder das Quartal zurückgesetzt wird. Ich würde dem Produktteam die Daten präsentieren: ‚Unser SLO liegt bei 99,9 %, und wir haben 100 % unseres Error Budgets verbraucht, mit 14 verbleibenden Tagen. Das Deployment eines großen Features bringt Deployment-Risiko mit sich, das uns weiter in eine SLO-Verletzung treiben könnte.' Ich würde Alternativen anbieten: Können wir das Feature hinter einem Feature Flag mit graduellem Rollout deployen (1 % -> 10 % -> 100 %), um den Blast Radius zu minimieren? Können wir eine bestimmte Zuverlässigkeitsverbesserung priorisieren, die das Budget schneller wiederherstellen würde? Gibt es eine Möglichkeit, zuerst in einer Teilmenge der Regionen zu deployen? Die Error-Budget-Richtlinie existiert genau für diese Situation — ohne sie würden wir von Fall zu Fall verhandeln, was das gesamte SLO-Framework untergräbt. Aber ich wäre auch flexibel: Wenn das Feature umsatzkritisch ist und die SLO-Verletzung geringfügig, könnte die Führungsebene das Risiko bei voller Transparenz über den Kompromiss akzeptieren [2]."

2. Die Änderung eines Junior-Ingenieurs hat einen Produktionsausfall verursacht. Wie gehen Sie mit der Nachbetrachtung um?

Expertenantwort: „Das Grundprinzip ist Schuldlosigkeit — die Nachbetrachtung untersucht, was passiert ist und warum das System es zugelassen hat, niemals wer schuld ist [2]. Ich würde die Nachbetrachtung leiten, indem ich die zeitlichen Fakten festhalte: Welche Änderung wurde vorgenommen, wann, was war die unmittelbare Auswirkung, wann wurde sie erkannt, wie wurde sie behoben? Dann würde ich mich auf systemische Ursachen konzentrieren: Warum hat der Change-Management-Prozess eine unsichere Änderung zugelassen? Gab es unzureichende Code-Reviews, fehlende automatisierte Tests, unzureichendes Canary-Deployment oder mangelnde Rollback-Fähigkeit? Die Maßnahmen sollten das System verbessern, nicht den Ingenieur bestrafen: automatisierte Validierung hinzufügen, die den Fehler erkannt hätte, die Staging-Umgebungsparität verbessern, damit das Problem vor der Produktion aufgefallen wäre, Monitoring hinzufügen, das den Fehlermodus schneller erkennt. Ich würde ausdrücklich im Nachbetrachtungsdokument festhalten: ‚Der Ingenieur hat den dokumentierten Prozess befolgt. Der Prozess war unzureichend, und diese Verbesserungen werden ein Wiederauftreten verhindern.' Eine schuldzuweisende Kultur treibt Ingenieure dazu, Fehler zu verbergen; eine schuldfreie Kultur treibt Ingenieure dazu, sie zu melden und zu beheben."

3. Sie übernehmen ein Legacy-System ohne Monitoring, ohne Dokumentation und ohne Tests. Wo beginnen Sie?

Expertenantwort: „Ich würde nach Blast Radius priorisieren. Woche 1: Grundlegendes Gesundheitsmonitoring hinzufügen — reagiert der Dienst? Wie hoch ist die Fehlerrate? Wie hoch ist die Ressourcenauslastung? Ich würde einen Prometheus-Exporter für Systemmetriken deployen und die Einstiegspunkte für Request-Level-Metriken instrumentieren. Das gibt mir Sichtbarkeit, bevor ich etwas anfasse. Woche 2–4: Die Systemarchitektur dokumentieren, indem ich den Code lese, Anfrageflüsse nachverfolge und Abhängigkeiten kartiere. Ich würde einen Abhängigkeitsgraphen erstellen, der zeigt, womit das System kommuniziert und was mit ihm kommuniziert. Monat 2: Integrationstests für den kritischen Pfad hinzufügen — die eine User Journey, die, wenn sie kaputt ist, einen Alarm auslösen würde. Das gibt mir ein Sicherheitsnetz für künftige Änderungen. Monat 3: CI/CD implementieren, damit Änderungen automatisierte Tests und gestaffeltes Deployment durchlaufen statt manuelles SSH-and-Deploy. Durchgehend würde ich Toil verfolgen: Welche manuellen Operationen erfordert dieses System? Das fließt in die Priorisierung der Automatisierungsarbeit ein. Das Schlüsselprinzip ist: Nicht umschreiben, stabilisieren. Ein Legacy-System, das seit Jahren läuft, hat unzählige Edge Cases überstanden — es zu ersetzen bringt neue Risiken mit sich."

4. Ihr Monitoring zeigt ein langsames Speicherleck in der Produktion. Der Dienst stürzt ab und startet alle 72 Stunden neu. Wie gehen Sie vor?

Expertenantwort: „Zunächst würde ich die Auswirkung quantifizieren: Verursachen die Neustarts für Nutzer sichtbare Fehler? Wenn der Neustart graceful ist (Verbindungen werden abgebaut, der Load Balancer markiert die Instanz als unhealthy vor dem Absturz), könnten die unmittelbaren Nutzerauswirkungen minimal sein. Wenn er ungraceful ist (OOM-Kill, abgebrochene Verbindungen), ist es ein P2, der umgehende Aufmerksamkeit erfordert. Für die Untersuchung: Ich würde Heap-Profiling aktivieren (pprof für Go, JVisualVM für Java, memory_profiler für Python) auf einer Produktionsinstanz mit reduziertem Verkehr. Ich würde Heap-Snapshots in regelmäßigen Abständen (stündlich) erstellen und Objektanzahlen und -größen vergleichen, um zu identifizieren, welche Objekttypen wachsen. Häufige Ursachen: Caching ohne Eviction, Goroutine/Thread-Leaks, Connection-Pool-Erschöpfung ohne ordnungsgemäßes Cleanup oder Event-Listener-Akkumulation. Für die kurzfristige Abhilfe würde ich einen CronJob oder eine Liveness Probe einrichten, der den Dienst alle 48 Stunden während verkehrsarmer Zeiten graceful neustartet — um Zeit zu gewinnen, während die Grundursache untersucht wird. Für die langfristige Lösung würde ich, sobald der leckende Objekttyp identifiziert ist, die Grundursache beheben, einen Speichernutzungs-SLI zu unserem Monitoring hinzufügen und einen Alert erstellen, wenn die Speicherwachstumsrate die historischen Normen übersteigt."

5. Die Geschäftsleitung bittet Sie, die Infrastrukturkosten um 30 % zu senken und dabei das aktuelle Zuverlässigkeitsniveau beizubehalten. Wie gehen Sie vor?

Expertenantwort: „Ich würde Kostensenkungsmöglichkeiten in vier Kategorien identifizieren. Richtige Dimensionierung: Instanztypen anhand der tatsächlichen Auslastung prüfen — meiner Erfahrung nach sind 40–60 % der Cloud-Instanzen überdimensioniert. Cloud-Anbieter-Empfehlungen nutzen (AWS Compute Optimizer, GCP Recommender) und mit tatsächlichen CPU-/Speicherauslastungsdaten validieren. Reservierte Kapazität: vorhersagbare Basis-Workloads von On-Demand auf Reserved Instances oder Savings Plans umstellen (typischerweise 30–50 % Einsparung). Spot/Preemptible Instances: fehlertolerante Workloads identifizieren (Batch-Verarbeitung, CI/CD-Runner, zustandslose Worker), die Unterbrechungen tolerieren können, und sie auf Spot-Preise umstellen (60–90 % Einsparung). Architekturoptimierung: Verschwendung identifizieren und eliminieren — ungenutzte Ressourcen, überreplizierte Daten, teures Logging, das niemand liest, und Entwicklungsumgebungen, die 24/7 laufen und nachts und am Wochenende heruntergefahren werden könnten. Ich würde jede Initiative mit prognostizierten Einsparungen, Implementierungsaufwand und Zuverlässigkeitsrisiko präsentieren. Die Einschränkung ist klar: Zuverlässigkeit ist nicht verhandelbar. Kostensenkung kommt durch Effizienz, nicht durch den Abbau von Redundanz oder die Verschlechterung der Dienstqualität."

Fragen an den Interviewer

1. Welche SLOs gelten für die Dienste, die dieses Team verantwortet, und wie werden Error Budgets verwaltet? Zeigt, ob das Team SRE-Prinzipien praktiziert oder nur den Titel verwendet.

2. Wie sieht die Bereitschaftsrotation aus — wie viele Ingenieure, wie hoch ist das Alert-Volumen, und wie lautet die Eskalationsrichtlinie? Wirkt sich direkt auf Ihre Lebensqualität aus und zeigt die operationale Gesundheit des Teams.

3. Wie gleicht das Team Projektarbeit (Zuverlässigkeitsverbesserungen) mit operativer Arbeit (Incident Response, Toil) aus? Zeigt, ob das Team Kapazität für Engineering-Arbeit hat oder im Feuerlöschmodus feststeckt.

4. Wie sieht die Beziehung des Teams zu Entwicklungsteams aus — ist SRE eingebettet oder zentralisiert? Bestimmt Ihr tägliches Zusammenarbeitsmodell und Ihren Einfluss.

5. Wie ist der Ansatz des Teams bei Nachbetrachtungen — sind sie schuldfrei, und welcher Prozentsatz der Maßnahmen wird umgesetzt? Zeigt die Lernkultur des Teams bei Vorfällen — ein Team, das Nachbetrachtungen schreibt, aber nie Maßnahmen umsetzt, hat ein Kulturproblem.

6. Welche Infrastruktur und welche Tools verwaltet das Team — Cloud-Anbieter, Container-Orchestrierung, Observability-Stack? Praktische Frage zur technischen Umgebung.

7. Was sind die größten Zuverlässigkeitsherausforderungen, vor denen das Team derzeit steht? Gibt Einblick in die Probleme, die Sie lösen würden, und ob sie interessant sind.

Format des Vorstellungsgesprächs und was Sie erwartet

SRE-Vorstellungsgespräche bei großen Technologieunternehmen erstrecken sich typischerweise über 4–6 Stunden im gesamten Interviewprozess [3]. Die Programmierrunde testet die Beherrschung von Python/Go/Java mit Problemen, die sich auf Automatisierung, Datenverarbeitung oder System-Tooling konzentrieren — erwarten Sie Aufgaben wie „Schreiben Sie einen Log-Parser, der Fehlermuster identifiziert" statt reines LeetCode. Die Systemdesign-Runde verlangt, dass Sie verteilte Systeme mit expliziten Zuverlässigkeitsanforderungen entwerfen — „Entwerfen Sie einen URL-Shortener, der 99,99 % der Anfragen innerhalb von 100 ms bedient." Die Fehlerbehebungsrunde präsentiert ein Produktionsszenario (Dienstverschlechterung, kaskadierende Ausfälle, mysteriöse Alerts) und bewertet Ihre diagnostische Methodik. Die Verhaltensrunde bewertet Bereitschaftserfahrung, Incident-Management, teamübergreifende Zusammenarbeit und Toil-Reduktion. Einige Unternehmen fügen eine Linux/Netzwerk-Grundlagenrunde hinzu, die Themen wie Prozessverwaltung, Dateisystemoperationen, TCP/IP und DNS-Auflösung abdeckt. Der gesamte Prozess vom Recruiter-Screening bis zum Angebot dauert typischerweise 3–6 Wochen.

Vorbereitung

• Studieren Sie das Google SRE-Buch. Kapitel über SLOs, Error Budgets, Toil und Incident-Management sind grundlegend und werden in Vorstellungsgesprächen häufig referenziert [2].
• Üben Sie Systemdesign mit Zuverlässigkeitsanforderungen. Entwerfen Sie Systeme mit expliziten Verfügbarkeitszielen, Fehlermodi und Strategien für graceful Degradation.
• Bereiten Sie Incident-Geschichten vor. Halten Sie 3–5 detaillierte Vorfallsberichte bereit mit Ihrer Rolle, Zeitablauf, Grundursache, Lösung und systemischen Verbesserungen.
• Wiederholen Sie Linux-Grundlagen. Prozessverwaltung, Dateisystemoperationen, Netzwerkbefehle (ss, tcpdump, dig, traceroute) und System-Performance-Tools (top, vmstat, iostat, sar).
• Üben Sie Programmierung für Automatisierung. Schreiben Sie Skripte, die Logs parsen, mit APIs interagieren, Infrastrukturzustand verwalten und Fehlerfälle graceful behandeln.
• Kennen Sie Ihren Observability-Stack. Seien Sie bereit, Prometheus, Grafana, Jaeger/Tempo, ELK/Loki, PagerDuty zu besprechen und wie Sie sie in der Produktion eingesetzt haben.

Häufige Fehler im Vorstellungsgespräch

1. Für Skalierung entwerfen, ohne für Ausfälle zu entwerfen. SRE-Vorstellungsgespräche testen speziell, wie Ihr System mit Ausfällen umgeht — ein System zu beschreiben, das „davon ausgeht, dass alles funktioniert", ist ein Warnsignal [2].
2. Zuverlässigkeit nicht quantifizieren. „Das System sollte hochverfügbar sein" zu sagen statt „Das System sollte ein SLO von 99,95 % Verfügbarkeit erreichen, gemessen an der erfolgreichen Anfragerate", zeigt, dass Sie SRE-Prinzipien nicht verinnerlicht haben.
3. Vorfälle als rein technische Probleme behandeln. Kommunikation, Koordination und Nachbetrachtungsprozesse bei Vorfallsgeschichten nicht zu besprechen, deutet auf mangelnde Incident-Management-Erfahrung hin.
4. Toil ignorieren. SRE-Vorstellungsgespräche fragen häufig nach Toil-Reduktion. Keine Beispiele für manuelle operative Arbeit zu haben, die Sie automatisiert haben, ist eine Lücke.
5. Lösungen überentwickeln. Five-Nines-Architektur für einen nicht-kritischen Dienst vorzuschlagen, zeigt mangelndes Urteilsvermögen. SRE dreht sich um angemessene Zuverlässigkeit, nicht maximale Zuverlässigkeit [2].
6. Das Error-Budget-Modell nicht verstehen. Wenn Sie nicht erklären können, wie Error Budgets Alignment zwischen SRE- und Produktteams schaffen, haben Sie das SRE-Framework nicht studiert.
7. Programmierfähigkeit nicht demonstrieren. SREs sind Ingenieure, keine Operatoren. Bei einer Programmieraufgabe zu scheitern, signalisiert, dass Sie möglicherweise nicht in der Lage sind, die Automatisierung und das Tooling zu entwickeln, die die Rolle definieren [3].

Wichtigste Erkenntnisse

• SRE-Vorstellungsgespräche testen eine spezifische Engineering-Denkweise: Zuverlässigkeit quantifizieren, datengesteuerte Kompromisse eingehen und Betrieb als Software-Engineering-Probleme behandeln.
• SLOs, SLIs, Error Budgets und Toil sind das Vokabular von SRE — verwenden Sie sie fließend und demonstrieren Sie praktische Erfahrung mit jedem Konzept.
• Bereiten Sie detaillierte Vorfallsgeschichten vor, die Ihre diagnostische Methodik, Kommunikationsfähigkeiten und Ihr Denken in systemischen Verbesserungen zeigen.
• Systemdesign-Antworten müssen explizite Fehlermodi, Strategien für graceful Degradation und Verfügbarkeitsziele beinhalten.

Möchten Sie sicherstellen, dass Ihr Lebenslauf Sie zum Vorstellungsgespräch bringt? Probieren Sie den kostenlosen ATS-Score-Checker von ResumeGeni aus, um Ihren Site Reliability Engineer-Lebenslauf vor der Bewerbung zu optimieren.

FAQ

Was ist der Unterschied zwischen SRE und DevOps?

SRE ist eine spezifische Implementierung von DevOps-Prinzipien mit verbindlichen Praktiken: SLOs, Error Budgets, Toil Budgets und ein definiertes Engagement-Modell mit Entwicklungsteams. DevOps ist eine breitere kulturelle Bewegung, die die Zusammenarbeit zwischen Entwicklung und Betrieb betont. SRE liefert das konkrete Framework — SLOs, Error Budgets und die 50-%-Engineering-Zeit-Regel —, das DevOps-Prinzipien umsetzbar macht. Viele Unternehmen verwenden die Begriffe austauschbar, aber in Vorstellungsgesprächen bei Unternehmen, die SRE formell praktizieren (Google, LinkedIn, Dropbox), ist die Unterscheidung wichtig [2].

Welche Programmiersprachen sollte ich für SRE-Vorstellungsgespräche beherrschen?

Python und Go sind die am häufigsten verwendeten Sprachen in der SRE-Praxis. Python für Scripting, Automatisierung und operatives Tooling. Go für leistungskritisches System-Tooling (viele Tools im Kubernetes-Ökosystem, Prometheus und interne Infrastrukturtools sind in Go geschrieben). Einige Unternehmen verwenden Java oder Ruby. Sie sollten mindestens eine kompilierte Sprache und eine Skriptsprache beherrschen [3].

Welches Gehalt kann ich als Site Reliability Engineer erwarten?

Die Gehälter reichen von 128.842 US-Dollar (PayScale-Durchschnitt) bis 169.680 US-Dollar (Glassdoor-Durchschnitt), wobei das 75. Perzentil bei 213.272 US-Dollar liegt [1]. Senior SREs bei FAANG-Unternehmen können 300.000–500.000+ US-Dollar einschließlich Aktienvergütung verdienen. Die Vergütung variiert je nach Unternehmensstufe, Standort und Spezialisierung. SRE bietet typischerweise einen Aufschlag von 10–20 % gegenüber allgemeinen Software-Engineering-Rollen im selben Unternehmen.

Wie wichtig ist das Google SRE-Buch für die Vorbereitung auf Vorstellungsgespräche?

Sehr wichtig. Das Google SRE-Buch („Site Reliability Engineering: How Google Runs Production Systems") definiert die Konzepte, die die meisten SRE-Vorstellungsgespräche testen: SLOs, Error Budgets, Toil, Incident-Management und das SRE-Engagement-Modell [2]. Selbst wenn Sie sich bei einem Unternehmen bewerben, das nicht genau Googles Praktiken folgt, liefert das Buch das Vokabular und die Frameworks, die Interviewer verwenden.

Brauche ich Bereitschaftserfahrung, um eine SRE-Stelle zu bekommen?

Bereitschaftserfahrung wird stark bevorzugt, ist aber nicht immer erforderlich für SRE-Einstiegspositionen. Wenn Sie keine formelle Bereitschaftserfahrung haben, demonstrieren Sie gleichwertige Fähigkeiten: Monitoring-Systeme, die Sie aufgebaut haben, Vorfälle, auf die Sie reagiert haben (auch in Staging- oder Entwicklungsumgebungen), und Automatisierung, die Sie erstellt haben, um manuelle Operationen zu reduzieren. Zeigen Sie, dass Sie die operationale Realität des Betriebs von Produktionssystemen verstehen.

Welche Zertifizierungen sind nützlich für SRE-Vorstellungsgespräche?

Google Cloud Professional Cloud DevOps Engineer, AWS DevOps Engineer Professional und Certified Kubernetes Administrator (CKA) sind die relevantesten Zertifizierungen. Allerdings gewichten SRE-Vorstellungsgespräche bei Spitzenunternehmen praktische Erfahrung und Problemlösungsfähigkeit weit mehr als Zertifizierungen. Zertifizierungen können Ihnen helfen, das Lebenslauf-Screening zu bestehen, aber sie werden Sie nicht durch ein technisches Vorstellungsgespräch tragen.

Wie unterscheidet sich ein SRE-Vorstellungsgespräch von einem Software-Engineering-Vorstellungsgespräch?

SRE-Vorstellungsgespräche beinhalten Systemdesign mit expliziten Zuverlässigkeitsanforderungen (SLOs, Fehlermodi, graceful Degradation), Fehlerbehebungsrunden (Diagnose von Produktionsszenarien) und Verhaltensfragen zu Incident-Management und Bereitschaftserfahrung. Software-Engineering-Vorstellungsgespräche konzentrieren sich stärker auf algorithmische Programmierung, anwendungsebenes Systemdesign und Produktdenken. SRE-Programmieraufgaben sind tendenziell praxisnäher und automatisierungsorientierter als reine Algorithmusaufgaben [3].

Quellen: [1] Glassdoor, "Site Reliability Engineer: Average Salary & Pay Trends 2026," https://www.glassdoor.com/Salaries/site-reliability-engineer-salary-SRCH_KO0,25.htm [2] Google, "Site Reliability Engineering: How Google Runs Production Systems," https://sre.google/sre-book/table-of-contents/ [3] InterviewBit, "SRE (Site Reliability Engineer) Interview Questions (2025)," https://www.interviewbit.com/sre-interview-questions/ [4] Exponent, "Site Reliability Engineer Interview Questions Explained (Updated 2026)," https://www.tryexponent.com/questions?role=sre [5] Wiz, "Site Reliability Engineer Interview Questions Explained," https://www.wiz.io/academy/cloud-careers/site-reliability-engineer-interview-questions [6] NovelVista, "50 Site Reliability Engineer (SRE) Interview Questions 2026," https://www.novelvista.com/blogs/devops/top-sre-interview-question-answer [7] MindMajix, "Top 50 Site Reliability Engineer (SRE) Interview Questions 2025," https://mindmajix.com/sre-interview-questions [8] Coursera, "Site Reliability Engineer Salary Guide 2026," https://www.coursera.org/articles/site-reliability-engineer-salary