Alert Fatigue (Alarmmüdigkeit) bezeichnet die Abstumpfung, die entsteht, wenn On-Call-Engineers mehr Alerts erhalten, als sie sinnvoll bearbeiten können. Sind die meisten Benachrichtigungen verrauscht, doppelt oder nicht handlungsrelevant, werden sie ignoriert, stummgeschaltet oder pauschal quittiert. Echte Incidents fallen dadurch später auf und die Reaktionszeiten steigen.
Was Alert Fatigue bedeutet
Alert Fatigue, auf Deutsch auch Alarmmüdigkeit, beschreibt, was mit Menschen und Teams passiert, wenn die Zahl der Alerts ihre Kapazität zum Handeln übersteigt. Der Begriff stammt aus der Medizin: Pflegekräfte, die ständig Monitoralarme hören, blenden diese irgendwann aus. Im IT-Betrieb funktioniert der Mechanismus genauso. Wenn sich neun von zehn Pages als harmlos herausstellen, lernt das Team, dass auch die zehnte vermutlich harmlos ist. Alerts werden quittiert, ohne sie zu prüfen, Mute-Regeln entstehen, oder niemand schaut mehr in den Alert-Kanal.
Tückisch ist, dass Alarmmüdigkeit von außen kaum auffällt. Die Dashboards sind grün, für alles gibt es eine Alert-Regel, das Team wirkt gut abgesichert. Die Kosten zeigen sich erst im echten Incident: Das kritische Signal kam rechtzeitig, aber niemand hat reagiert, und die Mean Time to Resolve wächst weit über das hinaus, was die Tools eigentlich ermöglichen.
Typische Ursachen
- Ursachen- statt symptombasierte Alerts. Pages auf hohe CPU-Last, eine volle Disk-Queue oder einen einzelnen fehlgeschlagenen Pod erzeugen viele Alerts, die Nutzer gar nicht betreffen.
- Statische Schwellenwerte. Ein fester Grenzwert wie „Latenz über 300 ms“ feuert jeden Montagmorgen zur Lastspitze und bleibt bei einer schleichenden Verschlechterung nachts stumm. Der Vergleich mit einer gelernten Baseline ist meist präziser.
- Duplikate und Alert-Stürme. Eine ausgefallene Datenbank löst Alerts in jedem abhängigen Service aus, jeweils in eigenen Kanälen.
- Flapping. Metriken, die um einen Schwellenwert pendeln, feuern und lösen sich ständig neu, weil Auswertungsfenster oder Hysterese fehlen.
- Kein Owner, keine Aktion. Alerts ohne Verantwortliche oder ohne dokumentierte Reaktion sammeln sich über Jahre an und werden nie aufgeräumt.
Warum das Thema wichtig ist
Alarmmüdigkeit schadet Zuverlässigkeit und Menschen gleichzeitig. Verpasste oder verspätete Pages verlängern Ausfälle und verbrauchen Error Budgets. Unterbrochene Nächte und ständige Kontextwechsel führen zu Burnout und Fluktuation in der Rufbereitschaft, und damit verliert das Team genau die erfahrenen Engineers, die es im Incident braucht.
Messbar wird das Problem mit wenigen Kennzahlen pro Rotation: Pages pro Schicht, Pages außerhalb der Arbeitszeit, der Anteil der Pages, die ohne weitere Aktion quittiert wurden, und die mittlere Zeit bis zur Quittierung. Steigt die Zeit bis zur Quittierung gleichzeitig mit dem Page-Volumen, setzt mit hoher Wahrscheinlichkeit Alarmmüdigkeit ein. Zudem leidet das Vertrauen: Wer das Alerting für unzuverlässig hält, investiert nicht mehr hinein, und das Verhältnis von Signal zu Rauschen verschlechtert sich weiter.
Beispiel: von Ursachen-Alerts zu Burn-Rate-Alerts
Nehmen wir einen beispielhaften Checkout-Service mit einem SLO von 99,9 % Verfügbarkeit über 30 Tage. Ursprünglich gab es eigene Pages für CPU über 85 %, eine Fehlerrate über 1 % in einer Minute und jeden Pod-Neustart. Ein verbreiteter Ersatz, beschrieben im Google SRE Workbook, ist Multi-Window-, Multi-Burn-Rate-Alerting auf das Error Budget:
| Dringlichkeit | Burn Rate | Langes Fenster | Kurzes Fenster |
|---|---|---|---|
| Page | 14,4x | 1 Stunde | 5 Minuten |
| Page | 6x | 6 Stunden | 30 Minuten |
| Ticket | 1x | 3 Tage | 6 Stunden |
Eine Burn Rate von 14,4 über eine Stunde verbraucht etwa 2 % eines 30-Tage-Budgets. Beide Fenster müssen den Schwellenwert überschreiten: Der Alert feuert bei echten Problemen schnell und löst sich ebenso schnell auf, sobald sie vorbei sind. CPU und Neustarts werden zu Dashboard-Signalen und Diagnosekontext statt zu Pages.
Best Practices gegen Alarmmüdigkeit
- Auf Symptome alarmieren, die Nutzer spüren: Fehler, Latenz, Sättigung nutzerrelevanter Kapazität, idealerweise als SLO-Burn-Rate.
- Jede Page muss handlungsrelevant sein. Jeder Alert verweist auf ein Runbook und hat einen klaren Owner. Gibt es nichts zu tun, sollte er nicht pagen.
- Dringlichkeitsstufen trennen. Pages für sofortiges Handeln, Tickets für Arbeit, die bis zur Kernarbeitszeit warten kann, Dashboards für alles andere.
- Zusammengehörige Alerts gruppieren und deduplizieren, mithilfe der Topologie lässt sich nachgelagertes Rauschen unterdrücken.
- Alerts regelmäßig überprüfen. Messen Sie Pages pro Schicht und den Anteil, der zu einer Aktion führte, und löschen oder entschärfen Sie Regeln, die das nie tun.
Häufige Fehler
Viele Teams reagieren auf einen verpassten Incident mit einem weiteren Alert und erhöhen so das Rauschen. Andere senken nach jedem Ausfall die Schwellenwerte „zur Sicherheit“. Ein dritter Fehler ist es, alles in einen gemeinsamen Kanal zu routen, in dem sich niemand persönlich zuständig fühlt. Jede dieser Maßnahmen wirkt einzeln vernünftig und verstärkt in Summe die Alarmmüdigkeit.
Wie Obseria unterstützt
Obseria unterstützt SLOs und Burn-Rate-Alerting ohne Zusatzaufwand, und die Anomalie-Erkennung lernt Baselines, statt sich auf statische Schwellenwerte zu verlassen. Obseria TopoGraph kennt die Abhängigkeiten zwischen Services, sodass das Incident Management zusammengehörige Alerts zu einem Problem bündelt. Obseria Intelligence liefert dazu eine Beweiskette zur wahrscheinlichen Ursache.
