Interviewfrage für Site Reliability Engineer

Was ist ein Error Budget, und was sollte ein Team tatsächlich tun, wenn es aufgebraucht ist?

Worauf der Interviewer abzielt, wie du deine Antwort aufbaust und ein gesprochenes Beispiel zum Anpassen.

Kurzantwort

Ein Error Budget ist die Unzuverlässigkeit, die dein SLO erlaubt. Bei einem SLO von 99,9% über 28 Tage sind das 0,1% der Requests, also grob 40 Minuten Gesamtausfall. Teams geben es für riskante Launches, Migrationen und Experimente aus. Ist es aufgebraucht, friert die schriftliche Policy üblicherweise Feature-Releases ein und lenkt das Team auf Zuverlässigkeitsarbeit um, bis sich das Budget im rollierenden Fenster erholt.

Warum Interviewer das fragen

Das trennt Leute, die das SRE-Buch gelesen haben, von Leuten, die es gelebt haben. Der Interviewer prüft, ob du das Budget als Entscheidungswerkzeug mit einer Policy dahinter behandelst und nicht als Dashboard, das keiner liest. Er will außerdem hören, wie du die politische Seite handhabst, denn ein Release-Freeze funktioniert nur, wenn die Führung vorher zugestimmt hat und der Ausnahmeweg definiert ist.

So baust du deine Antwort auf

  • Leite das Budget rechnerisch aus dem SLO ab, damit es konkret wird.
  • Sag, was das Budget verbraucht: Launches, Incidents, Migrationen, Dependencies.
  • Beschreib die schriftliche Policy, die bei null greift.
  • Erwähn Burn-Rate-Alerts als Frühwarnung, nicht als Postmortem.
  • Nenn den Ausnahmeweg und wer ihn freigibt.

Beispielantwort

Gesprochenes Beispiel, erste Person

Das Budget ist einfach die Umkehrung des SLO. Bei 99,9% über 28 Tage hatten wir rund 40 Minuten Vollausfall-Äquivalent zu verteilen, und wir haben es bewusst für Dinge wie eine Datenbankmigration oder ein riskantes Rollout ausgegeben. Der wichtige Teil ist die Policy, nicht die Zahl. Unsere sagte: Verbrennen wir mitten im Fenster mehr als die Hälfte, werden Canaries langsamer und jede Änderung braucht einen zweiten Reviewer, und bei null stoppen Feature-Releases und das Team arbeitet an Zuverlässigkeit, bis das rollierende Fenster geheilt ist. Das war vom Product Director abgezeichnet, bevor wir es je gebraucht haben, und nur deshalb hat es beim ersten Einsatz gehalten. Wir hatten außerdem Multi-Window-Burn-Rate-Alerts, einen schnellen für 14x Burn über eine Stunde und einen langsamen für 6x über sechs Stunden, damit wir es während des Incidents mitbekommen und nicht am Monatsende.

Steht dieses Vorstellungsgespräch bald an? GhostPilot hört bei deinem Live-Call mit, erkennt die Frage in dem Moment, in dem sie gestellt wird, und bringt dir eine strukturierte Antwort in Echtzeit auf den Bildschirm. Probier es im nächsten Mock aus, oder hol dir einen $29 Session Pass, kein Abo, für den Ernstfall.

So funktioniert es

Nachfragen, mit denen du rechnen solltest

  • Wer darf einen Release-Freeze übersteuern, und was kostet das das Team?
  • Wie würdest du Multi-Window-Burn-Rate-Alerts auf einem 28-Tage-SLO konfigurieren?
  • Was, wenn das Budget von einem Cloud-Provider-Ausfall zerstört wird, den du nicht kontrollierst?

Weitere Fragen für Site Reliability Engineer

Dein Interviewer stellt seine eigene Version davon. Kopier deine echte Stellenbeschreibung in den kostenlosen Question Predictor und bekomm die 20 Fragen, die diese Rolle am wahrscheinlichsten stellt, samt dem, worauf jede wirklich abzielt.

Meine Fragen vorhersagen

Üb die harten Fragen, bevor sie gestellt werden

Trainier mit einem Live-Copiloten und geh dann vorbereitet rein. Ein $29 Session Pass bringt dich durch das Vorstellungsgespräch, ohne Abo und ohne Bindung.

GhostPilot holen