Junior SRE Interviewfragen mit Antworten

Milad Bonakdar
Autor
Bereite dich auf Junior-SRE-Interviews mit praktischen Fragen zu SLOs, Error Budgets, Alerting, Incidents, Linux-Troubleshooting, Automatisierung und Kubernetes vor.
Worauf Junior-SRE-Interviews achten
Junior-SRE-Interviews prüfen meist, ob du von Nutzerimpact zu Systemsignalen denken kannst: SLOs, Error Budgets, Alerting, Incidents, Linux-Signale, Automatisierung, Container und grundlegende Kubernetes-Abläufe. Du musst nicht wie ein Principal Engineer klingen. Wichtig ist, dass du strukturiert untersuchst, während eines Incidents klar kommunizierst und repetitive operative Arbeit sicher reduzierst.
Nutze diese Fragen, um kurze Antworten zu üben, und verbinde jede Antwort mit einem Beispiel aus Projekten, Labs, Praktika oder On-Call-Shadowing.
SRE-Grundlagen
1. Was ist Site Reliability Engineering und wie unterscheidet es sich von DevOps?
Antwort: SRE ist Googles Ansatz, Produktionssysteme zuverlässig und in großem Umfang zu betreiben.
Hauptprinzipien:
- Behandlung des Betriebs als Softwareproblem
- Maximal 50 % der Zeit für operative Tätigkeiten (Toil)
- Fehlerbudgets zum Ausgleich von Zuverlässigkeit und Geschwindigkeit
- Fehlerfreie Postmortems
- Stufenweise Rollouts und automatisierte Rollbacks
SRE vs. DevOps:
SRE implementiert DevOps-Prinzipien mit spezifischen Praktiken und Metriken.
Seltenheit: Sehr häufig Schwierigkeit: Leicht
2. Erkläre SLIs, SLOs und Fehlerbudgets.
Antwort: Dies sind zentrale SRE-Konzepte zur Messung und zum Management der Zuverlässigkeit:
SLI (Service Level Indicator):
- Quantitative Messung des Servicelevels
- Beispiele: Latenz, Verfügbarkeit, Fehlerrate
SLO (Service Level Objective):
- Zielwert für einen SLI
- Beispiel: "99,9 % der Anfragen sind erfolgreich"
Fehlerbudget:
- Zulässige Fehlerrate (100 % - SLO)
- Wird verwendet, um Zuverlässigkeit und Feature-Geschwindigkeit auszugleichen
Seltenheit: Sehr häufig Schwierigkeit: Mittel
3. Was ist Toil und wie reduzierst du es?
Antwort: Toil ist repetitive, manuelle operative Arbeit, die:
- Manuell ist (erfordert menschliches Handeln)
- Repetitiv ist
- Automatisiert werden kann
- Keinen bleibenden Wert hat
- Linear mit dem Service-Wachstum wächst
Beispiele für Toil:
- Manuelles Neustarten von Diensten
- Kopieren von Dateien zwischen Servern
- Manuelles Skalieren von Ressourcen
- Wiederholte Ticketantworten
Strategien zur Toil-Reduzierung:
SRE-Ziel: Toil unter 50 % der Zeit halten, den Rest automatisieren.
Seltenheit: Sehr häufig Schwierigkeit: Leicht-Mittel
Überwachung und Observability
4. Was ist der Unterschied zwischen Monitoring und Observability?
Antwort: Monitoring: Sammeln vordefinierter Metriken und Warnungen
- Known-Unknowns: Du weißt, worauf du achten musst
- Dashboards, Warnungen, Metriken
- Beispiele: CPU, Speicher, Anfragerate
Observability: Verstehen des Systemzustands anhand von Ausgaben
- Unknown-Unknowns: Debuggen von Problemen, die du nicht erwartet hast
- Protokolle, Metriken, Traces kombiniert
- Kann beliebige Fragen beantworten
Drei Säulen der Observability:
- Metriken: Aggregierte Zahlen (CPU, Latenz)
- Protokolle: Diskrete Ereignisse
- Traces: Anfragefluss durch das System
Beispiel: Prometheus + Grafana + Loki
Seltenheit: Häufig Schwierigkeit: Mittel
5. Wie richtest du effektive Warnungen ein?
Antwort: Gute Warnungen sind umsetzbar, aussagekräftig und verursachen keine Ermüdung.
Best Practices für Warnungen:
1. Warne bei Symptomen, nicht bei Ursachen:
2. Füge Runbook-Links hinzu:
3. Verwende geeignete Schweregrade:
4. Vermeide Alarmmüdigkeit:
- Verwende
for:, um Flattern zu vermeiden - Gruppiere verwandte Warnungen
- Lege geeignete Schwellenwerte fest
- Überprüfe und optimiere regelmäßig
Seltenheit: Sehr häufig Schwierigkeit: Mittel
Reaktion auf Vorfälle
6. Beschreibe deinen Prozess zur Reaktion auf Vorfälle.
Antwort: Eine strukturierte Reaktion auf Vorfälle minimiert die Auswirkungen und die Wiederherstellungszeit:
Schritte zur Reaktion auf Vorfälle:
1. Erkennung:
- Warnung wird ausgelöst oder Benutzer meldet ein Problem
- Warnung bestätigen
- Vorfall-Kanal erstellen
2. Triage:
3. Entschärfung:
4. Behebung:
- Behebung der Ursache
- Überprüfen, ob die Metriken wieder normal sind
- Überwachen auf Wiederauftreten
5. Postmortem (Blameless):
Seltenheit: Sehr häufig Schwierigkeit: Mittel
7. Wie behebst du Probleme mit einem Dienst, der eine hohe Latenz aufweist?
Antwort: Systematischer Debugging-Ansatz:
Häufige Ursachen:
- Langsame Datenbankabfragen
- Externe API-Timeouts
- Speicherdruck (GC-Pausen)
- Netzwerkprobleme
- Ressourcenerschöpfung
- Ineffiziente Codepfade
Seltenheit: Sehr häufig Schwierigkeit: Mittel
Automatisierung und Skripterstellung
8. Schreibe ein Skript, um zu überprüfen, ob ein Dienst fehlerfrei ist, und ihn bei Bedarf neu zu starten.
Antwort: Skript zur Überprüfung des Zustands und zur automatischen Behebung:
Seltenheit: Häufig Schwierigkeit: Mittel
Zuverlässigkeitspraktiken
9. Was ist ein Runbook und warum ist es wichtig?
Antwort: Ein Runbook ist eine dokumentierte Vorgehensweise für die Handhabung operativer Aufgaben und Vorfälle.
Runbook-Struktur:
2. Engpass identifizieren
- Datenbankabfragezeit überprüfen
- Externe API-Aufrufe überprüfen
- Cache-Trefferrate überprüfen
- Letzte Bereitstellungen überprüfen
3. Abhängigkeiten überprüfen
Maßnahmen zur Entschärfung
Schnelle Korrekturen (< 5 Minuten)
- Anwendungsserver hochskalieren
- Cache-TTL vorübergehend erhöhen
Wenn das Problem weiterhin besteht
- Letzte Bereitstellung zurücksetzen
- Ratenbegrenzung aktivieren
Behebung
- Ursache beheben (langsame Abfrage, ineffizienter Code)
- Korrektur bereitstellen
- 30 Minuten lang überwachen
- Zurückskalieren auf normale Kapazität
Eskalation
Wenn die Behebung nicht innerhalb von 30 Minuten möglich ist:
- Eskalieren an: @backend-team
- Slack-Kanal: #incidents
- Bereitschaftsdienst: PagerDuty-Eskalationsrichtlinie verwenden
Verwandte Themen
2. Circuit Breaker:
3. Timeouts und Wiederholungen:
Seltenheit: Häufig Schwierigkeit: Mittel
Containerisierungsgrundlagen
11. Was ist Docker und wie unterscheidet es sich von virtuellen Maschinen?
Antwort: Docker ist eine Containerisierungsplattform, die Anwendungen mit ihren Abhängigkeiten verpackt.
Container vs. Virtuelle Maschinen:
Hauptunterschiede:
Docker-Grundlagen:
Dockerfile-Beispiel:
Erstellen und Ausführen:
Docker Compose (Multi-Container):
Mit Docker Compose ausführen:
Best Practices:
- Offizielle Basis-Images verwenden
- Anzahl der Ebenen minimieren
- Nicht als Root ausführen
- .dockerignore verwenden
- Images ordnungsgemäß taggen
- Auf Schwachstellen scannen
Seltenheit: Sehr häufig Schwierigkeit: Leicht-Mittel
Versionskontrolle und Bereitstellung
12. Erkläre Git-Workflows und wie du Bereitstellungen handhabst.
Antwort: Git ist unerlässlich für die Versionskontrolle und die Automatisierung der Bereitstellung.
Häufiger Git-Workflow:
Grundlegende Git-Befehle:
Branching-Strategie:
1. Gitflow:
main: Produktionsreifer Codedevelop: Integrations-Branchfeature/*: Neue Funktionenrelease/*: Vorbereitung der Versionhotfix/*: Notfallbehebungen
2. Trunk-Based Development:
Bereitstellungs-Workflow:
1. CI/CD-Pipeline (GitHub Actions):
Fazit
Bereite dich auf ein Junior-SRE-Interview vor, indem du SLOs, Alerting, Incident Response, Linux-Troubleshooting und sichere Automatisierung praktisch übst. Gute Antworten erklären nicht nur Befehle, sondern auch Priorisierung: erst Nutzerimpact verstehen, dann Signale prüfen, dann risikoarm mitigieren und danach sauber nachbereiten.


