Ein Bereitschaftsalarm schlägt um 2:30 Uhr an. Der Service antwortet nicht, das Dashboard zeigt rote Metriken, der Kollege auf Rotation kennt diese Systemkomponente kaum. In diesem Moment ist ein gut gepflegtes Runbook kein nice-to-have – es ist der Unterschied zwischen einer schnellen Lösung und einer Stunde verzweifelter Suche.
Runbooks – strukturierte Anleitungen für den Umgang mit bekannten Problemen – sind im SRE-Betrieb seit Jahren ein Standardwerkzeug. Doch wie verändert der Einzug von KI-Assistenten und Sprachmodellen die Nutzung, Pflege und Wirksamkeit dieser Dokumente? Dieser Beitrag zeigt, wo der Mehrwert liegt – und wo nicht.
Was ein gutes Runbook leisten muss
Bevor KI ins Spiel kommt, lohnt es sich zu definieren, was ein effektives Runbook ausmacht. Ein Runbook beschreibt für einen konkreten Alarmtyp oder eine bekannte Fehlersituation:
- Welche Symptome zu erwarten sind
- Welche ersten Diagnoseschritte durchzuführen sind
- Welche Systeme und Abhängigkeiten betroffen sein könnten
- Konkrete Befehle, Links und Diagnosepfade
- Wann eskaliert werden sollte und an wen
Das klingt einfach, ist aber schwer zu pflegen. Runbooks veralten schnell: Systeme ändern sich, neue Abhängigkeiten entstehen, Teams wechseln. Ein Runbook, das vor sechs Monaten geschrieben wurde, kann heute irreführend sein. Genau hier beginnt die Verbindung zu KI-Werkzeugen interessant zu werden.
KI als Navigationsassistent im Runbook
Sprachmodelle lassen sich mit bestehenden Runbooks verknüpfen – als durchsuchbare, konversationelle Schnittstelle. Statt im Notfall durch mehrere Wikiseiten zu navigieren, kann ein On-Call-Ingenieur in natürlicher Sprache fragen: „Welche Schritte sind bei einem Redis-Verbindungsabbruch in der Produktionsumgebung zu folgen?" – und erhält eine gebündelte Antwort aus dem hinterlegten Wissensstand.
Werkzeuge mit RAG-Anbindung (Retrieval-Augmented Generation) oder dedizierte On-Call-Assistenten ermöglichen genau das. Sie durchsuchen nicht nur Runbooks, sondern können auch Monitoring-Daten, Logs und Incident-Historien in die Antwort einbeziehen.
Der Vorteil liegt in der Geschwindigkeit und Zugänglichkeit: Ein Teammitglied ohne tiefes Vorwissen über eine Systemkomponente kann in Minuten die richtigen Diagnoseschritte nachvollziehen – ohne selbst Experte zu sein.
KI als Runbook-Co-Autor
Neben der Nutzung bestehender Runbooks können Sprachmodelle auch bei Erstellung und Pflege helfen. Wenn ein Incident abgeschlossen ist, kann ein KI-gestütztes System die während des Vorfalls ausgeführten Befehle, die genutzten Nachrichten und abgeschlossene Incident-Tickets analysieren und einen Runbook-Entwurf für ähnliche künftige Situationen erstellen.
Das spart die mühsamste Phase der Runbook-Erstellung: das strukturierte Zusammenfassen unmittelbar nach einem Incident, wenn das Team erschöpft ist. Ein erster Entwurf, den ein Mensch überprüft und anpasst, ist besser als ein leerer Dokumenteneintrag.
Grenzen und Risiken
KI-Assistenten in kritischen On-Call-Szenarien haben klare Grenzen, die nicht unterschätzt werden sollten:
- Halluzinationen: Sprachmodelle können Informationen erfinden, die plausibel klingen, aber falsch sind. Befehle, die ein KI-Assistent vorschlägt, müssen immer manuell geprüft werden – besonders in Produktionsumgebungen.
- Veraltetes Wissen: Wenn das Runbook veraltet ist, liefert die KI veraltete Antworten – nur schneller und selbstsicherer. KI ersetzt keine Runbook-Pflege.
- Kontext-Blindheit: Ein Sprachmodell kennt nicht den spezifischen Zustand einer Infrastruktur zum Zeitpunkt des Incidents. Ohne direkte Integration von Live-Monitoring-Daten sind Empfehlungen kontextfrei.
Wirklich wertvolle KI-Integration im On-Call-Betrieb setzt deshalb auf enge Verbindung mit tatsächlichen Systemdaten: Monitoring-Metriken, aktuelle Logs, Deployment-History. Nur dann kann ein Assistent kontextbezogene Hinweise geben statt generischer Checklisten.
ChatOps: KI direkt im Incident-Kanal
Ein konkretes Einsatzszenario, das zunehmend Verbreitung findet, ist die KI-Integration in ChatOps-Plattformen. Wenn ein Incident geöffnet wird, wird automatisch ein Kommunikationskanal erstellt, in dem ein Bot nicht nur Runbook-Links bereitstellt, sondern auch:
- Relevante Monitoring-Grafiken einbettet
- Ähnliche vergangene Incidents aus der Datenbank zieht
- Den Status laufender Abhilfemaßnahmen trackt
- Am Ende einen Postmortem-Entwurf generiert
Teams berichten von merklich kürzeren Mean Time to Resolution (MTTR) bei gut eingerichteten ChatOps-Integrationen – wobei die Qualität des darunterliegenden Wissensmanagements entscheidend bleibt.
Was Teams jetzt konkret tun können
Wer Runbooks im KI-Zeitalter verbessern will, muss nicht sofort auf proprietäre KI-Plattformen setzen. Einige pragmatische Schritte wirken auch ohne großes Budget:
- Runbooks strukturieren: Eine einheitliche Vorlage für alle Runbooks – Symptombeschreibung, Diagnoseschritte, Eskalation – erleichtert sowohl menschliche als auch maschinelle Verarbeitung.
- Runbooks versionieren: Git-basierte Runbooks machen Änderungen nachvollziehbar und ermöglichen spätere Analyse, welche Versionen bei welchen Incidents genutzt wurden.
- Nach jedem Incident aktualisieren: Jeder abgeschlossene Incident ist eine Gelegenheit, das zugehörige Runbook zu erweitern. Dieser Schritt sollte explizit im Postmortem-Prozess verankert sein.
- KI als Entwurfshelfer nutzen: Sprachmodelle eignen sich gut für das Erstformulieren eines Runbook-Entwurfs. Ein Experte überprüft und verfeinert – aber der erste Rohling entsteht schneller.
Fazit
Runbooks werden durch KI nicht überflüssig – sie werden wichtiger. Denn ein Sprachmodell, das auf schlechtem oder veraltetem Wissen basiert, liefert schnelle, aber falsche Antworten. Die Qualität des Wissensmanagements entscheidet über den Nutzen jedes KI-Assistenten. Teams, die ihre Runbooks heute sauber pflegen, haben morgen die bessere Grundlage für jede KI-Erweiterung.
Das On-Call-Erlebnis lässt sich dadurch spürbar verbessern: nicht durch mehr Automatisierung, sondern durch besser zugängliches Wissen – zum richtigen Zeitpunkt, im richtigen Kanal, mit dem richtigen Kontext.
Quellen: PagerDuty Incident Management Guides (pagerduty.com), Google SRE Workbook (sre.google), Atlassian Incident Management Blog (atlassian.com).
