Postmortems im ITSM: Welche 5 Routinen Service-Organisationen zwischen Major Incident und Problem Management wirklich brauchen

Viele ITSM-Organisationen sind im akuten Ausfall inzwischen deutlich besser geworden. Es gibt On-Call-Pläne, Major-Incident-Bridges, Statusmeldungen und oft auch saubere Eskalationswege. Der eigentliche Reifegrad entscheidet sich aber nicht im War Room, sondern in den Tagen danach. Genau dort kippt es häufig. Der Service ist wieder da, der Druck sinkt, alle gehen zurück in den Betrieb, und aus dem Incident bleibt am Ende nur ein knappes RCA-Dokument oder ein Ticket mit dem Vermerk „Ursache behoben“.

Damit geht viel verloren. Google beschreibt Postmortems im SRE-Umfeld ausdrücklich als schriftliche Aufarbeitung von Impact, Verlauf, Ursachen, Gegenmaßnahmen und Follow-ups, nicht als bürokratischen Abschluss. Microsoft definiert die Retrospektive im Incident-Management ähnlich: blameless, strukturiert und auf umsetzbare Verbesserungen ausgerichtet. PagerDuty weist zusätzlich darauf hin, dass auch der Incident-Prozess selbst überprüft werden muss, nicht nur der technische Defekt. Für klassische ITSM-Teams ist das relevant, weil zwischen Major Incident, Problem Management, Known Error und Change oft noch Brüche liegen.

Wer Post-Incident-Reviews nur als Pflichttermin behandelt, produziert Dokumente. Wer sie als Betriebsroutine ernst nimmt, verbessert Servicequalität, Change-Sicherheit und Wissensbasis. Fünf Routinen machen dabei den Unterschied.

1. Auslöser für ein Postmortem vorab festziehen

Der erste Fehler passiert oft schon vor dem eigentlichen Review. Viele Teams entscheiden erst nach einem Vorfall spontan, ob sich eine Aufarbeitung „lohnt“. Genau das führt dazu, dass politisch sichtbare Incidents untersucht werden, operative Beinahe-Schäden oder langwierige Degradationen aber unter dem Radar bleiben.

Google empfiehlt deshalb klare Trigger vorab, zum Beispiel nutzersichtbare Ausfälle über einem Schwellenwert, Datenverlust, manuelle Eingriffe des On-Call-Teams, lange Wiederherstellungszeiten oder Monitoring-Versagen. Diese Logik ist für ITSM sofort brauchbar. Ein Postmortem sollte verbindlich werden, wenn ein Major Incident ausgerufen wurde, ein geschäftskritischer Service sein Zielniveau spürbar verletzt, eine Notfalländerung nötig war oder ein Incident trotz Alarmierung zu spät erkannt wurde.

Wichtig ist, diese Kriterien nicht an Hierarchie oder Bauchgefühl zu knüpfen. Sonst werden Reviews gerade dann übersprungen, wenn operative Hektik, Fremdprovider oder peinliche Prozessfehler im Spiel waren. Gute Organisationen definieren deshalb zusätzlich, dass auch Service Owner, Problem Manager oder betroffene Fachbereiche ein Postmortem anfordern dürfen.

2. Timeline, Impact und Beitragsfaktoren sauber voneinander trennen

In schwachen Reviews wird sofort nach dem Schuldigen gesucht oder zu früh über „die Ursache“ gesprochen. Das ist gefährlich, weil komplexe Störungen selten monokausal sind. Microsoft unterscheidet im Incident-Management bewusst zwischen Triage, Containment, Mitigation, Root Cause Analysis und Retrospektive. Diese Disziplin hilft auch im ITSM-Alltag.

Praktisch sollte jedes Postmortem zuerst drei Dinge getrennt festhalten. Erstens die Timeline: Was ist wann passiert, welche Signale gab es, wann wurde eskaliert, wann wurde mitigiert, wann war der Service stabil? Zweitens den Impact: Welche Nutzer, Standorte, Geschäftsprozesse oder Schnittstellen waren tatsächlich betroffen? Drittens die Beitragsfaktoren: technische Schwächen, unklare Runbooks, Monitoring-Lücken, fehlerhafte Freigaben, Provider-Übergaben oder missverständliche Verantwortlichkeiten.

Erst wenn diese drei Ebenen sauber dokumentiert sind, lohnt sich die Root-Cause-Diskussion. Genau darin steckt der Kern blamelesser Reviews. Nicht die Person steht im Zentrum, sondern die Frage, warum das System, der Prozess oder die Entscheidungsumgebung einen Fehler begünstigt haben. Das ist kein Kuschelkurs, sondern betriebliche Nüchternheit.

3. Das Review direkt ins Problem Management und in Known Errors übersetzen

Viele Postmortems bleiben isolierte Dokumente. Das ist einer der größten Reibungspunkte zwischen Incident- und Problem-Management. Ein gutes Review endet deshalb nicht mit einem PDF, sondern mit klarer operativer Übersetzung. Wenn eine Ursache noch nicht nachhaltig beseitigt ist, braucht es einen Problem Record. Wenn ein Fehlerbild reproduzierbar ist und mit Workaround beschrieben werden kann, gehört daraus ein Known Error samt sauberer Wissensbasis für Service Desk und Betrieb.

Gerade hier gewinnen ITSM-Organisationen viel Zeit zurück. Wiederkehrende Incidents werden schneller erkannt, First- und Second-Level-Support können gezielter reagieren, und Provider-Diskussionen verlieren an Nebel. Der Review-Termin sollte daher immer die Frage erzwingen: Was wird Problem Record, was wird Known Error, was wird reines Verbesserungs-Item, und was ist nur Beobachtung?

Ohne diese Übersetzung bleibt Problem Management reaktiv. Mit ihr wird aus einem Major Incident ein belastbarer Baustein für dauerhafte Betriebsstabilität.

4. Action Items in Change und Betriebssteuerung verankern

Postmortems scheitern nicht an der Analyse, sondern an folgenlosen Maßnahmenlisten. PagerDuty betont deshalb zu Recht, dass der Wert in der kontinuierlichen Verbesserung liegt. Für ITSM heißt das: Jedes Action Item braucht einen Typ, einen Owner, einen Termin und einen Einbaupunkt in die operative Steuerung.

Hilfreich ist eine einfache Unterscheidung in vier Klassen. Präventive Maßnahmen beseitigen Ursachen, etwa durch Code-, Architektur- oder Konfigurationsänderungen. Detektive Maßnahmen verbessern Monitoring, Alerting oder Dashboards. Prozessmaßnahmen betreffen Eskalation, Kommunikation, Rollen oder Runbooks. Resilienzmaßnahmen begrenzen künftig den Blast Radius, zum Beispiel durch bessere Segmentierung, Fallbacks oder Load Shedding.

Spätestens an dieser Stelle muss Change Enablement mit am Tisch sitzen. Wenn die Review-Ergebnisse nicht in CAB-Logik, Standard Changes, Emergency-Change-Regeln oder Release-Gates eingehen, bleibt die Lernschleife offen. Google zeigt in seiner Postmortem-Auswertung zudem, dass Änderungen und Konfigurationsänderungen bei großen Incident-Mengen besonders häufig als Auslöser auftauchen. Wer diese Erkenntnisse nicht in Freigabe- und Deployment-Praxis zurückführt, lernt operativ zu wenig.

5. Über einzelne Incidents hinaus Muster bilden

Der größte Hebel entsteht oft erst über mehrere Reviews hinweg. Googles veröffentlichte Auswertung historischer Postmortems zeigt nicht nur Einzelursachen, sondern Muster, etwa hohe Anteile von Binary Pushes, Configuration Pushes und Entwicklungsprozessfehlern. Genau diese Sicht fehlt in vielen ITSM-Organisationen. Dort gibt es zwar Incident-Statistiken, aber kaum eine systematische Klammer über Postmortems.

Deshalb sollten Problem Management oder Service Governance quartalsweise Trendanalysen fahren. Wiederholen sich bestimmte Change-Typen? Häufen sich Provider-Übergaben als Verzögerungsfaktor? Werden kritische Services zu oft manuell entdeckt? Sind Runbooks vorhanden, aber unter Stress unbrauchbar? Kommen Emergency Changes regelmäßig aus denselben Plattformen?

Erst aus dieser Mustersicht werden Postmortems zu Managementdaten. Dann lässt sich begründen, warum ein Team in Observability investieren muss, warum ein Provider-RACI nicht trägt oder warum ein Service trotz „grüner“ SLA-Berichte operativ instabil ist.

Was in einem belastbaren ITSM-Postmortem mindestens stehen sollte

• klare Incident-Zusammenfassung und betroffener Service
• saubere Timeline mit Detection, Eskalation, Mitigation und Recovery
• geschäftlicher und technischer Impact
• Root Cause und vor allem beitragende Faktoren
• Workarounds, Known Errors und offene Risiken
• konkrete Action Items mit Ownern und Terminen
• Bewertung, was im Incident-Prozess selbst gut oder schlecht funktioniert hat

Fazit

Ein Postmortem ist im ITSM nicht bloß der Nachbericht zum Ausfall. Es ist die Brücke zwischen Major Incident, Problem Management, Wissensbasis und besserer Change-Steuerung. Wer klare Trigger definiert, Timeline und Beitragsfaktoren sauber trennt, Ergebnisse konsequent in Problem Records und Known Errors übersetzt, Maßnahmen in die Betriebssteuerung einbaut und anschließend Muster über mehrere Reviews bildet, bekommt aus Incident-Lernen endlich operative Wirkung. Genau daran trennt sich hektische Störungsbearbeitung von belastbarem Service Management.

Quellen

• Google SRE Book: Postmortem Culture
• Google SRE Workbook: Results of Postmortem Analysis
• Google SRE Book: Example Postmortem
• Microsoft Learn: Develop an Incident Management Practice to Recover from Disruptions
• Microsoft Learn: Architecture strategies for designing an incident management process
• PagerDuty: What is an Incident Postmortem?