Incident Response endet nicht mit der Wiederherstellung ── Eine Postmortem-Vorlage (Rückfallprävention) für kleine Entwicklungsteams

„Wir sehen den gleichen Fehler, den Sie letzten Monat behoben haben, diesmal nur auf einem anderen Bildschirm.“ Jeder, der ein System wartet, hat diesen Satz wahrscheinlich schon gehört und stand dabei sprachlos da.

Die eigentliche Incident Response – erkennen, Ursache eingrenzen, beheben, ausliefern, sich entschuldigen – beherrschen die meisten Teams bereits ordentlich. Das Problem liegt in dem, was danach kommt. Sobald die Wiederherstellung erfolgt ist, kehrt jeder zu seiner regulären Arbeit zurück, und das Protokoll des Vorfalls bleibt zurück und verblasst, verstreut über den Posteingang und die Chat-Verläufe einer Person. Sechs Monate später tritt an anderer Stelle ein strukturell identischer Fehler erneut auf, und dieselbe Untersuchung wird von Grund auf neu durchgeführt. Incident Response als „beheben, entschuldigen, fertig“ zu behandeln ist eine Betriebsweise, die immer wieder dasselbe Lehrgeld zahlt.

Auf diesem Blog haben wir die technische Seite der Vorfalluntersuchung – wie man tatsächlich zur Grundursache gelangt – bereits in „Eine Einführung in das Sammeln von Windows-Absturz-Dumps“ und „Wohin gehören catch und Logging in der Ausnahmebehandlung?“ behandelt. Dieser Artikel behandelt den nächsten Schritt: wie man den Rückblick (das Postmortem) durchführt, der sicherstellt, dass sich derselbe Vorfall nie wiederholt, sobald man die Ursache bereits kennt. Statt großer Webdienste konzentrieren wir uns eng auf eine Vorlage, die ein kleines Team von zwei bis fünf Personen, das Geschäftsanwendungen und Windows-Software wartet, tatsächlich dauerhaft durchhalten kann.

1. Das Wichtigste zuerst

• Wiederherstellung, Ursachenermittlung und Rückfallprävention sind getrennte Aufgaben. Wiederherstellung bedeutet „den heutigen Betrieb zurückbekommen“; Ursachenermittlung bedeutet „erklären können, warum es passiert ist“; Rückfallprävention bedeutet „das System ändern.“ Vermischt man diese, bleiben alle drei auf halbem Weg stecken.
• Keine Schuldigen zu suchen (blameless) ist eine Frage der Praktikabilität, nicht der Ethik. In einem Umfeld, in dem Einzelpersonen beschuldigt werden, hört Information auf, aufzutauchen, und man erreicht nie die Grundursache. Anzunehmen, dass alle Beteiligten angesichts der ihnen zur Verfügung stehenden Informationen zum jeweiligen Zeitpunkt korrekt gehandelt haben, und dann nach dem Loch im System zu suchen – das ist das blameless-Postmortem-Prinzip, wie es in der SRE-Praxis etabliert wurde.¹
• Rückfallpräventionsmaßnahmen sollten in einem System (Code, Tests, Monitoring, Verfahren) landen, nicht in „Vorsicht walten lassen“. Maßnahmen, die von menschlicher Aufmerksamkeit abhängen, verschwinden in dem Moment, in dem die verantwortliche Person wechselt. Kapitel 6 liefert eine Entscheidungstabelle zur Beurteilung der Stärke einer gegebenen Maßnahme.
• Trennen Sie die Ursache in eine „direkte Ursache“ und „beitragende Faktoren“. Was Sie tatsächlich beheben können, sind meist die beitragenden Faktoren, und der Kniff bei den Fünf Warums ist, nicht bei einer menschlichen Handlung stehenzubleiben, sondern bis zum System durchzugraben.
• Führen Sie nicht für jeden Vorfall ein vollständiges Postmortem durch. Staffeln Sie nach Auswirkung mal Wiederholungswahrscheinlichkeit (Kapitel 7), und lassen Sie für kleinere Vorfälle einfach einen Absatz-Eintrag zurück. Den Arbeitsaufwand auf einem tragbaren Niveau zu halten, ist die wichtigste Voraussetzung, um die Praxis am Leben zu erhalten.
• Bemessen Sie das Postmortem so, dass es sich in einer Stunde schreiben lässt. Kapitel 4 liefert eine minimale Vorlage. Jedes Mal einen groben Eintrag zu hinterlassen, ist mehr wert, als null ausgefeilte Dokumente im Monat zu schreiben.
• Trennen Sie in der Auftragsentwicklung den Zweck vom kundenseitigen Vorfallbericht, während Sie dessen Inhalt aus dem Postmortem wiederverwenden (Kapitel 8). Das Rechenschaftsdokument nicht mit dem Rückfallpräventionsdokument zu vermischen, schützt die Qualität beider.

2. Warum sich dieselben Fehler immer wieder wiederholen

Vorfälle, die sich wiederholen, folgen einem betrieblichen Muster, keinem technischen.

In dem Moment, in dem die Wiederherstellung erfolgt, gilt der Fall als „erledigt“. Incident Response ist eine Notfall-Unterbrechung, und sobald alles wieder läuft, kehrt jeder zu dem liegen gebliebenen Rückstand der normalen Arbeit zurück. In niemandes Kalender ist Zeit für den Rückblick eingeplant, und „wenn sich alles beruhigt hat“ kommt nie tatsächlich.

Der Bericht endet mit „wir werden künftig vorsichtiger sein“. Das Feld zur Rückfallprävention in einem Bericht an Kunden oder Vorgesetzte wird mit Formulierungen wie „wir werden gründlich prüfen“ oder „wir werden doppelt kontrollieren“ abgeschlossen. Diese Formulierung ändert nichts am System, weshalb ein paar Monate später, sobald die Aufmerksamkeit nachgelassen hat, alle wieder ins selbe Loch fallen.

Die Schuld auf eine Einzelperson schieben und die Struktur nie beheben. Den Fall mit „weil diese Person den Test übersprungen hat“ abzuschließen, lässt die Struktur, die das Überspringen des Tests überhaupt erst ermöglichte – kein Test-Gate im Release-Verfahren, stillschweigend geduldete Auslassungen unter Termindruck – genau so bestehen, wie sie war. Beim nächsten Mal macht jemand anderes dieselbe Auslassung.

Kein Protokoll bleibt erhalten, und dasselbe Loch wird Jahre später erneut betreten. Die Wartung durch ein kleines Team läuft eine Weile auch ohne Protokolle gut, gerade weil dieselbe Person weiterhin alles bearbeitet. Doch das Gedächtnis dieser Person verblasst über die Jahre und verschwindet vollständig, wenn sie das Unternehmen verlässt oder die Rolle abgibt. „Ich glaube, ich habe diesen Fehler schon einmal gesehen, kann mich aber nicht erinnern, was wir dagegen getan haben“ macht aus einer Untersuchung, die mit einem Protokoll eine Zehn-Minuten-Aufgabe gewesen wäre, einen ganzen Arbeitstag.

Nichts davon ist eine Frage der Kompetenz – es ist eine Folge der Tatsache, dass der Rückblick nie als Teil der Arbeit definiert wurde. Genau deshalb lohnt es sich, vorab eine Vorlage festzulegen (ein Dokumentformat und Kriterien, wann sie zum Einsatz kommt).

3. Was ein Postmortem ist – Die SRE-Vorlage für kleinteilige Wartung übertragen

Ein Postmortem ist eine Rückblick-Vorlage zur Dokumentation eines Vorfallprotokolls – Auswirkung, Grundursache, zeitlicher Ablauf der Reaktion und Rückfallpräventionsmaßnahmen –, die sich durch die Site-Reliability-Engineering-Praxis (SRE) von Google weithin etabliert hat. Im Kern steht das Prinzip blameless zu sein. „Ein blameless Postmortem geht davon aus, dass alle Beteiligten in gutem Glauben gehandelt haben und angesichts der ihnen zum jeweiligen Zeitpunkt vorliegenden Informationen das Richtige getan haben“ – statt Menschen zu bestrafen, behebt man das System, das der richtigen Handlung im Weg stand.¹

Diese Idee ist nicht auf Google beschränkt. Auch Microsofts Architektur-Leitfaden (das Azure Well-Architected Framework) definiert ein Postmortem als „einen strukturierten, blameless Rückblick unter Beteiligung aller betroffenen Teams“ und empfiehlt, die Ergebnisse der Ursachenanalyse (Root Cause Analysis, RCA) in Form von Verbesserungen des Reaktionsprozesses, verstärkter Erkennung (Observability) und Design-Verbesserungen in das System zurückzuführen.²

Es liegt nahe anzunehmen, „wir sind kein großer Webdienst, das gilt für uns nicht“ – doch ich denke, das Gegenteil ist der Fall. Das Postmortem zahlt sich gerade in einem Umfeld aus, in dem ein kleines Team, ohne jemanden vor Ort beim Kunden, eine Desktop-Anwendung wartet. Dafür gibt es drei Gründe.

1. Dieselbe Person bearbeitet weiterhin alles, sodass Wissen ohne Protokolle vollständig in diesem einen Kopf gefangen bleibt. In einer großen Organisation erinnert sich meist noch jemand anderes; in einem Team aus zwei oder drei Personen ist „die Person, die sich erinnert“ die einzige Datenbank, die es gibt. Das Postmortem wird zu diesem externen Gedächtnis.
2. Vorfälle liegen weit auseinander. Anders als bei einem Webdienst gibt es bei einer Geschäftsanwendung nur wenige ernste Vorfälle pro Jahr. Der nächste tritt tendenziell genau dann auf, wenn die Erinnerung an die letzte Reaktion bereits verblasst ist, was den Wert eines schriftlichen Protokolls relativ erhöht.
3. Weil Sie nicht vor Ort sein können, werden Belege und Protokolle zur Lebensader. Bei der Fernwartung hängt alles davon ab, im Nachhinein rekonstruieren zu können, „was in diesem Moment tatsächlich geschah“, und das steht in direkter Kontinuität zum zeitlichen Protokoll eines Postmortems.

Als grobe Richtlinie dafür, was ein Postmortem rechtfertigt, nennt das SRE-Buch Beispiele wie für Nutzer sichtbare Ausfälle, Datenverlust oder Fälle, die ein Eingreifen des Bereitschaftsdienstes erforderten.¹ Wir greifen in Kapitel 7 Kriterien auf, die für ein kleines Team geeignet sind.

4. Eine minimale Postmortem-Vorlage

Die mit Abstand wichtigste Voraussetzung, um dies durchzuhalten, ist der Arbeitsaufwand. Hier eine Markdown-Vorlage, entworfen mit der Obergrenze, den ersten Entwurf in einer Stunde schreiben zu können. Ich empfehle, sie als datierte Datei unter etwa docs/postmortem/ im Repository zu führen, versionskontrolliert am selben Ort wie der Code.

# Postmortem: Auftragsliste zeigt doppelte Zeilen über eine Tagesgrenze hinweg (2026-07-15)

- Status: Abgeschlossen / Maßnahmen laufen / nur erfasst
- Autor: Komura
- Schweregrad: Mittel (Geschäftsbetrieb lief weiter, erforderte aber manuellen Abgleich)

## Zusammenfassung (max. 3 Zeilen)
Beim Öffnen der Auftragsliste während des laufenden Monatsabschlussjobs
wurden die Belege des Vortags doppelt angezeigt. Reines Anzeigeproblem;
die Daten in der Datenbank waren korrekt.

## Auswirkung (wer / was / wie viel)
- Betroffen: 3 Mitarbeitende der Verkaufsniederlassung
- Was passierte: Doppelte Zeilen in der Listenansicht. 1 Fall, in dem
  eine Lieferung beinahe versehentlich zweimal versendet worden wäre
- Dauer: etwa 09:10-11:40 Uhr am 15.7. (rund 2,5 Stunden)

## Zeitlicher Ablauf
- 09:10 Nutzer ruft an: „derselbe Beleg erscheint als zwei Zeilen“ (erkannt)
- 09:30 Remote-Bildschirmfreigabe; Reproduktionsbedingungen bestätigt
- 10:15 Übergangslösung: Nutzer gebeten, die Liste während des laufenden
  Abschlusses nicht zu öffnen
- 11:40 Korrigierte Version bereitgestellt und Wiederherstellung bestätigt

## Direkte Ursache
Die Listenabfrage führte ein UNION ALL zwischen der Haupttabelle und den
Zeilen aus, die der Abschlussjob in eine temporäre Tabelle kopiert hatte
(ohne Sperrung).

## Beitragende Faktoren
- Die gleichzeitige Ausführung von Abschlussjob und Bildschirmabfrage
  war in keinem Testszenario enthalten
- Die Existenz der temporären Tabelle war nie im Designdokument
  festgehalten, weshalb sie bei der Änderung des Bildschirms nicht
  berücksichtigt wurde
- Es gab keinen Mechanismus zur Erkennung der doppelten Anzeige; die
  Entdeckung hing vollständig davon ab, dass der Nutzer es bemerkte

## Was gut lief
- Der Nutzer hatte die Uhrzeit in seinem eigenen Betriebsprotokoll
  notiert, was die Eingrenzung der Reproduktionsbedingungen beschleunigte
- Die Deployment-Pipeline war automatisiert, sodass die Korrektur
  noch am selben Tag ausgeliefert werden konnte

## Rückfallpräventionsmaßnahmen (Verantwortlicher und Frist)
- [ ] Eine Duplikat-Erkennungs-Assertion zur Listenabfrage hinzufügen (Komura, 22.7.)
- [ ] Einen Test für die gleichzeitige Ausführung von Abschlussjob/Abfrage hinzufügen (Komura, 29.7.)
- [ ] Den Ansatz mit der temporären Tabelle ablösen und Snapshot-Isolation prüfen (Komura, Grundsatzentscheidung bis Ende August)

Ein paar Hinweise, wie man das gut schreibt.

• Halten Sie die „Zusammenfassung“ auf maximal drei Zeilen. Wer dieses Dokument später sucht, ist Ihr zukünftiges Ich. In drei Zeilen verstehen zu können, wenn man es bei einer Suche findet, zählt mehr als eine elegante Struktur.
• Der zeitliche Ablauf sollte nur Fakten enthalten, jeweils mit Zeitstempel. Halten Sie Interpretation („es hätte … sein sollen“, „wir hätten … tun sollen“) getrennt in den Ursachenabschnitten. Vermischen Sie Interpretation in den Zeitablauf, verlieren Sie die Fähigkeit, beim späteren Lesen zu rekonstruieren, was tatsächlich wann geschah.
• Schreiben Sie immer auf, „was gut lief“. Das bewahrt den Rückblick davor, zu einer Selbstgeißelungssitzung zu werden, und gibt Ihnen einen Ansatzpunkt, um Dinge, die zufällig funktioniert haben (etwa ein Protokoll, das zufällig vorhanden war), zu einem echten Mechanismus zu befördern.
• Jede Maßnahme muss einen Verantwortlichen und eine Frist haben. Eine Maßnahme ohne beides wird nie erledigt. Die tatsächliche Wirksamkeit eines Postmortems bemisst sich daran, ob es überprüft wird und ob seine Maßnahmen nachverfolgt werden.¹

5. Die Praxis der Ursachenanalyse – Direkte Ursachen von beitragenden Faktoren trennen

Es gibt einen Grund, warum die Vorlage das Ursachenfeld in zwei Teile aufteilt.

Die direkte Ursache ist das technische Ereignis, das den Vorfall unmittelbar ausgelöst hat – „eine Ausnahme durch eine fehlende NULL-Prüfung“, „ein UNION ALL ohne Sperrung.“ Das ist es, was der Korrektur-Patch tatsächlich behebt.

Beitragende Faktoren sind die Bedingungen, die es ermöglichten, dass die direkte Ursache unbemerkt eindrang, unentdeckt blieb oder den Schaden weiter ausbreitete – „es gab keinen Test für diesen Fall“, „es stand nicht im Designdokument“, „die Erkennung hing davon ab, dass der Nutzer es bemerkte.“ Dies ist das Hauptschlachtfeld für Rückfallpräventionsmaßnahmen, und es gibt davon meist mehrere.

Der Grund für die Trennung ist einfach: Beheben Sie nur die direkte Ursache, und bleiben die beitragenden Faktoren bestehen, wird eine andere direkte Ursache über denselben Weg eindringen. Der „gleiche Fehler auf einem anderen Bildschirm“ aus der Einleitung dieses Artikels ist genau das.

5.1 Lassen Sie die Fünf Warums nicht bei „einer menschlichen Handlung“ stehenbleiben

Die Fünf Warums sind ein wirksames Werkzeug, um eine Ursache zu ergründen, doch in die falsche Richtung gegraben, werden sie zu einem Werkzeug der Schuldzuweisung. Der typische Fehler ist, bei „warum? – weil die verantwortliche Person die Prüfung vergessen hat“ stehenzubleiben. Bleiben Sie dort nicht stehen; graben Sie eine Ebene tiefer.

• Warum war es möglich, die Prüfung zu vergessen? → Weil die Prüfung weder in einem Verfahrensdokument noch in einer Checkliste stand und rein vom Erinnerungsvermögen abhing
• Warum hing sie vom Erinnerungsvermögen ab? → Weil das Release-Verfahren nie dokumentiert und jedes Mal spontan zusammengestellt wurde

Taucht eine menschliche Handlung als Antwort auf, ist das nicht der Endpunkt – es ist der Einstieg in die nächste Frage, die das System betrifft. Akzeptiert man die Prämisse, dass Menschen immer wieder Fehler machen werden, verschiebt sich die Frage, die es zu ergründen lohnt, von „warum haben sie den Fehler gemacht“ zu „warum erreichte der Fehler unverändert die Produktion.“

5.2 Ohne Belege kommt die Analyse nie in Gang

Die Qualität einer Ursachenanalyse ist durch die Qualität der zum Zeitpunkt des Vorfalls hinterlassenen Belege gedeckelt. Ein Postmortem, das den zeitlichen Ablauf nicht rekonstruieren kann, wird zu einem Stück spekulativer Fiktion. Für die Wartung einer Windows-App sind hier die minimal drei Dinge, die vorhanden sein müssen.

• Absturz-Dumps. Richten Sie WER LocalDumps ein, und ein Dump bleibt zurück, wann immer die App unerwartet beendet wird, ohne dass der Nutzer irgendetwas tun muss. Die Einrichtung wird in „Eine Einführung in das Sammeln von Windows-Absturz-Dumps“ behandelt, das Auslesen in „Absturz-Dumps mit WinDbg + SOS lesen“.
• Anwendungsprotokolle. Zeitstempel, eine korrelierbare ID und synchrones Schreiben für kritische Ereignisse. Siehe „Windows-Apps so entwerfen, dass sie beim Absturz Protokolle und Dumps hinterlassen“ dafür, wie man sicherstellt, dass das Logging einen Absturz übersteht.
• Das Ereignisprotokoll. Selbst wenn das eigene Logging versagt, hält das Standard-Ereignisprotokoll des Betriebssystems weiterhin einen Eintrag zum App-Absturz fest (Application Error). Wie man es nutzt, wird in „Eine Einführung in Windows Event Log und ETW“ behandelt.

Setzen Sie sich hin, um das Postmortem zu schreiben, und können den zeitlichen Ablauf nicht ausfüllen, ist diese Unfähigkeit selbst ein beitragender Faktor – „die Erkennungs- und Logging-Mechanismen sind unzureichend“ – und ein Kandidat für eine Rückfallpräventionsmaßnahme.

6. Die Qualität von Rückfallpräventionsmaßnahmen – Eine Stärke-Entscheidungstabelle

Sobald Sie Rückfallpräventionsmaßnahmen aufgeschrieben haben, beurteilen Sie deren Stärke. Der Beurteilungsmaßstab ist, wie stark die Maßnahme von menschlicher Aufmerksamkeit abhängt.

Die realistische Regel hier lautet nicht „schwache Maßnahmen verbieten“, sondern „eine schwache Maßnahme nicht das letzte Wort sein lassen“. Bewusstsein zu schärfen hat als Übergangsreaktion, die man noch am selben Tag umsetzen kann, durchaus Wert, doch was ins Feld für die dauerhafte Lösung gehört, ist mindestens Mittel, und wo möglich Stark.

Kommen Ihnen nur schwache Maßnahmen in den Sinn, prüfen Sie diese noch einmal anhand dieser Fragen.

• „Würde dieser Vorfall auch dann nicht passieren, wenn eine brandneue Mitarbeiterin genau in dieselbe Situation gebracht würde?“ Wenn die Antwort Nein lautet, ist es noch kein System.
• „Kann dieser Fehler vom Compiler, einem Test oder der CI abgefangen werden?“ Wenn das Problem beispielsweise war, dass „wir beim Herunterfahren eine Ausnahme verschluckt haben“, ist die starke Maßnahme nicht Bewusstsein zu schärfen – sondern im gemeinsamen Ausnahmebehandler der App eine Richtlinie umzusetzen, wie sie in „Eine Entscheidungstabelle dafür, ob man nach einer unerwarteten Ausnahme beenden oder fortfahren sollte“ dargelegt ist.
• „Können wir den Fehler unmöglich machen? Können wir ihn schnell bemerkbar machen?“ Ist Prävention teuer, ist es auch eine völlig legitime starke Maßnahme, stattdessen auf Erkennung zu setzen (Monitoring, Alarme, ein Abgleich-Batch-Job). Die Lehren eines Vorfalls in stärkere Erkennung und verbessertes Design zurückzuführen, ist dieselbe Struktur, die Microsofts Leitfaden empfiehlt.²

Weil starke Maßnahmen echten Aufwand erfordern, ist der praktische Ansatz, sowohl „eine mittlere Maßnahme, diese Woche zu erledigen“ als auch „eine starke Maßnahme, nächsten Monat zu erledigen“ auf die Aktionsliste zu setzen und beide nach Frist zu verwalten.

7. Welche Vorfälle eines bekommen – Die Umsetzung staffeln

Schreiben Sie ein vollständiges Postmortem für jeden einzelnen Vorfall zwingend vor, schreibt sie innerhalb von drei Monaten niemand mehr. Legen Sie den Aufwand nach Auswirkung mal Wiederholungswahrscheinlichkeit fest.

Es gibt drei Schlüssel für die Durchführung.

• Ein wiederholter Vorfall gleichen Typs wird unabhängig von der Auswirkung um eine Stufe hochgestuft. Die bloße Tatsache der Wiederholung ist der Beweis, dass die vorherige Maßnahme nie zu einem echten System wurde.
• Lassen Sie selbst bei Kleinigkeiten immer zumindest ein Protokoll zurück. Ein Absatz genügt. Mit nur vier Punkten – Datum, Symptom, Ursache, Reaktion – wird Ihr zukünftiges Ich Jahre später durch eine Suche gerettet. Sobald sich genug Protokolle kleiner Vorfälle angesammelt haben, werden auch strukturelle Ungleichgewichte sichtbar, etwa „allein dieser eine Bildschirm ist für die meisten Vorfälle verantwortlich.“
• Im Zweifel lieber etwas schreiben, aber den Umfang verringern. Wenn Sie Zeit damit verbringen, vollständig gegen nicht vollständig zu diskutieren, sind Sie schneller fertig, wenn Sie einfach mit der leichten Version anfangen.

8. Der Umgang damit in der Auftragsentwicklung – Das Verhältnis zu kundenseitigen Vorfallberichten

Bei Auftrags- oder Wartungsarbeiten fordern Kunden nach einem Vorfall einen „Vorfallbericht“ an. Das Verhältnis zwischen dem Postmortem und diesem Bericht vorab zu klären, erspart Ihnen doppelte Arbeit.

Etwa 80 % des Inhalts lassen sich direkt wiederverwenden. Zusammenfassung, Auswirkung, zeitlicher Ablauf, direkte Ursache und Rückfallpräventionsmaßnahmen sind genau die Bestandteile eines kundenseitigen Berichts. Schreiben Sie zuerst das interne Postmortem und redigieren Sie es dann für den Kunden herunter, und Sie schreiben nie Prosa, die allein für den Bericht existiert.

Behalten Sie dabei jedoch im Hinterkopf, dass dies zwei Dokumente mit unterschiedlichen Zwecken sind, und halten Sie sie getrennt.

Der wichtigste Grund für die Trennung ist, dass die Vermischung der Haftungs-/Entschädigungsdiskussion mit der Rückfallpräventionsdiskussion beide verzerrt. In einem Dokument, das mit einer Haftungsfrage verstrickt ist, schreiben alle Beteiligten zwangsläufig defensiv. Beitragende Faktoren verschwinden aus einem defensiven Dokument, und Rückfallprävention verkommt zu „wir werden vorsichtig sein.“ Umgekehrt: Geben Sie ein offen geschriebenes internes Postmortem direkt an einen Kunden weiter, können aus dem Zusammenhang gerissene Passagen ein Eigenleben entwickeln. Der sichere Ansatz ist, „das interne Dokument, offen geschrieben“ und „das externe Dokument, präzise kommuniziert“ getrennt zu halten und daraus eine Einbahnstraße zu machen: Bauen Sie Letzteres aus Ersterem auf.

Noch etwas: Sobald eine geplante Rückfallpräventionsmaßnahme in einen kundenseitigen Bericht geschrieben wird, wird sie zu einem Versprechen an diesen Kunden. Verwalten Sie ihre Frist genauso wie die Aktionspunkte des Postmortems, und melden Sie zurück, sobald sie erledigt ist. Genau dieser eine Rückweg macht aus einem Vorfall eine echte Gelegenheit, Vertrauen aufzubauen.

9. Zusammenfassung

• Incident Response endet nicht mit der Wiederherstellung. Behandeln Sie Wiederherstellung, Ursachenermittlung und Rückfallprävention als getrennte Aufgaben und bauen Sie den Rückblick (das Postmortem) in Ihre reguläre Arbeit ein.
• Blamelessness ist das Leitprinzip des Postmortems. Beschuldigen Sie Menschen, hört Information auf, aufzutauchen, und Sie erreichen nie die Grundursache. Beenden Sie die Analyse nicht bei einer menschlichen Handlung – graben Sie bis zum Loch im System (den beitragenden Faktoren) durch.¹
• Eine minimale Vorlage, die sich in einer Stunde schreiben lässt – Zusammenfassung, Auswirkung, zeitlicher Ablauf, direkte Ursache, beitragende Faktoren, was gut lief und Maßnahmen mit Verantwortlichem und Frist – genügt. Als Voraussetzung, um den zeitlichen Ablauf ausfüllen zu können, richten Sie vorab die Beweissicherung ein: Absturz-Dumps, Protokolle und das Ereignisprotokoll.
• Heben Sie Rückfallpräventionsmaßnahmen von „Vorsicht walten lassen“ (schwach) auf ein Verfahrensdokument (mittel) und wo möglich bis hin zu mechanischer Verhinderung durch Tests, Assertions, Monitoring oder eine Design-Änderung (stark) an. Die Lehren in Erkennung und Design zurückzuführen, ist eine Struktur, die sowohl SRE als auch Microsofts Leitfaden gemeinsam ist.¹²
• Führen Sie nicht für jeden Vorfall den vollständigen Prozess durch. Staffeln Sie nach Auswirkung mal Wiederholungswahrscheinlichkeit, und hinterlassen Sie selbst bei Kleinigkeiten immer zumindest einen Absatz-Eintrag.
• Schreiben Sie in der Auftragsentwicklung zuerst das interne Postmortem, und redigieren Sie daraus den kundenseitigen Vorfallbericht. Das Haftungs-/Entschädigungsdokument vom Rückfallpräventionsdokument zu trennen, schützt die Qualität beider.

Verwandte Artikel

• Eine Einführung in das Sammeln von Windows-Absturz-Dumps - WER/ProcDump/WinDbg
• Absturz-Dumps mit WinDbg + SOS lesen ── Ein praktischer Leitfaden zur Analyse nach dem Sammeln
• Windows-Apps so entwerfen, dass sie beim Absturz Protokolle und Dumps hinterlassen
• Eine Einführung in Windows Event Log und ETW ── Die Protokolle Ihrer Geschäftsanwendung auf die Standardmechanismen des Betriebssystems bringen
• Wohin gehören catch und Logging in der Ausnahmebehandlung?
• Eine Entscheidungstabelle dafür, ob man nach einer unerwarteten Ausnahme beenden oder fortfahren sollte

Verwandte Beratungsleistungen

Die Komura Software LLC übernimmt alles von der Untersuchung und Diagnose schwer reproduzierbarer Fehler über den Aufbau von Mechanismen zur Beweissicherung (Logging und Dump-Sammlung) bis hin zur Organisation einer Wartungs- und Betriebsstruktur, die Rückfallprävention einschließt. Wir freuen uns auch über Anfragen im Stadium von „derselbe Vorfall wiederholt sich immer wieder“ oder „die Rückfallpräventionsmaßnahmen in unseren Vorfallberichten sind zur Formsache geworden.“

• Fehlersuche & Ursachenanalyse
• Wartung & Modernisierung bestehender Windows-Software
• Technische Beratung & Designprüfung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist ein Postmortem? Worin unterscheidet es sich von einem Vorfallbericht?

Ein Postmortem ist ein strukturiertes Rückblick-Dokument und eine ebensolche Tätigkeit, die nach der Wiederherstellung von einem Vorfall durchgeführt wird – eine Technik, die sich im Bereich SRE (Site Reliability Engineering) etabliert hat. Ausgehend von der Prämisse „blameless“ (niemanden persönlich beschuldigen) hält es den zeitlichen Ablauf, die direkte Ursache, die beitragenden Faktoren und die Rückfallpräventionsmaßnahmen fest. Während ein kundenseitiger Vorfallbericht ein Dokument ist, das Rechenschaft ablegt – „was ist passiert und wie haben wir reagiert“ –, ist ein Postmortem ein internes Dokument zur Entscheidung, „wie das System geändert werden muss, damit das nie wieder passiert.“ Da sich die Inhalte weitgehend überschneiden, ist es jedoch effizient, zuerst das Postmortem zu schreiben und daraus dann einen kundenseitigen Bericht zu redigieren.

Meine Rückfallpräventionsmaßnahmen laufen immer nur auf ‚wir werden künftig vorsichtiger sein' hinaus. Was soll ich tun?

„Vorsichtig sein“ und „Bewusstsein schärfen“ hängen von menschlichem Erinnerungsvermögen und guten Vorsätzen ab, weshalb ihre Wirkung garantiert mit der Zeit verblasst, sobald Personen wechseln. Fragen Sie sich beim Ausarbeiten einer Maßnahme erneut: „Würde dieser Vorfall auch dann nicht passieren, wenn eine brandneue Mitarbeiterin genau in dieselbe Situation gebracht würde?“ Wenn die Antwort Nein lautet, ist es noch kein System. Eine starke Maßnahme ist eine, die mechanisch erkannt oder verhindert wird, ohne dass jemand vorsichtig sein muss – ein Test, eine Assertion, eine im Typsystem oder Design verankerte Beschränkung, ein Monitoring-Alarm. Wenn Sie nicht sofort eine starke Maßnahme umsetzen können, nutzen Sie als Zwischenschritt eine Checkliste oder ein schriftliches Verfahren, und protokollieren Sie die dauerhafte Lösung als Aktion mit Frist.

Wir sind ein kleiner Auftragsentwicklungsbetrieb ohne Spielraum, für jeden einzelnen Vorfall ein Postmortem zu schreiben.

Sie brauchen kein vollständiges Postmortem für jeden Vorfall, und würden Sie es versuchen, würde die Praxis selbst nicht überleben. Staffeln Sie den Aufwand nach Auswirkung und Wiederholungswahrscheinlichkeit: den vollständigen Prozess für Vorfälle mit Geschäftsunterbrechung oder Datenverfälschung, oder wenn sich ein gleichartiger Vorfall wiederholt; für kleinere Fälle genügt ein Absatz im Vorfallprotokoll. Wichtig ist, dass Sie selbst für Kleinigkeiten immer zumindest einen Eintrag hinterlassen – ob Sie einen früheren Vorfall Jahre später bei erneutem Auftreten wiederfinden können, macht einen enormen Unterschied für die Dauer der Untersuchung.

Ist ‚keine Schuldigen suchen' (blameless) nicht nur eine Art, Verantwortlichkeit im Vagen zu belassen?

Nein. Blamelessness ist ein Prinzip, um den Fokus weg von ‚wer hat den Fehler gemacht' und hin zu ‚warum das System es dieser Person ermöglicht hat, ihn zu machen' zu verschieben. Hat ein Bediener bei einer Aktion einen Fehler gemacht, gibt es einen beitragenden Faktor in der Oberfläche oder im Verfahren, der den Fehler erst möglich gemacht hat. In einer Organisation, die Einzelpersonen bestraft, wird beim nächsten Mal Information verborgen, und man erreicht nie die Grundursache. Rechenschaft gegenüber dem Kunden – was passiert ist und wie es ausgeglichen wird – sollte als eigenes Dokument und eigener Prozess behandelt werden, und das steht nicht im Widerspruch zu einem blameless Rückblick. Das interne Dokument vom Rechenschaftsdokument getrennt zu halten, ist der praktische Schlüssel.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.