Katalog
method#Zuverlässigkeit#Governance#Lieferung

Postmortem

Formalisierte Nachanalyse eines Vorfalls zur Fehlerursachenklärung, Dokumentation und Ableitung von Verbesserungen.

Ein Postmortem ist eine strukturierte Nachanalyse nach Störungen oder fehlerhaften Releases.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Organisatorisch
  • Organisation
  • Fortgeschritten

Technischer Kontext

Observability-Tools (Monitoring, Tracing)Ticketing- und Task-Management-SystemeKnowledge-Base / Confluence

Prinzipien & Ziele

Keine Schuldzuweisung; Fokus auf Ursachen und Systeme.Kurz, präzise Timeline und belegbare Fakten.Konkrete, nachverfolgbare Aktionen mit Besitzern.
Iteration
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Wiederholung ohne Umsetzung der Maßnahmen.
  • Schuldzuweisungen und Demotivation von Teams.
  • Sensible Informationen werden unzureichend geschützt.
  • Blameless-Ansatz etablieren zur Förderung offener Kommunikation.
  • Kurze Timeline zuerst, dann tiefergehende Analysen bei Bedarf.
  • Ergebnisse in bestehende Prozesse und Playbooks integrieren.

I/O & Ressourcen

  • System- und Anwendungs-Logs
  • Monitoring- und Tracing-Metriken
  • Incident-Timeline und beteiligte Personen
  • Root-Cause-Analyse-Bericht
  • Maßnahmenplan mit Besitzern und Terminen
  • Gelerntes für Playbooks und Prozesse

Beschreibung

Ein Postmortem ist eine strukturierte Nachanalyse nach Störungen oder fehlerhaften Releases. Es dokumentiert Ursachen, Auswirkungen und Maßnahmen, fördert eine lernende Kultur und hilft, wiederkehrende Probleme zu vermeiden. Ziel ist die nachhaltige Verbesserung von Prozessen und Systemzuverlässigkeit.

✔

  • Verbesserte Systemstabilität durch gezielte Gegenmaßnahmen.
  • Wissenstransfer und organisatorisches Lernen.
  • Reduktion wiederkehrender Vorfälle.

✖

  • Erfolg hängt von Offenheit und Unternehmenskultur ab.
  • Aufwändig bei komplexen oder schlecht dokumentierten Systemen.
  • Kann oberflächlich bleiben ohne klare Follow-up-Prozesse.

  • Mean Time to Recovery (MTTR)

    Mittlere Zeit bis zur Wiederherstellung eines Services nach einem Vorfall.

  • Anzahl wiederkehrender Vorfälle

    Zählt Vorfälle mit gleicher Ursache innerhalb eines definierten Zeitraums.

  • Umsetzungsquote empfohlener Maßnahmen

    Prozentsatz der Postmortem-Empfehlungen, die termingerecht umgesetzt wurden.

Incident-Analyse: Auth-Service-Ausfall

Dokumentiertes Postmortem mit Timeline, RCA und drei Follow-up-Tasks zur Stabilisierung.

Fehlgeschlagener Rollout rückgängig gemacht

Postmortem zeigte fehlende Canary-Checks; Deployment-Prozess wurde angepasst.

Monatliche Risiko-Review

Regelmäßige Zusammenfassung von Postmortems zur Identifikation systemischer Schwachstellen.

1

Vorlage und Timeline definieren; Verantwortliche benennen.

2

Datensammlung: Logs, Metriken und Kommunikationsprotokolle.

3

Gemeinsame Analyse-Session; Ursachen und Maßnahmen ableiten.

4

Maßnahmen in Backlogs einpflegen und Fortschritt verfolgen.

⚠️ Technische Schulden & Engpässe

  • Unzureichende Observability erschwert RCA.
  • Veraltete Runbooks und fehlende Playbooks.
  • Kurzfristige Hotfixes ohne nachhaltige Lösung.
Unvollständige LogsMangelnde interdisziplinäre ZusammenarbeitFehlende Nachverfolgung von Maßnahmen
  • Postmortem als Sanktionsinstrument in Performance-Gesprächen.
  • Nur symbolische Postmortems ohne echte Datenauswertung.
  • Interne Details öffentlich machen ohne Risikoabschätzung.
  • Zu späte Durchführung führt zu unsicheren Erinnerungen.
  • Mangelnde Priorisierung der abgeleiteten Maßnahmen.
  • Fehlende Messung des Effekts umgesetzter Maßnahmen.
Root-Cause-AnalyseModeration und FacilitationSystemisches Denken
Erkennbarkeit von Fehlern und EreignissenNachvollziehbarkeit von Abläufen und EntscheidungenVerfügbarkeit von Observability-Daten
  • • Zeitdruck nach kritischen Vorfällen
  • • Datenschutz und Compliance-Anforderungen
  • • Begrenzte Ressourcen für tiefe Analysen