ITIL Knowledge: Incident / Problem
ITIL unterscheidet streng zwischen einem «Incident» und einem «Problem». Die Verwechslung zwischen den beiden verursacht Stolpersteine. Dieter Gut, ID Direktion Qualitäts- und Prozessmanagement, erklärt den Unterschied praxisgerecht.
- Incident: Plötzliche oder drohende Störung der Serviceerbringung.
- Problem: Immer wieder auftretende, identische oder ähnliche Störungen, bekannte Fehler oder nicht mehr behebbare Störungen mit unbekannter Ursache.
- Incident Management: Prozess zur Beseitigung der Auswirkungen einer Störung durch einfache Massnahmen (z. B. Reboot) oder durch Anwendung eines Workarounds.
- Problem Management: Forschung nach der Ursache einer Störung oder eines bekannten Fehlers mit dem Ziel diese Ursache zu beseitigen. Damit soll künftig ein stabilerer Betrieb ermöglicht werden.
Häufig machen die IT Betreiber den Fehler, dass sie keinen Problem Record eröffnen und stattdessen nur mit einem Incident Record arbeiten. Das kann dazu führen, dass die Incident Records weit über die Störungsdauer geöffnet bleiben weil ja die Ursache noch gefunden werden soll. Es gibt viele offene Incident Tickets. Das erschwert die Übersicht. Es sind ja gar nicht so viele Störungen vorhanden. Die Reportings an die Kunden machen einen schlechten Eindruck. Andererseits führt ein zu schnelles Schliessen des Incident Tickets zur Gefahr, dass nicht erkannt wird, dass die Störung immer wieder auftritt. Dadurch wird der Betreiber belastet und der Kunde verärgert.
Am folgenden Praxisbeispiel wird der Mechanismus dargestellt
Ein Kunde ruft beim ID Service Desk an, weil in einer Datenbank kein neuer Datensatz mehr erfasst werden kann. In den vergangenen vier Wochen gab es schon mehrere ähnliche Calls. Deshalb hat der Service Desk schon einen «Known Error» (KE) erfasst. Es war jeweils die Festplatte des Servers plötzlich vollgelaufen. Nach einem Neustart der Datenbank durch die Administratorin bzw. den Administrator ging es immer wieder. Der Service Desk startet die Datenbank noch während dem Anruf neu und es kann sofort wieder gearbeitet werden. Der Service Desk sieht, dass dies nun das fünfte Mal hintereinander war und schliesst das Incident Ticket. Er macht stattdessen ein Problem Ticket auf, referenziert den KE und alle bisherigen Incident Tickets.
Die Problem Managerin bzw. der Problem Manager akzeptiert den Problem Record, sucht sich Fachkräfte und beauftragt sie mit der Analyse. Das Team findet heraus, dass in dieser Version der Datenbank ein Fehler besteht. Speicher wird erst nach dem Neustart der Datenbank wieder freigegeben. Es gibt einen Patch dafür vom Hersteller. Es wird ein Request for Change (RfC) gemacht. Das Release Management soll den Patch ausrollen auf alle Datenbanken mit der fehlerhaften Version. Aus der CMDB sieht man, dass nur eine einzige Installation betroffen ist. Der KE wird aktualisiert. Das Problem Ticket bleibt solange offen, bis sicher ist, dass der Change das Problem behoben hat. Da der Change erst im Wartungsfenster gemacht werden darf tritt derselbe Fehler noch einmal auf. Der Service Desk sieht aber diesmal im KE, dass die Ursache bekannt ist und ein Change hängig ist und kann die Anwenderin oder den Anwender kompetent informieren, dass der Fehler nach dem Change Datum nicht mehr auftreten sollte.
Situation in den Informatikdiensten der ETH Zürich
Alle hier angesprochenen Prozesse sind in den Informatikdiensten der ETH vorhanden. Es mangelt etwas an der Systematik, am Bewusstsein und am Datenfluss zwischen den einzelnen Prozessen. Es fehlt das Wissen, was die Kolleginnen und Kollegen schon gemacht haben. Da gibt es Verbesserungspotenzial.
Prozesse und Ausdrücke im Beispiel
- Incident Management Prozess in der Phase Operation
- Ticket/Call Datensatz
- Service Desk Funktion
- Problem Management Prozess in der Phase Operation
- Known Error (KE) Datensatz
- Service Asset and Configuration Management Prozess in der Phase Transition
- Configuration Management Database (CMDB) Datenhaltung
- Change Management Prozess in der Phase Transition
- Request for Change (RfC) Datensatz
- Release and Deployment Management Prozess in der Phase Transition
Posted on
in Kommunikation, Mail, Web, Multimedia, Drucken, News, Passwort, Applikationen, Software, Arbeitsplätze, Speicher, Support, Wissenschaftl. Rechnen
