Bildquelle: extern
Der Bereitschaftsdienst soll kritische Störungen schnell erkennen. Er verliert genau diese Stärke, wenn jedes kleine Signal denselben Druck erzeugt.
Alarmflut bedeutet nicht einfach, dass zu viele Meldungen auflaufen. Das eigentliche Problem entsteht, wenn der Betrieb nicht mehr sauber unterscheiden kann, welcher Alarm sofortige Hilfe braucht, welcher nur beobachtet werden muss und welcher aus einer bekannten Nebensache stammt. Für ITSM-Generalisten ist das ein Führungsthema im Betrieb. Es geht um Servicewirkung, Prioritäten, Zuständigkeiten und die Frage, ob Menschen nachts noch gute Entscheidungen treffen können.
Monitoring ist die technische Beobachtung von Systemen, Diensten und Nutzerpfaden. Alerting ist der Teil, der aus einer Beobachtung eine aktive Meldung macht. Ein Alarm ist deshalb kein Messwert, sondern eine Aufforderung zum Handeln. Genau diese Schwelle muss gut gesetzt sein. Wer zu spät alarmiert, übersieht Ausfälle. Wer zu früh und zu oft alarmiert, stumpft die Bereitschaft ab.
Ein Alarm braucht eine klare Handlung
Ein guter Alarm beantwortet eine einfache Frage: Was soll jetzt passieren? Wenn die Antwort unklar bleibt, ist der Alarm vermutlich noch keine Bereitschaftsmeldung. Dann handelt es sich eher um ein Signal für ein Dashboard, einen Tagescheck oder eine spätere Analyse. Diese Unterscheidung wirkt klein, entscheidet aber über die Belastung im Betrieb.
Google beschreibt in seinem SRE-Buch Monitoring unter anderem mit der Leitfrage, ob eine Meldung für Menschen eine unmittelbare Aktion auslösen soll. Atlassian und PagerDuty ordnen Alert Fatigue als Risiko ein, bei dem zu viele oder schlecht priorisierte Meldungen die Reaktionsfähigkeit senken. IBM beschreibt Incident Management als Prozess, der Auswirkungen begrenzen und Services wiederherstellen soll. Zusammengenommen ergibt sich eine praktische Regel: Nur Meldungen mit echter Servicewirkung und klarer Sofortentscheidung gehören in den Bereitschaftskanal.
Das bedeutet nicht, dass alle anderen Signale unwichtig sind. Sie brauchen nur einen anderen Ort. Kapazitätstrends, langsame Verschlechterungen, seltene Fehler und Warnungen ohne Nutzerwirkung können sehr wertvoll sein. Sie gehören aber oft in Review-Routinen, Problem Management oder Kapazitätsplanung, nicht in den nächtlichen Alarmton.
Dringlichkeit entsteht durch Wirkung, nicht durch Lautstärke
In vielen Umgebungen wächst die Alarmflut schleichend. Ein Team ergänzt eine Warnung nach einem Vorfall. Ein anderes Team setzt vorsichtshalber einen Schwellwert niedriger. Ein Lieferant bringt eigene Meldungen mit. Ein neues System wird angeschlossen, ohne alte Regeln zu bereinigen. Nach einigen Monaten klingt alles dringend, obwohl nur ein Teil wirklich einen betroffenen Service erklärt.
Die bessere Sortierung beginnt bei der Servicewirkung. Ist ein geschäftskritischer Dienst betroffen? Merken Nutzer bereits eine Einschränkung? Gibt es einen klaren Zeitdruck, weil sonst Daten verloren gehen, Sicherheit gefährdet ist oder eine zentrale Frist gerissen wird? Gibt es eine bekannte Umgehung? Solche Fragen machen aus technischen Meldungen betriebliche Prioritäten.
Eine CPU-Warnung kann harmlos sein, wenn sie kurz auftritt und keinen Dienst beeinträchtigt. Dieselbe technische Kennzahl kann kritisch werden, wenn sie einen zentralen Nutzerpfad blockiert. Umgekehrt kann ein einzelner fehlgeschlagener Check wichtig sein, wenn er den einzigen Eingang für Kunden oder Mitarbeitende betrifft. Die Priorität entsteht also nicht allein aus dem Messwert, sondern aus dem Zusammenhang.
Bereitschaft darf kein Sammelkorb sein
Der Bereitschaftskanal ist eine knappe Ressource. Er bündelt Aufmerksamkeit, Schlafunterbrechung, Entscheidungskraft und Verantwortung. Deshalb darf er nicht als Sammelkorb für alles dienen, was irgendein Tool auffällig findet. Jede Meldung im Bereitschaftskanal sollte begründen können, warum sie Menschen außerhalb der normalen Arbeitszeit stören darf.
Hilfreich ist eine einfache Klassifizierung. Sofortalarme brauchen unmittelbare Reaktion, weil ein Dienst ausfällt, ein kritischer Nutzerpfad gestört ist oder ein Sicherheitsrisiko aktiv wird. Zeitnahe Alarme brauchen Bearbeitung im nächsten Betriebsfenster, weil sich ein Risiko aufbaut. Beobachtungssignale bleiben sichtbar, erzeugen aber keinen Weckruf. Informationsmeldungen landen nur in Protokollen oder Tagesberichten.
Diese Klassifizierung muss öffentlich sein. Service Owner, Plattformteams, Service Desk und Management sollten dieselbe Sprache verwenden. Sonst eskaliert jede Gruppe nach eigener Wahrnehmung. Ein klarer Bereitschaftsstandard schützt nicht nur die Menschen im Dienst, sondern auch die Erwartung der Fachbereiche.
Jede Meldung braucht Besitzer und Runbook in Alltagssprache
Ein Alarm ohne Besitzer erzeugt Sucharbeit. Ein Alarm ohne verständlichen Ablaufplan erzeugt Unsicherheit. Beides verlängert die Reaktionszeit. Für jeden Bereitschaftsalarm sollte deshalb klar sein, wer zuerst reagiert, welche Prüfung als erstes erfolgt, welche Eskalation gilt und wann der Service Desk informiert wird.
Der Ablaufplan muss nicht kompliziert sein. Wichtig ist, dass er unter Druck funktioniert. Er sollte den betroffenen Service nennen, die wahrscheinlichsten Ursachen eingrenzen, sichere Erstmaßnahmen beschreiben und eine Grenze setzen, ab der eskaliert wird. Fachbegriffe dürfen vorkommen, aber die erste Orientierung muss auch für jemanden möglich sein, der den Dienst nicht täglich betreut.
Wenn ein Alarm regelmäßig ohne Handlung geschlossen wird, ist das ein Qualitätsproblem. Dann stimmt entweder der Schwellwert nicht, die Meldung ist am falschen Ort oder der Ablaufplan fehlt. Solche Alarme gehören in eine regelmäßige Bereinigung. Sonst trainiert der Betrieb genau das falsche Verhalten: wegklicken, warten, ignorieren.
Der Service Desk braucht die gleiche Sicht
Alarmierung ist nicht nur Sache der Technikteams. Sobald Nutzer betroffen sind, wird der Service Desk zur Übersetzungsstelle. Er muss wissen, ob ein Problem bekannt ist, welche Dienste betroffen sind, welche Erstinformation kommuniziert werden kann und wann ein Update folgt. Ohne diese Verbindung entsteht ein zweiter Stresskanal: Nutzer fragen nach, während die Bereitschaft noch versucht, den Alarm einzuordnen.
Darum sollte jeder kritische Alarm eine Kommunikationsnotiz auslösen oder zumindest vorbereiten. Diese Notiz muss nicht lang sein. Sie sollte sagen, was beobachtet wird, welche Nutzergruppen wahrscheinlich betroffen sind, ob bereits eine Umgehung bekannt ist und wann die nächste Aktualisierung kommt. So wird aus einem technischen Signal schneller eine steuerbare Serviceinformation.
Alarmqualität gehört in die Nachbereitung
Nach einer Störung wird oft über Ursache, Behebung und Kommunikation gesprochen. Die Qualität der Alarmierung gehört genauso in diese Nachbereitung. Kam der erste brauchbare Hinweis früh genug? Waren zu viele Nebensignale im Weg? Wurde die richtige Person geweckt? War die erste Maßnahme klar? Hat der Service Desk rechtzeitig eine verständliche Information bekommen?
Diese Fragen machen Bereitschaftsdienste besser. Ein einzelner schlechter Alarm ist kein Weltuntergang. Ein schlechter Alarm, der monatelang unverändert bleibt, wird zum Betriebsrisiko. Gute Teams behandeln Alarmregeln deshalb wie Servicebestandteile. Sie werden gepflegt, versioniert, nach Vorfällen überprüft und bei Änderungen am Dienst angepasst.
Weniger Alarm kann mehr Sicherheit bedeuten
Es klingt zunächst riskant, Alarme zu reduzieren. Tatsächlich kann genau das die Sicherheit erhöhen, wenn die verbleibenden Meldungen klarer, handlungsnäher und besser priorisiert sind. Bereitschaft lebt nicht von maximaler Lautstärke, sondern von Vertrauen. Wer geweckt wird, muss davon ausgehen können, dass eine relevante Entscheidung ansteht.
Der praktische Einstieg ist überschaubar. Die letzten 20 Bereitschaftsalarme werden geprüft. Welche führten zu echter Handlung? Welche wurden nur bestätigt? Welche kamen mehrfach aus derselben Ursache? Welche hatten keinen Besitzer? Aus dieser Auswertung entsteht eine kurze Liste: sofort behalten, Schwellwert ändern, in Tagescheck verschieben, Ablaufplan ergänzen oder löschen.
So wird Alarmierung wieder zu dem, was sie sein soll: ein zuverlässiger Weg vom Serviceproblem zur passenden Reaktion. Nicht jeder Messwert verdient einen Weckruf. Aber jeder Weckruf verdient eine klare Entscheidung.
Quellen und Einordnung: Google SRE Book zu Monitoring, Atlassian zu Alert Fatigue im Bereitschaftsbetrieb, PagerDuty zu Alert Fatigue, IBM Übersicht zu Incident Management. Stand der Quellenprüfung 22.06.2026. Der Beitrag enthält keine Preise, Gebühren oder Leistungssätze.
