Was vorher fertig sein muss
Eine wiederkehrende operative Taetigkeit oder ein definierter Incident-Typ ist identifiziert (Mindestens 2-3 Vorkommen in 90 Tagen oder klar absehbares Risiko).
Rollen und Eskalationspfade im Incident sind bekannt, sodass das Runbook konkrete Verantwortlichkeiten referenzieren kann.
Was vor Start vorliegen muss
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.
Ein Runbook-Owner (meist SRE oder Service Owner); ein Reviewer aus dem operativen Team; ein Testpilot, der das Runbook unter Drillbedingungen ausfuehrt.
Existierende Tickets, Postmortems oder Aufzeichnungen, die den Ablauf bei realem Auftreten zeigen; Logs, Metriken-Dashboards, beteiligte Services; bekannte Sonderfaelle.
Erstellung 2-6 h pro Runbook, Test 1-2 h, Review jaehrlich oder nach Aenderung
Template anlegen. Naming-Konvention (Service + Trigger). Speicherort einheitlich. Verweis aus Alerts direkt auf Runbook-URL. Sichtbar in Incident-Channel.
Die eine Frage, die diese Methode beantwortet
Welche Schritte fuehrt eine geschulte Person in welcher Reihenfolge aus, um den Trigger sicher zu behandeln, ohne improvisieren zu muessen?
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Header und Trigger | 20 min | Header befuellen: Titel, Service, Owner, Reviewer, letzte Aktualisierung, Severity. Trigger und Symptome konkret beschreiben (Alert-Name, Metrik-Schwelle, Logeintraege). | Wenn Symptome wage sind, wird das Runbook beim falschen Alarm gezogen. Konkretes Beispiel-Logeintrag oder Screenshot hilft enorm. |
2Sektion 2: Vorbedingungen und Zugriffe | 20 min | Tools, Berechtigungen, VPN, Konfigurationen, die fuer Ausfuehrung benoetigt werden. Pre-Checks auflisten: Was muss vorhanden sein, bevor Schritt 1 startet. | Nichts ist frustrierender als Schritt 4 zu erreichen und keinen Tool-Zugang zu haben. Pre-Checks erzwingen, dass Berechtigungen vorher gepflegt sind. |
3Sektion 3: Schritte | 60-120 min | Pro Schritt: Nummer, Aktion (Kommando oder UI-Anweisung), erwartete Antwort, naechster Schritt. Decision Points als If/Then. Idempotenz pro Schritt pruefen. | Schritte muessen so konkret sein, dass jemand ohne Vorerfahrung sie ausfuehren kann. Keine impliziten Annahmen. Lieber zu detailliert als zu knapp. |
4Sektion 4: Verifikation und Rollback | 20 min | Verifikationsschritte: woran erkennt der Operator, dass die Aktion erfolgreich war. Rollback-Schritte fuer den Fall, dass Wirkung ausbleibt oder Nebeneffekt eintritt. | Verifikation ist nicht „schau ob es laeuft“. Konkretes Kommando oder Metrik mit Schwellwert. Rollback ist Pflichtsektion, kein Optional. |
5Sektion 5: Eskalation und Postcheck | 15 min | Wann eskalieren, an wen, mit welchem Kontext. Postcheck: was im Anschluss zu erledigen ist (Ticket schliessen, Postmortem starten, Owner informieren). | Eskalations-Trigger explizit: nach 30 min ohne Wirkung, bei Severity-Erhoehung, bei Sicherheitsindikatoren. Sonst zoegert der Operator im Ernstfall zu lange. |
6Sektion 6: Drill und Review | 1-2 h pro Drill | Testpilot fuehrt das Runbook auf Staging oder im Game Day aus. Feedback einarbeiten. Review-Cadence (z. B. halbjaehrlich oder nach Aenderung) festlegen. | Ein Runbook, das nie geuebt wurde, wird im Incident nicht funktionieren. Mindestens ein Drill nach Erstellung und nach groesserer Aenderung. |
Was am Ende rauskommt
Markdown- oder Wiki-Eintrag mit den genannten Sektionen, eindeutiger Naming-Konvention, Verweisen auf Logs, Dashboards und Tools, sowie Aenderungslog am Ende.
Git-versioniert mit Pull-Request-Review. Letztes Aktualisierungsdatum sichtbar. Aenderungen mit Datum und Aenderungsgrund im Footer. Annual Review als Pflichttermin im Kalender.
Checkliste für operative Runbooks mit Trigger, Diagnose, Aktion, Rollback und Eskalation.
- [ ] 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 dokumentiertKonkret gefülltes Szenario
## Runbook: order-api 5xx Error Spike
**Service**: order-api. **Owner**: SRE-Team. **Severity**: Sev-2. **Letzte Aktualisierung**: 12.05.2026.
**Trigger**: Alert `order-api-5xx-rate > 1.5% over 5 min`.
**Symptome**: Datadog-Dashboard `order-api`, Tile „5xx Rate“ rot. Logs enthalten `TimeoutException` haeufiger als 10/min.
**Pre-Checks**
- VPN aktiv.
- kubectl-Zugriff auf prod-cluster.
- PagerDuty-Incident aktiv (sonst manuell anlegen).
**Schritte**
1. `kubectl -n order get pods` -> alle Pods Ready? Wenn nein, Schritt 3.
2. Datadog-Dashboard `order-api-db` pruefen: Connection-Pool ausgelastet? Wenn ja, Schritt 4. Sonst Schritt 5.
3. `kubectl -n order rollout restart deployment order-api`. Warten 2 min. Verifikation Schritt 6.
4. `kubectl -n order scale deployment order-api --replicas=8` (Standard ist 4). Warten 3 min. Verifikation Schritt 6.
5. Logs filtern `kubectl -n order logs -l app=order-api --tail=200 | grep ERROR`. Pattern identifizieren. Wenn unbekannt, eskalieren.
6. Datadog: 5xx-Rate muss in 5 min unter 0.5% fallen. Wenn nicht, eskalieren.
**Rollback**: Bei Schritt 4 nach Stabilisierung Replicas wieder auf 4 setzen.
**Eskalation**: Nach 30 min ohne Wirkung an Service Owner @ben (+49-...) und SRE-Lead @lisa. Severity auf Sev-1 erhoehen.
**Postcheck**: PagerDuty-Incident schliessen, Postmortem in Confluence anlegen, Ticket fuer Root-Cause-Analyse in JIRA.
**Aenderungslog**: 12.05.2026 - Schritt 4 hinzugefuegt nach Incident INC-2026-031. Owner: @lisa.Symptome erkennen, gegensteuern
Im Incident stellt sich heraus, dass ein Kommando falsche Syntax hat oder ein Tool nicht installiert ist.
Drill nach Erstellung Pflicht. Mindestens jaehrlich Game Day mit Runbook. Fehler vom Drill ins Runbook zurueckspielen.
Tool-Befehle stimmen nicht mehr, Service heisst anders, Schwellen sind veraltet.
Annual Review als Termin. Bei jeder groesseren Aenderung am Service Runbook reviewen. Letztes Update sichtbar im Header, alte Runbooks (>1 Jahr) markieren.
Schritt 3 erwartet Vorwissen, Operator stockt.
Bei Erstellung „Junior-Test“: kann jemand ohne Vorerfahrung den Schritt ausfuehren? Wenn nein, Schritt zerlegen. Glossar verlinken.
Schritt verschlechtert die Situation, niemand weiss, wie zurueckgedreht wird.
Rollback ist Pflicht-Sektion. Pro destruktivem Schritt mindestens eine Rueckdrehoption. Wenn keine moeglich, explizit markieren („Achtung: nicht rueckholbar“).
Operator wuestet 2 h herum, bevor er Hilfe holt.
Konkreter Trigger: nach X Minuten ohne Erfolg eskalieren, an Y, mit Z Kontext. Eskalation ist nicht Versagen, sondern Teil des Protokolls.
Operator weiss nicht, dass es ein Runbook gibt, oder findet es nicht.
Alert-Konfiguration enthaelt Runbook-URL. Naming-Konvention erlaubt Suche per Service. Incident-Bot postet Link beim Page.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.