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

Leider ist das die Realität Vorfall-Lebenszyklus-Management für viel zu viele Software- und IT-Unternehmen – aber das muss nicht so sein. Die Wahrheit ist, dass ein echtes, proaktives Incident-Lifecycle-Management verhindern kann, dass Incident-Response-Teams in den chronischen Überlebens- oder Panikmodus verfallen.

Das Incident-Lifecycle-Management ist ein Rahmenwerk zum Kategorisieren, Reagieren, Lösen und Dokumentieren von Incidents, sodass diese effektiv und mit minimalem Serviceverlust und gut organisierter Nachverfolgung bearbeitet werden können. Ein End-to-End-Framework 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 entwickelt wurde. Das ITIL-Modell konzentriert sich auf die Aufrechterhaltung der Dienste für Klienten und Kunden, 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 von Benutzerdiensten von großer Bedeutung ist. Die wichtigsten Elemente des ITIL-Modells, die beim Einrichten eines Rahmens für das Incident-Lifecycle-Management zu beachten sind, sind:

Erste Reaktion

In dieser Phase werden eingehende Warnmeldungen protokolliert, kategorisiert und an die entsprechenden Teams weitergeleitet. In vielerlei Hinsicht ist dies der wichtigste Teil des Incident-Management-Lebenszyklus, denn hier erkennen Sie Probleme 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 gemanagt, kann es passieren, dass wichtige Alarme übersehen, mit zu niedriger Priorität behandelt oder an die falschen Einsatzkräfte weitergeleitet werden. Auch kann es zu einer unausgewogenen Arbeitsbelastung der Einsatzteams kommen.

Level 1-Antwort

Nachdem eine Warnung kategorisiert wurde, wird sie an ein Level-1-Reaktionsteam gesendet. Level-1-Teams sind die Ersthelfer. Ihre Aufgabe besteht darin, den Vorfall zur Zufriedenheit des Kunden zu lösen, normalerweise innerhalb eines bestimmten Zeitrahmens. Das Level-1-Team untersucht den Vorfall, findet heraus, was das grundlegende Problem ist, 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 oder Klienten aufrechtzuerhalten und Statusaktualisierungen in vertraglich oder durch Organisationsrichtlinien festgelegten Intervallen bereitzustellen. Auf diese Weise ist es möglich, einen konsistenten Kommunikations- und Supportkanal aufrechtzuerhalten, selbst wenn der Vorfall an den Support auf höherer Ebene weitergeleitet wurde.

Level 2-Antwort

Wenn ein Vorfall die Diagnose- und Lösungskapazitäten des Level-1-Supports übersteigt, wird er normalerweise an ein Level-2-Supportteam weitergeleitet, das im Allgemeinen über mehr Ressourcen und Erfahrung verfügen kann.

Level-2-Teams können auch spezialisierten Support und Support von Drittanbietern (Hersteller, Anbieter usw.) in Anspruch nehmen. Das grundlegende Ziel des Level-2-Supports bleibt das gleiche wie bei Level 1: den Service für den Kunden oder Klienten so schnell wie möglich wiederherzustellen.

Berichterstattung und Überprüfung nach der Lösung

Das formale ITIL-Modell unterteilt dies in zwei Prozesse: Abschluss und Auswertung sowie Vorfallmanagement-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 den Einsatzteams und Managern zur Verfügung steht und über ausreichende Indizes und Suchfunktionen verfügt, um als leicht zugängliche Informationsquelle für die Reaktion auf (und hoffentlich auch für die Verhinderung) künftiger Vorfälle zu dienen.

Andere wichtige Themen

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

Handhabung schwerwiegender Vorfälle

Schwerwiegende Störungen sind in der Regel solche, die eine unmittelbare, ernsthafte Bedrohung für den Betrieb oder die Sicherheit der Basisinfrastruktur oder wichtiger Dienste darstellen. Das Ziel ist zwar immer noch, das System so schnell wie möglich wieder zum Laufen zu bringen, aber die Priorität und die anfängliche Reaktionsstufe können viel höher sein. Eine schwerwiegende Störung kann direkt an Stufe 2, an ein spezialisiertes Supportteam oder sogar an den Support eines Drittanbieters weitergeleitet werden (beispielsweise, 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 Reaktionsstufe 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 das ES oder Entwicklungsteam Sie können 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, denn jeder Workaround führt zu Technische Schulden , deren Kosten im Allgemeinen umso höher werden, je länger sie unbezahlt bleiben. Das 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 für Ihr Incident-Response-Team wirklich keine Notwendigkeit, Tag für Tag im Überlebensmodus zu arbeiten. In einer Welt, in der es noch nie so teuer war, auf Probleme mit Auswirkungen auf den Kunden nicht vorbereitet zu sein, führt dies zu Chaos und Angst.

Mit einem Framework zur Vorfall-Lebenszyklusverwaltung Auf die Bedürfnisse Ihres Unternehmens zugeschnitten, können Sie kritische Anwendungen und Infrastrukturen mit minimalen Serviceunterbrechungen und Belastungen am Laufen halten. Die Implementierung des Best-Practice-Incident-Lebenszyklus ist der Schlüssel zur Zuverlässigkeit, und Zuverlässigkeit selbst ist ein unverzichtbarer Service, der Ihren langfristigen Erfolg mitbestimmt.