On-Call-Runbooks mit Claude erstellen: Aus Postmortems zu wiederverwendbaren Vorlagen

1. Warum Runbooks meistens veraltet oder unbrauchbar sind

In vielen Teams existieren Runbooks nur auf dem Papier: ein Wiki-Artikel, der vor zwei Jahren einmal geschrieben wurde, seitdem aber nie wieder aktualisiert wurde, während sich die Architektur des Systems in der Zwischenzeit mehrfach verändert hat. Wenn ein neuer Vorfall auftritt, verlässt sich die diensthabende Person deshalb oft nicht auf das Runbook, sondern auf das eigene Erfahrungswissen oder auf einen Kollegen, der zufällig erreichbar ist, was die Reaktionszeit unnötig verlängert und einzelne Personen zu unersetzlichen Single Points of Failure macht.

Claude verändert die Ökonomie dieser Pflege grundlegend: Statt ein Runbook mühsam von Hand aus dem Gedächtnis zu rekonstruieren, lassen sich aus bereits geschriebenen Postmortems in Minuten strukturierte Entwürfe extrahieren, die anschließend nur noch fachlich geprüft und verfeinert werden müssen. Das senkt die Hürde, Runbooks tatsächlich aktuell zu halten, erheblich, weil der teuerste Teil, das erste Grundgerüst, praktisch automatisiert wird.

2. Wiederkehrende Muster aus bestehenden Postmortems extrahieren

Die meisten Teams sammeln über Monate und Jahre eine beachtliche Menge an Postmortem-Dokumenten an, ohne sie systematisch nach wiederkehrenden Mustern auszuwerten. Claude eignet sich hervorragend dafür, mehrere Postmortems desselben Systems einzulesen und Gemeinsamkeiten herauszuarbeiten, etwa dass drei von fünf Datenbank-Incidents mit demselben Symptom begannen, nämlich einer steigenden Anzahl offener Verbindungen kurz vor dem eigentlichen Ausfall.

Aus dieser Musteranalyse lässt sich ein generisches Runbook für die Symptomklasse Datenbank-Verbindungspool erschöpft ableiten, das nicht nur für den einen konkreten Vorfall gilt, sondern für die gesamte Kategorie ähnlicher zukünftiger Vorfälle. Das ist deutlich wertvoller als ein Runbook pro einzelnem historischen Vorfall, weil On-Call-Personal unter Stress selten Zeit hat, aus einer langen Liste ähnlicher Dokumente das passende auszuwählen.

# Prompt-Beispiel für Claude
"Hier sind fünf Postmortems zu Datenbank-Incidents der letzten
sechs Monate (als Markdown-Dateien angehängt). Identifiziere
wiederkehrende Symptome, gemeinsame Root Causes und extrahiere
daraus ein generisches Runbook für die Symptomklasse
'Verbindungspool erschöpft'."

3. Eine einheitliche Runbook-Struktur mit Claude entwerfen

Ein Runbook ohne konsistente Struktur zwingt die diensthabende Person, sich unter Stress erst durch unbekannten Aufbau zu orientieren, bevor überhaupt mit der eigentlichen Diagnose begonnen werden kann. Claude eignet sich gut, um eine wiederverwendbare Vorlage zu entwerfen, die für jedes Runbook identisch aufgebaut ist: Symptombeschreibung, Diagnose-Checkliste für die ersten Minuten, wahrscheinlichste Ursachen mit jeweiliger Prüfmethode, konkrete Sofortmaßnahmen und ein klarer Eskalationspfad, wenn die Sofortmaßnahmen nicht greifen.

Sobald diese Struktur einmal mit dem Team abgestimmt ist, kann Claude jedes neue Runbook konsequent in genau diesem Format erzeugen, was die kognitive Last beim Lesen unter Zeitdruck erheblich senkt, weil erfahrenes On-Call-Personal weiß, an welcher Stelle im Dokument welche Information zu finden ist, ohne jedes Mal neu suchen zu müssen.

4. Eine Checkliste für die ersten fünf Minuten unter Stress entwerfen

Die ersten Minuten eines Incidents entscheiden häufig darüber, ob ein Problem schnell eingedämmt wird oder eskaliert, gleichzeitig ist die kognitive Kapazität einer gerade geweckten, gestressten Person in dieser Phase am geringsten. Claude hilft, eine bewusst minimalistische Checkliste zu entwerfen, die sich auf wenige, klar priorisierte Schritte beschränkt: aktuellen Systemstatus in einem Blick erfassen, betroffenen Nutzerkreis grob einschätzen, Schweregrad nach einer festen Skala festlegen und bei Bedarf sofort eskalieren, statt allein zu versuchen, das Problem selbst zu lösen.

Wichtig ist, dass diese erste Checkliste bewusst keine tiefgehende Diagnose enthält, sondern ausschließlich Triage-Schritte, die auch von einer weniger erfahrenen Person unter Stress zuverlässig ausgeführt werden können. Claude lässt sich gezielt bitten, jeden Schritt auf seine kognitive Komplexität zu prüfen und zu vereinfachen, etwa einen Schritt mit drei möglichen Interpretationen durch eine klare Ja-Nein-Entscheidung zu ersetzen.

## Erste 5 Minuten: Datenbank-Verbindungspool erschöpft

1. Grafana-Dashboard "DB Connections" öffnen: aktueller Wert
   über 90 Prozent des konfigurierten Limits?
   JA -> weiter zu Schritt 2
   NEIN -> anderes Runbook, Symptom passt nicht

2. Betroffene Services prüfen: nur ein Service oder mehrere?
   Ein Service -> Sofortmassnahme A (Service-Neustart)
   Mehrere Services -> sofort eskalieren, Schritt 5

3. Schweregrad festlegen (SEV1 bis SEV3) nach Team-Skala
4. Incident-Channel öffnen, Schweregrad und Symptom posten
5. Bei SEV1: Secondary On-Call sofort über PagerDuty rufen

5. Eskalationspfade klar und eindeutig festlegen

Ein häufiger Schwachpunkt in Runbooks ist eine vage formulierte Eskalation wie bei Bedarf das Team informieren, ohne konkrete Namen, Kontaktwege oder Zeitgrenzen zu nennen. Claude hilft, aus einer Beschreibung der Teamstruktur, der Bereitschaftspläne und der Schweregrad-Definitionen eine konkrete Eskalationsmatrix abzuleiten, die für jeden Schweregrad genau festlegt, wer nach welcher Zeitspanne ohne Fortschritt kontaktiert wird und über welchen Kanal.

Besonders wertvoll ist es, Claude explizit nach Lücken in der Eskalationslogik fragen zu lassen, etwa was passiert, wenn die primäre On-Call-Person nicht innerhalb von zehn Minuten reagiert, oder wie verfahren wird, wenn ein Vorfall mehrere Teams gleichzeitig betrifft und keine der beteiligten Personen offensichtlich die Gesamtverantwortung trägt. Solche Randfälle werden beim ersten Entwurf eines Runbooks häufig übersehen, fallen aber in einem echten Vorfall besonders schwer ins Gewicht.

6. Ein konkretes Runbook für ein bekanntes Fehlerbild generieren

Am konkretesten wird der Nutzen, wenn man Claude ein spezifisches, bereits bekanntes Fehlerbild beschreibt, etwa eine Zahlungsdienstleister-API, die unter Last mit HTTP 503 antwortet, und daraus ein vollständiges Runbook erzeugen lässt, das die Symptombeschreibung, die wahrscheinlichsten Ursachen samt Prüfbefehlen, eine Sofortmaßnahme wie das Aktivieren eines Fallback-Zahlungsanbieters und die zugehörige Eskalationsstufe enthält.

Solche Runbooks lassen sich anschließend direkt gegen die tatsächliche Systemlandschaft testen, indem ein erfahrenes Teammitglied die beschriebenen Prüfbefehle tatsächlich ausführt und verifiziert, ob die vorgeschlagenen Diagnosewege in der Praxis funktionieren. Diese Validierung ist unverzichtbar, weil Claude die tatsächlichen Befehle, Dashboards und Zugriffswege des Teams ohne mitgelieferten Kontext nicht kennt und plausibel klingende, aber im Detail falsche Befehle vorschlagen kann.

7. Runbooks nach jedem Incident systematisch aktualisieren

Ein Runbook, das nach seiner Erstellung nie wieder angefasst wird, veraltet mit der Zeit genauso wie jede andere Dokumentation. Ein bewährter Prozess ist, nach jedem abgeschlossenen Postmortem gezielt zu prüfen, ob das zugehörige Runbook noch mit der Realität übereinstimmt, und Claude dabei einzubinden, indem man ihm das neue Postmortem und das bestehende Runbook gemeinsam vorlegt und nach konkreten Abweichungen fragen lässt.

Besonders hilfreich ist Claude dabei, wenn ein Vorfall zeigt, dass ein im Runbook beschriebener Diagnoseschritt in der Praxis nicht mehr funktioniert hat, etwa weil sich ein Dashboard-Name geändert hat oder ein Service umbenannt wurde. Claude kann aus dem Postmortem-Text automatisch einen konkreten Änderungsvorschlag für das Runbook als Diff formulieren, den ein Teammitglied nur noch prüfen und übernehmen muss, statt das gesamte Dokument erneut durchzulesen.

8. Runbooks als Code im Git-Repository pflegen

Teams, die Runbooks als Markdown-Dateien in einem Git-Repository statt in einem separaten Wiki pflegen, profitieren davon, Claude Code direkt in diesem Repository arbeiten zu lassen. Nach einem abgeschlossenen Postmortem lässt sich Claude Code anweisen, die betroffenen Runbook-Dateien zu identifizieren und Aktualisierungsvorschläge als normalen Pull Request einzureichen, der wie jede andere Codeänderung von einem Teammitglied geprüft wird, bevor er gemergt wird.

Dieser Workflow hat den zusätzlichen Vorteil, dass die Pflege von Runbooks fest in den ohnehin etablierten Postmortem-Prozess integriert wird, statt eine separate, leicht vergessene Aufgabe zu sein. Ein Postmortem-Template kann sogar direkt einen Punkt enthalten, der explizit dazu auffordert, das entsprechende Runbook mit Claude Code zu aktualisieren, bevor der Vorfall als abgeschlossen markiert wird.

cd runbooks-repo
claude "Lies postmortems/2026-08-05-db-pool-exhaustion.md
und prüfe, ob runbooks/db-connection-pool-exhausted.md noch
korrekt ist. Schlage konkrete Änderungen als Diff vor."

git diff runbooks/db-connection-pool-exhausted.md
git add runbooks/db-connection-pool-exhausted.md
git commit -m "Runbook nach Incident 2026-08-05 aktualisieren"

9. Grenzen: Claude kennt eure internen Zugriffswege nicht

Claude kennt weder die tatsächlichen internen Tool-URLs noch die konkreten Zugriffsrechte, die für bestimmte Diagnoseschritte notwendig sind, und kann insbesondere bei destruktiven Befehlen, etwa einem Datenbank-Failover oder einem Cache-Flush, keine verlässliche Einschätzung der tatsächlichen Auswirkungen im eigenen produktiven System liefern. Jedes generierte Runbook muss deshalb von einer Person mit echtem operativem Wissen gegengeprüft werden, bevor es im Ernstfall verwendet wird.

Ein Runbook ist außerdem immer eine Unterstützung für die Entscheidung eines Menschen, kein Ersatz für diese Entscheidung selbst. Gerade bei ungewöhnlichen Vorfällen, die von keinem bekannten Muster abgedeckt sind, bleibt die Fähigkeit erfahrener On-Call-Ingenieure, situativ zu improvisieren, unverzichtbar, und ein zu starres Vertrauen in ein vermeintlich vollständiges Runbook kann in solchen Fällen sogar kontraproduktiv wirken.

10. Zusammenfassung

11. FAQ: On-Call-Runbooks mit Claude: Häufige Fragen