„Lebenszyklusmanagement von Vorfällen? Wenn wir es schaffen, von einem Vorfall zum nächsten durchzuhalten, ist es ein guter Tag. An einem schlechten Tag herrscht Panik.“

Leider ist das die Realität Vorfall-Lebenszyklusmanagement Für viel zu viele Software- und IT-Unternehmen ist das ein Problem – aber das muss nicht sein. Tatsächlich kann ein echtes, proaktives Incident-Lifecycle-Management verhindern, dass Incident-Response-Teams in einen chronischen Überlebens- oder Panikmodus verfallen.

Das Incident Lifecycle Management ist ein Rahmenwerk für die Kategorisierung, Reaktion, Lösung und Dokumentation von Incidents, um deren effektive Bearbeitung mit minimalem Serviceverlust und gut organisierter Nachverfolgung zu gewährleisten. Ein durchgängiges Rahmenwerk zur Incident-Lösung ist für die Aufrechterhaltung kritischer Services von entscheidender Bedeutung.

Kundenzentriertes Incident Management

Die meisten modernen Incident-Management-Systeme basieren in unterschiedlichem Maße auf dem ITIL-Modell, das erstmals in den 1980er Jahren von der britischen Central Computing and Telecommunications Agency (CIAA) entwickelt wurde. Das ITIL-Modell konzentriert sich auf die Aufrechterhaltung der Dienste für Kunden und Auftraggeber, im Gegensatz zur Wartung wichtiger Systeme streng nach technischen Spezifikationen. Dies macht es zu einem idealen Modell für die Reaktion auf Vorfälle in nach außen gerichteten Anwendungen, bei denen die Wartung der Benutzerdienste von großer Bedeutung ist. Die wichtigsten Elemente des ITIL-Modells, die beim Einrichten eines Incident-Lifecycle-Management-Frameworks zu beachten sind, sind:

Erste Reaktion

In dieser Phase werden eingehende Warnmeldungen protokolliert, kategorisiert und an die entsprechenden Teams weitergeleitet. Dies ist in vielerlei Hinsicht der wichtigste Teil des Incident-Management-Lebenszyklus, da hier Probleme erkannt und Rauschen herausfiltern (Warnmeldungen ohne Handlungsbedarf), legen Sie Prioritäten fest und bestimmen Sie, wohin jede Warnmeldung weitergeleitet werden soll.

Wird dieser Teil des Prozesses nicht angemessen verwaltet, kann dies dazu führen, dass wichtige Warnmeldungen übersehen, mit zu niedriger Priorität behandelt oder an die falschen Einsatzkräfte weitergeleitet werden. Zudem kann es zu einer unausgewogenen Arbeitsbelastung der Einsatzteams kommen.

Antwort der Stufe 1

Nachdem eine Warnung kategorisiert wurde, wird sie an ein Reaktionsteam der Stufe 1 weitergeleitet. Diese Teams sind die Ersthelfer. Ihre Aufgabe ist es, den Vorfall zur Zufriedenheit des Kunden zu lösen, in der Regel innerhalb eines festgelegten Zeitrahmens. Das Team der Stufe 1 untersucht den Vorfall, ermittelt das grundlegende Problem und wendet, soweit möglich, bekannte oder empfohlene Abhilfemaßnahmen an.

Der Level-1-Support überwacht außerdem den Status des Vorfalls, insbesondere im Hinblick auf die Eskalation. Eine weitere wichtige Aufgabe des Level-1-Supports besteht darin, die Kommunikation mit dem betroffenen Kunden aufrechtzuerhalten und Statusaktualisierungen in vertraglich oder durch Unternehmensrichtlinien festgelegten Intervallen bereitzustellen. Dies ermöglicht die Aufrechterhaltung eines konsistenten Kommunikations- und Supportkanals, auch wenn der Vorfall an den Support der höheren Ebene weitergeleitet wurde.

Reaktion der Stufe 2

Wenn ein Vorfall die Diagnose- und schnelle Lösungskapazität des Level-1-Supports übersteigt, wird er normalerweise an ein Level-2-Supportteam weitergeleitet, das in der Regel mehr Ressourcen und Erfahrung einbringen kann.

Level-2-Teams können auch spezialisierten Support und Support von Drittanbietern (Herstellern, Lieferanten usw.) hinzuziehen. Das grundlegende Ziel des Level-2-Supports ist dasselbe wie bei Level 1: die schnellstmögliche Wiederherstellung des Dienstes für den Kunden oder Klienten.

Berichterstattung und Überprüfung nach der Lösung

Das formale ITIL-Modell unterteilt dies in zwei Prozesse: Abschluss und Auswertung sowie Incident Management Reporting. Für viele Organisationen, insbesondere kleinere, ist es möglicherweise praktischer, diese in einem einzigen Prozess zu kombinieren.

Die wichtigsten Elemente jeder Nachbereitung nach der Lösung sind die Überprüfung, Aufzeichnung und Bewertung der Lösung (oder des Fehlens einer solchen) sowie die vollständige Berichterstattung der Einzelheiten des Vorfalls (normalerweise mit einem Obduktionsbericht ). Obduktion des Vorfalls Berichte sollten in eine Informationsdatenbank eingegeben werden, die Reaktionsteams und Managern zur Verfügung steht und die ausreichend indiziert und durchsuchbar ist, um als leicht zugängliche Informationsquelle für die Reaktion auf (und hoffentlich Verhinderung) zukünftiger Vorfälle zu dienen.

Weitere wichtige Themen

Zusätzlich zu den oben aufgeführten Elementen umfasst das ITIL-Modell zwei weitere Faktoren, die in jedem realistischen Incident-Lifecycle-Management-System eine Rolle spielen:

Handhabung schwerwiegender Vorfälle

Schwerwiegende Störungen stellen typischerweise eine unmittelbare, ernsthafte Bedrohung für den Betrieb oder die Sicherheit der Basisinfrastruktur oder wichtiger Dienste dar. Ziel ist zwar immer noch, das System schnellstmöglich wieder betriebsbereit zu machen, die Priorität und die erste Reaktionsstufe können jedoch deutlich höher sein. Eine schwerwiegende Störung kann direkt an die Stufe 2, an ein spezialisiertes Supportteam oder sogar an den Support eines Drittanbieters weitergeleitet werden (z. B. wenn eine wichtige Komponente der Hardware-Infrastruktur ausfällt).

Jede Organisation hat möglicherweise ihre eigenen Standards dafür, was einen schwerwiegenden Vorfall ausmacht. Für die meisten Organisationen ist es jedoch wichtig zu erkennen, dass schwerwiegende Vorfälle eine eigene Kategorie mit einer wesentlich höheren Priorität und Reaktion darstellen.

Problemumgehungen

Da eine der obersten Prioritäten des Incident Managements im ITIL-Modell darin besteht, den Kundenservice so schnell wie möglich aufrechtzuerhalten oder wiederherzustellen, kann die anfängliche Lösung Workarounds beinhalten – beispielsweise ein Rollback. Dies gilt auf allen Ebenen. Die Logik ist einfach: Wenn Sie den Kundenservice jetzt wiederherstellen, haben Sie das unmittelbare Problem gelöst und die ES oder Entwicklungsteam kann sich dann so viel Zeit nehmen wie nötig, um die zugrunde liegenden Probleme zu lösen.

Es ist wichtig, alle Workarounds zu protokollieren und zu identifizieren, sowohl im Vorfallberichtssystem als auch bei der Planung von IT- und Entwicklungsupdates, da jeder Workaround zu technische Schulden , deren Kosten im Allgemeinen umso höher werden, je länger die Zahlung unbezahlt bleibt. Dies bedeutet, dass Workarounds, die sich aus Reaktion auf Vorfälle sollten so schnell wie möglich durch Lösungen ersetzt werden, die den Systemdesignstandards entsprechen. In vielerlei Hinsicht ist ein Vorfall erst dann vollständig behoben, wenn alle Workarounds durch dauerhaftere Lösungen ersetzt wurden.

Es besteht wirklich keine Notwendigkeit, dass Ihr Incident-Response-Team von Tag zu Tag im Überlebensmodus arbeitet. In einer Welt, in der es noch nie so teuer war, auf Probleme mit Auswirkungen auf den Kunden unvorbereitet zu sein, führt dies zu Chaos und Angst.

Mit einem Rahmen für das Vorfalllebenszyklusmanagement Mit maßgeschneiderten Lösungen für Ihr Unternehmen können Sie kritische Anwendungen und Infrastrukturen mit minimalen Serviceunterbrechungen und Belastungen am Laufen halten. Die Implementierung des Best-Practice-Incident-Lifecycle ist der Schlüssel zur Zuverlässigkeit. Und Zuverlässigkeit selbst ist ein unverzichtbarer Service, der Ihren langfristigen Erfolg bestimmt.