Begriffe wie „Incident“, „Ereignis“ und „Störfall“ spielen eine wichtige Rolle beim Verständnis von IT- und OT-Operationen. In der Regel gibt es eine Fülle von Interpretationen und Definitionen. Außerdem finden sich bei jedem Anbieter von Tools für die Überwachung und das Service Management unterschiedliche Bezeichnungen. Also, lass uns eintauchen.
Wie ist ein Incident definiert?
ITIL (v2) definiert Incidents wie folgt:
„Ein Ereignis, das nicht zum Standardbetrieb eines Dienstes gehört und das eine Unterbrechung oder eine Verringerung der Qualität der Dienste und der Kundenproduktivität verursacht oder verursachen kann.“
In ITIL v3 ist es definiert als
„Eine ungeplante Unterbrechung eines IT-Service oder eine Verringerung der Qualität eines IT-Service. Der Ausfall eines Konfigurationselements, der sich noch nicht auf den Service ausgewirkt hat, ist ebenfalls ein Incident. Zum Beispiel der Ausfall einer Festplatte in einem Mirror-Set.“
Nicht alle Alarme sind Incidents und es gibt auch nicht unbedingt eine 1:1-Beziehung zwischen Alarmen und Incidents. Incidents, oder Störfälle, können mit Alarmen verknüpft sein, d.h. bestimmte Alarme deuten auf einen Incident hin. In vielen Szenarien werden Warnungen mit einem bestimmten Schweregrad automatisch an ein Service Management System übertragen und bilden die Grundlage für die Erstellung eines Incident Tickets. Nur der Vollständigkeit halber – hier eine weitere Definition, die wahrscheinlich zu eng gefasst ist:
„Ein Incident ist ein von Menschen verursachtes, schädliches Ereignis, das zu einer erheblichen Unterbrechung des Geschäftsbetriebs führt (oder führen kann).“ Quelle: danielmiessner.com
Warum sollte ein Incident nur von Menschen verursacht werden? Wenn ein Fertigungsroboter ausfällt, IST das ein Störfall. Und er wird nicht von Menschen verursacht (es sei denn, der Konstrukteur dieser Maschine soll dafür verantwortlich gemacht werden).
Wie SIGNL4 auf Incidents reagiert
SIGNL4 unterscheidet nicht unbedingt zwischen Alarmen und Incidents, bzw. Störfällen. SIGNL4 kann jedoch leicht so konfiguriert werden, dass Alarme als Störfälle gekennzeichnet werden, d.h. dass bestimmte Alarme auf der Grundlage von Umfang und Nutzlast automatisch als Störfall qualifiziert werden. Mithilfe einer regelbasierten Logik können solche Incidents dann an verschiedene Teams und auf unterschiedliche Weise verteilt und auch auf eine bestimmte Art und Weise visuell und akustisch benachrichtigt werden (z.B. durch Stummschaltung).
