DevOps Operative Praxis

Blameless Postmortem

Ein Blameless Postmortem untersucht nach einem Vorfall das Zusammenspiel von Systembedingungen und Ereignissen und leitet nachverfolgbare Verbesserungen ab.

Ein Blameless Postmortem untersucht nach einem Vorfall das Zusammenspiel von Systembedingungen und Ereignissen. Die Analyse erklärt, unter welchen Bedingungen die Beteiligten gehandelt haben, und leitet daraus nachverfolgbare Verbesserungen ab.

Kernfrage

Welche Bedingungen ermöglichten den Vorfall, und wie reduzieren wir Wiederholung oder Auswirkung?

Planung vorbereiten Methodenanleitung

Vergleich starten

Feedback gebenHilft dir diese Methode?

Teilnehmende: 3-12
Zeit: 30-90 min

Die Phasen können iterativ durchlaufen werden; ihre Reihenfolge unterstützt den Einstieg, ersetzt aber kein fachliches Urteil.

Arbeitsfläche für Blameless Postmortem: Frage, Beobachtungen und nächste Entscheidung sind sichtbar.

Fakten
Lernrahmen und Fakten sichern
Vorfall abgrenzen, Beteiligte einladen und Logs, Statusmeldungen sowie Zeitstempel sichern.
Zeitlinie
Zeitlinie rekonstruieren
Ereignisse, Entscheidungen, Signale und Auswirkungen mit Quellen sortieren; Wissenslücken markieren.
Bedingungen
Bedingungen untersuchen
Frage nach Systembedingungen, die Handlungen und Verlauf verständlich machen; keine Schuldperson suchen.
Maßnahmen
Maßnahmen nachhalten
Formuliere konkrete Präventions-/Erkennungs-/Behebungsmaßnahmen mit Owner und Termin.

Prüfe Ergebnis und offene Annahmen beim nächsten passenden Termin. Halte Änderungen, Verantwortung und neue Evidenz fest.

Geeignet, wenn

Geeignet: Abgeschlossener, auswertungswürdiger Vorfall mit Beteiligten, Faktenquellen und einem sicheren Lernrahmen.

Ideal für

Incidents
Outages
Reliability Culture

Nicht gut für

Performance Evaluation
Punitive Investigations

Ergebnisse

Arbeitsbild
Arbeitsbild mit abgegrenztem Vorfall, Beteiligten sowie gesicherten Logs, Statusmeldungen und Zeitstempeln.
Prüfbare Evidenz
Die Analyse beschreibt Systembedingungen, die Handlungen und Verlauf verständlich machen. Sie richtet den Blick auf Verbesserungen am System.
Nächster Schritt
Konkrete Präventions-, Erkennungs- oder Behebungsmaßnahmen mit Owner und Termin.

Zeitlinie, Bedingungen und Maßnahmen

Fiktives Lehrbeispiel

Untersuche nach einem Vorfall, wie Systembedingungen und Ereignisse zusammenwirkten, und leite nachverfolgbare Verbesserungen ab.

Auswirkung

Notiere Incident-ID, Auswirkung, Zeitraum und Reviewauftrag.

Fiktiv: Buchungsbestätigung verzögert; 23 Minuten, betroffene Sessions dokumentiert.

Zeitlinie

Ordne Ereignisse mit Quelle und damaligem Informationsstand.

10:02 Konfigurationswechsel; 10:14 Queue-Alarm; 10:25 Rollback; 10:31 Rückstau abgebaut.

Bedingungen

Halte Prozess-, Werkzeug- und Systembedingungen sowie Unsicherheit fest.

Alarmgrenze spät; Rollback-Verfahren nicht geübt; gleichzeitig keine automatische Rücknahme.

Maßnahmen

Ergänze Prävention/Erkennung/Behebung, Owner und Termin.

Warnschwelle prüfen (SRE, 30.09.); Rollback üben (Service-Team, 07.10.).

Fiktiv: Ein Konfigurationswechsel blockiert 23 Minuten lang Buchungsbestätigungen. Alarmierung zeigte Queue-Wachstum erst nach 12 Minuten; Rücknahme gelang nach manueller Eskalation. Bericht hält Zeitlinie, unklare Warnschwelle und fehlenden getesteten Rollback fest. Maßnahmen: Schwelle prüfen, Rollback automatisieren, Eigentümer und Termin zuordnen.

Using SRE to meet reliability challenges · Google Cloud

Erster Schritt

Beginne mit einer abgegrenzten Frage, kläre Zugang und Beteiligte und sichere vorhandene Belege. Untersuche nach einem Vorfall, wie Systembedingungen und Ereignisse zusammenwirkten, und leite nachverfolgbare Verbesserungen ab.

Zur Methodenanleitung

Davor sinnvoll

DevOps

Incident Command

Liefert den stabilisierten, abgeschlossenen Vorfall als Prüfgegenstand.

Wie geht es weiter?

Delivery

RAID Log

Trägt die formulierten Maßnahmen als verfolgte Einträge mit Termin ein.

Operations

Runbook

Aktualisiert das betroffene Verfahren um die neue Erkenntnis.

Vertiefung

Zweck

Nach einem Incident mit Schaden oder Beinahe-Schaden schafft die Methode ein nüchternes Lernfeld ohne Schuldzuweisung. Sie richtet den Blick auf Verlauf, Bedingungen und wirksame Gegenmaßnahmen.

Funktionsweise

Der Vorfall wird so rekonstruiert, dass Fakten und Entscheidungen nachvollziehbar bleiben, ohne Menschen zum Erklärziel zu machen. Dadurch treten systemische Beiträge und Signale aus dem Alltag klarer hervor. Die nachfolgenden Verbesserungen zielen auf Robustheit statt auf persönliche Rechtfertigung.

Im Detail

Ein Blameless Postmortem schafft Lernfähigkeit nach Störungen, weil es Entscheidungen im Kontext rekonstruiert statt Schuldige zu suchen. Timeline, Impact, beitragende Faktoren und Maßnahmen brauchen klare Trennung. Der Nutzen entsteht, wenn das Team bessere Schutzmechanismen, Signale oder Recovery-Pfade ableitet und die Geschichte des Incidents nachvollziehbar bleibt.

Durchführung

Sichere Timeline, Logs, Screenshots und getroffene Entscheidungen, solange der Vorfall noch frisch im Gedächtnis liegt. Die Stimmung bleibt konstruktiv, wenn Formulierungen Bedingungen, Signale und Trade-offs beschreiben statt Personen zu bewerten. Schließe mit Systemänderungen, einem Nachverfolgungsweg und einem Termin, an dem die Wirksamkeit der Maßnahmen überprüft wird.

Die Methodenanleitung führt mit 4 Phasen, Zeitrahmen, 4 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen

Site Reliability Engineering Incident Lernen Zuverlässigkeit

Quellen

Using SRE to meet reliability challenges · Google Cloudcloud.google.comGeprüfte Methodenreferenz; stützt die fachliche Abgrenzung und Arbeitsschritte für Blameless Postmortem. Beispiele und redaktionelle Anleitung sind eigenständig und ausdrücklich fiktiv.

In Playbooks

Incident aufarbeitenVon verstreuten Logs und Erinnerungen zu Timeline, Lernpunkten und konkreten Verbesserungen.

Artefakt-Vorlagen

Blameless Postmortem: ArbeitsvorlageBereite Blameless Postmortem mit klarer Frage, Rollen und Quellen vor.

markdown

postmortem-markdown.md

Bereite Blameless Postmortem mit klarer Frage, Rollen und Quellen vor.

Blameless Postmortem: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Vollständigen Ablauf planen Zeit: Nach Umfang und verfügbaren Belegen festlegen

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Gemeinsame Arbeitsfläche, zugängliche Quellen und Notiz für Entscheidungen.
Rollen: Incident-Beteiligte · Moderation · Action Owner
Vorab-Infos: Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.
Gesamter Zeitbedarf: 60–90 Minuten nach gesicherter Stabilisierung; Quellenaufbereitung und Maßnahmenverfolgung separat.
Setup: Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.