Alarmmüdigkeit ist ein Designproblem, kein Disziplinproblem
Von Das Atflow-Team
Jedes Team, das seit mehr als einem Jahr einen Bereitschaftsdienst betreibt, kennt denselben Kanal: mit guten Absichten angelegt, von der Hälfte der Ingenieure stummgeschaltet und erst geprüft, nachdem jemand in einem anderen Kanal »Ist Prod down?« gefragt hat. Die übliche Diagnose lautet, dass es den Leuten an Disziplin fehlt. Diese Diagnose ist falsch, und sie führt zu Lösungen, die alles nur schlimmer machen.
Ein Alarm ist ein Anspruch auf Ihre Aufmerksamkeit
Jede Benachrichtigung behauptet, dass ein Mensch aufhören sollte, was er gerade tut. Wenn sich die meisten davon als nicht berechtigt herausstellen, lernen die Leute — zu Recht —, dass es sich nicht lohnt, den Kanal zu unterbrechen. Stummschalten ist eine rationale Reaktion auf einen Kanal, der gelogen hat.
Die drei Dinge, die das wirklich beheben
- Gleiche Fehler gruppieren. Dreihundert Auftreten eines Bugs sind ein Problem und sollten eine Nachricht sein.
- Nach Konsequenz weiterleiten, nicht nach Schweregrad-Label. Eine abgelehnte Karte mailt den Kunden; ein fehlgeschlagener Schreibvorgang alarmiert den Bereitschaftsdienst.
- Bekannt laute Berichte einen leiseren Pfad nehmen lassen, statt das Alarmieren ganz abzuschalten.
- Pro Incident einmal eskalieren, nicht einmal pro Ereignis.
“Wenn Ihr Alarmkanal stummgeschaltet ist, ist der Kanal kaputt. Die Leute verhalten sich vernünftig.”
Alle drei sind Weiterleitungsentscheidungen, und deshalb gehören sie in einen Flow, den man sehen und ändern kann, statt verstreut in if-Anweisungen in vier Diensten zu liegen.