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:

Je nach Kritikalität unterscheiden sich die weiteren Maßnahmen.

Alarme priorisieren

Nicht jeder Alarm besitzt dieselbe Bedeutung.

Mögliche Kriterien:

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:

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:

Nicht jede Situation erfordert sofort einen Administrator.

Selbstheilung (Self-Healing)

Self-Healing beschreibt automatische Korrekturmaßnahmen.

Beispiele:

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:

Das ITSM-System erstellt automatisch ein Incident-Ticket.

Eskalationen

Kann ein Alarm nicht automatisch gelöst werden,

beginnt häufig eine Eskalation.

Beispiele:

Welche Eskalation erfolgt,

hängt von Schwere und Auswirkungen ab.

Zeitabhängige Eskalationen

Nicht jeder Alarm wird sofort eskaliert.

Beispiel:

CPU-Auslastung:

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:

Durch Abhängigkeitsregeln wird möglichst nur der eigentliche Fehler hervorgehoben.

Alarmkorrelation

Mehrere Alarme können zusammengehören.

Beispiel:

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:

Dadurch steigt die Qualität der Alarmierung.

Dashboards

Dashboards stellen Alarme übersichtlich dar.

Typische Informationen:

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:

gesendet werden.

Dadurch bleibt die Reaktionsfähigkeit erhalten.

Praxisbeispiel

Ein RAID-Verbund meldet:

Eine Festplatte ausgefallen.

Automatisch geschieht:

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:

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

Quellen und Versionsstand

Offizielle Grundlagen

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

Revision #1
Created 2 August 2026 21:07:58 by Admin
Updated 2 August 2026 21:08:14 by Admin