Vorfälle: eindämmen, Radius bestimmen, kompensieren

Was einen Agentenvorfall unterscheidet

Bei einem klassischen Softwarevorfall ist die erste Frage, was kaputt ist. Bei einem Agentenvorfall ist die erste Frage eine andere: Was hat er getan? Ein Agent, der falsch läuft, ist kein Dienst mit Ausfall, sondern ein Akteur mit Wirkung.

Klassischer Ausfall

Ein Dienst antwortet nicht. Der Schaden ist die entgangene Nutzung, und der Zustand ist unverändert.

Agentenvorfall

Ein Dienst hat gehandelt. Der Schaden liegt in veränderten Zuständen — verteilt über mehrere Systeme, oft außerhalb der eigenen Kontrolle.

Dazu kommt die Geschwindigkeit. Ein Agent, der 200 Vorgänge pro Stunde bearbeitet, erzeugt in zwanzig Minuten Fehlverhalten rund siebzig falsche Wirkungen — bevor überhaupt jemand einen Alarm gelesen hat. Deshalb ist Eindämmung hier keine Phase nach der Analyse, sondern die erste Handlung.

Der Rahmen — und was daran aktuell ist

Für die Vorfallbehandlung gibt es einen etablierten Rahmen, und an ihm lässt sich eine verbreitete Ungenauigkeit korrigieren. Die viel zitierte Abfolge aus Vorbereitung, Erkennung und Analyse, Eindämmung und Behebung sowie Nachbereitung stammt aus einer zurückgezogenen Fassung.

Die aktuelle Fassung ist an sechs Funktionen ausgerichtet: Govern, Identify, Protect, Detect, Respond und Recover. Der Vorfall selbst ist dabei Detect, Respond und Recover — die vorbereitenden Funktionen Govern, Identify und Protect sind ausdrücklich nicht Teil der Vorfallbehandlung, sondern übergreifende Risikomanagement-Tätigkeiten.

Diese Trennung ist mehr als Begriffspflege. Sie sagt, dass die Dinge, die einen Vorfall beherrschbar machen — Kopien-Inventar, Korrelationskennung, abgestufte Schalter, Kompensationsliste — nicht im Vorfall entstehen. Wer sie dann anlegt, ist zu spät. Der Vorfall verbraucht nur, was vorher gebaut wurde.

Eindämmung ist abgestuft

Der Reflex „alles abschalten“ ist selten die beste erste Handlung, weil er teuer ist und deshalb zögerlich ausgelöst wird. Nützlicher ist eine Leiter, deren unterste Sprossen billig genug sind, um sie beim Verdacht zu betreten.

Neue Läufe nicht mehr annehmen

Laufende Läufe beenden normal, nichts Neues beginnt. Billigste Stufe, sofort umkehrbar, stoppt den Zufluss.

Schreibende Werkzeuge sperren

Läufe arbeiten weiter und wirken nicht mehr. Erhält Diagnosefähigkeit, entfernt das Risiko.

Ein einzelnes Werkzeug sperren

Wenn der Verdacht auf eine Aktionsart zeigt. Trifft nur den betroffenen Pfad.

Alles anhalten

Läufe pausieren nach dem aktuellen Schritt. Teuer, aber ohne Teilwirkung.

Harter Abbruch

Nur, wenn ein Lauf hängt oder aktiv schadet. Hinterlässt Teilwirkung und damit Nacharbeit.

Die zweite Stufe ist die im Betrieb wertvollste und wird selten gebaut. Ein Agent, der lesen aber nicht mehr schreiben darf, ist eine laufende Diagnosequelle ohne Risiko: Man sieht weiter, was er vorhat, und nichts davon wird wahr.

Damit diese Leiter im Ernstfall benutzbar ist, muss jede Sprosse ein Schalter in der Ausführungsschicht sein und keine Codeänderung. Üblich ist ein Satz von Feldern, die zur Laufzeit gelesen werden: accept_new_runs, allow_write_tools, blocked_tools, pause_all. Wer stattdessen ein Deployment braucht, um schreibende Werkzeuge zu sperren, hat im Vorfall eine Wartezeit von Minuten an der Stelle, an der Minuten zählen.

Beweise sichern, bevor sie ablaufen

Eine Handlung gehört fast an den Anfang und steht in keinem Standard-Ablaufplan: die Aufbewahrungsfrist der betroffenen Läufe verlängern.

Der Grund liegt in einer Entscheidung, die aus guten Gründen getroffen wurde. Vollständige Trajektorien sind eine sensible Zweitkopie und werden deshalb kurz aufbewahrt — dreißig Tage sind üblich. Ein Vorfall, der nach vier Wochen entdeckt wird, trifft auf eine Beweislage, die in Tagen verschwindet, und eine Untersuchung dauert selten nur Tage.

• Betroffene Läufe markieren und von der regulären Löschung ausnehmen — mit dokumentiertem Grund und eigener Frist.
• Den Umfang großzügig wählen: lieber ein zu weites Zeitfenster markieren als nachträglich feststellen, dass der Anfang fehlt.
• Zielsystem-Protokolle mitdenken — auch dort gelten Fristen, und dort hat man selten Einfluss darauf.
• Die Markierung selbst protokollieren, damit die Ausnahme von der Löschregel nachvollziehbar bleibt.

Der letzte Punkt ist die Stelle, an der Vorfallbehandlung und Datenschutz aufeinandertreffen. Eine Aufbewahrung über die Regelfrist hinaus braucht einen Grund und ein Ende — sonst wird aus der Beweissicherung ein dauerhafter Zweitbestand, den niemand mehr aufräumt.

Der Wirkungsradius kommt aus dem Protokoll

Die zentrale Frage nach der Eindämmung lautet: Was hat der Agent angefasst? Die verbreitete Antwort — alle Änderungen im betroffenen Zeitfenster — ist in beide Richtungen falsch.

Zu weit

Ein Zeitfenster enthält alle Änderungen aus dieser Zeit, auch die von Menschen und anderen Diensten. Man kompensiert dann fremde Arbeit mit.

Zu eng

Wirkungen mit Verzögerung — ein ausgelöster Stapelauftrag, eine zeitversetzte Zustellung — liegen außerhalb des Fensters und fehlen.

Richtig

Die Menge der Aktionen dieser Läufe, ermittelt über die Korrelationskennung in den Protokollen der Zielsysteme.

Damit hat die Korrelationskennung ihren eigentlichen Zahltag. Ohne sie ist die Bestimmung des Radius eine Rekonstruktion über Zeitfenster und Heuristiken; mit ihr ist sie eine Abfrage. Der Unterschied entscheidet, ob eine Kompensation gezielt oder pauschal erfolgt.

Wirkungsradius — Die vollständige Menge der Zustandsänderungen, die auf die betroffenen Läufe zurückgehen — einschließlich der mittelbaren, die eine dieser Aktionen ausgelöst hat. Nicht: alle Änderungen im betroffenen Zeitraum.

Die mittelbaren Wirkungen sind der schwierige Teil. Eine Statusänderung, die eine Benachrichtigung auslöst, die einen Prozess startet — die Kette verlässt den eigenen Protokollbereich nach ein bis zwei Sprüngen. Deshalb gehört zur Radiusbestimmung nicht nur eine Abfrage, sondern eine Liste der Auslöseketten, die an den eigenen Aktionen hängen.

Praktisch ist die Abfrage banal, wenn die Vorarbeit stimmt: In den Protokollen der Zielsysteme steht je Eintrag eine correlation_id, und die Menge der betroffenen Läufe liefert die Menge der zu prüfenden Kennungen. Aus einer Rekonstruktion wird damit ein WHERE correlation_id IN (…). Fehlt die Kennung, bleibt nur der Zeitstempel — und der ist, wie oben gezeigt, in beide Richtungen ungenau.

Kompensation statt Rollback

Über mehrere Fremdsysteme hinweg gibt es kein gemeinsames Zurückrollen. Was in System A geschrieben wurde, bleibt dort, auch wenn System C nie erreicht wurde. Die Frage lautet deshalb nicht, wie man zurückrollt, sondern welche Gegenaktion den fachlichen Effekt aufhebt.

Vollständig kompensierbar

Statusänderung zurücksetzen, Kennzeichnung entfernen, Datensatz auf den Vorwert setzen. Voraussetzung: Der Vorwert ist bekannt.

Teilweise kompensierbar

Eine Bestellung stornieren — der Vorgang endet, die Spuren bleiben: Belege, Benachrichtigungen, ausgelöste Folgeprozesse.

Nicht kompensierbar

Eine versendete E-Mail, eine ausgelöste Zahlung an Dritte, eine an eine Behörde übermittelte Meldung. Hier bleibt nur Information und Korrektur.

Die dritte Zeile ist die, die vorher benannt werden muss. Eine Liste der nicht kompensierbaren Aktionsarten ist kein pessimistisches Dokument, sondern eine Entwurfsvorgabe: Genau diese Aktionen sind die, für die sich eine Freigabepflicht, eine Verzögerung oder ein zweistufiger Vertrag lohnt.

Reihenfolge unter Druck

Nicht reproduzierbar heißt nicht selten

Nach einem Agentenvorfall folgt regelmäßig derselbe Satz: „Wir haben es zwanzigmal versucht und konnten es nicht nachstellen.“ Daraus wird dann geschlossen, der Fall sei ein Ausreißer. Dieser Schluss ist ein Rechenfehler.

Ein Pfad, der mit einer Wahrscheinlichkeit von einem halben Prozent auftritt, bleibt in zwanzig Versuchen mit rund neunzig Prozent Wahrscheinlichkeit unsichtbar. Bei 50.000 Läufen am Tag tritt derselbe Pfad 250-mal auf. Nicht reproduzierbar in zwanzig Versuchen und häufig in Produktion sind kein Widerspruch, sondern derselbe Befund.

Die praktische Konsequenz: Statt weiter zu wiederholen, sucht man in den Produktionsprotokollen nach dem Muster. Die Frage „wie oft ist dieser Pfad in den letzten dreißig Tagen aufgetreten“ ist beantwortbar und liefert eine Zahl, während die Reproduktion nur ein Gefühl liefert.

Die Rechnung dahinter lohnt sich zu kennen, weil sie in Vorfallbesprechungen sofort trägt. Bei einer Auftretenswahrscheinlichkeit p bleibt ein Pfad in n Versuchen mit der Wahrscheinlichkeit (1−p) hoch n unentdeckt. Bei p von einem halben Prozent und zwanzig Versuchen sind das rund 90 Prozent. Um denselben Pfad mit 95 Prozent Sicherheit mindestens einmal zu sehen, bräuchte man knapp 600 Versuche — und die kosten mehr als eine Abfrage über die Produktionsprotokolle.

Kommunikation als Teil der Behandlung

Bei einem Agenten, der nach außen gewirkt hat, ist Kommunikation keine Nachbereitung, sondern eine Aufgabe mit Frist. Und sie hängt an derselben Grundlage wie die Kompensation: an der genauen Liste der Betroffenen.

• Wer ist tatsächlich betroffen — aus dem Wirkungsradius, nicht aus einer Schätzung nach Zeitfenster.
• Was ist passiert — in Wirkungen beschrieben, nicht in Systembegriffen.
• Was wurde bereits behoben — und was ausdrücklich nicht, weil es sich nicht zurücknehmen lässt.
• Was Betroffene tun sollten — falls etwas zu tun ist; sonst ausdrücklich, dass nichts zu tun ist.
• Wen sie erreichen — ein Weg, der auf die Vorfallkennung Bezug nimmt.

Der erste Punkt entscheidet über die Glaubwürdigkeit. Eine Benachrichtigung an alle Kunden „vorsichtshalber“ ist teurer als eine genaue Liste, verunsichert Unbeteiligte und macht den Umfang größer, als er war. Sie ist die Folge davon, den Radius nicht bestimmen zu können — nicht eine Entscheidung für Transparenz.

Aus dem Vorfall wird ein Testfall

Die Nachbereitung eines Agentenvorfalls hat zwei Ergebnisse, und nur eines davon ist ein Dokument. Das wichtigere ist ein dauerhafter Eintrag in der Prüfstrecke.

Der Testfall

Formuliert über sein Ziel, nicht über seinen Wortlaut: „Ein Ticket mit widersprüchlicher Kategorisierung darf keine Kundenmail auslösen.“ Bleibt über Modellwechsel gültig.

Die Laufzeitkontrolle

Eine Grenze, die denselben Fall auch dann fängt, wenn der Testfall ihn nicht erwischt: Mengenprüfung, Freigabepflicht, Positivliste.

Das Dokument

Nützlich für die Organisation, wirkungslos gegen eine Wiederholung. Es hindert kein System an irgendetwas.

Der zweite Punkt ist der, der bei nichtdeterministischen Systemen den Ausschlag gibt. Ein Testfall prüft, ob ein bekanntes Muster wieder auftritt; eine Laufzeitgrenze fängt auch die Variante, an die niemand gedacht hat. Ein Vorfall, der nur einen Testfall hinterlässt, ist zur Hälfte aufgearbeitet.

Wann der Agent wieder laufen darf

Die letzte Entscheidung ist die unbequemste, weil sie unter Druck getroffen wird: Wann wird die Eindämmung aufgehoben? Der übliche Auslöser — „die Ursache ist behoben“ — reicht nicht, weil er eine Aussage über eine Hypothese ist.

• Der Radius ist vollständig bestimmt — nicht: weitgehend. Sonst laufen neue Wirkungen in eine unfertige Bestandsaufnahme.
• Die Kompensation ist erledigt oder ausdrücklich zurückgestellt — mit Verantwortlichem und Frist.
• Eine Kontrolle greift, die den Fall auch dann fängt, wenn die Ursachenhypothese falsch war.
• Ein begrenzter Wiederanlauf — kleiner Anteil, enge Beobachtung, vorab gesetztes Abbruchkriterium. Nicht der volle Betrieb.
• Eine benannte Person entscheidet — der Wiederanlauf ist eine Entscheidung, kein Zustand, der von selbst eintritt.

Der dritte Punkt ist der, der am häufigsten übersprungen wird. Nach einem Vorfall ist die Ursachenhypothese frisch und überzeugend — und in einem nichtdeterministischen System oft unvollständig. Eine Kontrolle, die unabhängig von der Hypothese greift, ist die Absicherung gegen genau diesen Fall.

Die Reihenfolge ist dabei nicht verhandelbar, weil jede Stufe die nächste absichert. Ein Wiederanlauf vor abgeschlossener Radiusbestimmung mischt neue Wirkungen unter die alten und macht die Bestandsaufnahme unbrauchbar — der häufigste Grund dafür, dass ein Vorfall zweimal aufgearbeitet werden muss.

Was der Check prüft

• Die ersten Handlungen in die Reihenfolge bringen, in der jede die nächste ermöglicht.
• Eine Eindämmungsstufe wählen, die den Zufluss stoppt, ohne die Diagnose zu verlieren.
• Beweise sichern, bevor eine reguläre Aufbewahrungsfrist sie entfernt.
• Eine Schalterkonfiguration lesen und die Stufe finden, die im Ernstfall fehlt.
• Einen Wirkungsradius aus dem Aktionsprotokoll statt aus einem Zeitfenster bestimmen.
• Wirkungen nach Kompensierbarkeit sortieren und die nicht kompensierbaren benennen.
• Aus einer gescheiterten Reproduktion nicht auf Seltenheit schließen.
• Betroffene aus dem Radius benachrichtigen statt vorsichtshalber alle.
• Einen Wiederanlauf an Bedingungen knüpfen, die nicht an der Ursachenhypothese hängen.

Der gemeinsame Nenner: Ein Agentenvorfall ist kein Ausfall, sondern eine Menge unerwünschter Wirkungen. Beherrschbar ist er nur, wenn man diese Menge genau bestimmen kann — und diese Fähigkeit entsteht lange vor dem Vorfall.