Ein schwerer Produktionsausfall ist bewältigt, die Systeme laufen wieder stabil – doch das On-Call-Team steht vor der nächsten Herausforderung: dem Postmortem. Was genau ist passiert? Wann? Warum? Was wurde getan, was wird geändert? Die Antworten auf diese Fragen landen idealerweise in einem strukturierten Abschlussbericht, der für das gesamte Team nachvollziehbar und archivierbar ist.
In der Realität scheitert gute Incident-Dokumentation häufig am schlichten Zeitdruck. Nach einem anstrengenden Incident fehlt die Energie für sorgfältiges Schreiben – der Bericht wird skizzenhaft, lückenhaft oder ganz vergessen. Genau hier können Sprachmodelle als Dokumentationsassistenten echten Mehrwert liefern.
Was KI bei der Incident-Dokumentation leisten kann
Moderne LLMs sind keine passiven Textgeneratoren mehr. Sie können strukturierte Eingaben – Logs, Alerthistorien, Chat-Protokolle, Ticket-Kommentare – auswerten und daraus kohärente, leicht lesbare Texte erzeugen. Für die Incident-Dokumentation bedeutet das konkret:
- Zeitstrahl rekonstruieren: Aus Timestamps in Logs und Alerting-Systemen einen chronologischen Ablauf des Incidents erzeugen.
- Ursache zusammenfassen: Aus technischen Logs und Kommentaren eine verständliche Beschreibung der Root Cause erstellen.
- Maßnahmen dokumentieren: Was wurde wann von wem getan? KI kann diese Informationen aus Chat-Protokollen oder Ticket-Kommentaren extrahieren und strukturieren.
- Follow-up-Aufgaben vorschlagen: Basierend auf der beschriebenen Ursache Empfehlungen für Präventivmaßnahmen generieren.
Das Ergebnis ist ein erster strukturierter Entwurf des Postmortems – kein fertiger Bericht, aber eine solide Grundlage, die das Team überprüft, ergänzt und freigibt.
Typischer Workflow in der Praxis
Schritt 1: Daten aggregieren
Die KI braucht Rohmaterial. Das bedeutet: Alert-Zeitstempel aus dem Monitoring, relevante Log-Ausschnitte, den Chat-Verlauf des Incident-Channels (z.B. Slack oder Teams), Ticket-Kommentare und ggf. Metriken aus dem Observability-Stack. Je vollständiger die Eingabe, desto präziser der Output.
Schritt 2: Strukturierter Prompt
Ein guter Prompt für die Postmortem-Generierung gibt der KI explizit vor, welche Abschnitte erwartet werden: Zusammenfassung, Zeitstrahl, Ursache, Auswirkungen, durchgeführte Maßnahmen, offene Punkte. Teams, die regelmäßig Postmortems schreiben, können einen Standard-Prompt entwickeln, der intern geteilt und gepflegt wird.
Schritt 3: Review und Anpassung
Der KI-generierte Entwurf ist kein Endprodukt. Das Team, das den Incident gelebt hat, prüft ihn: Stimmt die Chronologie? Ist die Ursache korrekt beschrieben? Fehlen wichtige Kontext-Informationen? Diese Review-Phase sollte nicht unterschätzt werden – sie ist auch eine inhaltliche Auseinandersetzung mit dem Incident.
Schritt 4: Freigabe und Archivierung
Das geprüfte Dokument wird archiviert – intern im Wiki, in einem Incident-Management-Tool oder im Knowledge-Base-System. Die Follow-up-Aufgaben werden in das Ticket-System überführt und nachverfolgt.
Blameless bleibt Pflicht – auch mit KI
Eine kritische Anforderung bei Postmortems ist die blameless Kultur: Keine Person wird für einen Incident verantwortlich gemacht, der Fokus liegt auf Systemschwächen und Prozessverbesserungen. Hier müssen Teams beim Einsatz von KI-Assistenten aktiv gegensteuern.
Sprachmodelle neigen dazu, in Formulierungen implizite Schuldzuweisungen einzubauen – etwa indem sie beschreiben, dass „Nutzer X die falsche Konfiguration eingespielt hat", ohne den Systemkontext zu nennen, der diesen Fehler ermöglichte. Prompt-Richtlinien müssen das explizit adressieren: „Formuliere systemorientiert, vermeide personenbezogene Schuldzuweisungen, beschreibe Kontext und Rahmenbedingungen."
Integration in bestehende Toolchains
Die stärkste Form dieser Automatisierung entsteht, wenn LLMs direkt in bestehende Incident-Workflows eingebunden werden. Mögliche Integrationspunkte:
- PagerDuty / OpsGenie: Nach Incident-Abschluss automatisch alle Timeline-Events an ein LLM übergeben und einen Entwurf generieren lassen.
- Slack / Teams Bots: Ein Bot im Incident-Channel kann am Ende des Incidents alle relevanten Nachrichten zusammenfassen.
- Jira / Linear: Aus Ticket-Beschreibungen und Kommentaren automatisch ein strukturiertes Abschlussdokument erstellen.
- Monitoring-Plattformen: Alerting-Systeme können ihren Kontext (betroffene Monitore, Alert-Zeitstempel, betroffene Systeme) direkt als strukturierten Input mitliefern.
Das Model Context Protocol (MCP) erleichtert diese Integrationen zunehmend: Statt manuelle Exporte zu erstellen, stellt ein MCP-Server die Incident-Daten direkt für den KI-Assistenten bereit.
Grenzen und Risiken klar benennen
KI-generierte Postmortems haben Grenzen, die man kennen muss:
- Fehlende implizite Kenntnisse: Was im Slack-Chat als „das übliche Speicherproblem" bezeichnet wird, ist für die KI ohne Kontext nicht interpretierbar.
- Halluzinationen: LLMs können Details erfinden, die sich schlüssig anfühlen, aber faktisch falsch sind. Review ist nicht optional.
- Datenschutz: Incident-Logs und Chat-Protokolle können sensible Kundendaten enthalten. Vor dem Einsatz cloudbasierter KI-Dienste muss die DSGVO-Compliance geprüft werden – lokal betriebene Modelle sind für viele Teams hier die sicherere Wahl.
Fazit: KI als Schreibassistent, nicht als Denkersatz
KI-gestützte Incident-Dokumentation ist kein Allheilmittel, aber ein ernstzunehmender Effizienzgewinn – besonders für Teams, die nach einem langen Incident kaum noch Energie für sorgfältiges Schreiben haben. Der Schlüssel liegt in einem klaren Workflow: strukturierte Dateneingabe, überprüfte Prompts und ein obligatorisches Review durch das Team.
Das Ziel bleibt das gleiche wie vor der KI-Ära: ein ehrliches, lernfähiges Postmortem, das das gesamte Team weiterbringt. Die KI übernimmt dabei die strukturelle Schwerstarbeit – die inhaltliche Verantwortung bleibt beim Team.
Quellen: Google SRE Workbook – Postmortem Culture; PagerDuty – The Anatomy of an Incident Report (2025); Atlassian – Blameless Postmortems Guide.
