Der erste Artikel dieser Serie hat erläutert, warum sich die meisten IT-Ops-Teams bei der Alarmierung eher für die vorsichtige Variante entscheiden. Mit anderen Worten: Sie optimieren ihr Monitoring so, dass die Anzahl von Fehlern des Typs II möglichst gering ist, erhöhen dadurch jedoch die Anzahl der auftretenden Typ-I-Fehler.

Dass diese Vorsicht einen Preis hat, erwähnt der Artikel ebenfalls: Wenn man zehntausende Warnmeldungen sichten und eine große Mehrheit als bedeutungslos verwerfen muss, hat das Auswirkungen auf die direkten Kosten. Schließlich resultiert dieser Vorgang in Hunderten von Arbeitsstunden hoch qualifizierter – und daher teurer – Spezialisten.

Das Beispiel eines tribe29 Kunden eignet sich besonders gut zur Veranschaulichung: Das IT-Ops-Team erhielt vor seinem Wechsel zu Checkmk von seinem alten Monitoring-System zwischen 8.000 und 10.000 Warnmeldungen im Monat – die meisten davon waren Fehlalarme.

In den Gesprächen mit besagten Teammitgliedern war die schiere Arbeitsbelastung nur eines der genannten Probleme. Sie umschrieben den Prozess für die Überprüfung der Alarme mit Worten wie „hirnverbrannt“, „verkorkst“, „zeitraubend“ oder „völlig sinnlos“.

Risiko einer akuten Alarmmüdigkeit

Damit wird schnell klar, worum es im Kern geht. Das gesamte IT-Ops-Team litt unter einer akuten Alarmmüdigkeit (Alert Fatigue). Alarmmüdigkeit beschreibt ein Phänomen, bei dem Arbeitnehmer gegenüber Sicherheitswarnungen desensibilisiert werden und in der Folge solche Warnungen ignorieren oder nicht angemessen darauf reagieren. Bekannt ist dieser Effekt beispielsweise aus dem Gesundheitswesen, dem Baugewerbe, dem Bergbau oder – was besonders beunruhigend ist – aus Kernkraftwerken. Aber auch in IT-Abteilungen, im Netzwerkbetrieb und in SOCs (Security Operations Center) auf der ganzen Welt kommt es immer wieder zu dieser Müdigkeit.

Die Auswirkungen auf IT-Ops-Teams sind gravierend: Wenn sie den Großteil der Zeit damit verbringen, (wahrscheinlich bedeutungslose) Alarme zu verifizieren, verbringen die Teams die Zeit mit weniger interessanten Dingen, als sie eigentlich möchten. Auf Dauer kann dies ihre Moral zermürben und dazu führen, dass Mitarbeiter sich nach neuen Herausforderungen umsehen und das Unternehmen verlassen. Dadurch stehen dem Unternehmen weniger Mitarbeiter zur Verfügung und es muss letztendlich viel Zeit und Geld aufwenden, um Ersatz zu finden und/oder auszubilden.

Darüber hinaus entstehen hohe Gelegenheitskosten: Ist das IT-Ops-Team mit dem Alarmierungsprozess überfordert und von der Flut an Benachrichtigungen ausgelaugt, ist es nicht in der Lage, die IT-Infrastruktur und -Plattformen zu erneuern und zu verbessern. Das Team ist damit beschäftigt, auf (wiederum: wahrscheinlich bedeutungslose) Warnmeldungen zu reagieren, statt sich um die Weiterentwicklung von Systemen und Automatisierungsprozessen für die Infrastruktur zu kümmern oder aktiv Ursachen für mögliche Probleme anzugehen. Dies führt über kurz oder lang zu technischen Schulden, da Probleme nie mit dauerhaften Lösungen angegangen werden.

Die Alternative ist jedoch nicht besser: Sie besteht darin, Warnmeldungen gänzlich auszuschalten oder gar zu ignorieren. Auch wenn jeder weiß, dass man das nicht tun sollte, ist das immer wieder der Fall.

Fehlalarme in der Nacht

Ein System-Administrator in Bereitschaft erhält nachts einen Alarm. Wenn er davon aufwacht, weiß er bereits, dass es sich mit 80 prozentiger Wahrscheinlichkeit um einen Fehlalarm handelt. Was würden Sie tun?

Die Reaktion ist nur natürlich. In einer Untersuchung des IT-Sicherheitsunternehmens Critical Start gaben fast 40 Prozent der befragten IT-Ops-Experten zu, bestimmte Kategorien von Warnmeldungen zu ignorieren. So viel zum Thema Vermeidung von falsch-negativen Benachrichtigungen, oder?

Aber ist auf der anderen Seite eine Quote von 80 Prozent falscher Alarme nicht etwas zu hoch gegriffen? In der gleichen Studie sagte fast die Hälfte aller Befragten, dass die Rate der Fehlalarme bei über 50 Prozent liegt. Kein Wunder also, dass die Leute abschalten. Einige Kunden bestätigen uns in ihren Erzählungen ebenfalls diese sehr hohen Fehlalarm-Raten.

Doch was ist jetzt die Lösung? Die Antwort liefert wieder das Beispiel des Kunden aus dem ersten Artikel: Als das Unternehmen mithilfe des tribe29-Partners SVA Checkmk einführte, betrieben sie einen hohen Aufwand, um die Alarmierung zu optimieren. Durch den Einsatz der verschiedenen Tools, die Checkmk zur Verfügung stellt, sank die Zahl der monatlichen Warnmeldungen auf etwa 2.000. Das entspricht einer Reduzierung der Warnmeldungen um etwa 75 bis 80 Prozent – ohne Beeinträchtigung der Service-Qualität. Allein dadurch spart das Unternehmen jeden Monat Hunderte von Stunden, die es in der Vergangenheit mit der Durchsicht sinnloser Warnmeldungen verbrachte. Die Investition in das Abonnement der Checkmk Enterprise Edition hat sich somit schnell bezahlt gemacht.

Der dritte und letzte Teil dieser Artikelserie wirft einen Blick auf die verschiedenen Tools, die Partner und Kunden von tribe29 verwenden, um bessere Warnmeldungen und Benachrichtigungen zu erhalten.


Related Articles

Log4j-Schwachstellen in Ihrer IT-Infrastruktur aufspüren
Log4j-Schwachstellen in Ihrer IT-Infrastruktur aufspüren
Der Zero-Day-Exploit Log4Shell gefährdet zahlreiche Server in Unternehmen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt, dass…
Benachrichtigen oder nicht benachrichtigen – Fehlalarme im Monitoring
Benachrichtigen oder nicht benachrichtigen – Fehlalarme im Monitoring
In der Statistik treten immer zwei Fehler auf, die man typischerweise als „Typ I“ oder „Typ II“ unterscheidet. In der Sprache der Statistiker ist ein…
Checkmk als Alarmquelle in iLert einrichten
Checkmk als Alarmquelle in iLert einrichten
In diesem Blogpost erkläre ich, wie Sie Ihr Checkmk-Monitoring als Alarmquelle in iLert einrichten und anschließend erste Schritte in iLert…