Von einem simulierten Ausfall über geübte Vorfallsführung zu einer dokumentierten, verbesserten Lernschleife.
Ein geübter Vorfallsablauf mit geklärten Rollen, funktionierender Kommunikation und dokumentierten Verbesserungen am Deployment-Fluss.
Du kannst entscheiden, welche Verbesserungen am Deployment-Fluss priorisiert umgesetzt werden.
Die abgeleiteten Verbesserungen in Runbooks überführen und einen weiteren Game Day terminieren.
Erkennen und bewältigen System und Einsatzteam dieses vorab begrenzte Störungsszenario sicher?
Ein simulierter Ausfall deckt Schwachstellen auf, bevor sie in einem echten Vorfall Kosten verursachen.
Die im Game Day sichtbar gewordenen Schwachstellen zeigen, ob die Vorfallsführung tragfähig ist.
Wer führt, wer arbeitet an der Technik, und wie halten wir ein gemeinsames Lagebild?
Eine klare Rollenstruktur verhindert, dass im echten Vorfall Zeit mit Zuständigkeitsfragen verloren geht.
Die geklärten Rollen brauchen einen gemeinsamen Kommunikationskanal, um im Ernstfall zu funktionieren.
Welche Betriebsaktion profitiert von geteilter Sichtbarkeit, und welche Kontrollen verhindern Fehlbedienung?
Ein gebündelter Kanal macht den Vorfallsverlauf für alle Beteiligten nachvollziehbar und beschleunigt Abstimmung.
Nach der Übung wird der gesamte Ablauf strukturiert ausgewertet, um daraus zu lernen.
Was sollte geschehen, was geschah tatsächlich, was lernen wir daraus und was ändern oder erhalten wir?
Die strukturierte Nachbetrachtung stellt sicher, dass die Erkenntnisse aus der Übung tatsächlich in Verbesserungen münden.
Die abgeleiteten Verbesserungen werden in Runbooks und Deployment-Prozess übernommen.
Die Artefakte bleiben zugeklappt, bis du sie wirklich brauchst.
Bereite Game Day mit klarer Frage, Rollen und Quellen vor.
# Game Day: 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:** Übungsleitung · Safety Lead · Einsatzteam · Beobachtende
- **Vorab-Infos:** Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.
- **Gesamter Zeitbedarf:** Wiederkehrende Übung; Vorbereitung, Durchführung, Recovery und Maßnahmenreview getrennt planen.
- **Setup:** Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.
### Für die Arbeitsschritte bereitstellen
#### Übungsziel: Übungsziel und Risiko wählen
- Resilienzziel, Dienstkritikalität und Risiko
#### Grenzen: Teilnehmende und Stopps festlegen
- Genehmigtes Szenario, Teilnehmer und Kill-Switch
#### Durchführung: Szenario kontrolliert ausführen
- Monitoring, Beobachterprotokoll und reale Impact-Grenze
#### Lernen: Erkenntnisse nachverfolgen
- Befunde, Abhilfen und nächster Übungstermin
## Sicherheitsbegrenztes Szenario und Übungserkenntnis
### Szenario
Formuliere Lernziel, Dienst, Szenario und Umgebung.
...
### Sicherheitsgrenze
Definiere Beteiligte, Beobachtung, Kill-Switch und Grenzwerte.
...
### Erwartete Signale
Erfasse Alarme, Systemzustand und Reaktion während der Übung.
...
### Lernpunkt
Notiere Wiederherstellung, Befunde, Owner und nächste Übung.
...
Leere Vorlage: beginne mit einer abgegrenzten Frage. Trage nur erhobene Fakten ein, markiere Annahmen und halte offene Fragen sowie Quellen fest.
[Conduct game days regularly · AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html)
## Übungsziel: Übungsziel und Risiko wählen
Erwartetes Artefakt: Begrenztes, genehmigtes Störungsszenario
Begrenztes, genehmigtes Störungsszenario
Eintrag:
...
- [ ] Ist das Szenario genehmigt und begrenzt?
## Grenzen: Teilnehmende und Stopps festlegen
Erwartetes Artefakt: Teilnehmer-, Kommunikations- und Safety-Plan
Teilnehmer-, Kommunikations- und Safety-Plan
Eintrag:
...
- [ ] Kann jede Person die Übung stoppen?
## Durchführung: Szenario kontrolliert ausführen
Erwartetes Artefakt: Beobachtete System- und Teamreaktion
Beobachtete System- und Teamreaktion
Eintrag:
...
- [ ] Bleibt der reale Nutzerschutz gewährleistet?
## Lernen: Erkenntnisse nachverfolgen
Erwartetes Artefakt: Nachverfolgte Befunde samt Wiederholungsplan
Nachverfolgte Befunde samt Wiederholungsplan
Eintrag:
...
- [ ] Fließen Lücken in Verfahren und Folgetest ein?
## Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/game-day/run-sheet
Bereite Incident Command mit klarer Frage, Rollen und Quellen vor.
# Incident Command: 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 Commander · Operations · Communications · Scribe
- **Vorab-Infos:** Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.
- **Gesamter Zeitbedarf:** Für die Dauer des Incidents; Rollen, Update-Takt und Übergaben passen sich der Lage an.
- **Setup:** Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.
### Für die Arbeitsschritte bereitstellen
#### Führung: Incident ausrufen und führen
- Incident-Symptome, Schweregrad und Einsatzkräfte
#### Lagebild: Lagebild etablieren
- Bestätigte Fakten, Auswirkungen und Systeme
#### Koordination: Arbeit und Kommunikation takten
- Rollen, Arbeitsstränge und Update-Empfänger
#### Übergabe: Stabilisieren und übergeben
- Stabilitätsnachweis, offene Risiken und Übergabe
## Lagebild, Arbeitsstränge und Übergabe
### Lage
Notiere Severity, Incident Commander und Startzeit.
...
### Rollen
Trenne bestätigte Fakten, Vermutungen, Impact und offene Fragen.
...
### Takt
Weise Arbeitsstränge, Update-Takt und Empfänger zu.
...
### Übergabe
Dokumentiere Stabilitätskriterien, Restgefahren und Annahme der Übergabe.
...
Leere Vorlage: beginne mit einer abgegrenzten Frage. Trage nur erhobene Fakten ein, markiere Annahmen und halte offene Fragen sowie Quellen fest.
[Incident management at Google · Google Cloud](https://cloud.google.com/blog/products/gcp/incident-management-at-google-adventures-in-sre-land)
## Führung: Incident ausrufen und führen
Erwartetes Artefakt: Incident-Erklärung mit Einsatzleitung
Incident-Erklärung mit Einsatzleitung
Eintrag:
...
- [ ] Ist eine Person klar für Koordination zuständig?
## Lagebild: Lagebild etablieren
Erwartetes Artefakt: Gemeinsames Lagebild und Impact-Zusammenfassung
Gemeinsames Lagebild und Impact-Zusammenfassung
Eintrag:
...
- [ ] Sind offene Annahmen kenntlich?
## Koordination: Arbeit und Kommunikation takten
Erwartetes Artefakt: Getaktete technische und kommunikative Arbeit
Getaktete technische und kommunikative Arbeit
Eintrag:
...
- [ ] Können Helfende beitragen ohne parallele widersprüchliche Kommandos?
## Übergabe: Stabilisieren und übergeben
Erwartetes Artefakt: Dokumentierte Stabilisierung und Kommandoübergabe
Dokumentierte Stabilisierung und Kommandoübergabe
Eintrag:
...
- [ ] Sind Dienst und Verantwortung klar übergeben?
## Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/incident-command/run-sheet
Bereite ChatOps mit klarer Frage, Rollen und Quellen vor.
# ChatOps: 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:** Service Owner · Security · Bot-Verantwortung · Nutzende
- **Vorab-Infos:** Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.
- **Gesamter Zeitbedarf:** Mehrere Schritte von Auswahl über Rechteprüfung bis Pilot; danach regelmäßig Zugriffe und Nutzung prüfen.
- **Setup:** Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.
### Für die Arbeitsschritte bereitstellen
#### Vorgang: Geeigneten Vorgang wählen
- Wiederkehrender Vorgang und Nutzerbedürfnis
#### Kontrollen: Befehle und Rechte begrenzen
- Berechtigungen, allowlist und Freigabepolitik
#### Rückmeldung: Feedback in den Chat bringen
- Testumgebung, Bot-Integration und Fehlerpfade
#### Review: Nutzung und Risiken prüfen
- Audit-Einträge, Nutzung und Sicherheitsbefunde
## Kontrollierter Betriebsbefehl mit Audit
### Befehl
Beschreibe Vorgang, Nutzerbedarf und Chatkanal.
...
### Kontrollen
Notiere Befehlserlaubnis, Identität, Freigabe und Rollback.
...
### Rückmeldung
Ergänze Testresultat, Fehlerfälle und Rückmeldung im Chat.
...
### Nachvollziehbarkeit
Halte Auditquelle, Owner und nächsten Sicherheitsreview fest.
...
Leere Vorlage: beginne mit einer abgegrenzten Frage. Trage nur erhobene Fakten ein, markiere Annahmen und halte offene Fragen sowie Quellen fest.
[Using ChatOps to help Actions on-call engineers · GitHub Blog](https://github.blog/engineering/infrastructure/using-chatops-to-help-actions-on-call-engineers/)
## Vorgang: Geeigneten Vorgang wählen
Erwartetes Artefakt: Geeigneter, klar begrenzter ChatOps-Anwendungsfall
Geeigneter, klar begrenzter ChatOps-Anwendungsfall
Eintrag:
...
- [ ] Ist der Chat der richtige Ort für diese Aktion?
## Kontrollen: Befehle und Rechte begrenzen
Erwartetes Artefakt: Least-privilege-Befehls- und Freigabepolitik
Least-privilege-Befehls- und Freigabepolitik
Eintrag:
...
- [ ] Sind irreversible Aktionen geschützt?
## Rückmeldung: Feedback in den Chat bringen
Erwartetes Artefakt: Getesteter Befehl mit aussagekräftiger Rückmeldung
Getesteter Befehl mit aussagekräftiger Rückmeldung
Eintrag:
...
- [ ] Sind Fehlermeldungen handlungsfähig und sicher?
## Review: Nutzung und Risiken prüfen
Erwartetes Artefakt: Prüfbarer Audit- und Reviewpfad
Prüfbarer Audit- und Reviewpfad
Eintrag:
...
- [ ] Ist jede Aktion eindeutig einer Identität zuzuordnen?
## Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/chatops/run-sheet
Plane einen geschützten Rückblick auf ein abgeschlossenes Ereignis mit Plan, Zeitlinie und Follow-up.
# After-Action Review: Arbeitsvorlage
## Fragestellung
Noch zu klären
## Gewünschtes Ergebnis
Noch zu klären
## Rahmen
Ein Ereignis gemeinsam auswerten
Zeit: 20–45 Minuten nach dem Ereignis; Recherche und Maßnahmenumsetzung zusätzlich
Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.
## Vorbereitung für diesen Umfang
### Methodische Grundausstattung
- **Materialien:** Ziel oder Plan, Ablaufdaten und relevante Arbeitsartefakte; geschützter Gesprächsraum, Facilitator und gemeinsames Notizdokument.
- **Rollen:** Facilitator sorgt für klare Fragen und Beteiligung. Teilnehmende rekonstruieren den Ablauf. Eine Person sichert Lessons, Actions, Owner und Review.
- **Vorab-Infos:** Ziel, Plan, Zeitlinie, relevante Entscheidungen und beobachtbare Fakten sammeln. Unsicherheit ausdrücklich markieren.
- **Gesamter Zeitbedarf:** 20–45 Minuten für einen abgegrenzten Rückblick. Tiefe Untersuchung, formelle Incident-Berichte und Maßnahmenumsetzung sind zusätzliche Arbeit.
- **Setup:** Beginne mit vier Fragen: Was war vorgesehen? Was geschah tatsächlich? Was lief gut oder erschwerte die Aufgabe, und warum? Was ändern wir beim nächsten Mal? Vergleiche Plan und Ablauf, bevor Ursachen erklärt werden. Nutze offene Fragen, unterscheide Fakten von Hypothesen und beende mit wenigen verantworteten Actions. Die Army-Doktrin dient als Ursprungsreferenz; für zivile Teams werden Ablauf und Sprache an den Kontext angepasst.
### Für die Arbeitsschritte bereitstellen
#### Absicht: Ziel und Rahmen klären
- Plan, Ziel, Kontext
#### Verlauf: Tatsächliche Ereignisse rekonstruieren
- Zeitstempel, Protokolle, beteiligte Perspektiven
#### Vergleich: Plan und Realität gegenüberstellen
- Gemeinsame Erwartung und Zeitlinie
#### Erklären: Bedingungen und Lessons prüfen
- Vergleich, Ursachenhypothesen, Belege
#### Anpassen: Actions und spätere Prüfung festlegen
- Lessons, Verantwortliche, Folgeereignis
## Reviewnotiz in fünf Abschnitten
### Ziel und Plan
Was sollte bis wann und mit welchem erwarteten Ergebnis geschehen? Den betrachteten Abschnitt eingrenzen.
...
### Tatsächlicher Verlauf
Welche beobachtbaren Ereignisse, Entscheidungen und Zeitpunkte sind belegt? Unbekanntes markieren.
...
### Vergleich und Bedingungen
Was wich vom Plan ab? Welche hilfreichen oder erschwerenden Bedingungen sind durch Quellen gestützt?
...
### Lessons und Hypothesen
Was behalten wir bei oder ändern wir? Welche Erklärung ist belegt, welche muss geprüft werden?
...
### Actions und spätere Prüfung
Welche wenige Änderung erhält Owner, Termin und überprüfbares Signal beim nächsten passenden Ereignis?
...
Leere Vorlage: Arbeitsimpulse beibehalten und eigene Fakten, Beobachtungen sowie Actions eintragen. Das fiktive Beispiel wird nicht übernommen.
[U.S. Army, NTC EXOP Annex A: After Action Review Standards, angepasst für zivile Arbeitskontexte](https://home.army.mil/irwin/application/files/1816/9455/6714/FY23_JUNE_2023_NTC_EXSOP_RELEASEABLE.pdf)
## Absicht: Ziel und Rahmen klären
Erwartetes Artefakt: Gemeinsamer Ausgangspunkt
Ohne klare Erwartung lassen sich Abweichungen nicht sinnvoll erkennen.
Eintrag:
...
- [ ] Die Review beginnt mit allgemeinen Meinungen zum Ereignis.
## Verlauf: Tatsächliche Ereignisse rekonstruieren
Erwartetes Artefakt: Faktenbasierte Zeitlinie
Eine plausible Erklärung ist noch kein belegter Ablauf.
Eintrag:
...
- [ ] Erinnerungen widersprechen sich und werden sofort bewertet.
## Vergleich: Plan und Realität gegenüberstellen
Erwartetes Artefakt: Vergleich mit Abweichungen
Ein Unterschied ist ein Lernanlass, keine individuelle Schuldzuweisung.
Eintrag:
...
- [ ] Die Diskussion springt direkt von Abweichung zu Vorwurf.
## Erklären: Bedingungen und Lessons prüfen
Erwartetes Artefakt: Lessons und offene Fragen
Eine Einzelerklärung kann systemische oder situative Bedingungen übersehen.
Eintrag:
...
- [ ] Die erste Erklärung wird ungeprüft zur Ursache.
## Anpassen: Actions und spätere Prüfung festlegen
Erwartetes Artefakt: Verbesserungsplan
Eine Maßnahme ohne späteren Check zeigt keine Wirkung.
Eintrag:
...
- [ ] Die Liste wird zu lang oder hat keine Owner.
## Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/after-action-review/run-sheet