Was ist eine Incidentanalyse?
Wir haben dies in einem früheren Modul in diesem Lernpfad erwähnt, hier aber noch einmal ein kurzer Überblick: Der Lebenszyklus von Incidents sieht wie folgt aus:
Ein Incident durchläuft die folgenden Phasen:
- Erkennung: Hier bemerken wir erstmals, dass ein Problem vorliegt (idealerweise von unserem Überwachungssystem, bevor uns ein Kunde benachrichtigt oder sich beschwert).
- Antwort: Wir handeln sofort, wenden unseren Incident-Response-Prozess an, versuchen uns einen Überblick über die Situation zu verschaffen und umgehend zu reagieren.
- Behebung: Wir arbeiten daran, das Problem zu ermitteln und das System oder den Dienst wieder in Gang zu bringen.
- Analyse: Nach dem Incident versuchen wir, aus der Erfahrung zu lernen und eventuell Punkte zu ermitteln, die wir im System oder in unserem Prozess ändern sollten.
- Vorbereitung: Wir nehmen Änderungen basierend auf den Erkenntnissen vor, die unsere Zuverlässigkeit und den zugehörigen Kontext (Prozesse usw.) verbessern können.
Das Thema dieses Moduls betrifft größtenteils die Analysephase. Wir lernen anhand von Incidents, indem wir eine Incidentanalyse vornehmen.
Nach jedem signifikanten Incident sollten Sie eine Incidentanalyse durchführen.
Obwohl die formale Überprüfung nach den Reaktions-und Wartungsphasen erfolgt, beginnen Sie mit dem Festlegen der Phase für die Analyse. Sobald Sie eine handlungsrelevante Warnung erhalten, dass ein Incident aufgetreten ist, informieren Sie die Teammitglieder und beginnen mit einer Konversation über den Incident.
Definieren der Incidentanalyse
Nicht jeder verwendet genau dieselbe Formulierung, um auf diesen Prozess zu verweisen. Einige Leute nennen es:
- Incidentanalyse
- Lernprozess der Incidentanalyse
- Postmortem
- Retrospektive
In diesem Modul wird der Begriff „Incidentanalyse“ verwendet.
Außerdem wird dieser Prozess nicht von allen auf genau dieselbe Weise durchgeführt. Viele fangen zum Beispiel damit an, alle Personen, die mit dem Incident im Zusammenhang stehen, in einem Raum zusammenzubringen, während andere die Überprüfung mittels einzelner Interviews vornehmen und anschließend der Gruppe Bericht erstatten.
Die letztere Methode funktioniert häufig besser, wenn die Gruppeneinstellungen in Ihrer Organisation eine einzelne größere Besprechung erschweren. Wenn etwa die Gruppendynamik, die Persönlichkeiten oder eine räumliche Verteilung eines Teams (verschiedene Zeitzonen) diese Art der Besprechung erschweren, kann es einfacher sein, die Überprüfung auf andere Weise anzugehen. Sie sollten das tun, was für Ihr Team und unter den gegebenen Umständen am besten geeignet ist.
Wie auch immer Sie es nennen und organisieren, Sie sollten drei wichtige Punkte beachten:
- Sie sollten versuchen, alle an der Incident Response beteiligten Personen in die Incidentanalyse einzubeziehen. Das Einbeziehen all dieser Stimmen ist wichtig, da verschiedene Personen unterschiedliche Perspektiven auf dasselbe Ereignis und verschiedene Erinnerungen daran haben werden.
- Sie sollten die Incidentanalyse innerhalb von 24 bis 36 Stunden nach dem Ereignis durchführen, sofern dies möglich ist. Die Neurowissenschaft hat bestätigt, dass das menschliche Erinnerungsvermögen bekanntermaßen unzuverlässig ist. Menschen vergessen Inhalte. Je mehr Zeit nach einem Ereignis verstrichen ist, desto weniger ausführliche und spezielle Erinnerungen liegen in der Regel vor.
- Eine Überprüfung des Incidents muss ohne Schuldzuweisung erfolgen. Dies wird in der nächsten Einheit ausführlicher erläutert.
Zweck der Incidentanalyse
Ziel der Incidentanalyse ist es, dass Ihr Team daraus lernen und sich verbessern kann. Sie sollten die Systeme und Maßnahmen untersuchen, die funktioniert oder nicht funktioniert haben, damit Sie Verbesserungen vornehmen können.
Gleichzeitig sollten Sie daran denken, dass die von Ihnen generierten Aktionselemente – Berichte, Aufgaben, Fehlerberichte, Tickets, Feedback – zwar nützlich, aber in dem Prozessschritt, in dem es um das Lernen und Verbessern geht, nebensächlich sind. Die Erstellung einer Liste von Aktionselementen ist bestenfalls ein zweitrangiges Ziel.