TL;DR

Ein gutes Postmortem dokumentiert was passiert ist, warum es passiert ist und wie es nicht wieder passiert. Das blameless Format fokussiert auf Systeme statt auf Personen. Mit einem strukturierten Template, klarer Severity-Klassifikation und konsequentem Action-Item-Tracking wird aus jedem Incident eine Verbesserung.

Postmortems für Kubernetes-Incidents

Dein Kubernetes-Cluster hatte einen Ausfall. Der Incident ist gelöst, alle atmen durch. Jetzt kommt der wichtigste Teil: das Postmortem. Ohne systematische Aufarbeitung wiederholen sich die gleichen Fehler — nur in anderer Verkleidung.

Blameless Culture: Die Grundregel

Blameless heißt nicht accountability-frei. Es bedeutet: Wir suchen nach Systemfehlern, nicht nach Schuldigen. Menschen treffen Entscheidungen auf Basis der Informationen, die ihnen zum Zeitpunkt zur Verfügung stehen. Das Postmortem fragt nicht „Wer hat den Fehler gemacht?" sondern „Warum hat das System diesen Fehler zugelassen?"

Praktisch umgesetzt:

# FALSCH:
"Developer X hat das Deployment ohne Tests ausgerollt."

# RICHTIG:
"Das Deployment wurde ohne automatisierte Tests in Production ausgerollt.
Die CI/CD-Pipeline hatte keine Quality-Gate-Prüfung vor dem Production-Deployment."

Die zweite Formulierung führt zu einer konkreten Verbesserung (Quality Gate einbauen). Die erste führt nur dazu, dass Developer X beim nächsten Mal nichts mehr deployt.

Severity-Klassifikation

Nicht jeder Incident braucht ein vollständiges Postmortem. Die Severity bestimmt den Aufwand:

Die Einstufung erfolgt direkt nach der Incident-Resolution durch den Incident Commander.

Das Postmortem-Template

Dieses Template deckt alle relevanten Aspekte ab. Kopiere es als Ausgangspunkt für jedes Postmortem:

# Postmortem: [Kurzer Titel des Incidents]

**Datum:** YYYY-MM-DD
**Severity:** SEV-X
**Dauer:** HH:MM (von Detection bis Resolution)
**Autor:** [Name]
**Reviewer:** [Name]
**Status:** Draft | In Review | Final

## Zusammenfassung

[2-3 Sätze: Was ist passiert? Welcher Impact? Wie wurde es gelöst?]

## Impact

- **Betroffene Services:** [Liste der Services]
- **Betroffene User:** [Anzahl oder Prozent]
- **Dauer des Impacts:** [Minuten/Stunden]
- **Finanzielle Auswirkung:** [Falls messbar]
- **SLO-Verletzung:** [Ja/Nein, welches SLO]

## Timeline (UTC)

| Zeit | Ereignis |
|------|----------|
| 14:00 | Monitoring-Alert: Pod-Restart-Rate > 5/min im Namespace production |
| 14:03 | On-Call-Engineer bestätigt Alert, beginnt Investigation |
| 14:10 | Root Cause identifiziert: OOMKilled durch Memory Leak nach Deployment v2.4.1 |
| 14:15 | Rollback auf v2.4.0 eingeleitet |
| 14:22 | Rollback abgeschlossen, Pods stabil |
| 14:30 | Monitoring bestätigt: Alle Metriken im Normalbereich |

## Root Cause

[Detaillierte technische Beschreibung der Ursache.
Was genau ist fehlgeschlagen und warum?]

## Contributing Factors

- [Faktor 1: z.B. Fehlende Memory-Limits im Deployment]
- [Faktor 2: z.B. Load-Test hat den Memory-Leak-Pfad nicht abgedeckt]
- [Faktor 3: z.B. Alerting hat erst nach 5 Minuten angeschlagen]

## Was hat gut funktioniert?

- [z.B. Rollback-Prozess war schnell und zuverlässig]
- [z.B. Runbooks waren aktuell und hilfreich]

## Was kann verbessert werden?

- [z.B. Schnellere Detection durch bessere Alerts]
- [z.B. Canary-Deployment hätte den Fehler früher erkannt]

## Action Items

| ID | Action | Owner | Priority | Deadline | Status |
|----|--------|-------|----------|----------|--------|
| 1 | Memory-Limits für alle Pods in Production setzen | Team A | P1 | KW 12 | Offen |
| 2 | OOM-Alert mit 2-Minuten-Window einrichten | SRE | P1 | KW 12 | Offen |
| 3 | Memory-Profiling in CI/CD integrieren | Team A | P2 | KW 14 | Offen |
| 4 | Canary-Deployment für Production aktivieren | Platform | P2 | KW 15 | Offen |

Kubernetes-spezifische Untersuchung

Bei Kubernetes-Incidents brauchst du systematisch Daten sammeln. Diese Befehle helfen bei der Analyse:

# Pod-Events zum Zeitpunkt des Incidents
kubectl get events --sort-by='.lastTimestamp' -n production \
  --field-selector reason=OOMKilled

# Restart-Historie der betroffenen Pods
kubectl get pods -n production -o wide \
  | grep -v Running

# Resource-Verbrauch zum Zeitpunkt des Incidents (falls Metrics Server aktiv)
kubectl top pods -n production --sort-by=memory

# Deployment-Historie: Welche Rollouts gab es?
kubectl rollout history deployment/api-server -n production

# Logs des betroffenen Pods (vorheriger Container nach Restart)
kubectl logs deployment/api-server -n production --previous --tail=200

# Node-Conditions prüfen (DiskPressure, MemoryPressure)
kubectl describe nodes | grep -A5 "Conditions:"

Sichere diese Outputs sofort nach dem Incident. Kubernetes-Events haben eine Default-Retention von nur einer Stunde.

Das Postmortem-Meeting

Das Meeting sollte 30-60 Minuten dauern und einem klaren Ablauf folgen:

Vorbereitung (vor dem Meeting): Der Postmortem-Autor schreibt den Draft und teilt ihn mindestens einen Tag vorher. Alle Teilnehmer lesen den Draft vorab.

Ablauf:

1. Timeline durchgehen — Fakten ergänzen und korrigieren (10 min)
2. Root Cause diskutieren — Ist die Analyse vollständig? (10 min)
3. Contributing Factors identifizieren — Was hat den Impact verschlimmert? (10 min)
4. Action Items priorisieren — Wer macht was bis wann? (15 min)
5. Learnings festhalten — Was nehmen wir mit? (5 min)

Keine Schuldzuweisungen. Wenn jemand anfängt mit „Hättest du mal...", wird umformuliert zu „Wie können wir sicherstellen, dass...".

Action Items tracken

Action Items ohne Tracking sind wertlos. Integriere sie in euer bestehendes Ticketsystem:

# Beispiel: Action Items als GitHub Issues erstellen
gh issue create \
  --title "[Postmortem 2026-03-10] Memory-Limits für Production-Pods" \
  --label "postmortem,reliability,P1" \
  --assignee "@team-a" \
  --body "Aus Postmortem: OOMKill-Incident vom 10.03.2026.
  Alle Deployments im Production-Namespace brauchen explizite Memory-Limits.
  Deadline: KW 12"

Überprüfe offene Action Items wöchentlich im Team-Standup. Ein Postmortem ohne abgeschlossene Action Items ist verschwendete Zeit.

Häufige Fehler bei Postmortems

Zu spät geschrieben: Nach zwei Wochen erinnert sich niemand mehr an Details. Starte den Draft innerhalb von 24 Stunden.

Zu oberflächlich: „Der Pod ist abgestürzt" ist keine Root Cause. Frag fünfmal „Warum?" bis du bei der eigentlichen Ursache bist.

Keine Follow-ups: Die Action Items verschwinden im Backlog. Setze einen Reminder für zwei Wochen nach dem Postmortem, um den Status zu prüfen.

FAQ

Wer sollte am Postmortem-Meeting teilnehmen?

Alle, die am Incident beteiligt waren: On-Call-Engineer, Incident Commander, betroffene Team-Leads. Optional: Product Owner (für Impact-Bewertung) und Management (nur zuhören, nicht steuern).

Wie detailliert muss die Timeline sein?

Jede relevante Aktion und Entdeckung sollte mit Zeitstempel dokumentiert sein. Die Timeline ist das Fundament für die Analyse — lieber zu detailliert als zu grob.

Müssen Postmortems öffentlich sein?

Innerhalb der Engineering-Organisation: ja. Transparenz fördert die Lernkultur. Gegenüber Kunden reicht ein Status-Page-Update mit den wichtigsten Fakten.

Was mache ich bei wiederkehrenden Incidents?

Wenn ein Incident-Typ zum dritten Mal auftritt, eskaliere. Die bisherigen Action Items haben offensichtlich nicht gegriffen. Plane ein dediziertes Projekt statt einzelner Fixes.

Wie messe ich ob Postmortems wirken?

Tracke die Wiederkehrrate von Incident-Typen und die Completion-Rate der Action Items. Wenn 80 % der Action Items in der gesetzten Frist abgeschlossen werden und die gleichen Incidents nicht wiederkehren, funktioniert der Prozess.