Junior Site Reliability Engineer: Die ultimative Interview-Fragen-Anleitung

Milad Bonakdar
Autor
Meistern Sie die Grundlagen von SRE mit umfassenden Interviewfragen zu Monitoring, Incident Response, SLOs, Automatisierung, Linux-Fehlerbehebung und Zuverlässigkeitspraktiken für Junior SRE-Positionen.
Einführung
Site Reliability Engineering (SRE) kombiniert Softwareentwicklung und Systemadministration, um umfangreiche, zuverlässige Systeme zu erstellen und zu betreiben. Als Junior SRE konzentrierst du dich auf Überwachung, Reaktion auf Vorfälle, Automatisierung und das Erlernen von Zuverlässigkeitspraktiken, die dafür sorgen, dass Dienste reibungslos laufen.
Dieser Leitfaden behandelt wichtige Fragen für Vorstellungsgespräche für Junior SREs, die nach Themen geordnet sind, um dir bei der effektiven Vorbereitung zu helfen. Jede Frage enthält detaillierte Antworten, praktische Beispiele und Hands-on-Szenarien.
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):


