Ein Postmortem soll nach einer Panne klären, was sich ändern muss. Michael Heap, Senior Director Product beim API-Anbieter Kong, beobachtet in vielen Firmen etwas anderes: Am Ende liegt eine saubere Chronologie vor, der alle zustimmen.[1] Als Lieblingsbeispiel für einen wertlosen Maßnahmenpunkt nennt Heap den Satz „Beim nächsten Mal passen wir besser auf“.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Den Anstoß für Heaps Essay gab ein Gespräch, in dem ein Senior Vice President of Engineering Heaps Erklärung einer Panne nach wenigen Sätzen unterbrach.[1]
Das Wichtigste in Kürze
- Michael Heap rät, nach einer Panne nicht nach dem Warum zu fragen, sondern nach der Änderung am System.
- Eine überzeugende Erklärung bremst nach Heaps Beobachtung jede Änderung.
- Google verlangt in seinen Postmortems konkrete Maßnahmen und verzichtet bewusst auf Schuldzuweisungen.
- Das BSI-Gesetz fordert von NIS2-Einrichtungen eine Abschlussmeldung mit Ursache und Abhilfemaßnahmen.
Warum will die Chefetage nach einer Panne keine Details hören?
Mit den Details ergebe jede Entscheidung Sinn, man fühle mit den Beteiligten mit, und dann passiere derselbe Fehler wieder. So begründete der Senior Vice President gegenüber Heap die Absage an eine ausführliche Erklärung.[1]
Zunächst empfand Heap den Einwand als Abfuhr. Später las der Kong-Manager darin einen Vertrauensbeweis. Die Führungskraft setzte die Kompetenz aller Beteiligten voraus und wollte nur noch wissen, was sich nun ändert.[1]
Aus „Alice war im Urlaub, und Bob hielt ein anderes Team für zuständig“ wird die Frage, wie Zuständigkeiten eindeutig bleiben, sobald jemand fehlt. Eine Warnung, die nach zwanzig nutzlosen Alarmen am selben Abend unterging, führt zur Frage nach dem Verhältnis von Signal zu Rauschen im Monitoring.
Was unterscheidet eine Erklärung von einer Korrektur?
Eine Korrektur wirkt auch dann noch, wenn alle Beteiligten morgen kündigen. Maßnahmen, die nur im Gedächtnis einzelner Mitarbeiter weiterleben, nennt Heap „organisatorische Folklore“.[1]
Googles Handbuch zum Site Reliability Engineering sieht das ähnlich: Menschen könne man nicht „reparieren“, Systeme und Prozesse dagegen schon, schreiben die Google-Ingenieure. Ein Postmortem benennt deshalb die Ursachen, ohne Einzelne oder Teams anzuklagen, und schließt mit konkreten Maßnahmenpunkten.[2]
Wie eine Systemänderung aussieht, zeigte CrowdStrike nach dem Ausfall im Juli 2024. Ein fehlerhaftes Inhaltsupdate legte nach Schätzung von Microsoft rund 8,5 Millionen Windows-Geräte lahm.[3] In der Ursachenanalyse vom 6. August 2024 kündigte CrowdStrike eine gestaffelte Auslieferung an: Neue Inhalte sollen zuerst eine Teilmenge der Sensoren erreichen, zuvor gingen solche Updates an alle Sensoren gleichzeitig.[4] Auch GitHub benannte nach dem Ausfall am 17. August eine technische Ursache statt eines Schuldigen.
Aus der Erklärung wird eine Frage an das System
Ein Postmortem, das mit guten Vorsätzen endet, beruhigt das Team und lässt das System unverändert. Die ehrlichste Zeile im Bericht nennt die Änderung oder das Risiko, das die Firma bewusst in Kauf nimmt.
— Markus Seyfferth, Chefredakteur Dr. Web
Was bedeutet das für Unternehmen im DACH-Raum?
Für NIS2-pflichtige Einrichtungen in Deutschland ist die Frage nach der Änderung gesetzlich vorgegeben. Die Abschlussmeldung an das BSI muss neben der Ursache auch die getroffenen und laufenden Abhilfemaßnahmen nennen.[5]
Seit dem 6. Dezember 2025 gelten die NIS2-Pflichten in Deutschland ohne Übergangsfrist. Laut § 32 BSIG geht die Abschlussmeldung spätestens einen Monat nach der ersten Vorfallmeldung ans Bundesamt.[5] Ein Vorsatz wie „Wir passen künftig besser auf“ taugt dort schlecht als Abhilfemaßnahme.
Heap warnt zugleich vor dem Gegenextrem: Manchmal kostet die Vorbeugung mehr als ein gelegentlicher Ausfall. In solchen Fällen gehört die bewusste Risikoannahme ins Protokoll, nicht das Versprechen, sich mehr Mühe zu geben.[1]
Für Ihr nächstes Postmortem lohnt ein einfacher Kündigungstest: Funktioniert jede Maßnahme auch ohne die Menschen, die heute im Raum sitzen? Geben Sie außerdem gerne jedem Punkt einen Verantwortlichen und ein Datum. Einen Überblick über die Pflichten für kleinere Firmen liefern die Cybersecurity-Grundlagen für KMU.
Quellen
[1] Michael Heap: „I don’t want the details“
[2] Google SRE Book: „Postmortem Culture: Learning from Failure“
[3] Microsoft: „Helping our customers through the CrowdStrike outage“
[4] CrowdStrike: „Channel File 291 Incident: Root Cause Analysis“
[5] Bundesministerium der Justiz: „§ 32 BSIG: Meldepflichten“
Mehr Newshunger?
- Samsung-Kühlschränke nach Firmware-Update lahmgelegt: Besitzer in Südkorea beklagen verdorbene Lebensmittel
- GitHub-Ausfall am 17. August: Die Kapazität im Rechenzentrum reichte nicht
- Hugging-Face-Hack: Wie sich OpenAIs KI-Agenten heimlich koordinierten
- KI-Agenten brauchen einen Notausgang, nicht nur eine Aufgabe
- NIS2: Die Produktionshalle wird zur Haftungsfalle
- Backup-Strategien 2026: So sichern Sie Ihre Unternehmensdaten gegen Ransomware
