Ein SLI ist eine Messung der Nutzererfahrung, etwa der Anteil der Requests, die erfolgreich und unter dreihundert Millisekunden beantwortet werden. Ein SLO ist das Ziel für diese Messung über ein Zeitfenster, sagen wir 99,9 Prozent über achtundzwanzig Tage. Das Error Budget ist der Rest, 99,9 Prozent lassen also rund dreiundvierzig Minuten Ausfall pro Monat. Ist das Budget gesund, shippst du schneller. Ist es aufgebraucht, hat Reliability-Arbeit Vorrang.
Warum Interviewer das fragen
Diese Frage prüft, ob du Zuverlässigkeit mit Geschäftsentscheidungen verbinden kannst, statt Uptime um ihrer selbst willen zu jagen. Der Interviewer will sehen, dass du Indikatoren aus Nutzersicht wählst, dass du weißt, dass hundert Prozent das falsche Ziel sind, und idealerweise, dass du Burn-Rate-Alerting beschreiben kannst statt bei jeder einzelnen Schwellenverletzung zu paging.
So baust du deine Antwort auf
- Definiere die drei Begriffe sauber mit einer konkreten Zahl.
- Erklär, warum das Budget den Tradeoff explizit macht.
- Beschreib, wie das Budget das Teamverhalten praktisch verändert.
- Erwähn Burn-Rate-Alerting statt roher Schwellenwert-Alerts.
Beispielantwort
Der Indikator ist das, was du von der Nutzerseite misst, bei einer API also meist der Anteil der Requests, die sowohl erfolgreich als auch schnell genug sind. Das Objective ist das Ziel über ein rollierendes Fenster, und das Budget ist der Rest. Drei Neunen über achtundzwanzig Tage sind rund dreiundvierzig Minuten Schlechtigkeit, die du ausgeben darfst, und es als Budget zu framen ist der ganze Witz, denn damit wird aus Zuverlässigkeit statt einer Diskussion eine Rechnung. Haben wir diesen Monat fünf Prozent des Budgets ausgegeben, shippen wir Features und gehen vernünftige Risiken ein. Haben wir bis zum Zehnten achtzig Prozent verbrannt, ist der nächste Sprint Reliability-Arbeit und riskante Launches warten. Fürs Alerting nutze ich Multi-Window-Burn-Rates statt sofort zu pagen, wenn die Quote absackt. Ein schneller Burn, der das Budget in einer Stunde aufbrauchen würde, pagt sofort, ein langsamer erzeugt ein Ticket. Das hat den Großteil unseres Nachtlärms gekillt. Der schwerste Teil ist ehrlicherweise die Wahl des Indikators, denn ein Ziel auf etwas, das Nutzer nicht spüren, ist Theater.
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 esNachfragen, mit denen du rechnen solltest
- Wie wählst du einen SLI für eine asynchrone Batch-Pipeline?
- Was machst du, wenn der Ausfall einer Dependency dein Budget verbrennt?
- Wie setzt du das erste Objective, wenn du keine historischen Daten hast?
Weitere Fragen für DevOps 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