Bildquelle: Pexels
Post-Incident-Reviews im ITSM: Welche 5 Bausteine aus Störungen echte Lernschleifen machen
Viele IT-Organisationen betreiben Incident Management inzwischen ordentlich, aber stolpern direkt nach der Entstörung in dieselbe Falle: Sobald das System wieder läuft, zieht das Tagesgeschäft alle Aufmerksamkeit ab. Genau dort verliert das Unternehmen den größten Lernhebel. Eine Post-Incident-Review, oft auch Postmortem oder Major-Incident-Review genannt, ist kein Bürokratie-Nachspiel. Sie ist der Moment, in dem aus einem teuren Vorfall belastbare Verbesserung entsteht.
Das ist nicht nur ein kulturelles Thema, sondern auch ein betriebswirtschaftliches. Google beschreibt Postmortems seit Jahren als zentrales Instrument, um wiederkehrende Ursachen sichtbar zu machen, systemische Schwächen zu adressieren und Wiederholungen zu vermeiden. Im SRE Workbook verweist Google zudem auf die Auswertung tausender Postmortems, bei denen Softwarefehler, Entwicklungsprozessversagen und komplexe Systemeffekte zu den häufigsten Ursachen gehörten. PagerDuty formuliert es praxisnäher: Für jeden größeren Vorfall braucht es einen blamefreien, detaillierten Nachlauf mit klaren Folgemaßnahmen. Für ITSM-Teams heißt das übersetzt: Eine gute Review entlastet nicht nur die Technik, sondern auch Service Desk, Change Advisory Board, Service Owner und Business Stakeholder beim nächsten Mal.
Die eigentliche Frage ist also nicht, ob man Post-Incident-Reviews macht, sondern wie sie so aufgesetzt werden, dass sie im Betrieb wirklich etwas verändern.
1. Vor dem nächsten Incident festlegen, wann eine Review Pflicht ist
Der häufigste Fehler beginnt lange vor der eigentlichen Analyse. Teams entscheiden erst nach einer Störung aus dem Bauch heraus, ob sich der Aufwand für eine Review lohnt. Genau das führt zu Lücken und politischen Diskussionen. Google empfiehlt deshalb ausdrücklich, die Trigger vorab zu definieren. Typische Kriterien sind sichtbare Service-Degradation für Nutzer, Datenverlust, manuelle Eingriffe durch On-Call- oder Betriebsteams, lange Lösungszeiten oder Monitoring-Ausfälle.
Im ITSM-Kontext sollte daraus eine einfache Regelmatrix entstehen: Welche Auswirkungen auf Verfügbarkeit, Bearbeitungszeit, SLA-Verletzung, Kundenkommunikation oder Eskalationsstufe lösen automatisch eine Review aus? Wer das nicht vorab festzieht, bekommt eine Review-Kultur nach Sympathie statt nach Risiko.
2. Eine verantwortliche Person benennen und eine kurze Taktung erzwingen
Eine gute Review scheitert selten an fehlenden Meinungen, aber oft an fehlender Zuständigkeit. PagerDuty empfiehlt deshalb, direkt nach einem Major Incident einen Owner zu benennen. Diese Person sammelt Daten, koordiniert Beiträge, bereitet die Zeitleiste vor, zieht andere Teams hinzu und organisiert den Termin. Ebenso wichtig ist der zeitliche Rahmen. Wenn die Review erst zwei oder drei Wochen später stattfindet, sind Chatverläufe lückenhaft, Kontext geht verloren und unangenehme Details werden weichgespült.
Praktisch hat sich ein enger Rhythmus bewährt: Termin sofort setzen, Review innerhalb weniger Arbeitstage durchführen, offene Maßnahmen direkt danach in das normale Steuerungsmodell überführen. Für klassische ITSM-Organisationen heißt das konkret: Action Items gehören nicht in eine lose Nachverfolgung per Mail, sondern in das bestehende Backlog, ins Problem Management oder in die Change-Pipeline, je nach Art der Maßnahme.
3. Die Zeitleiste evidenzbasiert aufbauen, nicht aus Erinnerung
Eine belastbare Post-Incident-Review besteht nicht aus Erzählungen, sondern aus überprüfbaren Datenpunkten. PagerDuty empfiehlt, jede wichtige Station in der Timeline mit Metriken, Logs, Statusseiten, Suchabfragen oder anderen Belegen zu hinterlegen. Google betont ebenfalls, dass Impact und Verlauf nur dann wirklich auswertbar sind, wenn Zahlen, Zeitpunkte und Zusammenhänge sauber dokumentiert werden.
Gerade im ITSM ist das entscheidend, weil hier nicht nur die technische Ursache zählt. Eine gute Review beantwortet mindestens vier Fragen mit Daten:
- Wann begann die tatsächliche Servicebeeinträchtigung?
- Wann wurde sie erkannt, eingeordnet und kommuniziert?
- Welche Nutzer, Services, Transaktionen oder Prozesse waren konkret betroffen?
- Welche Maßnahmen haben den Zustand verbessert, verschlechtert oder gar nicht verändert?
Dieser Punkt trennt operative Reife von Rückschau-Rhetorik. Wer eine Timeline nur aus Chat-Erinnerungen rekonstruiert, übersieht fast immer Verzögerungen zwischen erster Anomalie, Incident-Declaration, Eskalation und externer Kommunikation. Genau dort sitzen aber oft die teuersten Lücken.
4. Zwischen Auslöser, beitragenden Faktoren und individueller Schuld unterscheiden
Blameless heißt nicht folgenlos. Es heißt, dass die Analyse nicht an der Person hängen bleibt, die zufällig den sichtbaren Fehler ausgelöst hat. Google formuliert das sehr klar: Menschen handeln in komplexen Lagen mit den Informationen und Systemen, die ihnen gerade zur Verfügung stehen. Wer nur einen Bedienfehler benennt, verpasst die eigentlichen Verbesserungshebel im Systemdesign, in Freigaben, in Runbooks, in Alarmierung oder in der Change-Qualität.
Für ITSM-Teams ist diese Unterscheidung extrem wertvoll. In fast jedem schweren Vorfall gibt es einen Trigger, aber mehrere beitragende Faktoren. Ein fehlerhaftes Deployment kann etwa der Auslöser sein. Dass daraus ein Major Incident wird, liegt dann oft zusätzlich an unklaren Rollback-Schritten, fehlenden Abhängigkeiten im CMDB-Kontext, schwachen Monitoring-Schwellen oder unklaren Verantwortlichkeiten zwischen Betrieb und Entwicklung.
Wer diese Ebenen sauber trennt, landet nicht bei der billigen Maßnahme Team sensibilisieren, sondern bei wirksamen Verbesserungen.
5. Nur wenige, harte Maßnahmen beschließen und sichtbar nachverfolgen
Der Abschluss einer Review ist nicht das Meeting, sondern die Umsetzung. PagerDuty warnt ausdrücklich davor, zu viele Tickets anzulegen. Sinnvoll sind wenige Maßnahmen mit echtem Risikobeitrag, klarer Zuständigkeit und Priorität. Auch Googles Beispiele zeigen, dass gute Postmortems zwischen präventiven, mitigierenden und prozessbezogenen Maßnahmen unterscheiden.
Für die Praxis bedeutet das: Jede Review sollte mit einem kleinen, belastbaren Maßnahmenpaket enden. Typischerweise gehören dazu eine technische Präventionsmaßnahme, eine operative Verbesserungsmaßnahme und eine Kommunikations- oder Prozesskorrektur. Wichtig ist außerdem, dass diese Punkte nicht im Incident-Tool versanden. Service Owner, Problem Manager und Plattformverantwortliche müssen dieselben Maßnahmen in ihrer regulären Steuerung wiederfinden.
Ein gutes Prüfmaß ist einfach: Wenn 30 Tage nach der Review niemand mehr sagen kann, welcher Vorfall welche Veränderung ausgelöst hat, war die Review formal vorhanden, aber betrieblich wertlos.
Was ITSM-Teams jetzt konkret einführen sollten
- Review-Trigger definieren: Major Incidents, SLA-Verletzungen, Datenverlust, manuelle Notmaßnahmen und Kommunikationsvorfälle vorab als Pflichtfälle festlegen.
- Owner-Modell festziehen: Jede Review braucht genau eine verantwortliche Person mit Termin- und Lieferpflicht.
- Timeline-Standard bauen: Ereignisse immer mit Logs, Monitoring, Ticketzeiten und Statusmeldungen belegen.
- Impact quantifizieren: Betroffene Nutzer, Ausfallzeit, SLA-Verzug, Transaktionsverlust oder Ticketanstieg konkret benennen.
- Maßnahmen begrenzen: Lieber drei starke Action Items mit Owner und Fälligkeit als zwölf lose Absichtserklärungen.
- Lernschleife schließen: Ergebnisse ins Problem Management, in Changes, in Runbooks und in Service-Reviews zurückführen.
Post-Incident-Reviews sind damit weit mehr als ein Ritual aus der SRE- oder DevOps-Welt. Richtig eingesetzt, sind sie ein Kerninstrument für modernes IT Service Management. Sie verbessern Incident Response, machen Servicequalität messbarer und verhindern, dass dieselben Störungen in neuer Verpackung wiederkommen. Gerade in Organisationen mit vielen Übergaben zwischen Service Desk, Betrieb, Plattformteams und Fachbereichen entsteht hier echter Wert: weniger Wiederholung, klarere Verantwortlichkeiten und bessere Entscheidungen unter Druck.
