Alert Fatigue und die Disziplin des Cockpit-Funks

Als Flugschüler flog ich einmal zum ersten Mal einen stark frequentierten Class-B-Flughafen an. Der Funk war für mich kaum verständlich. Lotsen sprachen schnell, Piloten antworteten in Kurzform, Funksprüche überlappten. Mein Fluglehrer ließ mich einen Anflug lang schwimmen und sagte dann etwas, das ich nie vergessen habe: „Erst zuhören, dann senden. Sagen, was wichtig ist. Aufhören, wenn man fertig ist.“

Foto von Tom Fisk auf Pexels

Monitoring-Systeme nutzen keine 121,5 MHz, erzeugen aber dasselbe kognitive Wetter, wenn niemand Disziplin einfordert. Pages um drei Uhr morgens. Slack-Kanäle, die nie zur Ruhe kommen. Dashboards, auf denen jedes Panel rot ist, weil der Grenzwert falsch gewählt wurde. Menschen im Bereitschaftsdienst, die Benachrichtigungen stummschalten — nicht aus Faulheit, sondern weil das Signal vor Jahren im Rauschen untergegangen ist.

Ich habe kein perfektes Alerting-Setup. Ich werde keinen Anbieter und keine Universalschablone verkaufen. Was ich anbieten kann, ist ein Vergleich, der mir beim Ausdünnen von Rauschen hilft: Alert Fatigue entsteht, wenn Monitoring sich wie eine überfüllte Frequenz ohne Funkdisziplin verhält.

Eine Frequenz ohne Regeln

Luftfahrtfunk funktioniert, weil die Regeln eng gefasst sind und ständig wiederholt werden:

• Wen man ruft — „Boston Approach, Cessna 123AB“
• Was man braucht — „requesting vectors ILS 4R“
• Wesentliche Readbacks — Höhen, Kurse, Freigaben
• Stille beim Zuhören — man sendet nicht in andere Funksprüche hinein

Wer diese Regeln bricht, wird blockiert, korrigiert oder ignoriert. Das System rechnet mit Überlastung und ist auf Klarheit unter Druck ausgelegt.

Monitoring-Stacks machen oft das Gegenteil:

• Alerts feuern ohne klare Zuständigkeit („irgendwas im Cluster“)
• Dieselbe Bedingung alarmiert fünf Kanäle, weil drei Teams dieselbe Prometheus-Regel kopiert haben
• Warning und Critical unterscheiden sich nur im Emoji
• Auto-Resolve fehlt, alte Feuer glimmen in der Oberfläche weiter
• Jeder Deploy erzeugt einen kurzen CPU-Ausschlag, der drei Leute weckt

Die Person im Bereitschaftsdienst wird zum Lotsen, der Verkehr trennen soll, obwohl die Hälfte der Funksprüche kein Rufzeichen hat. Lotsen werden dafür ausgebildet. Wir bekommen einen PagerDuty-Plan und Hoffnung.

Ich gebe den Tools nicht die Schuld. Ich habe alle falsch konfiguriert. Das Disziplin-Problem ist menschlich und organisatorisch, bevor es technisch ist.

Warnung oder Notfall: nicht jeder Ausschlag ist Mayday

Beim Fliegen hat Dringlichkeit ein Vokabular. Pan-Pan steht für dringend, aber nicht unmittelbar lebensbedrohlich. Mayday steht für akute Gefahr. Lotsen reagieren unterschiedlich; Piloten sagen nicht Mayday wegen eines rau laufenden Magnetchecks am Boden.

In Ops glätten wir Schweregrade oft so lange, bis alles CRITICAL ist oder gar nichts mehr:

Luftfahrt-Gewohnheit	Monitoring-Äquivalent
Mayday	Kundensichtbarer Ausfall, laufender Datenverlust, aktiver Sicherheitsbruch
Pan-Pan	Eingeschränkt, aber liefernd; SLO-Burn; eine AZ verloren, Failover läuft
Routine call	Ticket am nächsten Werktag; Kapazität entwickelt sich in zwei Wochen kritisch
Guard-Frequency-Gerede	Log-Rauschen; Debug-Ereignisse ohne Handlungsbedarf

Wenn die Plattform für Pan-Pan und Guard-Gerede den Bereitschaftsdienst weckt, ist Ermüdung kein Rätsel. Sie ist das Ergebnis der Regeln.

In einem Job haben wir ein Jahr damit verbracht, Alerts langsam neu einzustufen. Langweilige Arbeit. Die Regel war: Wenn die empfangende Person innerhalb von fünf Minuten keine konkrete erste Handlung ableiten kann, ist es keine Page. Es kann immer noch ein Ticket sein, eine Dashboard-Annotation oder eine tägliche Zusammenfassung. Es sollte nur kein Telefon vibrieren.

Kubernetes macht das schwerer, weil dasselbe Symptom Verschiedenes bedeuten kann. CrashLoopBackOff auf einem Batch-Worker nachts ist vielleicht ein CronJob mit schlechten Eingabedaten. Beim Payment-Service ist es Mayday. Kontext gehört in den Alert — Namespace, Workload, Runbook-Link — wie ein Rufzeichen. „CrashLoopBackOff“ allein ist „Flugzeug in Not irgendwo in New England.“

Erst zuhören, dann senden

Der Satz meines Fluglehrers heißt im Monitoring: beobachten, bevor man alarmiert.

Gute Lotsen bauen sich ein Lagebild, bevor sie Vektoren geben. Gute Alerting-Pipelines fragen: Stimmt das noch? Ist es neu? Arbeitet schon jemand daran?

Praktiken, die unser Rauschen reduzierten, ohne echte Feuer zu verstecken:

Gruppierung und Inhibition. Wenn mehrere Pods während eines Node-Drains an derselben Probe scheitern, sollte nicht pro Pod eine Page kommen. Ein Alert, Node-Name im Label, Inhibition solange die Drain-Annotation vorhanden ist. Beim ersten Versuch haben wir echte Node-Ausfälle übersehen; das Nachjustieren dauerte Wochen.

Rate Limits und Deduplizierung. Derselbe Alert, der eine Stunde lang jede Minute feuert, sollte nicht jede Minute neu benachrichtigen, außer die Schwere steigt. PagerDuty und Alertmanager unterstützen das; trotzdem finden wir immer wieder Routen, die daran vorbeilaufen.

SLO-basiertes Pagen. Burn-Rate-Alerts auf das Error Budget — wecken, wenn das Kundenerlebnis bedroht ist, nicht wenn eine Replica kurz stolpert. Ich implementiere SLOs nicht perfekt. Selbst ein grober SLI ist besser als eine Page bei CPU > 80 %, nur weil jemand 2019 einen Datadog-Monitor kopiert hat.

Deploy-Fenster. Bekannte harmlose Ausschläge während eines Rollouts unterdrücken, aber mit harter Obergrenze: Dauert die Unterdrückung länger als N Minuten, wird eskaliert. Wie Wartung auf ATIS anzukündigen, damit Approach nicht jeden Go-Around als Notfall behandelt.

Erst zuhören heißt auch: Der Bereitschaftsdienst liest den Raum — bestehender Störungskanal, kürzliche Deploys, Statusseite schon rot. Noch eine Sirene hilft niemandem, wenn der War Room bereits voll ist.

Sagen, was zählt, dann aufhören

Kurze Funksprüche sind keine Unhöflichkeit; sie sind Respekt vor geteilter Aufmerksamkeit. Alert-Text sollte enthalten:

• Service / Nutzerwirkung — „checkout API 5xx rate 12 % (baseline 0,1 %)“
• Umfang — Cluster, Region, Namespace, Deployment
• Vorgeschlagene erste Prüfung — Link zum Runbook-Abschnitt oder ein kubectl-Befehl, keine Wiki-Startseite
• Zuständigkeit — Team oder Eskalationsrichtlinie

Aufhören heißt: keine siebzehn Graphen an die Page hängen. Nicht sechs Slack-Kanäle „zur Sichtbarkeit“ erwähnen. Keine Alert-Ketten bauen, die sich nur durch das wiederholte Wort „critical“ unterscheiden.

Ich schreibe Runbook-Links in Annotations, wo es geht. Wenn ich müde Bereitschaft habe, ist „siehe Runbook“ ohne URL das Monitoring-Äquivalent zu „contact approach“ ohne Frequenz.

Bei Kubernetes-nativen Alerts liegt der Unterschied zwischen nützlich und nutzlos oft in den Labels:

# Alert annotation that actually helps at 2 a.m.
annotations:
  summary: "High 5xx on ingress nginx in prod-eu"
  runbook_url: "https://wiki.example/runbooks/ingress-5xx#tls-expiry"
  dashboard: "https://grafana.example/d/ingress-eu"

Die Query zählt ebenfalls. rate(http_requests_total{status=~"5.."}[5m]) ohne job- oder ingress-Label ist ein Mayday-Ruf ohne Positionsmeldung.

Readbacks: den Kreis schließen

Lotsen verlangen Readbacks bei kritischen Punkten, damit alle dieselbe Realität teilen. Alerts ohne Abschluss trainieren Menschen darauf, den nächsten zu ignorieren.

Wir haben — unvollkommen — versucht, Störungsnotizen für jede Page zu verlangen, selbst wenn die Notiz nur „false positive, threshold adjusted“ lautet. Höchstens fünf Sätze. Was feuerte, was wir geprüft haben, was wir geändert haben. Ohne das weckt derselbe False Positive jeden Dienstag jemanden, bis eine Person das Team verlässt und Wissen verdampft.

Bei False Positives lautet der Readback konkret: Alert innerhalb von 48 Stunden korrigieren oder herabstufen. Nicht „acknowledgen und für immer stummschalten“. Die Luftfahrt würde rebellieren, wenn derselbe falsche NOTAM täglich auftauchte. Im Monitoring haben wir so etwas jahrelang normalisiert.

Wenn eine Page echt ist, aber schnell erledigt wird, zählt der Abschluss trotzdem: Postmortem optional bei Kleinkram, aber ein Slack-Thread-Tag #alert-tuning hilft der nächsten Person. Ich mag keinen Prozess um des Prozesses willen. Dieser hat uns doppelte Pages erspart, weil drei Menschen unabhängig dieselbe Regel „repariert“ hatten.

Der Mute-Button ist kein CRM

Piloten schalten den Funk nicht aus, nur weil Approach viel redet. Sie wechseln die Frequenz, bitten um ruhigere Vektoren oder werden in weniger belasteten Luftraum geführt. Stummschalten ist der letzte Ausweg.

Wenn Ingenieure Slack oder PagerDuty Mobile stummschalten, liest Management das manchmal als mangelndes Engagement. Oft ist es rationale Anpassung an ein feindliches Signal-Rausch-Verhältnis. Das zu beheben ist Führungs- und Werkzeugaufgabe, keine Predigt über Verantwortung.

Was Muting auf Teams, in denen ich war, wirklich reduzierte:

• Zusage der Führung, dass Bereitschaft schlafen darf, wenn die zweite Stufe bei echten Criticals weckt
• Vierteljährliche Alert-Audits mit Löschrechten — heilige Kühe werden entfernt oder korrigiert
• Rotierende „Noise Duty“ — eine Person pro Sprint triagiert feuernde, aber nicht pagende Alerts
• Work Queues von Wake Queues trennen — E-Mail-Digest statt SMS

CRM im Cockpit heißt: sprechen, wenn etwas zählt, und still sein, wenn nicht. Derselbe Vertrag gilt für Alerts: psychologische Sicherheit, sagen zu dürfen „diese Page ist wertlos“, ohne als unkollegial abgestempelt zu werden.

Plattformmuster, die die Frequenz respektieren

Ein paar Kubernetes-spezifische Muster, auf die wir uns gestützt haben:

PDB-Verletzungen bei freiwilligen Disruptions — oft Warnung im Chat, keine Page, wenn die Disruption annotiert ist und SLOs halten.

Pending Pods — pagen, wenn pending > N Minuten und der Workload nutzerseitig ist und kein bekanntes Quota-Problem vorliegt. Nur Pending ist allein zu gesprächig.

Node NotReady — Plattform-Bereitschaft mit Node-Name pagen; Crash-Loop-Folgealerts auf dieser Node inhibieren, um Alert-Bursts zu vermeiden.

Zertifikatsablauf — Pan-Pan bei 14 Tagen, Mayday bei 72 Stunden, wenn Auto-Renew fehlschlug. Ein Alert pro Zertifikatsquelle, nicht pro Secret-Duplikat.

HPA am Maximum — Trend-Ticket, außer Latenz oder Fehler überschreiten die Kundenschwelle. Max Replicas ist oft ein Kapazitätsplanungssignal, kein Notfall.

Die eigene Flotte wird anders aussehen. Die Gewohnheit ist, vor dem Merge der Regel zu fragen: „Welche Handlung verlangt diese Page?“

Wie gut klingt

Ruhige Bereitschaft heißt nicht, dass nie etwas kaputtgeht. Es heißt: Wenn das Telefon klingelt, vertraut das Team darauf, dass Aufwachen sinnvoll ist.

Gute Wochen klingen wie:

• Ein oder zwei Pages, beide handlungsrelevant
• False Positives werden Tickets, nicht Schulterzucken
• Deploy-bezogene Ausschläge bleiben im Deploy-Channel
• Störungen erzeugen Alert-Follow-ups in derselben Woche

Schlechte Wochen klingen wie:

• „Hat sonst noch jemand eine Page bekommen?“-Threads um vier Uhr morgens
• Bereitschaft beendet die Schicht mit zwanzig Acks und null Ursachenbehebungen
• Neue Leute hören: „Die kannst du ignorieren“

Ich habe beides erlebt. Der Ausweg war nie eine einzelne Werkzeugmigration. Es war langsame Funkdisziplin: weniger Stimmen, klarere Rufzeichen, passende Dringlichkeit, Readbacks.

Was ich noch lerne

Ich erstelle noch Alerts ohne den Fünf-Minuten-Handlungstest. Ich kopiere noch YAML aus alten Repos und vergesse die Runbook-URL. Ich diskutiere noch, ob Burn-Rate-Pages für unser Lastprofil zu langsam sind.

Alert Fatigue ist kein moralisches Versagen von Menschen im Bereitschaftsdienst. Sie ist Feedback, dass das System auf sich selbst sendet. Die Luftfahrt hat das mit Verfahren und Kultur gelöst, lange bevor bessere Funkgeräte existierten. Den Kulturteil kann man übernehmen, ohne so zu tun, als säße man im Cockpit.

Erst zuhören, dann senden. Sagen, was zählt. Aufhören, wenn man fertig ist. Die Guard-Frequenz aufräumen, damit das nächste Mayday schnell beantwortet wird.

Das ist die ganze Disziplin. Der Rest ist Tuning und Demut.