Meine Session planen

# Session Brief: Incident Command

## Ziel
Artefakt: Incident Log

## Arbeitsfrage
Wer hält gerade welche Rolle, welcher Effekt soll als nächstes überprüft werden, und wann erfolgt das nächste Stakeholder-Update?

## Kontext
Severity-Definition (SEV1-SEV3) mit klaren Kriterien; Eskalationspfade; Status-Page-Templates pro Severity; Liste der Stakeholder pro Severity; bekannte Service-Dependencies.

## Setup
- Format: Methoden-Session
- Dauer: Erste IC-Übernahme binnen 5 min, Incident-Dauer offen, Hand-off alle 2 h
- Modus: Workshop oder async
- Teilnehmende: Incident Commander (IC) koordiniert; Operations Lead (OL) führt technische Schritte; Communications Lead (CL) hält Stakeholder informiert; Scribe protokolliert Aktionen mit Zeitstempel; Subject Matter Experts (SMEs) auf Abruf.
- Owner: Incident Commander (IC) koordiniert
- 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 Incident Log hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Incident-Channel-Template (Slack, MS Teams) mit vorgefertigten Befehlen; Status-Page-Zugang; Pager-Tool (PagerDuty, Opsgenie, Grafana OnCall); Conference-Bridge oder Video-Call-Link; Logging-Dashboard pro Service; Eskalations-Liste.

## Vorbereitung
Pager-Alert öffnet automatisch einen Incident-Channel mit Topic, Severity, IC-Slot. Bot postet Rollenliste und nächste Schritte. Conference-Bridge im Topic. Status-Page wird bei SEV1/SEV2 automatisch in Investigating gesetzt.

## Agenda
1. Phase 1: Aktivierung (0-5 min)
   Owner: Facilitator
   Aktion: Erster Responder übernimmt IC-Rolle und postet im Channel: ich bin IC, Severity X, Hypothese Y. Channel-Topic mit IC-Name aktualisieren. Pager-Alarm bestätigen. Hinweis: Wenn niemand IC übernimmt, eskaliert der Pager nach 5 min. IC-Übernahme ist explizit, nicht implizit. Kein „kümmert sich schon jemand?“. 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: Incident Log

2. Phase 2: Rollen besetzen (5-15 min)
   Owner: Facilitator
   Aktion: IC ruft Operations Lead und Communications Lead. Scribe wird benannt. SMEs werden gezielt gepagert, nicht das ganze Team. Conference-Bridge wird gestartet, Channel bleibt das Hauptmedium. Hinweis: IC bleibt Koordinator, nicht Operator. Wenn IC selbst tippt, fehlt jemand für den Überblick. Bei SEV1 sofort separaten OL benennen. 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 Tracker

3. Phase 3: Investigation und Mitigation (variabel)
   Owner: Facilitator
   Aktion: OL führt Hypothesen-Tests, Scribe protokolliert mit Zeitstempel. IC koordiniert: was wurde getestet, was ist die nächste Aktion, wer macht. CL postet alle 30 min Status-Updates an Stakeholder. Hinweis: Mitigation schlägt Ursachenfindung. Wenn ein Rollback verfügbar ist, OL rollt zurück, Ursachenanalyse folgt im Postmortem. Keine parallelen Aktionen ohne IC-Bestätigung. 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: Stakeholder Updates

4. Phase 4: Resolution und Hand-off (15 min)
   Owner: Facilitator
   Aktion: IC bestätigt Recovery anhand SLO-Metriken, nicht anhand Bauchgefühl. Channel-Topic auf Resolved. Status-Page geschlossen. Bei langem Incident vorher Hand-off mit Übergabe an neuen IC alle 2 h. Hinweis: Recovery braucht zwei aufeinanderfolgende grüne Mess-Intervalle. Wenn nur ein Tick grün ist, bleibt der Incident offen. Hand-off mit explizitem Übergabe-Statement (Status, offene Punkte, nächste Schritte). 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: Incident Log

5. Phase 5: Übergabe an Postmortem (15 min nach Resolution)
   Owner: Owner
   Aktion: IC erstellt Postmortem-Ticket mit Incident-ID, verlinkt Channel-Log und Timeline. Postmortem-Termin binnen 5 Werktagen. Action Items aus dem Incident vorab im Ticket gesammelt. Hinweis: Wer den Channel verlässt, bevor das Postmortem-Ticket existiert, riskiert dass die Lessons verloren gehen. Scribe ist verantwortlich für vollständigen Log-Export. 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 Tracker

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: Incident Log

## Abschluss
- Ergebnisartefakt aktualisieren: Incident Log
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Incident Log: Incident Command

## Arbeitsfrage
Wer hält gerade welche Rolle, welcher Effekt soll als nächstes überprüft werden, und wann erfolgt das nächste Stakeholder-Update?

## Kontext
Severity-Definition (SEV1-SEV3) mit klaren Kriterien; Eskalationspfade; Status-Page-Templates pro Severity; Liste der Stakeholder pro Severity; bekannte Service-Dependencies.

## Beteiligte
- Owner: Incident Commander (IC) koordiniert
- Teilnehmende: Incident Commander (IC) koordiniert; Operations Lead (OL) führt technische Schritte; Communications Lead (CL) hält Stakeholder informiert; Scribe protokolliert Aktionen mit Zeitstempel; Subject Matter Experts (SMEs) auf Abruf.

## Input
Incident-Channel-Template (Slack, MS Teams) mit vorgefertigten Befehlen; Status-Page-Zugang; Pager-Tool (PagerDuty, Opsgenie, Grafana OnCall); Conference-Bridge oder Video-Call-Link; Logging-Dashboard pro Service; Eskalations-Liste.

## Vorlage
# Incident Command Arbeitsvorlage

## Ziel

Rollenbasierter Ansatz für die Koordination größerer Incidents.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Incident Log:
- Action Tracker:
- Stakeholder Updates:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Incident Log 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 terminieren