Bildquelle: Pexels / Photo by SpaceX: https://www.pexels.com/photo/group-of-colleagues-working-in-modern-office-with-big-map-on-screen-586104/
Post-Incident-Reviews im IT Service Management: Fünf Regeln, damit aus Major Incidents messbare Verbesserungen werden
Viele Organisationen behandeln einen Major Incident als beendet, sobald der Service wieder läuft, die Kommunikation beruhigt ist und das Ticket geschlossen werden kann. Genau dort beginnt in Wirklichkeit der zweite, oft wichtigete Teil der Arbeit. Denn ein sauber gelöster Incident verhindert noch keinen Wiederholungsfehler. Er sorgt nur dafür, dass der akute Schaden stoppt.
Wenn Service-Organisationen 2026 mit dichterer Änderungsfrequenz, mehr SaaS-Abhängigkeiten und engeren Geschäftszeiten stabil bleiben wollen, müssen Post-Incident-Reviews mehr leisten als eine Timeline und drei lose To-dos. Sie müssen Incident Management, Problem Management, Change Enablement und Wissensmanagement zusammenbringen. Sonst bleibt aus dem teuersten Lernmoment des Betriebs nur ein Protokoll ohne Wirkung.
Google beschreibt Postmortems deshalb nicht als formale Pflicht, sondern als Werkzeug, um Ursache, Auswirkung und wirksame Präventionsmaßnahmen belastbar festzuhalten. Gerade dieser Punkt ist für ITSM-Teams zentral. Ein Review ist nicht dann gut, wenn es vollständig klingt. Es ist gut, wenn daraus weniger Folgeausfälle, schnellere Diagnose und sauberere Changes entstehen.
Was dafür in der Praxis sitzen muss, zeigen fünf Regeln.
1. Vor dem nächsten Vorfall definieren, wann ein Review verpflichtend ist
Die erste Schwäche vieler Organisationen ist nicht die Qualität einzelner Reviews, sondern die fehlende Auslöselogik. Wenn erst nach einem Vorfall diskutiert wird, ob ein Review „wirklich nötig“ ist, gewinnt fast immer der Tagesbetrieb. Dann werden nur spektakuläre Ausfälle analysiert, während wiederkehrende Störungen mit hohem Arbeitsaufwand unter dem Radar bleiben.
Google empfiehlt deshalb objektive Trigger vorab festzulegen. Dazu zählen etwa nutzersichtbare Ausfälle, Datenverlust, Eingriffe des On-Call-Teams, ungewöhnlich lange Wiederherstellungszeiten oder auch ein Monitoring-Versagen. Für ITSM-Organisationen lässt sich das sehr gut übersetzen: Ein Post-Incident-Review sollte verpflichtend sein, wenn ein Major Incident ausgerufen wurde, wenn mehrere Teams beteiligt waren, wenn ein manueller Notfall-Change nötig war, wenn Eskalationswege versagt haben oder wenn derselbe Störungstyp innerhalb kurzer Zeit erneut auftritt.
Wichtig ist die operative Konsequenz: Diese Trigger gehören in das Major-Incident-Verfahren, nicht in eine lose Teamkonvention. Sobald der Incident geschlossen wird, muss automatisch klar sein, ob ein Review fällig ist, wer es moderiert und bis wann es vorliegen soll. Nur so wird aus guter Absicht ein verlässlicher Prozess.
2. Der Impact muss in Geschäfts- und Betriebsdaten beschrieben werden, nicht nur in Stimmungsbildern
Ein erstaunlich häufiger Fehler ist die Formulierung „es gab Beeinträchtigungen“ ohne belastbare Größenordnung. Für ein wirksames Review reicht das nicht. Wer den Impact nicht quantifiziert, kann weder Prioritäten sauber setzen noch später belegen, ob Maßnahmen Wirkung gezeigt haben.
Die Google-SRE-Leitlinien betonen genau diesen Punkt: Ein Postmortem braucht nachvollziehbare Angaben zur Auswirkung. Für den ITSM-Alltag heißt das, mindestens fünf Dinge sauber zu erfassen: betroffene Services, Dauer der Beeinträchtigung, Zahl oder Anteil betroffener Nutzer, Geschäftsfolgen und zusätzlicher Betriebsaufwand. Geschäftsfolgen können Umsatzausfälle, Produktionsunterbrechungen, Wartezeiten im Contact Center oder verpasste SLA-Ziele sein. Betriebsaufwand zeigt sich oft in Überstunden, manuellen Workarounds, erhöhter Ticketlast oder zusätzlichen Provider-Eskalationen.
Erst mit diesen Daten wird sichtbar, ob der eigentliche Schaden in der Ausfallminute lag oder im langen Nachlauf. Gerade bei SaaS- und Identitätsstörungen ist Letzteres häufig der Fall. Die Plattform läuft formal wieder, aber Service Desk, Fachbereich und Admin-Teams tragen die Last noch Stunden weiter. Ein gutes Review bildet genau das ab. Es erzählt nicht nur, wann das Monitoring wieder grün war, sondern wann der Betrieb wirklich normalisiert war.
3. Aus dem Incident-Review muss zwingend ein Problem Record entstehen
Viele Reviews scheitern daran, dass sie organisatorisch am Incident kleben bleiben. Das Dokument wird im Major-Incident-Ticket abgelegt, alle nicken es ab, und damit endet die Lernkurve. Für IT Service Management ist das zu kurz gedacht. Ein Incident beschreibt die Störung. Dauerhafte Ursachenarbeit gehört in das Problem Management.
Deshalb sollte jedes Review mit einer klaren Entscheidung enden: Gibt es einen Problem Record, wer besitzt ihn und welche Hypothesen oder Known Errors werden dort weitergeführt? Genau an dieser Stelle trennt sich ein belastbarer ITSM-Prozess von einer reinen Nachbesprechung. Ohne Problem-Ownership versanden Maßnahmen schnell zwischen Betrieb, Applikation, Infrastruktur und externen Providern.
Praktisch bewährt sich eine einfache Struktur. Das Incident-Review dokumentiert Verlauf, Impact, Trigger, Sofortmaßnahmen und erste Erkenntnisse. Der Problem Record übernimmt die tiefergehende Ursachenanalyse, die Abgrenzung systemischer Schwächen und die länger laufenden Korrekturmaßnahmen. So bleibt der Incident nicht künstlich offen, ohne dass die eigentliche Ursachenarbeit verloren geht.
Gerade bei wiederkehrenden Ausfällen, Schnittstellenfehlern oder instabilen Changes ist diese Trennung Gold wert. Sie verhindert, dass Teams nur Symptome dokumentieren und die eigentliche Störungslogik bei jeder Eskalation neu entdecken müssen.
4. Maßnahmen müssen nach Prävention, Erkennung und Recovery getrennt priorisiert werden
Ein Klassiker in schlechten Reviews ist eine To-do-Liste ohne Priorität, ohne Eigentümer und ohne klare Erfolgsdefinition. Googles Postmortem-Praxis weist ausdrücklich darauf hin, dass unklare Formulierungen wie „verbessern“ oder „besser absichern“ kaum steuerbar sind. Für ITSM-Teams kommt noch ein zweites Problem hinzu: Oft landen nur Präventionsideen auf der Liste, während Erkennung und Wiederherstellung vernachlässigt werden.
Genau das ist riskant. Nicht jede Ursache lässt sich kurzfristig eliminieren. Aber fast jeder Betrieb kann seine Erkennung schärfen und seine Recovery verkürzen. Deshalb sollten Maßnahmen aus einem Post-Incident-Review in drei Klassen getrennt werden: Prävention, Erkennung und Recovery. Prävention umfasst etwa Architekturänderungen, Härtungen, Freigaberegeln oder Lieferantenmaßnahmen. Erkennung betrifft Monitoring, Event-Korrelation, Alarmqualität oder Runbook-Hinweise im Service Desk. Recovery betrifft Rollback-Pfade, Notfallzugänge, Kommunikationsvorlagen und klare Umschaltverfahren.
Dazu kommt die Priorisierung. Die Google-Auswertung tausender Postmortems zeigt, dass Änderungen selbst ein dominanter Auslöser für Ausfälle sind, insbesondere Binary Pushes und Configuration Pushes. Für ITSM-Teams ist das ein deutlicher Hinweis: Ein relevanter Teil der Maßnahmen gehört fast immer in Change-Prozesse, Freigabekriterien, Testtiefen oder Deployment-Geländer. Wer nach einem Incident nur das betroffene System patcht, aber den fehlerhaften Änderungsweg unangetastet lässt, lädt die nächste Störung praktisch schon wieder ein.
Jede Maßnahme braucht deshalb einen Owner, eine Frist und ein überprüfbares Ergebnis. „Fallback für IdP im Runbook ergänzt und im nächsten Monatsfenster getestet“ ist steuerbar. „Dokumentation verbessern“ ist es nicht.
5. Reviews müssen in Wissen, Standards und Übung zurück in den Betrieb fließen
Der größte Wert eines Post-Incident-Reviews entsteht nicht im Dokument selbst, sondern in seiner Rückwirkung auf den Regelbetrieb. Google betont die breite Teilbarkeit von Postmortems, weil Lernen sonst lokal bleibt. Für klassische ITSM-Organisationen ist genau das oft die Schwachstelle. Das Review bleibt bei einem kleinen Technikzirkel hängen, während Service Desk, Change Advisory Rollen, Supplier Management oder die betroffenen Fachservices kaum etwas davon sehen.
Ein wirksames Review endet daher nicht mit der Freigabe des Dokuments, sondern mit drei Transfers. Erstens müssen relevante Erkenntnisse in Knowledge-Artikel, Diagnosehilfen und Runbooks einfließen. Zweitens brauchen Standards und Verfahren ein Update, etwa für Major-Incident-Kommunikation, Eskalationsmatrizen oder Notfall-Changes. Drittens sollten kritische Szenarien in Übungen oder Simulationen wieder auftauchen. Sonst bleibt das Wissen theoretisch.
Besonders wertvoll ist dieser Transfer bei Schnittstellen zwischen Service Desk und Fachteams. Wenn aus einem Review klar wird, welche frühen Symptome übersehen wurden, welche Statusmeldungen zu spät kamen oder welcher Workaround tatsächlich geholfen hat, steigt die Qualität beim nächsten Vorfall spürbar. Dann wird aus Erfahrung echte Betriebsreife.
Fazit
Post-Incident-Reviews sind kein Luxus für reife SRE-Organisationen, sondern ein Kerninstrument guten IT Service Managements. Sie schaffen nur dann Nutzen, wenn Auslöser vorab klar sind, der Impact belastbar beschrieben wird, Problem-Ownership sauber entsteht, Maßnahmen priorisiert und überprüfbar sind und die Erkenntnisse zurück in Prozesse, Wissen und Übungen fließen.
Wer Major Incidents ernsthaft reduzieren will, sollte Reviews deshalb nicht als Pflichtanhang des Incident Managements behandeln. Sie sind die Stelle, an der sich entscheidet, ob der Betrieb nur wieder anläuft oder ob er tatsächlich robuster wird. Genau das trennt hektische Störungsbewältigung von lernfähigem Service Management.
