Ein Runbook für eine KI-Funktion schreiben, die Ihr Team betreibt

Wo ein gewöhnliches Service-Runbook nicht reicht

Ein gewöhnliches Runbook geht davon aus, dass sich Ausfälle als Fehler zeigen. KI-Funktionen können scheitern und trotzdem HTTP 200 liefern: eine selbstsichere falsche Antwort, eine Tool-Schleife, die weiter Tokens verbraucht, ein Agent, der jeden Fall an einen Menschen weiterreicht. Manche Ursachen liegen außerhalb Ihres Codes, etwa ein überlasteter Anbieter, ein Wechsel der Modellversion oder eine neue Art von Eingabe. Und wer Bereitschaft hat, kennt sich womöglich weder mit Prompts noch mit Evaluierung aus. Das Runbook muss all das in Prüfungen übersetzen, die eine Generalistin um drei Uhr morgens ausführen kann.

Zuerst das Symptom einordnen

• Langsam: Latenz über dem Ziel, sichtbar an Time to First Token, End-to-End-Latenz, Warteschlangentiefe und Antwortzeiten des Anbieters
• Nicht verfügbar: Fehler vom Anbieter oder aus dem eigenen Serving; Anthropic dokumentiert zum Beispiel einen 429 rate_limit_error und einen 529 overloaded_error
• Teuer: Tokens oder Kosten pro Anfrage oder Vorgang über Budget, oft durch Schleifen, Wiederholungen oder wachsenden Kontext
• Falsch: eine fehlschlagende Canary-Evaluierung, strukturierte Ausgaben, die die Validierung nicht bestehen, steigende Eskalationen oder Nutzermeldungen
• Außerhalb der Grenzen: Aktionen jenseits der erwarteten Limits, ein Anstieg abgelehnter Tool-Aufrufe oder Verdacht auf Prompt Injection

Beispiele für Runbook-Einträge

Jeder Eintrag nennt erste Prüfungen, eine sichere Maßnahme und die verantwortliche Stelle. Die folgenden Einträge sind hypothetisch und beziehen sich auf einen Assistenten für Kunden.

1. 1

   Langsam

   Sehen Sie in der Trace-Aufschlüsselung nach, ob die Zeit beim Anbieter, beim Retrieval oder bei Tools verloren geht. Ist der Anbieter langsam, wechseln Sie auf die getestete Ausweichroute oder drosseln nicht dringende Anfragen. Verantwortlich, falls ungelöst: Plattformteam.

2. 2

   Nicht verfügbar

   Prüfen Sie den Status des Anbieters und die Fehlertypen. Wiederholungen brauchen Backoff mit Jitter und ein Budget; das SRE-Buch von Google zeigt, wie Wiederholungen auf mehreren Ebenen die Last auf einem überlasteten Backend vervielfachen. Halten die Fehler an, schalten Sie die Ausweichroute oder den Weg ohne KI ein. Verantwortlich: Plattformteam.

3. 3

   Teuer

   Listen Sie die Vorgänge mit den meisten Tokens der letzten Stunde auf; Schleifen zeigen sich als viele Aufrufe pro Vorgang. Setzen Sie Limits pro Vorgang für Tool-Aufrufe oder Tokens, oder schalten Sie den betroffenen Ablauf ab. Verantwortlich: Feature-Team.

4. 4

   Falsch

   Führen Sie das Canary-Evaluierungsset gegen die Produktionskonfiguration aus, mit synthetischen Testdaten und durch Attrappen ersetzten oder isolierten schreibenden Tools, damit der Test keine echten Geschäftsaktionen auslöst. Schlägt es nach einer kürzlichen Änderung an Prompt oder Modellversion fehl, rollen Sie diese Änderung zurück. Stellen Sie einen älteren Retrieval-Index nicht einfach wieder her: Er kann zurückgezogene Dokumente oder veraltete Berechtigungen enthalten. Wenden Sie zuerst aktuelle Löschungen und Zugriffsregeln an, oder behalten Sie den aktuellen Index und eskalieren. Hat sich nichts geändert, sammeln Sie Beispiele für die Verantwortlichen und ändern in der Bereitschaft keine Prompts. Verantwortlich: Feature-Team mit der fachlich verantwortlichen Person.

5. 5

   Außerhalb der Grenzen

   Schalten Sie schreibende Tools oder die Funktion ab, sichern Sie die Traces, entziehen Sie bei Verdacht auf Missbrauch Zugangsdaten und folgen Sie dem Prozess für Sicherheitsvorfälle. Verantwortlich: Security.

Schalter, die vor dem ersten Vorfall bereitstehen sollten

Die meisten der genannten Maßnahmen funktionieren nur, wenn jemand sie vorab gebaut und getestet hat:

• Ein Feature Flag, das den KI-Pfad abschaltet und auf den bisherigen Ablauf oder eine klare Meldung zurückfällt
• Ein eigener Schalter für jedes schreibende Tool und ein reiner Lesemodus für Agenten
• Eine festgelegte Modellversion und eine Ausweichroute, die das Evaluierungsset bestanden hat
• Kosten- und Ratenobergrenzen je Mandant, Nutzer oder Vorgang

Üben Sie jeden Schalter in einer geplanten Übung. Das SRE-Buch von Google sagt es über Notbetriebsmodi deutlich: Ein Codepfad, den Sie nie nutzen, funktioniert oft nicht.

Verantwortung und Eskalation

Das SRE-Buch von Google empfiehlt, einen Vorfall früh auszurufen und klare Bedingungen dafür festzulegen, etwa wenn ein zweites Team nötig ist, Kunden den Ausfall sehen oder ein Problem nach einer Stunde konzentrierter Analyse ungelöst bleibt. Es trennt außerdem Rollen: eine Incident-Leitung, eine operative Leitung, deren Team unter ihrer Führung als einzige Gruppe das System verändert, und jemand für die Kommunikation. KI-Funktionen bringen eine weitere Rolle mit. Ob Antworten falsch sind, kann womöglich nur eine fachlich verantwortliche Person beurteilen, etwa die Leitung der Schadenbearbeitung bei einem Assistenten für Schadenfälle. Nennen Sie diese Person im Runbook samt Erreichbarkeit.

Das Runbook aktuell halten

Jedes Postmortem sollte einen Eintrag ergänzen oder korrigieren. Auch Änderungen beim Anbieter gehören ins Runbook: eine neue Modellversion, ein geändertes Rate Limit, ein Abkündigungsdatum. Prüfen Sie, welche Trace-Daten die Bereitschaft tatsächlich sehen kann, denn benötigte Inhalte werden womöglich bewusst zurückgehalten. Ein praktischer nächster Schritt: Schreiben Sie die fünf Klassen für eine Funktion mit den Signalen auf, die Sie bereits erfassen, und markieren Sie jede Stelle, an der ein Signal oder ein Schalter fehlt.

KI-Engineering und -Architektur