Ein guter Page ist dringend, handlungsfähig und an Nutzerauswirkung gebunden, mit einem Runbook-Link dran. Alles andere gehört in ein Ticket oder auf ein Dashboard. Zum Aufräumen ziehst du einen Monat Pages, zählst sie pro Alert und löschst oder degradierst alles, was routinemäßig quittiert wird, ohne dass jemand handelt. Ersetz ursachenbasierte Alerts durch symptombasierte SLO-Burn-Rate-Alerts und setz ein Page-Budget pro Schicht.
Warum Interviewer das fragen
Alert Fatigue ist ein echtes Zuverlässigkeitsrisiko, denn eine Rufbereitschaft, die vierzigmal pro Woche pagt, trainiert Leute darauf, den einen zu ignorieren, der zählt. Interviewer wollen einen datengetriebenen Aufräumprozess, die Unterscheidung Symptom gegen Ursache und Belege, dass du Alerts tatsächlich löschst statt weitere hinzuzufügen. Eine Ziel-Page-Rate zu nennen zeigt, dass du eine Rotation verantwortet hast.
So baust du deine Antwort auf
- Nenn die drei Tests, die ein Page bestehen muss: dringend, handlungsfähig, nutzerrelevant.
- Zieh die Daten: Pages pro Alert, pro Schicht und die ergriffene Maßnahme.
- Lösch oder degradier die Alerts, die nie zu einer Handlung führen.
- Wechsel von ursachenbasierten Alerts zu SLO-Burn-Rate-Alerts.
- Setz ein Page-Budget und behandle ein Überschreiten als Bug.
Beispielantwort
Mein Test ist simpel: Braucht es jetzt sofort einen Menschen, kann dieser Mensch etwas dagegen tun, und kümmert es einen User. Ist eins davon nein, ist es ein Ticket oder ein Graph, kein Page. Fürs Aufräumen starte ich immer bei den Daten, ich exportiere also einen Monat Pages gruppiert nach Alert-Regel und ergänze eine Spalte, was der Responder tatsächlich getan hat. Beim letzten Mal machten vier Regeln über 70% der Pages aus, und jede einzelne wurde mit quittieren und nichts tun abgeschlossen. Die wurden gelöscht, nicht getunt. Danach habe ich eine Wand ursachenbasierter Regeln wie Disk bei 80% und Pod neu gestartet durch Burn-Rate-Alerts auf dem SLO ersetzt, sodass wir pagen, wenn Usern in einem Tempo geschadet wird, das das Error Budget aufbraucht, und die Ursachen tauchen während der Untersuchung auf den Dashboards auf. Wir haben ein Ziel von weniger als zwei Pages pro Schicht gesetzt und eine Überschreitung als Defekt mit Ticket behandelt, was es ehrlich gehalten hat.
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ürdest du schnelle und langsame Burn-Rate-Alerts zusammen aufbauen?
- Was machst du mit einem Alert, der laut ist, aber gelegentlich echt?
- Wie gehst du mit einem Team um, das sich weigert, seine Alerts zu löschen?
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