Incident Managements. Doch kommen wir nun zuerst zum Begriff des Incidents". Laut [OGC, 2004] ist ein Incident definiert als:

Transkript

1 2.4.2 Incident Management Primäres Ziel des Incident Managements ist die schnellstmögliche Wiederherstellung des normalen" störungsfreien Betriebs, die Minimierung der Einflüsse der Störungen auf die Geschäftsope- rationen und die Sicherstellung, dass die vereinbarten Service Levels eingehalten bzw. wieder erreicht werden. Primäres Ziel des Incident Managements ist die schnelle Wiederherstellung des normalen Betriebs. Der normale" störungsfreie Betrieb kann definiert werden über Vereinbarungen, die mit dem Kunden getroffen werden und in den Service Level Agreements niedergeschrieben sind. Um es gleich vorweg zu nehmen: Zentrale Funktion (nicht Prozess!) des Incident Managements ist der Service Desk, bei dem jede Anfrage oder Meldung eines Kunden oder Anwenders entgegengenommen und weiter bearbeitet wird. Doch kommen wir nun zuerst zum Begriff des Incidents". Laut [OGC, 2004] ist ein Incident definiert als: any event which is not part of the Standard Operation of a Service and which causes, or may cause, an Interruption to, or a reduction in, the quality of that service. Qualität der Ser- Hier finden wir den Begriff der 'Qualität der Services'. Also nur vices: Störungen nach exakter Definition der zu erbringenden Service-Leistungen sind Verletzungen und nach Vereinbarung mit dem Service-Nehmer über Qualitäten der vereinbarten und Service-Grenzen, die vom Service-Geber oder neudeutsch Service-Grenzen. "Provider" eingehalten werden müssen, lassen sich auch Überschreitungen dieser Grenzen als eine Störung des normalen Betriebs definieren. In diesem Sinne ist ein Incident jedes Ereignis, das nicht Teil der vereinbarten Service-Leistungen bzw. -Operationen ist und das eine Unterbrechung oder Reduktion der Qualität der Services verursacht oder verursachen kann. 34

2 Jede beim Service Desk eingehende Meldung oder Anfrage ist zunächst ein Incident. In [ findet man die folgenden Übersetzungen für den Begriff "Incident": die Begebenheit das Ereignis das Geschehnis der Vorfall der Vorgang das Vorkommnis der Zwischenfall Um an der zentralen Stelle zur Entgegennahme von Incident- Meldungen - dem Service Desk - jede eingehende Meldung oder Anfrage gleichwertig zu behandeln, ist diese vor genauerer Prüfung erst einmal als Incident zu behandeln. Nur so lässt sich ein zentraler Single Point of Contact" wirksam realisieren. Klassifiziert man Incidents, so lassen sich z. B. folgende Kategorien für Quellen von Incidents finden: Anfragen - Ein IT-Anwender fragt nach Informationen, nach Hilfe oder auch nur nach Dokumentation. Auch der immer wieder auftretende Fall des vergessenen Passwortes lässt sich als Beispiel nennen. - Ein IT-Anwender verlangt Veränderungen der IT-Infrastruktur, so z. B. einen neuen Drucker oder auch nur die Bereitstellung oder den Einbau von Tonerkartuschen in seinen Drucker. - Ein IT-Anwender hat allgemeine Fragen bzgl. der IT- Services, der vereinbarten Dienstleistungen und Qualitäten des Services. Hier kann es sich auch um Anfragen des Kunden bzgl. der vertraglichen Vereinbarungen handeln. An diesem Beispiel wird deutlich, wie vielseitig und heterogen der Status der anfragenden IT-Anwender sein kann und wie auf Seiten des Servicegebers unterschiedliche Rollen gefordert sind (IT-Spezialisten, Service Level Manager etc.). 35

3 Applikation - Eine für das Kerngeschäft des Kunden notwendige Geschäfts-Anwendung ist nicht verfügbar - Fehler in der Anwendung behindern oder verhindern die Arbeit des Kunden oder führen zu falschen Ergebnissen, was katastrophale Auswirkungen auf das Geschäft des Kunden haben kann. - Eine Anwendung überschreitet verfügbare Kapazitäten der Hardware. Beispiel könnte die Überschreitung von Schwellwerten bei Plattenbelegungen sein. Hardware - Ganze Rechnersysteme sind nicht betriebsbereit oder Verbindungen zu den Systemen sind unterbrochen. - Automatische Warnmeldungen aus den Rechnersystemen oder innerhalb der Netzwerke signalisieren Hardware- Probleme. - Konfigurationen sind nicht zugreifbar. - Ein klassisches Beispiel ist auch der aus der Werbung bekannte arg strapazierte Fall: Der Drucker druckt nicht". (Wie es scheint, ist dies eines der ungelösten Probleme der Informatik.) Unabhängig von der Quelle des Incidents lassen sich oft auch folgende Klassifizierungen finden: einfache Anfragen des IT-Anwenders Störungen, also abnormales Systemverhalten Schwerwiegende Störungen, auch Mehrfachstörungen - ganze Benutzergruppen sind betroffen - die Störung verursachte eine lang anhaltende Betriebsunterbrechung Störungen, die als Ursache einen,bekannten Fehler' besitzen und für die es z. B. einen Workaround oder eine andere bekannte Behebung der Störung gibt. Die Übersetzung des Begriffs Workaround macht nur allzu deutlich, dass es sich bestenfalls um eine kurzfristige Lösung 36

4 handelt, bei der man sich mit der Störung arrangiert, sie um geht, aber diese nicht wirklich löst im Sinne von beseitigt". Anfrage nach Änderungen an der IT-Infrastruktur oder an Software Komponenten: der Request forchange (RfC). Ein Request for Change ist ein formaler Änderungsantrag. Der Formalismus bewirkt beim Antragsteller eine gewisse Disziplin, so dass nur ernst gemeinte und wirklich notwendige Anträge überhaupt gestellt werden. Grundsätzlich jedoch gilt: Jeder Kontakt eines IT-Anwenders mit dem Service Desk - der primären und in der Regel einzigen Anlaufstelle eines IT-Anwenders - wird als Incident behandelt und löst einen Prozess im Incident Management aus. Im Service Desk erfolgt in Abhängigkeit vom Typ des Incidents ein entsprechender Prozess als Reaktion auf den gemeldeten Incident. Das Eintreffen eines Incidents löst eine Folge von Prozesssch ritten aus. Die folgenden Basis-Aktivitäten laufen im Incident Management beim Eintreffen eines Incidents ab: Incident Entdeckung und Aufzeichnung Klassifikation und erste Unterstützung Untersuchung und Diagnose Lösung bzw. Beseitigung und (Recovery) Incident Abschluss (Closure) Wiederherstellung Incident Ownership (Verantwortung), Monitoring, Tracking und Kommunikation Abbildung 8 liefert einen Überblick über den Ablauf der Basis- Aktivitäten. 37

5 An diesen Prozessen beteiligte Rollen sind u.a. First (Service Desk), second- und third-line Support-Gruppen, einschließlich Unterstützung durch Spezialisten und externe Zulieferer (Rollen) Incident Manager (Rolle) Service Desk Manager (Funktion) Der Input für diesen Prozess kommt aus den unterschiedlichsten Quellen, wie z. B. dem Service Desk, den Netzwerken oder Operationen auf den Rechnersystemen, beispielsweise über Agenten oder Dienste. Ein zentrales Hilfsmittel für das Incident Management ist die Configuration Management Database (CMDB) zur Verwaltung aller mit den zu erbringenden Dienstleistungen in Zusammenhang stehenden Elementen (Configuration Items). Diese Datenbank liefert alle notwendigen Details über betroffene Services oder Infrastrukturen. Darüber hinaus existieren Datenbanken, die Auskunft über bekannte Probleme oder bekannte Fehler und entsprechende Lösungen oder Workarounds zur Behebung der Incidents liefern können. Auch ein in der Vergangenheit gestellter Request for Change liefert seinen Status und eventuelle Ver- 38

6 änderungen an Services oder der Infrastruktur als Input in die Prozesse des Incident Managements. Output bzw, Ergebnisse der Prozesse des Incident Managements sind z.b. Requests for Change, wenn die Lösung bzw. Beseitigung der Störung in einer Veränderung der Services oder Infrastruktur liegt. Insbesondere die Kommunikation mit dem IT-Anwender über gelöste oder beseitigte Incidents und der formale Abschluss von Incidents gehören zu den Ergebnissen der Incident Management Prozesse, wie auch die Kommunikation mit dem Kunden bezüglich SLA-relevanter Aspekte. Wie das in den einzelnen Teilprozessen des Incident Managements aussieht (vgl. Abbildung 8), wird im Folgenden erläutert. Incident entdecken und aufzeichnen. Teilschritt 1: Incident Entdeckung und Aufzeichnung In diesem ersten Teilschritt wird der Incident entgegen genommen und aufgezeichnet. Aufzeichnen der grundlegenden Details des Incidents Nachdem ein Incident beim Service Desk eingegangen ist, z. B. durch die Anfrage eines IT-Anwenders oder die Meldung einer Störung durch einen System-Administrator, erfolgt das Aufzeichnen der Details des Incidents. Werkzeuge sollten zur Verfügung stehen, um dies effizient zu unterstützen. Benachrichtigen der Spezialisten Support - Gruppen, falls notwendig Ziel ist es, im Service Desk ohne Einschalten weiterer Kräfte 80 % der Incidents zu lösen (Erstlösungrate) und für eine Beseitigung der Störung zu sorgen. Falls dies mit den Kräften und Kenntnissen des Service Desks nicht möglich ist, erfolgt die Aktivierung weiterer Spezialistengruppen auf weiteren Ebenen: dem so genannten Second- oder Third-Level. In ITIL wird dies als funktionale Eskalation bezeichnet. In der Regel handelt es sich hier um die Weitergabe an Support Gruppen, wie z. B. den On Site Support. Starten der Prozeduren für die Behandlung des Service RequestS Nach erfolgreicher Entgegennahme (Entdeckung) und Aufzeichnung erfolgt die eigentliche Behandlung des Incidents in den nachfolgenden Teilprozessen. 39

7 Incident klassifizieren, bewerten, schnelle Lösung bieten oder weiterleiten. Teilschritt 2: Klassifikation und erste Unterstützung im nächsten Teilschritt erfolgen die Klassifikation und eine erste Unterstützung des IT Anwenders oder Kunden 6. Klassifizierung von Incidents und Abbildung gegen bekannte Fehler" oder bekannte Probleme" Ausgehend von den unter Teilschritt 1 aufgezeichneten Details des Incidents und unter Zuhilfenahme zugehöriger Details aus der Configuration Management Database (CMDB) erfolgt hier die Klassifizierung des Incidents. Parameter eines Incident Records zur Klassifizierung können sein: - Der betroffene Service (Impact für den IT-Service) - Die Dauer der Downtime - Die Anzahl der betroffenen Benutzer Ergebnis einer Abfrage verwenden Evtl. wurde im vorhergehenden Schritt auch bereits eine Abfrage an die Datenbank mit bekannten Problemen oder bekannten Fehlern gestellt, deren Ergebnis nun vorliegt und zur Klassifizierung verwendet wird. Informieren des Problem Managements über die Existenz eines neuen Problems und über unbekannte oder mehrfach aufgetretene Incidents Können einem unbekannten Incident keine bekannten Fehler oder bekannte Probleme zugeordnet werden, oder treten Incidents mehrfach auf, muss das Problem Management informiert werden und für eine endgültige Beseitigung der Ursachen für diesen Incident oder Typ von Incidents sorgen. Ob dies eine Hol- oder Bringschuld ist, ist in ITIL nicht beschrieben. In der Praxis ist es so, dass nicht jede unbekannte Ursache vom Problem Management untersucht wird. Sehr oft kommt das Problem Management erst dann ins Spiel, wenn es sich um mehrfach auftretende Störungen mit identischen Symptomen oder um schwere Störungen handelt. 6 Im Allgemeinen wendet sich der Kunde an das Service Level Management. 40

8 Incident Management vs. Problem Management. Zuweisung von Auswirkung", Dringlichkeit" und daraus folgernd Priorität Wichtig für die weitere Verarbeitung ist die Zuweisung dieser Parameter. Aus der Kombination von Auswirkung" und Dringlichkeit" ergibt sich eine Priorität, mit der dieser Incident behandelt werden muss. Bewertung in Zusammenhang stehender Configuration Details und initialer Support Hier erfolgt auch eine erste Bewertung der zum Incident gehörigen Details mit dem Ziel, eine schnelle Lösung zu finden. An dieser Stelle der Hinweis, dass die Aufgaben des Incident Managements evtl. im Widerspruch zu den Aufgaben eines Problem Managements stehen, bei dem es um die langfristige und endgültige Beseitigung einer Ursache für auftretende oder auch nur potentielle Incidents geht. Im Incident Management geht es tatsächlich nur um die schnelle und unter Umständen auch nur provisorische Beseitigung der Störung. Das Problem Management kann sich dann um eine Vorbeugung gegen weiteres Auftreten kümmern. Abschluss des Incidents oder Routen zu einer Spezialisten- Support-Gruppe und Informieren des IT-Anwenders Sollte es bereits hier zu einer Beseitigung der Störung und einer Wiederaufnahme des,normalen" Betriebs - also zu einer in den Grenzen der Service Level Agreements ablaufenden Operation oder Service-Erbringung - gekommen sein, erfolgt hier der Abschluss des Incidents. Alternativ erfolgt die Weiterleitung zu einer Spezialistengruppe zur weiteren Bearbeitung des Incidents. Auch die Beauftragung in Form eines Requests for Change, also der Wunsch nach einer Veränderung des Services oder der IT-Infrastruktur kann erforderlich werden und wird an dieser Stelle vom Incident Management entgegengenommen. Aktualisierte Details des Incidents in der Datenbank sind Ergebnis dieses Teilschritts. Dies kann auch z. B. die Beschreibung eines Workarounds, oder die Weiterleitung zum 2nd oder 3rd-Level Support umfassen. 41

9 Teilschritt 3: Untersuchung und Diagnose In diesem Schritt wird der vorliegende Incidenl Im Detail untei sucht und bewertet. Incident detail- Auf der Basis der bereits im vorangegangenen Teilschritt heran liert untersuchen, gezogenen und aktualisierten Details zum Incident und mit Hilfe Lösung oder aller Einzelheiten, die in der zentralen Datenbank CMDB verfüg Workaround er- bar vorlagen, kommt es zu diesen Aktivitäten: arbeiten. Bewertung der Incident Details Alle nun vorliegenden Einzelheiten werden bewertet. Es erfolgt eine Analyse aller in Zusammenhang mit dem Incident stehenden Informationen. Lösung oder Weiterleitung Das Ergebnis der Analyse und Diagnose sollte eine Lösung des Incidents sein. Dies umfasst auch einen Workaround (Umgehungslösung), der die IT-Anwender in die Lage versetzt, ihre Aufgaben - evtl. auch mit verringertem oder kurzfristig verschlechtertem Service - weiter zu erledigen. Der Prozess der Untersuchung und Diagnose kann die Weiterleitung an eine Spezialistengruppe erfordern, in der die Elimination der Ursachen für den Incident angestrebt wird. Dies wird evtl. sogar zu einem iterativen Prozess unter Einbeziehung verschiedener unterstützender Gruppen. Die Koordination und Verantwortung für diesen Prozess, der sich möglicherweise über mehrere Tage und damit verbunden z. B. auch Schichtwechsel des Personals erstreckt, erfordert eine rigorose und disziplinierte Kontrolle. Der Dokumentation der durchgeführten Aktivitäten und die Aktualisierung der Detaildaten des Incidents einerseits steht die ständige Information des IT-Anwenders andererseits gegenüber. Somit ist der Service Desk als zentrale Funktion im Incident Management für die Koordination aller Aufgaben rund um Untersuchung und Diagnose des Incidents verantwortlich. Teilschritt 4: Lösung und Wiederherstellung (Recovery) Alle in den vorherigen Schritten beauftragten oder durchgeführten Lösungsschritte laufen nun hier zusammen und ihre Ergebnisse werden verwendet, um die Lösung oder Beseitigung des Incidents herbeizuführen. 42

10 Incident beseitigen und Service wiederherstellen. Bei den vorliegenden Details kann es sich um Folgendes handeln: Workaround Es wurde eine Umgehungslösung erarbeitet. Die Ursache für den Incident wurde (noch) nicht beseitigt, aber es gibt eine kurzfristige und hoffentlich vorübergehende Umgehung der Störung. Die IT-Anwender können mit verringertem Service weiter arbeiten. Hier noch einmal der Hinweis: es ist nicht Aufgabe des Incident Managements, für die gründliche und evtl. langwierige Beseitigung der Ursachen zu sorgen, sondern die schnelle Wiederaufnahme der Geschäftsprozesse der Anwender zu ermöglichen. Lösung Hierbei kann es sich um eine schnelle und unbürokratische Lösung der Störung handeln: Nachfüllen von Toner oder Papier in einen Drucker ist genauso ein Beispiel dafür wie das Rücksetzen eines Passwortes. Antwort auf einen vorangegangenen Request for Change Die Beauftragung oder besser der Wunsch nach einer Veränderung in der Infrastruktur oder den Dienstleistungen wurde vom zuständigen Bereich beantwortet. Dies kann die Erledigung des Auftrags, aber auch die Abweisung beinhalten. Auf der Basis dieser Details erfolgen nun die Aktivitäten zur Lösung und Wiederherstellung: Lösung oder Beseitigung des Incidents Beauftragung eines Request for Change alternativ Aktionen zur Wiederherstellung (Recovery) Diese Aktivitäten werden in den meisten Fällen noch von den beauftragten Support-Teams durchgeführt. Hier wird der Workaround beim IT-Anwender installiert, die Lösung herbeigeführt oder auch - falls erforderlich - ein Request for Change beauftragt. Falls Aktionen zur Wiederherstellung einer bestimmten Infrastruktur-Konfiguration oder eines Anwendungs- oder System- Zustands erforderlich sind, werden diese nun ausgeführt und der ursprüngliche Zustand wieder hergestellt (Recovery). 43

11 Teilschritt 5: Incident Abschluss Nach der erfolgreichen Lösung oder Beseitigung eines Incidents erfolgt ein formeller Abschluss in diesem Teilschritt Incident formell Bestätigung der Lösung bzw. Beseitigung an den IT-Anwenabschließen und der dokumentieren. Abschluss" der Kategorie Incident Der IT-Anwender, der den Incident ursprünglich gemeldet hat, wird ständig während der Prozesse über den Status des Incidents informiert. Hier erfolgt nun die endgültige Bestätigung über die Lösung bzw. Beseitigung des Incidents. In den Datenbanken werden die betroffenen Datensätze mit den Details zum Incident aktualisiert und der Datensatz geschlossen. Nach dem Abschluss des Incidents werden die Details aller durchgeführten Aktionen zur Lösung knapp, präzise und lesbar dokumentiert: vollständige und akkurate Klassifizierung des Incidents nach den Ursachen Dokumentation der mit dem Kunden oder IT-Anwender (verbal, , schriftlich) vereinbarten Aktivitäten zur Lösung oder Beseitigung Aufzeichnung aller Details wie IT-Anwenderzufriedenheit; Projekt-Codes der beauftragten Support-Gruppen bzw. Cost- Center; Aufwand; Personen, Datum, Zeit des Abschlusses etc. Begleitende Schritte: Incident Ownership, Monitoring, Tracking und Kommunikation Begleitend zu den vorgestellten Teilschritten erfolgen Prozesse, die notwendig sind, um die Übernahme der Verantwortung für den Incident, die ordnungsgemäße Dokumentation und Verfolgung und die Kommunikation zu allen beteiligten Gruppen sicher zu stellen. 44

12 Dies umfasst u. a.: Monitoren (Erkennung, Verfolgung, Aufzeichnung) Von Incidents Eskalation von Incidents Hier kann man zwischen funktionaler Eskalation" und hierarchischer Eskalation" unterscheiden: Funktionale Eskalation bezeichnet die Weiterleitung an andere Supportgruppen. Ist ein SLA gefährdet, so erfolgt eine hierarchische Eskalation an das verantwortliche Management. Beim Überschreiten von zeitlichen Grenzen müssen Incidents in die nachfolgenden Eskalationsstufen (2nd oder 3rd Level) überführt werden. Eine automatische Erkennung solcher Fälle verhindert, dass Incidents ungelöst zu lange in einer Instanz verbleiben und dort vergessen werden. Werkzeuge können hier helfen und bei einer Zeitüberschreitung mit automatischen Benachrichtigungen reagieren. Aber auch die fachlich notwendige Weiterleitung auf Grund fehlender Kenntnisse, z. B. im Service Desk, bedeutet eine Eskalation. Fortlaufende In- Informieren des IT-Anwenders formation der Die fortlaufende Information des IT-Anwenders über den Kunden oder IT- Status der Incidents ist kein Luxus, sondern notwendige und Anwender durch in den vertraglichen Vereinbarungen (Service Level Agreedie zentrale Funk- ments) festgelegte Aufgabe des Incident Managements. Als tion: Service Desk zentrale Funktion innerhalb des Incident Managements und Schnittstelle zum IT-Anwender muss der Service Desk diese wichtige Aufgabe sicherstellen. Management Reports Die Erstellung von Reports über den Fortschritt der Incident- Behandlung ist eine weitere wichtige Aufgabe, die in diesen begleitenden Prozessen erledigt wird. Hier können auch Kunden-Reports erstellt werden und z. B. über die Erbringung der in den Service Level Agreements festgelegten Dienstleistungen berichten. Dies ist ein wichtiges Instrument bei den Verhandlungen des Kunden über ordnungsgemäße Leistungserbringung oder im negativen Fall Überschreitung von festgesetzten Grenzwerten (z. B. Reaktions- und Lösungszeiten). 45