10.3 Alarme, Eskalationen und Automatisierung

Kurz erklärt 
 Nicht jedes Event erfordert menschliches Eingreifen. 
 Erst wenn ein Ereignis eine definierte Bedeutung besitzt, wird daraus ein Alarm. 
 Je nach Schwere können anschließend automatische Aktionen, Eskalationen oder die Erstellung eines Incident-Tickets erfolgen. 
 Ziel ist es, Probleme möglichst schnell und möglichst automatisch zu erkennen und zu behandeln. 
 
 
 Vom Event zum Alarm 
 Ein Monitoring-System erzeugt kontinuierlich Events. 
 Nur ein Teil dieser Events wird zu Alarmen. 
 Ein typischer Ablauf: 
 Monitoring
 │
 ▼
Event
 │
 ▼
Bewertung
 │
 ┌────┴────┐
 │ │
keine Alarm
Aktion │
 ▼
Reaktion
 
 Die Bewertung erfolgt anhand definierter Regeln. 
 
 Was ist ein Alarm? 
 Ein Alarm ist eine Benachrichtigung über ein relevantes Ereignis. 
 Er informiert darüber, dass eine Reaktion erforderlich oder zumindest sinnvoll sein kann. 
 Ein Alarm bedeutet jedoch nicht automatisch, dass bereits ein Incident vorliegt. 
 
 Beispiele für Alarme 
 Typische Alarme: 
 
 Festplatte fast voll 
 Backup fehlgeschlagen 
 RAID degradiert 
 Server nicht erreichbar 
 hohe CPU-Auslastung 
 Zertifikat läuft bald ab 
 Temperatur überschritten 
 Netzwerkverbindung unterbrochen 
 Container abgestürzt 
 Datenbank antwortet nicht 
 
 Je nach Kritikalität unterscheiden sich die weiteren Maßnahmen. 
 
 Alarme priorisieren 
 Nicht jeder Alarm besitzt dieselbe Bedeutung. 
 Mögliche Kriterien: 
 
 betroffener Service, 
 Business Impact, 
 Anzahl betroffener Benutzer, 
 Kritikalität, 
 Tageszeit, 
 Sicherheitsrelevanz, 
 vorhandene Redundanz, 
 Wiederholungen. 
 
 Dadurch kann dieselbe technische Meldung unterschiedlich behandelt werden. 
 
 Alarmstufen 
 Viele Organisationen verwenden mehrere Alarmstufen. 
 Beispiel: 
 
 
 
 Stufe 
 Bedeutung 
 
 
 
 
 Information 
 nur protokollieren 
 
 
 Warnung 
 beobachten 
 
 
 Hoch 
 Administrator informieren 
 
 
 Kritisch 
 sofort reagieren 
 
 
 Notfall 
 Eskalation und Incident 
 
 
 
 Die genaue Anzahl der Stufen ist organisationsabhängig. 
 
 Alarmkanäle 
 Alarme können über verschiedene Wege zugestellt werden. 
 Beispiele: 
 
 Dashboard 
 E-Mail 
 SMS 
 Push-Nachricht 
 Microsoft Teams 
 Slack 
 Telefonanruf 
 Bereitschaftssystem 
 Pager 
 ITSM-System 
 
 Der Kanal richtet sich nach der Kritikalität. 
 
 Alarmrouting 
 Nicht jeder Alarm geht an dieselbe Person. 
 Beispiele: 
 
 
 
 Alarm 
 Empfänger 
 
 
 
 
 Netzwerk 
 Netzwerkteam 
 
 
 Backup 
 Backup-Team 
 
 
 Datenbank 
 Datenbankadministration 
 
 
 Cloud 
 Cloud-Team 
 
 
 Active Directory 
 Windows-Team 
 
 
 Linux 
 Linux-Team 
 
 
 Container 
 Plattform-Team 
 
 
 
 Dadurch gelangen Informationen direkt an die zuständigen Personen. 
 
 Automatische Reaktionen 
 Viele Alarme können automatisiert verarbeitet werden. 
 Beispiele: 
 
 Dienst neu starten 
 Container neu starten 
 VM verschieben 
 Backup erneut starten 
 Speicher bereinigen 
 DNS umschalten 
 Last verteilen 
 Ticket erstellen 
 Benutzer informieren 
 
 Nicht jede Situation erfordert sofort einen Administrator. 
 
 Selbstheilung (Self-Healing) 
 Self-Healing beschreibt automatische Korrekturmaßnahmen. 
 Beispiele: 
 
 Dienst startet automatisch neu. 
 Container wird neu erstellt. 
 zweite Netzwerkverbindung wird aktiviert. 
 Cluster übernimmt den Betrieb. 
 Load Balancer entfernt fehlerhaften Server. 
 Speicherplatz wird automatisch erweitert. 
 
 Dadurch entstehen viele Incidents gar nicht erst. 
 
 Beispiel 
 Container beendet sich
 │
 ▼
Monitoring erkennt Fehler
 │
 ▼
Container automatisch neu starten
 │
 ▼
Container läuft wieder
 │
 ▼
Event dokumentieren
 
 Der Benutzer bemerkt den Fehler möglicherweise überhaupt nicht. 
 
 Automatisierte Incident-Erstellung 
 Nicht jeder Alarm erzeugt automatisch einen Incident. 
 Sinnvoll ist dies beispielsweise bei: 
 
 Serverausfall 
 RAID-Fehler 
 Datenbank nicht erreichbar 
 Backup fehlgeschlagen 
 Zertifikat abgelaufen 
 Cloud-Service ausgefallen 
 
 Das ITSM-System erstellt automatisch ein Incident-Ticket. 
 
 Eskalationen 
 Kann ein Alarm nicht automatisch gelöst werden, 
 beginnt häufig eine Eskalation. 
 Beispiele: 
 
 Bereitschaft informieren, 
 Spezialisten hinzuziehen, 
 Incident Manager benachrichtigen, 
 Major Incident aktivieren. 
 
 Welche Eskalation erfolgt, 
 hängt von Schwere und Auswirkungen ab. 
 
 Zeitabhängige Eskalationen 
 Nicht jeder Alarm wird sofort eskaliert. 
 Beispiel: 
 CPU-Auslastung: 
 
 über 90 % für 30 Sekunden → ignorieren 
 über 90 % für 10 Minuten → Warnung 
 über 95 % für 30 Minuten → Incident 
 
 Zeitfilter verhindern unnötige Reaktionen. 
 
 Mehrstufige Eskalationen 
 Ein möglicher Ablauf: 
 Alarm
 │
 ▼
Administrator
 │
 ▼
Bereitschaft
 │
 ▼
Teamleiter
 │
 ▼
Incident Manager
 │
 ▼
Major Incident
 
 Nicht jeder Alarm erreicht automatisch die höchste Eskalationsstufe. 
 
 Alarmunterdrückung 
 Während geplanter Wartungen können Alarme unterdrückt werden. 
 Beispiel: 
 Ein Server wird bewusst neu gestartet. 
 Das Monitoring erkennt: 
 Server nicht erreichbar. 
 Da ein genehmigter Change aktiv ist, 
 wird kein Incident erzeugt. 
 
 Abhängigkeiten berücksichtigen 
 Ein ausgefallener Router verursacht häufig viele weitere Alarme. 
 Beispiele: 
 
 Webserver offline 
 NAS offline 
 Drucker offline 
 VoIP offline 
 WLAN offline 
 
 Durch Abhängigkeitsregeln wird möglichst nur der eigentliche Fehler hervorgehoben. 
 
 Alarmkorrelation 
 Mehrere Alarme können zusammengehören. 
 Beispiel: 
 
 Datenbank langsam 
 Anwendung langsam 
 Webserver meldet Fehler 
 
 Die eigentliche Ursache: 
 Storage reagiert verzögert. 
 Alarmkorrelation unterstützt Administratoren bei der Ursachenanalyse. 
 
 Alarmfluten vermeiden 
 Zu viele Warnungen führen häufig dazu, 
 dass wichtige Alarme übersehen werden. 
 Typische Maßnahmen: 
 
 Filter, 
 Korrelation, 
 Deduplizierung, 
 sinnvolle Grenzwerte, 
 Wartungsfenster, 
 Zeitfilter. 
 
 Dadurch steigt die Qualität der Alarmierung. 
 
 Dashboards 
 Dashboards stellen Alarme übersichtlich dar. 
 Typische Informationen: 
 
 aktuelle Alarme, 
 kritische Services, 
 Verfügbarkeit, 
 offene Incidents, 
 Trends, 
 Systemstatus, 
 Karten, 
 Serviceübersichten. 
 
 Sie ermöglichen einen schnellen Überblick. 
 
 Benachrichtigung außerhalb der Arbeitszeit 
 Kritische Systeme werden häufig rund um die Uhr überwacht. 
 Außerhalb der Geschäftszeiten können Alarme beispielsweise an: 
 
 Rufbereitschaft, 
 Bereitschaftsdienst, 
 externen Dienstleister 
 
 gesendet werden. 
 Dadurch bleibt die Reaktionsfähigkeit erhalten. 
 
 Praxisbeispiel 
 Ein RAID-Verbund meldet: 
 Eine Festplatte ausgefallen. 
 Automatisch geschieht: 
 
 Alarm erzeugen, 
 Incident erstellen, 
 Storage-Team informieren, 
 Dashboard aktualisieren, 
 Bereitschaft benachrichtigen, 
 Dokumentation ergänzen. 
 
 Die eigentliche Reparatur erfolgt anschließend durch den zuständigen Administrator. 
 
 Typische Fehler 
 Fehler 1 
 Jeder Alarm erzeugt sofort einen Incident. 
 
 Fehler 2 
 Keine automatische Fehlerbehandlung. 
 
 Fehler 3 
 Keine Alarmkorrelation. 
 
 Fehler 4 
 Zu viele Benachrichtigungen. 
 
 Fehler 5 
 Keine Wartungsfenster berücksichtigt. 
 
 Fehler 6 
 Falsche Empfänger erhalten Alarme. 
 
 Fehler 7 
 Self-Healing wird nicht genutzt. 
 
 Fehler 8 
 Bereitschaft wird wegen unwichtiger Warnungen gestört. 
 
 Fehler 9 
 Alarmregeln werden nach Änderungen nicht angepasst. 
 
 Fehler 10 
 Fehlgeschlagene Automatisierungen bleiben unbemerkt. 
 
 Checkliste Alarmmanagement 
 
 Event korrekt bewertet 
 Alarmstufe festgelegt 
 richtiger Empfänger definiert 
 Eskalation vorhanden 
 Wartungsfenster berücksichtigt 
 Alarm dokumentiert 
 Korrelation eingerichtet 
 Deduplizierung aktiv 
 Dashboard aktualisiert 
 regelmäßige Überprüfung geplant 
 
 
 Checkliste Automatisierung 
 
 Self-Healing möglich 
 Workflow getestet 
 Rollback vorhanden 
 Fehler protokolliert 
 Monitoring aktiv 
 Incident-Erstellung geprüft 
 Benachrichtigungen getestet 
 Verantwortlichkeiten dokumentiert 
 
 
 Bedeutung für Fachinformatiker für Systemintegration 
 Fachinformatiker richten häufig Alarmierungen und automatische Reaktionen ein. 
 Typische Aufgaben: 
 
 Alarmregeln definieren, 
 Eskalationen konfigurieren, 
 Dashboards pflegen, 
 Automatisierungen entwickeln, 
 Self-Healing testen, 
 Benachrichtigungen überprüfen, 
 Alarmfluten reduzieren, 
 Monitoring kontinuierlich verbessern. 
 
 Ein gut abgestimmtes Alarmmanagement sorgt dafür, dass kritische Ereignisse schnell erkannt und möglichst automatisch behandelt werden. 
 
 Zusammenfassung 
 
 Monitoring erkennt Event 
 ↓ 
 Event bewerten 
 ↓ 
 Alarm erzeugen 
 ↓ 
 Priorisieren 
 ↓ 
 Automatische Reaktion oder Eskalation 
 ↓ 
 Incident (falls erforderlich) 
 ↓ 
 Dokumentation 
 
 
 Merksätze 
 
 Nicht jeder Alarm führt zu einem Incident. 
 
 
 Gute Alarmregeln vermeiden unnötige Benachrichtigungen. 
 
 
 Self-Healing kann viele Incidents vollständig verhindern. 
 
 
 Alarmkorrelation unterstützt die Ursachenanalyse. 
 
 
 Die richtige Information muss zur richtigen Zeit die richtige Person erreichen. 
 
 
 Verwandte Seiten 
 
 10.1 Ziele und Grundlagen des Monitoring and Event Management 
 10.2 Event-Typen, Filter und Priorisierung 
 10.4 Monitoring-Werkzeuge, Dashboards und Kennzahlen 
 10.5 Zusammenspiel mit Incident, Problem, Change und Service Configuration Management 
 Incident Management 
 Problem Management 
 Service Configuration Management 
 Continual Improvement 
 
 
 Quellen und Versionsstand 
 Offizielle Grundlagen 
 
 PeopleCert – ITIL Practice Guide: Monitoring and Event Management 
 ITIL Foundation – Version 5 
 
 Einordnung 
 Die dargestellten Alarmierungsstrategien, Eskalationsmodelle, Self-Healing-Beispiele und Automatisierungen sind herstellerneutrale Praxisempfehlungen. ITIL definiert die Grundprinzipien des Monitoring and Event Management, schreibt jedoch keine konkreten Alarmstufen, Eskalationswege oder Automatisierungsmechanismen vor. Diese werden organisationsabhängig anhand der Servicekritikalität und der eingesetzten Monitoring- und ITSM-Werkzeuge umgesetzt. 
 Behandelter Framework-Stand: ITIL Version 5 
 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance 
 Fachlicher Stand: August 2026