Meine Session planen

# Session Brief: Runbook

## Ziel
Artefakt: Runbook

## Arbeitsfrage
Welche Schritte fuehrt eine geschulte Person in welcher Reihenfolge aus, um den Trigger sicher zu behandeln, ohne improvisieren zu muessen?

## Kontext
Existierende Tickets, Postmortems oder Aufzeichnungen, die den Ablauf bei realem Auftreten zeigen; Logs, Metriken-Dashboards, beteiligte Services; bekannte Sonderfaelle.

## Setup
- Format: Async-Arbeitslauf
- Dauer: 24 bis 72 h
- Modus: asynchron
- Teilnehmende: Ein Runbook-Owner (meist SRE oder Service Owner); ein Reviewer aus dem operativen Team; ein Testpilot, der das Runbook unter Drillbedingungen ausfuehrt.
- Owner: Ein Runbook-Owner (meist SRE oder Service Owner)
- 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 Runbook hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Repository fuer Runbooks (Markdown im Git oder Wiki); Template mit Header (Trigger, Symptome, Schweregrad, Owner), Vorbedingungen, Schritte, Verifikation, Rollback, Eskalation; Verlinkung zu Dashboards, Logs und Tools.

## Vorbereitung
Template anlegen. Naming-Konvention (Service + Trigger). Speicherort einheitlich. Verweis aus Alerts direkt auf Runbook-URL. Sichtbar in Incident-Channel.

## Agenda
1. Brief vorbereiten (15-30 min)
   Owner: Owner
   Aktion: Arbeitsfrage, Input, Zielartefakt und Reviewfrist für Runbook vorbereiten. Verlinke relevante Daten, Quellen und bestehende Artefakte. 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: Session Brief

2. Asynchron bearbeiten (24 bis 72 h)
   Owner: Teilnehmende
   Aktion: Teilnehmende arbeiten die Methode entlang der Vorlage durch. Fokus: Beiträge direkt am Artefakt ergänzen, Annahmen markieren und Belege verlinken. 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: Runbook

3. Review bündeln (20-30 min)
   Owner: Facilitator
   Aktion: Kommentare, Widersprüche und offene Fragen clustern. Unklare Punkte als Entscheidungen, Risiken oder Follow-ups einsortieren. 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: Review Notes

4. Artefakt finalisieren (15-30 min)
   Owner: Owner
   Aktion: Eingearbeitete Version erstellen, Status setzen und nächsten Review oder Entscheidungspunkt terminieren. 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: Checklist

5. 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: Runbook

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

# Runbook: Runbook

## Arbeitsfrage
Welche Schritte fuehrt eine geschulte Person in welcher Reihenfolge aus, um den Trigger sicher zu behandeln, ohne improvisieren zu muessen?

## Kontext
Existierende Tickets, Postmortems oder Aufzeichnungen, die den Ablauf bei realem Auftreten zeigen; Logs, Metriken-Dashboards, beteiligte Services; bekannte Sonderfaelle.

## Beteiligte
- Owner: Ein Runbook-Owner (meist SRE oder Service Owner)
- Teilnehmende: Ein Runbook-Owner (meist SRE oder Service Owner); ein Reviewer aus dem operativen Team; ein Testpilot, der das Runbook unter Drillbedingungen ausfuehrt.

## Input
Repository fuer Runbooks (Markdown im Git oder Wiki); Template mit Header (Trigger, Symptome, Schweregrad, Owner), Vorbedingungen, Schritte, Verifikation, Rollback, Eskalation; Verlinkung zu Dashboards, Logs und Tools.

## Vorlage
- [ ] Trigger klar beschrieben
- [ ] Voraussetzungen und Zugänge genannt
- [ ] Diagnose-Schritte in Reihenfolge
- [ ] Aktionen mit erwarteter Wirkung
- [ ] Verifikation nach jeder kritischen Aktion
- [ ] Rollback oder Stop-Kriterium
- [ ] Eskalationspfad mit Kontakt
- [ ] Letzter Testlauf dokumentiert

## Fertigstellungscheck
- Runbook 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