Meine Session planen
Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.
Session: Blameless Postmortem
Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.
Methoden-Session mit 3-12. Der Plan nutzt die vorhandene Methodenlogik und das Run Sheet.
Run Sheet- 1
Phase 1: Timeline-Walkthrough
20 minFacilitator liest die Timeline laut vor, Beteiligte ergänzen Lücken, korrigieren Zeitstempel und kennzeichnen Entscheidungspunkte. Keine Diskussion über Ursachen, nur Faktenbasis. Hinweis: Wenn das Team in Phase 1 in Diskussion rutscht, Facilitator stoppt und schiebt Punkte in Phase 3. Timeline ist Grundlage, nicht Bewertung. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
FacilitatorPostmortem Doc - 2
Phase 2: Impact-Erfassung
10 minNutzer-Impact, Geschäfts-Impact und SLO-Verletzungen in Zahlen festhalten. Mindestens: Dauer der Beeinträchtigung, Anzahl betroffener Nutzer, geschätzter Umsatz- oder Reputationseffekt. Hinweis: Zahlen brauchen Quelle. Wenn Schätzungen, dann als Schätzung markieren. Impact treibt Priorität der Action Items. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
FacilitatorAction Items - 3
Phase 3: Contributing Factors
30 minBeitragende Faktoren in Kategorien sammeln: Technik, Prozess, Organisation, Information. Pro Faktor: was hat das System getan oder unterlassen, was hätte den Verlauf verändert. Sprache neutral halten. Hinweis: Facilitator unterbricht bei Personifizierungen und formuliert um. Statt „X hat vergessen“ wird daraus „der Prozess hatte keinen Kontrollpunkt“. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
FacilitatorTimeline - 4
Phase 4: Action Items
20 minPro Contributing Factor 0-2 Massnahmen mit Owner, Frist und Priorität. Action Items als kleine, ausführbare Tickets, keine Programme. Detection-Massnahmen klar von Ursachen-Massnahmen trennen. Hinweis: Wenn alle Action Items „bessere Doku“ oder „mehr Training“ sind, fehlt System-Tiefe. Mindestens eine technische Massnahme pro relevantem Faktor. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
FacilitatorPostmortem Doc - 5
Phase 5: Lessons und Sign-off
10 minDrei Lessons Learned formulieren, die andere Teams interessieren könnten. Veröffentlichungs-Format und Adressaten klären. Sign-off durch Incident Commander und Facilitator. Hinweis: Lessons gehören in den teamübergreifenden Lernkanal, nicht nur in den lokalen Wiki-Ordner. Wenn Lessons nur intern bleiben, fehlt der Multiplikator-Effekt. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
OwnerAction Items - 6
Artefakt veröffentlichen
10 minArtefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
OwnerPostmortem Doc
Session Brief
Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.
# Session Brief: Blameless Postmortem
## Ziel
Artefakt: Postmortem Doc
## Arbeitsfrage
Welche Systembedingungen und Entscheidungspunkte haben den Incident möglich gemacht, und welche konkreten Massnahmen verhindern die Wiederholung?
## Kontext
Incident-ID, Dauer, Impact in Zahlen (Nutzer, Umsatz, SLO-Verletzung); Timeline-Entwurf 24 h vor Termin; bekannte Workarounds; bisherige Hypothesen aus dem Chat-Verlauf; Datum und Owner des Termins.
## Setup
- Format: Methoden-Session
- Dauer: 60-90 min Workshop, plus 2 h asynchrone Vorbereitung durch Facilitator
- Modus: Workshop oder async
- Teilnehmende: Facilitator ohne direkte Incident-Beteiligung; Incident Commander des Vorfalls; alle Operatoren mit aktiver Handlung im Verlauf; ein Scribe für das Protokoll; optional ein neutraler Beobachter aus einem anderen Team für Externblick.
- Owner: Facilitator ohne direkte Incident-Beteiligung
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen
## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.
## Ergebnislogik
Die Session arbeitet direkt auf Postmortem Doc hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.
## Input
Postmortem-Template (Header, Timeline, Impact, Root Cause, Contributing Factors, Action Items, Lessons); geteiltes Dokument; Log-Auszüge und Graphen vom Incident-Tag; Chat-Transkript aus dem Incident-Channel; Liste der Beteiligten.
## Vorbereitung
Termin maximal 5 Werktage nach Resolution. Template mit Header und Timeline-Skeleton vorab ausfüllen. Regel ansagen: Sprache fokussiert auf Systemverhalten, keine Namen in Ursachenformulierungen. Aufzeichnung optional, aber Konsens vorab.
## Agenda
1. Phase 1: Timeline-Walkthrough (20 min)
Owner: Facilitator
Aktion: Facilitator liest die Timeline laut vor, Beteiligte ergänzen Lücken, korrigieren Zeitstempel und kennzeichnen Entscheidungspunkte. Keine Diskussion über Ursachen, nur Faktenbasis. Hinweis: Wenn das Team in Phase 1 in Diskussion rutscht, Facilitator stoppt und schiebt Punkte in Phase 3. Timeline ist Grundlage, nicht Bewertung. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Postmortem Doc
2. Phase 2: Impact-Erfassung (10 min)
Owner: Facilitator
Aktion: Nutzer-Impact, Geschäfts-Impact und SLO-Verletzungen in Zahlen festhalten. Mindestens: Dauer der Beeinträchtigung, Anzahl betroffener Nutzer, geschätzter Umsatz- oder Reputationseffekt. Hinweis: Zahlen brauchen Quelle. Wenn Schätzungen, dann als Schätzung markieren. Impact treibt Priorität der Action Items. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Action Items
3. Phase 3: Contributing Factors (30 min)
Owner: Facilitator
Aktion: Beitragende Faktoren in Kategorien sammeln: Technik, Prozess, Organisation, Information. Pro Faktor: was hat das System getan oder unterlassen, was hätte den Verlauf verändert. Sprache neutral halten. Hinweis: Facilitator unterbricht bei Personifizierungen und formuliert um. Statt „X hat vergessen“ wird daraus „der Prozess hatte keinen Kontrollpunkt“. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Timeline
4. Phase 4: Action Items (20 min)
Owner: Facilitator
Aktion: Pro Contributing Factor 0-2 Massnahmen mit Owner, Frist und Priorität. Action Items als kleine, ausführbare Tickets, keine Programme. Detection-Massnahmen klar von Ursachen-Massnahmen trennen. Hinweis: Wenn alle Action Items „bessere Doku“ oder „mehr Training“ sind, fehlt System-Tiefe. Mindestens eine technische Massnahme pro relevantem Faktor. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Postmortem Doc
5. Phase 5: Lessons und Sign-off (10 min)
Owner: Owner
Aktion: Drei Lessons Learned formulieren, die andere Teams interessieren könnten. Veröffentlichungs-Format und Adressaten klären. Sign-off durch Incident Commander und Facilitator. Hinweis: Lessons gehören in den teamübergreifenden Lernkanal, nicht nur in den lokalen Wiki-Ordner. Wenn Lessons nur intern bleiben, fehlt der Multiplikator-Effekt. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Action Items
6. Artefakt veröffentlichen (10 min)
Owner: Owner
Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
Output: Postmortem Doc
## Abschluss
- Ergebnisartefakt aktualisieren: Postmortem Doc
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.Arbeitsartefakt
Vorgefüllter Startpunkt auf Basis der passenden Vorlage.
# Postmortem Doc: Blameless Postmortem
## Arbeitsfrage
Welche Systembedingungen und Entscheidungspunkte haben den Incident möglich gemacht, und welche konkreten Massnahmen verhindern die Wiederholung?
## Kontext
Incident-ID, Dauer, Impact in Zahlen (Nutzer, Umsatz, SLO-Verletzung); Timeline-Entwurf 24 h vor Termin; bekannte Workarounds; bisherige Hypothesen aus dem Chat-Verlauf; Datum und Owner des Termins.
## Beteiligte
- Owner: Facilitator ohne direkte Incident-Beteiligung
- Teilnehmende: Facilitator ohne direkte Incident-Beteiligung; Incident Commander des Vorfalls; alle Operatoren mit aktiver Handlung im Verlauf; ein Scribe für das Protokoll; optional ein neutraler Beobachter aus einem anderen Team für Externblick.
## Input
Postmortem-Template (Header, Timeline, Impact, Root Cause, Contributing Factors, Action Items, Lessons); geteiltes Dokument; Log-Auszüge und Graphen vom Incident-Tag; Chat-Transkript aus dem Incident-Channel; Liste der Beteiligten.
## Vorlage
# Blameless Postmortem
## Zusammenfassung
Was ist passiert, welche Wirkung hatte es?
## Impact
- Kundenauswirkung:
- Dauer:
- Betroffene Systeme:
## Timeline
Link oder Auszug der Timeline.
## Beitragende Faktoren
- ...
## Was lief gut?
- ...
## Was verbessern wir?
| Maßnahme | Owner | Datum | Erwartete Wirkung |
|---|---|---|---|
## Follow-up
Review-Termin und Status.
## Fertigstellungscheck
- Postmortem Doc ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:
## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminierenBlameless Postmortem
# Blameless Postmortem
## Zusammenfassung
Was ist passiert, welche Wirkung hatte es?
## Impact
- Kundenauswirkung:
- Dauer:
- Betroffene Systeme:
## Timeline
Link oder Auszug der Timeline.
## Beitragende Faktoren
- ...
## Was lief gut?
- ...
## Was verbessern wir?
| Maßnahme | Owner | Datum | Erwartete Wirkung |
|---|---|---|---|
## Follow-up
Review-Termin und Status.- Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
- Das Ergebnis passt zu Postmortem Doc.
- Pro Incident ein Dokument mit Incident-ID im Titel. Status-Feld (draft, review, signed-off, follow-up-done). Action-Item-Status wird im Dokument-Header aktuell gehalten. Spätere Erkenntnisse als datierter Anhang, nicht durch Überschreibung.
- Offene Fragen sind als Follow-up notiert.
- Der nächste Review oder Entscheidungspunkt ist terminiert.