Wann ist ein Incident ein Incident?

Über die Definition von Incidents und die Zahl 42.

von Norbert Witzel

„Ein Incident ist eine nicht geplante Unterbrechung eines Service oder eine Qualitätsminderung eines Service.“ Aber was heißt das genau und wie stehen andere unserer ITIL Begriffe im Verhältnis dazu?
Etwa der Begriff „Event“: „Jede Statusänderung, die für das Management eines Service oder eines anderen Configuration Items von Bedeutung ist

Was mag uns bei der Beantwortung der Frage helfen? „42“, die Antwort auf alle (also wohl fast alle) Fragen, hilft uns nicht weiter. Hollywood ebenfalls nicht – im Gegenteil; Tom Hanks verwechselt gar Incident mit Problem, wenn er aus der Apollo 13 heraus meldet: „Houston we have a problem“.

Vielleicht müssen wir die Frage anders, exakter formulieren? Wie sagte Albert Einstein: „Wenn du dir die richtige Frage stellst – ergibt sich daraus schon die Antwort“. Versuchen wirs: Wann ist ein Event ein Incident?

Wann ist ein Event ein Incident?

ITIL gibt uns vier Arten von Events – vielleicht die 4 von der „42“?

• Informational:
  Reine Information, keine Aktion erforderlich – also: Kein Incident
• Instructional:
  Information, Aktion erforderlich – also: Kein Incident (wenn Aktion ausgeführt wird)
• Warning:
  Warnung/Grenzwert erreicht, Untersuchung erforderlich – also: Tendenziell noch im gelben Bereich, kein Incident
• Exception:
  Kritische Situation/Grenzwert deutlich überschritten, möglicherweise noch ohne Einfluss auf den Geschäftsbetrieb – also: Vermutlich ein Incident und sollte als Incident qualifiziert werden

Okay, also ist ein Event, das eine Exception ist, ein Incident… oder doch nicht jede? Wieso gibt es dann überhaupt den Begriff „Exception“?

Es trifft die Lieblingsantwort eines jeden Juristen zu: Es kommt darauf an.

Wann ist eine Exception ein Incident?

Kommen wir zurück zu unsere Definition von Incident: „Ein Incident ist eine nicht geplante Unterbrechung eines Service oder eine Qualitätsminderung“.

Als Exception haben wir einen Ausnahmezustand definiert, bei dem eine kritische Situation entstanden ist und wir handeln müssen/wollen. Eine exakte Definition der Exception liegt uns nicht vor – es ist unsere Aufgabe diese „Ausnahme“ festzulegen.

Die Exception fordert uns also auf, zu handeln. Eine Unterbrechung oder Qualitätsminderung, also ein Incident, kann vorliegen, muss aber nicht.

Zur Veranschaulichung ein Beispiel:

Nehmen wir an, wir haben für einen Service zwei Server im Einsatz. Einer der beiden ist der Live-Server, der andere der Back-Up Server – hot-stand-by. Fällt der Live-Server aus und der Back-Up Server übernimmt nahtlos, wird der Service nicht beeinträchtigt. Exception, aber kein Incident.
Oder doch ein Incident? Kann sein, wenn im SLA vereinbart ist, dass ein hot-stand-by Betrieb jederzeit gegeben ist. Unter dieser Voraussetzung würde es sich sowohl um eine Exception als auch einen Incident handeln.

Es kommt also tatsächlich darauf an – darauf was wir mit unserem Kunden vereinbart haben. Wir haben 2 Alternativen – die 2 der „42“ 😉

Gibt es „großzügigere“ Empfehlungen, wann ein Incident vorliegt?

Hier finden wir ein eindeutiges JA.
… in dem wir uns von den „harten“ SLA mit ZDF (Zahlen, Daten, Fakten) lösen und die weichere Beziehungsebene und die ITIL Grundprinzipien berücksichtigen.

Wieder sind es vier; diesmal vier Auslöser für einen Incident; sie unterscheiden den Auslöser und die empfohlene Reaktionsgeschwindigkeit:

• Anwender ist „unhappy“:
  Anwender nimmt Ungewöhnliches am Service wahr – wir registrieren einen Incident, unabhängig vom SLA (!) und beheben ihn so schnell wie möglich.
• SLA verletzt, ggf. ohne dass es der User merkt:
  Wir registrieren einen Incident und lösen ihn bevor der User es merkt.
• Ein CI (Configuration Item) verhält sich nicht gemäß technischer Spezifikation:
  Wir registrieren einen Incident und lösen ihn, bevor das SLA betroffen ist.
• Einer unsere Experten denkt, dass sich der Service / ein CI nicht normal verhält:
  Wir registrieren einen Incident und lösen ihn so schnell, wie es vernünftig ist.

Diese „großzügigere“ Auslegung mag (kurzfristig) zu höheren Kosten führen – aber auf jeden Fall zu zufriedeneren Kunden, zufriedeneren Anwendern und zufriedeneren Mitarbeitern. Eine gute Best-Practice-Empfehlung von ITIL.

Über den Autor: Norbert Witzel

Norbert ist Experte für ITIL. Er hat mehr als 20 Jahre Erfahrung auf C-Level in unterschiedlichen Branchen. Er war bereits als CFO, Leiter Zentrale Dienste, Geschäftsführer und als Aufsichtsrat tätig. Ebenso bringt er Erfahrungen aus Großprojekten mit, hat individuelle Kundenprojekte und M&A Projekte geleitet. Seit vielen Jahren gibt er sein Knowhow und seine Erfahrungen auch als Berater, Trainer und Lehrbeauftragter an Hochschulen weiter.

22.04.2024