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

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

Checkliste Automatisierung

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