IT Alarm Management – Voraussetzungen und Handlungsempfehlungen

Die IT-Organisationen größerer Unternehmen sehen sich täglich mit 5 kritischen und etwa 80 weniger kritischen Alarm-Meldungen konfrontiert. Es geht um viele kleinere und wenige, aber zentrale IT-Störungen. Letztere sind u.U. unternehmenskritisch, z.B. der Ausfall des Online-Banking-Services. Der aktuelle Gartner Hype Cycle ITSM 2020, der jedes Jahr die wichtigsten Marktentwicklungen und Tools im Bereich IT Service Management (ITSM) vorstellt, betont die wachsende Bedeutung von IT Service Alerting (ITSA). Entsprechende Werkzeuge sind mit ITSM-Systemen und Monitoring-Anwendungen verknüpft und automatisieren die Verteilung und Verwaltung von Alarm-Benachrichtigen an definierte Empfänger. Der von Gartner geprägte Begriff stellt den IT-Service in den Mittelpunkt der Betrachtung. In Europa ist jedoch der Begriff IT Alarm Management gebräuchlicher. Der Blogbeitrag beschreibt die zentrale Rolle des Event Managements, zeigt auf, wie ein idealer Alarmierungsprozess aussieht und gibt Empfehlungen, was jetzt zu tun ist.

Herausforderungen & Voraussetzungen – Event-Management gibt Struktur

Fehlalarme (false positives) sind auch im IT-Betrieb alltäglich. In der Regel erhalten Administratoren zu viele, nicht zu wenige Alarme. Nur die wenigsten davon sind relevant. Häufig gehen false positives auch als Sammelmail an eine Gruppe von Mitarbeitern, und es ist nicht klar, ob und wenn ja wer verantwortlich ist und reagieren sollte.

Daher ist die zentrale Herausforderung für ein professionelles Alarm Management nicht das Sammeln von Daten. Sie liegt vielmehr in der Filterung und Klassifizierung von Informationen und in ihrer sinnvollen Auswertung und Weiterverarbeitung. Hierfür ist das Event Management verantwortlich.

Basis ist der Teilprozess zur Definition und Pflege von Event-Monitoring-Mechanismen und -Regeln. Hier wird das Alarmierungs-Konzept abgebildet. Es wird festgelegt, aus welchen Configuration Items (CIs) sich die Services zusammensetzen, also welche Applikationen bzw. Infrastrukturkomponenten im Störfall ggf. für die Alarmierung relevant sind und welche Abhängigkeiten bestehen. Generell wird die Kritikalität der einzelnen Ereignisse und ihre Auswirkungen auf die Services und deren mögliche Konsequenzen definiert. Welche Rollen sind im Störfall zu benachrichtigen, z.B. IT-Operator, Netzwerk-Administrator, Service-Owner etc.? Welche Kommunikationskanäle sind je nach Störfall zu nutzen, wie sehen Eskalationspfade aus? Weitere wichtige Aspekte sind, welcher Kunde ggf. betroffen ist und wo die Geräte jeweils stehen. Diese Informationen erlauben im Störungsfall das rasche Erkennen der Auswirkungen (Impact-Analyse) und Ursachen (Root-Cause-Analyse). Jeweils hinterlegte Handlungsanweisungen aus einer Lösungsdatenbank beschleunigen die MTTR.

Die Modellierung von Business Services ist die Grundlage für die Event-Korrelation und damit für ein effektives Alarm Management. Wichtig ist in diesem Zusammenhang eine zentrale CMDB. Dort sollte über automatisierte Prozesse auch die Pflege des Servicebaums erfolgen

Die Mehrwerte durch eine vorgeschaltete Event-Korrelation liegen auf der Hand: Fällt bei einem internationalen Konzern beispielsweise das WAN-Netz in Shanghai aus, erhalten die Verantwortlichen EINE Alarm-Meldung. Ohne Korrelation würden die Vielzahl der hiervon betroffenen CIs ebenfalls Alarme generieren („Server XYZ down“, „Router XYZ down“ etc.). so dass hunderte von Alarmen bzw. Tickets zu verzeichnen wären. In der Praxis lässt sich dadurch also nicht nur die Anzahl der „false positives“ drastisch reduzieren, sondern die Qualität der Informationen und ein gut strukturierter Prozess sorgt für eine rasche Fehlerbehebung.

Sie möchten mehr erfahren?

Dieser Artikel ist ein Auszug aus einem umfangreichen Whitepaper, das hier heruntergeladen werden kann: 

Beispiel für einen „idealen“ Alarmierungsprozess

Wie oben skizziert, gewährleistet nur das Zusammenspiel zwischen Monitoring, Event-Management, Capacity Management, Incident Management und Alarmierungs-Modulen die Vermeidung technischer Ausfälle bzw. garantiert die schnellstmögliche Fehlerbehebung.

Deutlich wird dies anhand des folgenden Beispiels:

Während Online-Banking-Aktivitäten kommen Kunden nicht auf eine Seite, auf der der PIN für entsprechende Transaktionen angefordert wird, so dass Überweisungen, Daueraufträge etc. nicht möglich sind. Im Hintergrund sammelt ein zentrales Event Management die Daten und analysiert die Störungsursachen. Im besten Fall beseitigt das System selbst die Störung – zum Beispiel, indem die Applikation neu gestartet wird. Diese Self-Healing-Mechanismen reduzieren die Anzahl der Alarme in der Praxis um etwa 20 Prozent. Geht es bei der Störung beispielsweise um ein Kapazitäts-Problem (Server voll) oder eine ausgefallene Hardware (Überhitzung Server), lassen sich diese Probleme u.U. durch ggf. KI-gestütztes Predictive Monitoring rechtzeitig erkennen und beheben.

Bei einer akuten Alarmierung wird die Problemmeldung systemseitig mit wichtigen strukturierten Informationen angereichert: wo steht das betroffene Gerät bzw. was genau ist die fehlerhafte Funktion, welche Kunden sind betroffen, welche Service Level Agreements (SLAs) hat der Service, wie sieht die Lösung aus etc.

Abhängig von der Störung wird der im System hinterlegte Service-Techniker informiert und erhält eine Push-Nachricht via App oder SMS bzw. andere definierte Kanäle. Dieser quittiert dies ebenfalls über App bzw. SMS und dokumentiert so, dass er sich um die Störung kümmert und die Reparatur anhand der zur Verfügung gestellten spezifischen Lösung durchführt. Falls der Verantwortliche jedoch auch über verschiedene Kommunikationskanäle nicht erreicht werden kann, greift nach einem definierten, sequentiell angelegten Alarmierungs-Konzept der Eskalationsprozess: die nächste Person des Bereitschafts-Teams wird informiert, ggf. auch der Teamleiter.

In unserem Beispiel eines Online-Banking-Problems gilt i.d.R. die höchste Dringlichkeits-Stufe. Je nach Zeitpunkt werden weltweit agierende Organisationen mit ihren verteilten Service-Teams zu ihren Service-Zeiten alarmiert, so dass ein 7x24-Service nach dem „follow the sun-Prinzip“ sichergestellt ist.

Während die kritischen Störungen immer per App, SMS oder Voice gemeldet werden, alarmiert das System bei weniger kritischen Themen z.B. per E-Mail – Tag und Nacht. Da das Bereitschafts-Team häufig auch nach Einsatz bezahlt wird, lassen sich durch die Ressourcen-Entlastung auch die Kosten reduzieren.

Handlungsempfehlungen für Unternehmen

Die folgenden Praxistipps haben sich bei vielen Projekten zum Aufbau eines Alarmmanagements als wichtige Bausteine für den Erfolg erwiesen:

• Analysieren Sie, welche IT-gestützten Prozesse ggf. geschäftskritisch sind, quantifizieren Sie das Risiko von Störungen und investieren Sie ggf. zielgerichtet in ein darauf ausgerichtetes Alarmierungskonzept sowie die entsprechende Technologie
• Konzentrieren Sie sich vor dem Einsatz eines Tools zunächst auf die Verbesserung der zugrundeliegenden Monitoring-Werkzeuge und -prozesse für das Event Management. Denn Alarmings-Werkzeuge sind kein Allheilmittel für schlechtes Event Management.
• Beseitigen Sie damit das „Störungsrauschen“ in Form von „false positives“, bevor Sie sich um die Alarm-Kommunikation kritischer Fehler kümmern. Definieren Sie für jeden IT-Stakeholder, welche Information er wann und in welcher Form sehen sollte, um „Spam“ zu vermeiden
• Die komfortable Bedienbarkeit und individuelle Flexibilität der Bereitschaftsplanung ist ein wichtiger Faktor für die Akzeptanz der Service-Teams.