Im Site Reliability Engineering gilt das Postmortem als eines der wichtigsten Instrumente zur kontinuierlichen Verbesserung. Doch in der Praxis hinken Postmortems ihrem Anspruch oft hinterher: Sie werden zu spät geschrieben, zu oberflächlich formuliert und zu selten konsequent ausgewertet. Genau hier eröffnen Large Language Models neue Möglichkeiten – nicht als Ersatz für menschliches Urteilsvermögen, sondern als strukturierter Analysepartner.
Das klassische Postmortem-Problem
Ein gutes Postmortem beantwortet drei Kernfragen: Was ist genau passiert? Warum ist es passiert (Ursachenkette, nicht nur Symptom)? Wie verhindern wir, dass es wieder passiert? In der Realität sind diese Anforderungen schwer zu erfüllen, wenn das Incident-Team erschöpft ist, Zeitdruck herrscht und die relevanten Daten über Logs, Metriken, Tickets und Chat-Historien verteilt liegen.
Die Folgen sind bekannt: Postmortems bleiben vage, Handlungsempfehlungen werden zu allgemein formuliert und landen am Ende in einer Backlog-Schublade. Muster über mehrere Incidents hinweg werden nicht erkannt, weil niemand systematisch alle vergangenen Postmortems auswertet.
Was LLMs zur Postmortem-Analyse beitragen
Zusammenfassung von Incident-Daten
Ein Large Language Model kann strukturierte und unstrukturierte Daten aus einem Incident zusammenfassen: Alert-Meldungen, Deployment-Events, Chat-Nachrichten aus dem Incident-Kanal, manuell eingetragene Zeitstempel. Das Ergebnis ist eine kohärente, chronologische Darstellung des Geschehens – eine Basis, auf der das Team aufbauen kann, statt bei null anzufangen.
Ursachenhypothesen ableiten
Mit den richtigen Kontextinformationen kann ein Reasoning-fähiges Modell Hypothesen zur Ursachenkette formulieren. Es prüft, ob der Ausfall zeitlich mit einem Deployment zusammenfällt, ob ähnliche Muster in früheren Incidents auftraten und welche Systemkomponenten laut Abhängigkeitsgraph betroffen sein könnten. Das ersetzt keine tiefe technische Analyse durch Experten, liefert aber einen strukturierten Ausgangspunkt.
Mustererkennung über mehrere Incidents
Hier liegt eine der stärksten Anwendungen: Ein LLM, das auf alle vergangenen Postmortems eines Teams zugreifen kann, findet wiederkehrende Muster – etwa ob Datenbankprobleme häufig nach bestimmten Deployment-Typen auftreten, ob eine bestimmte Schnittstelle überdurchschnittlich oft in Incidents auftaucht oder ob bestimmte Teams systematisch mehr Incidents verursachen als andere. Solche Erkenntnisse wären manuell nur mit erheblichem Aufwand gewinnbar.
Qualitätsprüfung von Handlungsempfehlungen
LLMs können bestehende Action-Items auf Qualität und Spezifität prüfen. „Dokumentation verbessern" ist eine schlechte Handlungsempfehlung – zu vage, nicht zuweisbar, nicht messbar. Ein Modell kann solche schwachen Empfehlungen identifizieren und konkretere Formulierungen vorschlagen, die einem SMART-Kriteriensatz entsprechen.
Praktische Integration in den SRE-Workflow
Schritt 1: Datenaggregation
Die Grundlage jeder KI-gestützten Analyse ist ein vollständiger Datensatz. Das bedeutet: Alle relevanten Logs, Metriken und Ereignisse werden für den Zeitraum des Incidents zusammengestellt – idealerweise automatisch aus dem Monitoring-System exportiert. Ergänzt wird das durch Chat-Protokolle und manuelle Notizen aus dem Incident-Management-Tool.
Schritt 2: Erster Analyse-Prompt
Der aggregierte Datensatz wird dem LLM mit einem strukturierten Prompt übergeben. Dieser enthält die Anforderungen: chronologische Zusammenfassung, Hypothesen zur Ursachenkette, vorläufige Klassifikation (z. B. Infrastruktur, Code, Prozess) und erste Handlungsempfehlungen. Ein gutes Prompt-Design ist hier entscheidend – vage Fragen liefern auch mit LLMs vage Antworten.
Schritt 3: Review durch das Team
Die KI-Ausgabe wird nicht eins zu eins übernommen. Das Team prüft die Hypothesen, korrigiert Fehlannahmen und ergänzt implizites Wissen, das im Datensatz nicht sichtbar ist. Dieses Review ist keine Formalität – es ist der Kern der Lernmethode. Die KI beschleunigt den Prozess, die menschliche Expertise validiert das Ergebnis.
Schritt 4: Langzeitauswertung
Alle abgeschlossenen Postmortems werden in einer durchsuchbaren Wissensbasis gespeichert. Regelmäßig – etwa monatlich – wird ein Analyse-Lauf über den gesamten Bestand durchgeführt, um systemische Muster zu identifizieren. Die Erkenntnisse fließen direkt in die Quartalsplanung des SRE-Teams ein.
Was zu beachten ist
KI-gestützte Postmortem-Analyse birgt einige Risiken, die bewusst adressiert werden müssen:
- Datenschutz und Vertraulichkeit: Incident-Daten können sensible Informationen enthalten. Die Nutzung externer LLM-APIs erfordert eine klare Datenschutzstrategie – on-premise oder private-cloud-Deployment kann hier die richtige Wahl sein.
- Blame-Kultur: KI-Ausgaben können unbeabsichtigt auf bestimmte Personen oder Teams zeigen. Postmortem-Prozesse müssen blameless bleiben – auch wenn KI die Analyse unterstützt.
- Halluzinationen: LLMs erfinden gelegentlich Zusammenhänge, die in den Daten nicht vorhanden sind. Kritische Ursachenketten müssen immer durch technische Analyse bestätigt werden.
Fazit: KI als strukturierter Denkpartner
Large Language Models können die Qualität und Konsequenz von Postmortems erheblich verbessern – wenn sie richtig eingesetzt werden. Ihr Wert liegt nicht darin, das Team zu ersetzen, sondern darin, mühsame Aggregations- und Formulierungsarbeit zu übernehmen und langfristige Muster sichtbar zu machen, die sonst im Rauschen verschwinden. Für SRE-Teams, die Postmortems ernst nehmen, ist das eine echte Verstärkung.
Bildquelle: Pexels (pexels-photo-2599244.jpeg) – Serverraum / Infrastruktur
Quellen
- Google SRE Book: „Postmortem Culture: Learning from Failure" (sre.google)
- PagerDuty Incident Response Documentation (pagerduty.com)
- Atlassian: Blameless Postmortems Guide (atlassian.com)
