Checkliste Incident-Priorität
<seo metakeywords="incident priorisierung, incident priorisierung itil, incident priorität, major incident, Incident eskalation" metadescription="Richtlinie Incident-Priorisierung: Zuordnung von Prioritäten zu Incidents, Definition von Major Incidents und Incident-Eskalation." />
ITIL-Prozess: ITIL V3 Service Operation - Servicebetrieb - Incident Management
Checklisten-Kategorie: Checklisten ITIL V3 Service Operation (Servicebetrieb)
Quelle: Checkliste "Richtlinie Incident-Priorisierung" aus der ITIL-Prozesslandkarte V3
Die Richtlinie Incident-Priorisierung beschreibt die Regeln für die Zuordnung von Prioritäten zu Incidents und definiert, welche Incidents als Major Incidents zu behandeln sind. Da die Eskalationsregeln für Incidents in der Regel auf Prioritäten basieren, ist die Zuordnung der richtigen Priorität maßgeblich für die angemessene Eskalation von Incidents.
Die Priorität eines Incidents ergibt sich in der Regel aus der Bewertung von Incident-Auswirkung und Incident-Dringlichkeit, wobei
- Dringlichkeit ("Urgency") ausdrückt, wie schnell der Incident gelöst werden muss, und
- Auswirkung ("Impact") ausdrückt, wie umfangreich der Incident ist und welcher (potentielle) Schaden durch den Incident verursacht werden kann.
Incident-Dringlichkeit (Dringlichkeits-Kategorien)
Dieser Abschnitt gibt Dringlichkeits-Kategorien vor. Die Definitionen müssen auf die jeweilige Organisation genau abgestimmt sein, deshalb ist die folgenden Tabelle lediglich ein Beispiel:
Um die Incident-Dringlichkeit zu bestimmen, wähle die höchste zutreffende Kategorie:
| Kategorie | Beschreibung |
|---|---|
| Hoch (H) |
|
| Mittel (M) |
|
| Niedrig (N) |
|
Incident-Auswirkung (Auswirkungs-Kategorien)
Dieser Abschnitt gibt Auswirkungs-Kategorien vor. Die Definitionen müssen auf die jeweilige Organisation genau abgestimmt sein, deshalb ist die folgenden Tabelle lediglich ein Beispiel:
Um die Incident-Auswirkung zu bestimmen, wähle die höchste zutreffende Kategorie:
| Kategorie | Beschreibung |
|---|---|
| Hoch (H) |
|
| Mittel (M) |
|
| Niedrig (N) |
|
Incident-Priorität (Prioritäts-Kategorien)
Die Priorität eines Incidents leitet sich aus Dringlichkeit und Auswirkung ab. Wenn, wie oben dargestellt, Klassen zur Bestimmung von Dringlichkeit und Auswirkung definiert sind, kann eine Dringlichkeits-Auswirkungs-Matrix ("Urgency-Impact Matrix") verwendet werden, um Klassen von Prioritäten festzulegen, wie im folgenden Beispiel:
| Auswirkung | ||||
|---|---|---|---|---|
| H | M | N | ||
| Dringlichkeit | H | 1 | 2 | 3 |
| M | 2 | 3 | 4 | |
| N | 3 | 4 | 5 | |
| Prioritäts-Code | Beschreibung | Reaktionszeit-Vorgabe | Lösungszeit-Vorgabe |
|---|---|---|---|
| 1 | Kritisch | Sofort | 1 Stunde |
| 2 | Hoch | 10 Minuten | 4 Stunden |
| 3 | Mittel | 1 Stunde | 8 Stunden |
| 4 | Niedrig | 4 Stunden | 24 Stunden |
| 5 | Sehr niedrig | 1 Tag | 1 Woche |
Kriterien für die Behandlung eines Incidents als Major Incident
Major Incidents erfordern die Etablierung eines Major Incident Teams und werden durch den Prozess „Behebung von Major Incidents“ behandelt. Über das oben gezeigte Schema hinaus ist es oft angeraten, zusätzliche und leicht verständliche Indikatoren zur Bestimmung von Major Incidents zu definieren (s. dazu auch die Erläuterungen weiter unten). Beispiele für solche Indikatoren sind:
- Bestimmte (Gruppen von) geschäftskritischen Services, Anwendungen oder Infrastruktur-Komponenten sind nicht verfügbar und die voraussichtliche Zeit bis zur Wiederherstellung ist zu lang oder unbekannt (hier ist zu spezifizieren, welche Services, Anwendungen oder Infrastruktur-Komponenten zutreffen)
- Bestimmte (Gruppen von) geschäftskritischen Prozessen ("Vital Business Functions") sind betroffen und die voraussichtliche Zeit bis zur Wiederherstellung der vollständigen Leistungsfähigkeit dieser Prozesse ist übermäßig lang oder unbekannt (hier ist zu spezifizieren, welche geschäftskritischen Prozesse zutreffen)
Bestimmung von Major Incidents
Die Bereitstellung klarer Richtlinien zum Bestimmen von Major Incidents ist oft ein schwieriges Unterfangen, aber der 1st Level Support entwickelt zumeist einen "sechsten Sinn" für diese. Im Zweifelsfall ist es auch besser, auf der sicheren Seite zu bleiben.
Ein Major Incident ist durch seine großen Auswirkungen charakterisiert, insbesondere auch auf Kunden. Beispiele hierfür sind:
- Die Netzwerkanbindung fällt aus und damit ist die Kommunikation des Unternehmens mit der Außenwelt unterbrochen.
- Ein Web-Server fällt wegen unerwartet hoher Belastung aus, z.B. weil viele Kunden zugreifen, um Tickets zu reservieren; dadurch wird es vielen Kunden unmöglich, Tickets zu erwerben.
- Eine zentrale Datenbank stellt sich als korrupt heraus.
- Mehrere für das Geschäft wichtige Server sind von einem Virus befallen.
- Vertrauliche Informationen zu einer größeren Zahl von Kunden sind in die Öffentlichkeit gelangt.
Darüber hinaus sind alle Katastrophenfälle (die von der IT-Service-Continuity-Strategie und unterstützenden ITSCM-Plänen behandelt werden) als Major Incidents zu bewerten. Zu beachten ist auch, dass unkritische Incidents durch Fehler oder zu lange Inaktivität zu Major Incidents werden können.
Die wichtigsten Eigenschaften, an denen sich Major Incidents erkennen lassen, sind unter anderem:
- Eine signifikante Anzahl von Kunden bzw. von wichtigen Kundengruppen ist betroffen.
- Die Kosten bzw. aus dem Incident resultierenden Verluste für Kunden und/oder die Service-Organisation sind beträchtlich.
- Die Reputation des Service-Providers wird wahrscheinlich beschädigt.
UND
- Der Arbeits- und Zeitaufwand zur Lösung des Incidents ist vermutlich groß und es ist sehr wahrscheinlich, dass bestehende Service-Level-Vereinbarungen verletzt werden.
Ein Major Incident ist in aller Regel auch mit der Priorität "Kritisch" oder "Hoch" versehen.
