Jedes Engineering-Team hat dasselbe Post-Incident-Ritual. Der Vorfall passiert. Jemand schreibt eine kurze Zusammenfassung in Slack. Jemand anderes verspricht, das Runbook zu aktualisieren. Ein Post-Mortem wird geplant. Zwei Wochen später ist das Runbook immer noch nicht aktualisiert, das Post-Mortem-Dokument ist halb fertig, und beim nächsten Mal, wenn derselbe Vorfall passiert, muss der Bereitschaftsingenieur alles von vorne herausfinden.
Das Problem ist nicht Faulheit. Es ist, dass Dokumentation nach einem stressigen Vorfall zu schreiben das Letzte ist, was jemand tun will, und es konkurriert mit der Featurearbeit des nächsten Sprints. Die Dokumentationsschuld wächst, bis die Runbooks so veraltet sind, dass niemand ihnen vertraut.
Der Incident-Response-Workflow
Das Engineering Starter Pack enthält einen Workflow namens Incident Response. Er nimmt die rohen Vorfallsdaten — Zeitleiste, Symptome, ergriffene Maßnahmen, Ursache — und produziert drei Ausgaben in einem Durchgang.
-
Vorfallbericht — Ein strukturierter Post-Incident-Bericht mit: Vorfallzusammenfassung, Ereigniszeitleiste, Auswirkungsbewertung (betroffene Benutzer, Dauer, Schweregrad), Ursachenanalyse, beitragende Faktoren und sofort ergriffene Maßnahmen. Das Format ist über Vorfälle hinweg konsistent, was Mustererkennung über Monate von Berichten ermöglicht.
-
Runbook-Update — Die KI nimmt die Vorfalldetails und generiert Ergänzungen oder Updates zum relevanten Runbook. Wenn der Vorfall einen neuen Fehlermodus aufgedeckt hat, schreibt sie Erkennungsschritte, diagnostische Befehle und Abhilfeverfahren. Wenn es ein bekannter Fehlermodus mit einer neuen Wendung ist, aktualisiert sie den bestehenden Abschnitt. Die Ausgabe ist als runbook-fertiger Inhalt strukturiert, nicht als narrative Zusammenfassung.
-
Engineering-Lead-Review (Genehmigungsschritt) — Bevor etwas veröffentlicht wird, pausiert der Workflow zur Überprüfung. Der Engineering-Lead verifiziert die Zeitleisten-Genauigkeit, validiert die Ursachenanalyse und genehmigt die Runbook-Ergänzungen. Dieser Schritt ist kritisch — KI-generierte Runbooks brauchen einen Menschen, der dabei war, um zu bestätigen, dass die Verfahren korrekt sind.
-
Post-Mortem-Generierung — Nach der Genehmigung generiert die KI ein vollständiges Post-Mortem-Dokument: Was passiert ist, warum es passiert ist, was eine schnellere Lösung verhindert hat und Maßnahmen zur Verhinderung eines erneuten Auftretens. Jede Maßnahme hat einen vorgeschlagenen Verantwortlichen und eine Priorität.
Warum Konsistenz bei Vorfallsdokumentation wichtig ist
Wenn Vorfallberichte verschiedenen Formaten folgen, können Sie sie nicht vergleichen. Sie können nicht fragen „Wie viele P1-Vorfälle in diesem Quartal wurden durch Datenbankprobleme verursacht?”, es sei denn, jeder Bericht verwendet dieselbe Schweregradskalierung und Kategorisierung. Sie können nicht verfolgen, ob sich Abhilfezeiten verbessern, es sei denn, jeder Bericht enthält dieselben Zeitfelder.
Das Incident-Report-Recipe erzwingt ein konsistentes Schema. Jeder Bericht hat dieselben Abschnitte, dieselben Schweregradkategorien, dieselben Zeitfelder. Mit der Zeit wird dies zu einem strukturierten Datensatz, den Sie abfragen können, nicht nur ein Ordner mit Dokumenten.
Was der Ingenieur weiterhin tut
Der Workflow braucht genaue Eingaben. Der Ingenieur liefert:
- Was passiert ist — Zeitleiste der Ereignisse, beobachtete Symptome, ausgelöste Alerts
- Was er getan hat — Diagnostische Schritte, ausgeführte Befehle, angewandte Fixes
- Was die Ursache war — Ursache und beitragende Faktoren
Die KI untersucht den Vorfall nicht — sie dokumentiert ihn. Die Untersuchung, das Debugging, der Fix — das ist die Expertise des Ingenieurs. Die Aufgabe der KI ist es, diese Expertise in gut strukturierte Dokumentation umzuwandeln, die der nächste Bereitschaftsingenieur tatsächlich nutzen kann.
Runbook-Updates sind hier besonders wertvoll. Ein Ingenieur, der gerade zwei Stunden mit dem Debugging eines Produktionsproblems verbracht hat, weiß genau, welche Schritte beim nächsten Mal zu befolgen sind. Normalerweise bleibt dieses Wissen in seinem Kopf oder in einem Slack-Thread. Der Workflow erfasst es in einem Runbook-Abschnitt mit spezifischen Befehlen und Entscheidungspunkten.
Der Feature-Launch-Workflow
Das Engineering Pack enthält auch einen Feature Launch-Workflow, der die andere Dokumentationslücke schließt: Release-Kommunikation.
- Changelog-Einträge aus der Commit-Historie und PR-Beschreibungen schreiben
- Benutzergerichtete Release-Notes mit dem richtigen Detailgrad generieren
- API-Dokumentation aktualisieren, wenn sich Endpunkte geändert haben
- Alles für die Überprüfung verpacken
Und der Sprint-Cycle-Workflow automatisiert Planungs- und Retrospektiv-Dokumentation: Sprint-Ziele aus Backlog-Items generieren, Dokumentationspläne für neue Features erstellen und Retrospektiv-Notizen zu umsetzbaren Verbesserungen strukturieren.
Das vollständige Engineering Pack
Das Engineering Starter Pack enthält zwei weitere Workflows neben Incident Response:
- Feature Launch — Release-Notes, Changelog und Dokumentationsupdates in einem Durchgang
- Sprint Cycle — Planungs-, Dokumentations- und Retrospektiv-Automatisierung
Die eigenständigen Recipes — Tech-Spec-Writer, API-Dokumentationsgenerator, Code-Review-Feedback, Architecture-Decision-Records — funktionieren einzeln oder als Bausteine für benutzerdefinierte Engineering-Workflows.