Automatischer Rollback für Agenten-Nebenwirkungen

Ein Agenten-Rollback kann Code, Konfiguration oder ausgewählte Anwendungsdaten wiederherstellen. Er kann jedoch keine andere Organisation dazu bringen, eine Anfrage zu vergessen, eine zugestellte E-Mail aus dem Postfach zurückzuholen oder so zu tun, als hätte eine Kartenbelastung nie einen Zahlungsdienstleister erreicht. Teams, die all diese Vorgänge als „Rollback“ bezeichnen, bauen eine beruhigende Kontrolle, die genau dann versagt, wenn die Folgen wichtig werden.

Ein sicheres Design trennt vier Mechanismen: Anwendungssnapshots, Git-Reverts, Datenbankwiederherstellung und kompensierende Aktionen. Jeder hat eine eigene Grenze. Jede Aktion, die die Anwendungsgrenze überschreitet, braucht vor der Ausführung durch den Agenten eine eigene Freigabe, Nachweise, eine Wiederholungsregel und einen Wiederherstellungsweg. Kann niemand diesen Weg in einem Satz beschreiben, ist die Aktion nicht bereit für eine unbeaufsichtigte Ausführung.

Rollback hat vier unterschiedliche Bedeutungen

Rollback ist nur dann nützlich, wenn das Team den Zustand benennt, den er wiederherstellt, und den Zustand, den er nicht beeinflussen kann. Hinter dem Wort verbergen sich meist vier Mechanismen mit sehr unterschiedlichen Garantien.

Ein Snapshot stellt eine erfasste Version einer Anwendung oder eines Arbeitsbereichs wieder her. Je nach Produkt kann dieser Snapshot generierten Code, Konfiguration und ausgewählten verwalteten Zustand enthalten. Über externe Dienste sagt er nichts aus, es sei denn, der Snapshot-Vertrag schließt sie ausdrücklich ein.

Ein Git-Revert zeichnet einen neuen Commit auf, dessen Änderungen einen früheren Commit umkehren. Er repariert die Quellcode-Historie, ohne sie zu löschen. Er kontaktiert nicht die Dienste, die der alte Code während seiner Ausführung aufgerufen hat.

Die Datenbankwiederherstellung verändert Datensätze, die in der Datenbank liegen. Ein Transaktions-Rollback verwirft nicht festgeschriebene Schreibvorgänge innerhalb einer Transaktion. Das Wiederherstellen eines Backups oder eine Point-in-Time-Recovery ist ein deutlich größerer Vorgang, der einen Datenbankcluster in Richtung eines früheren Zustands bewegt. Keiner dieser Vorgänge gleicht Systeme außerhalb dieser Datenbank automatisch ab.

Eine kompensierende Aktion erzeugt eine neue Auswirkung, die eine frühere ausgleichen soll. Eine Rückerstattung kompensiert eine eingezogene Zahlung. Eine Stornierungsanfrage kompensiert eine Bestellung. Eine Korrektur-E-Mail kann die Folgen einer falschen E-Mail abmildern, sie kann die erste Nachricht aber nicht entfernen. Kompensation bewahrt die unbequeme Wahrheit, dass die ursprüngliche Aktion stattgefunden hat.

Bei Design-Reviews nutze ich eine Tabelle zur Zuständigkeit für Auswirkungen, weil sie präzise Antworten erzwingt:

Die letzte Spalte ist am wichtigsten. Ein umgekehrter Vorgang ist kein Beweis dafür, dass das Original verschwunden ist. Audit-Protokolle, Kopien bei Empfängern, Buchungseinträge, Webhooks und physische Arbeit können bestehen bleiben.

Ein Code-Revert ändert das Programm, nicht die Vergangenheit

Ein Code-Revert verhindert oder verändert künftiges Verhalten. Verhalten, das die alte Version bereits ausgelöst hat, kehrt er nicht um. Das gilt unabhängig davon, ob das Team Git, einen Plattformsnapshot oder ein Deployment-Rollback nutzt.

Die Git-Dokumentation beschreibt git revert als das Aufzeichnen von Commits, die Änderungen früherer Commits umkehren. Diese Formulierung ist genau: Git wendet einen inversen Patch auf den Repository-Inhalt an. Git weiß nichts über E-Mails, Zahlungen, Cloud-Ressourcen, Support-Tickets oder Partner-APIs, die entstanden sind, als der zurückgenommene Commit lief.

Angenommen, ein Agent ändert eine Abrechnungsfunktion, stellt sie bereit und ruft sie zweimal auf, bevor das Monitoring den Fehler erkennt. Das Zurücknehmen des Commits kann verhindern, dass die fehlerhafte Funktion erneut läuft. Beim Zahlungsdienstleister bleiben zwei Zahlungsversuche zurück. Wenn die lokale Datenbank nur einen Versuch erfasst hat, kann der Revert die Untersuchung sogar erschweren, weil er den Codepfad entfernt, der die zweite Antwort verstanden hat.

Ein Deployment-Rollback hat dieselbe Grenze. Wenn der Datenverkehr zurück auf einen früheren Build geleitet wird, stellt das ausführbares Verhalten wieder her. Anfragen, die der ersetzte Build bereits angenommen hat, behalten ihre Folgen. Auch in Warteschlangen befindliche Jobs können das Deployment überleben und alte Annahmen gegen die wiederhergestellte Version ausführen.

Bewahren Sie vor dem Revert die operativen Nachweise auf, die der alte Build erzeugt hat:

• Deployment-Kennung und Quell-Commit
• Kennungen für Agentenlauf und Intent
• Kennungen von Warteschlangennachrichten und Lease-Status
• Kennungen externer Anfragen
• Antworten des Anbieters und Zeitstempel

Stoppen Sie dann neue Ausführungen, gleichen Sie unvollständige Vorgänge ab und stellen Sie den Code wieder her. Erst zu revertieren und später Fragen zu stellen, zerstört oft den einfachsten Weg, um zu verstehen, welche Auswirkungen die Anwendungsgrenze überschritten haben.

Ein Snapshot kann umfassender sein als ein Git-Commit, doch dieselbe Regel gilt. Der Snapshot-Vertrag muss genau aufführen, welche Ressourcen er enthält. Wenn er Code und Konfiguration enthält, nennen Sie ihn einen Wiederherstellungsmechanismus für Code und Konfiguration. Machen Sie ihn nicht durch hoffnungsvolle Formulierungen in der Oberfläche zu einem universellen Rückgängig-Werkzeug.

Datenbankwiederherstellung hat eine engere Aufgabe, als viele annehmen

Die Datenbankwiederherstellung stellt den Datenbankzustand wieder her, nicht die geschäftliche Realität bei allen Beteiligten einer Transaktion. Eine Transaktion kann innerhalb einer Datenbank atomar sein, während der umgebende Vorgang auf mehrere Systeme verteilt bleibt.

Betrachten Sie diese Abfolge:

1. Der Agent fügt eine Rechnungszeile ein.
2. Er ruft eine Zahlungs-API auf.
3. Der Zahlungsdienstleister akzeptiert die Belastung.
4. Der Datenbank-Commit schlägt fehl.

Der lokale Rollback entfernt die Rechnungszeile. Die Belastung besteht weiterhin. Wird der gesamte Vorgang ohne Abgleich wiederholt, kann der Kunde erneut belastet werden. Das ist der klassische Dual-Write-Fehler: Die Anwendung wollte eine Geschäftsaktion über Systeme hinweg atomar machen, die keinen gemeinsamen Transaktionskoordinator teilen.

Die Reihenfolge umzukehren löst das Problem nicht. Wenn die Anwendung zuerst die Rechnung festschreibt und der Zahlungsaufruf dann fehlschlägt, enthält die Datenbank eine unbezahlte Rechnung. Dieser Zustand lässt sich leichter prüfen, doch die Anwendung braucht weiterhin einen Zustandsautomaten, der payment_pending, payment_confirmed, payment_failed und payment_unknown unterscheidet.

Die PostgreSQL-Dokumentation erklärt Point-in-Time-Recovery als Wiederherstellung eines Basis-Backups und anschließendes Wiedergeben von Write-Ahead-Log-Einträgen bis zu einem gewählten Wiederherstellungsziel. Das ist ein Verfahren für Betreiber, um einen Datenbankcluster wiederherzustellen. Es ist kein gezieltes Rückgängigmachen eines einzelnen Agentenlaufs und kann keinen Zahlungsdienstleister oder E-Mail-Dienst auf denselben Zeitpunkt zurückversetzen.

Ein Zurücksetzen der Datenbank kann einen zweiten Widerspruch erzeugen. Stellen Sie sich vor, Sie stellen nach einem Ausfall den Zustand von 10:00 Uhr wieder her. Ein Anbieter hat bis 10:07 Uhr Anfragen angenommen, doch die wiederhergestellte Datenbank enthält deren Datensätze nicht mehr. Agenten, die „fehlende“ Zeilen sehen, könnten die gesamte Arbeit dieser sieben Minuten erneut erzeugen. Deshalb braucht die Wiederherstellung eine Phase für den externen Abgleich, bevor Worker weiterlaufen.

Ein Outbox-Pattern verringert eine gefährliche Lücke. Die Anwendung schreibt ihre Geschäftsänderung und einen Intent für eine Auswirkung in derselben lokalen Transaktion fest:

BEGIN;

INSERT INTO invoices (invoice_id, customer_id, status)
VALUES ('inv_2048', 'cust_91', 'payment_pending');

INSERT INTO effect_intents
  (intent_id, operation, subject_id, status)
VALUES
  ('eff_7f31', 'capture_payment', 'inv_2048', 'pending');

COMMIT;

Ein Worker beansprucht später eff_7f31, ruft den Anbieter mit einem stabilen Idempotenzwert auf und erfasst das Ergebnis. Die Outbox macht den externen Aufruf nicht atomar. Sie gibt dem System einen dauerhaften Nachweis, dass die Arbeit beabsichtigt war. Dadurch werden Wiederholungen und Abgleich möglich.

Externe Aktionen brauchen Kompensation, manche haben keine

Eine externe Nebenwirkung braucht eine anbieterspezifische Kompensation oder die ausdrückliche Feststellung, dass keine sinnvolle Kompensation existiert. Jede Aktion als umkehrbar zu behandeln, ist schlimmer, als offen zuzugeben, dass manche Aktionen eine Freigabe brauchen.

E-Mail ist das einfachste Beispiel. Bevor der Anbieter die Nachricht annimmt, kann die Anwendung möglicherweise einen Job in der Warteschlange stornieren. Nach der Annahme erlaubt der Anbieter vielleicht während einer kurzen internen Phase eine Stornierung, doch eine allgemeine Rückrufgarantie über Empfänger und E-Mail-Systeme hinweg gibt es nicht. Nach der Zustellung kann eine zweite Nachricht den Sachverhalt korrigieren, aber die erste nicht löschen. Sensible Daten, rechtliche Mitteilungen und Reputationsschäden bleiben sichtbar.

Bei Zahlungen gibt es mehrere Zustände, die Teams oft unter „belastet“ zusammenfassen. Eine Autorisierung reserviert verfügbare Mittel. Eine Einziehung fordert die Bewegung von Geld auf Basis dieser Autorisierung an. Eine Stornierung kann eine noch nicht abgewickelte Autorisierung freigeben. Eine Rückerstattung erzeugt nach der Einziehung einen späteren Finanzposten, der Geld zurückzahlt. Diese Vorgänge haben unterschiedliche Zeitvorgaben, Gebühren, Berechtigungen und Auswirkungen für Kunden. Ein allgemeines Tool undo_payment verbirgt Informationen, die der Agent für sicheres Handeln braucht.

Andere APIs sind noch weniger kooperativ. Eine Anfrage kann Bestand bestellen, Infrastruktur bereitstellen, Inhalte veröffentlichen, Zugänge gewähren, ein Paket versenden oder eine Person veranlassen, mit der Arbeit zu beginnen. Ein DELETE-Endpunkt beweist keine Umkehrbarkeit. Das Löschen einer Ressource kann Audit-Protokolle, kopierte Daten, Benachrichtigungen, abhängige Ressourcen oder physische Folgen zurücklassen.

Ordnen Sie Kompensationen danach ein, was sie ehrlich leisten können:

• Eine exakte lokale Umkehrung bringt kontrollierten Zustand auf seinen vorherigen Wert zurück.
• Eine Stornierung beim Anbieter stoppt Arbeit, die noch nicht abgeschlossen ist.
• Eine finanzielle Kompensation erzeugt eine Rückerstattung oder Gutschrift.
• Eine korrigierende Mitteilung erkennt an, dass die erste Nachricht sichtbar bleibt.
• Manuelle Nacharbeit behandelt Auswirkungen, deren Kontext sich nicht in eine sichere automatisierte Regel fassen lässt.

Auch eine Kompensation kann fehlschlagen. Der Rückerstattungsendpunkt kann einen Timeout liefern. Das Stornierungsfenster kann sich schließen. Die Empfängeradresse kann die Korrektur ablehnen. Das Konto des Agenten hat möglicherweise keine Berechtigung. Deshalb muss das System die Kompensation als eigenen Vorgang mit eigener Intent-Kennung, Status, Versuchen, Nachweisen und Freigaberichtlinie verfolgen.

Bauen Sie keine rekursive Funktion „Rollback des Rollbacks“. Modellieren Sie die Historie als Aktionsledger. Wenn eine Kompensation einen neuen Fehler verursacht, lösen Sie nach Prüfung des aktuellen Zustands eine weitere ausdrückliche Aktion aus. Diese Historie ist länger, aber bei einem Vorfall bleibt sie verständlich.

Idempotenz verhindert Wiederholungen, kehrt Erfolg aber nicht um

Idempotenz schützt Wiederholungen davor, doppelte beabsichtigte Auswirkungen zu erzeugen. Sie macht die erste erfolgreiche Auswirkung nicht rückgängig. Teams verwischen diese beiden Dinge regelmäßig und merken den Unterschied erst nach einem Timeout.

RFC 9110 definiert eine idempotente Anfrage-Methode dadurch, dass die beabsichtigte Wirkung mehrerer identischer Anfragen dieselbe ist wie die einer einzelnen solchen Anfrage. PUT, DELETE und sichere Methoden gelten auf Ebene der Protokollsemantik als idempotent. POST ist im Allgemeinen nicht idempotent, obwohl eine API durch ihren eigenen Vertrag Idempotenzverhalten ergänzen kann.

Diese Einschränkung ist wichtig. Ein idempotentes DELETE kann bei jedem Aufruf weiterhin einen neuen Logeintrag, Messwert oder eine neue Antwort erzeugen. Die Idempotenzimplementierung eines Anbieters kann außerdem Einträge ablaufen lassen, Kennungen auf ein Konto beschränken, geänderte Parameter ablehnen oder nur ausgewählte Ergebnisse zwischenspeichern. Lesen Sie den Vertrag des Anbieters, statt Garantien aus einem HTTP-Verb abzuleiten.

Jeder Intent für eine Auswirkung sollte vor dem ersten Versuch einen stabilen Idempotenzwert erhalten. Wiederholungen desselben Intents verwenden ihn erneut. Ein neuer Geschäfts-Intent erhält einen neuen Wert. Leiten Sie ihn niemals nur aus veränderlichen Parametern wie Kunde, Betrag und Datum ab, denn zwei rechtmäßige Käufe können diese Werte teilen.

Ein Timeout erzeugt ein unbekanntes Ergebnis, keinen Fehlschlag. Nutzen Sie diese Abfolge:

1. Markieren Sie den Versuch als outcome_unknown und erstellen Sie keinen Ersatz-Intent.
2. Fragen Sie den Anbieter anhand des Idempotenzwerts oder der Vorgangsreferenz ab.
3. Bestätigt der Anbieter den Erfolg, speichern Sie ihn lokal.
4. Bestätigt er, dass kein Vorgang erfolgt ist, wiederholen Sie mit demselben Wert.
5. Kann er keine Auskunft geben, halten Sie den Vorgang für Abgleich oder menschliche Prüfung an.

Diese Antwortform gibt dem Agenten genug Informationen, um Annahme von Transportunsicherheit zu unterscheiden:

{
  "intent_id": "eff_7f31",
  "attempt": 2,
  "idempotency_key": "eff_7f31",
  "transport_status": "timeout",
  "provider_status": "unknown",
  "provider_reference": null,
  "next_action": "reconcile"
}

Ein Idempotenzwert sollte, sofern unterstützt, durch Logs, Warteschlangennachrichten, API-Header und Metadaten des Anbieters mitgeführt werden. Können Betreiber auf beiden Seiten der Grenze nicht danach suchen, müssen sie während der Wiederherstellung raten.

Die Freigabe gehört an die Grenze der Auswirkung

Die Freigabe muss erfolgen, nachdem der Agent die genaue externe Aktion formuliert hat und bevor die erste irreversible Anfrage das System verlässt. Eine Freigabe am Beginn einer umfassenden Aufgabe lässt dem Agenten zu viel Spielraum, später Empfänger, Beträge, Umfang oder Tools zu ändern.

„Bearbeite das Konto dieses Kunden“ ist keine ausreichende Freigabe, um eine Karte zu belasten oder allen Nutzern eine E-Mail zu senden. Eine gültige Freigabe beschreibt den konkreten Vorgang: Empfänger, Betrag und Währung, Digest der Nachricht oder Nutzlast, Zielkonto, Tool, Ablaufzeit und erlaubte Anzahl von Versuchen. Ändert sich ein freigegebenes Feld, passt die Freigabe nicht mehr.

Eine sinnvolle Richtlinie sortiert Auswirkungen nach ihren Folgen, nicht danach, welcher Agent oder welches Modell sie angefordert hat. Lesezugriff kann private Daten offenlegen, erzeugt aber nicht dasselbe Wiederherstellungsproblem wie eine ausgehende Aktion. Das Verfassen einer E-Mail ist lokal und umkehrbar. Ihr Versand überschreitet die Grenze. Das Erstellen eines Zahlungsvorschlags ist lokal. Das Einziehen von Geld überschreitet die Grenze.

Verlangen Sie eine ausdrückliche Freigabe für Aktionen, die:

• Geld bewegen oder eine finanzielle Verpflichtung erzeugen
• Informationen an eine Person oder externe Organisation senden
• Daten außerhalb kontrollierter Speicherung veröffentlichen, löschen oder offenlegen
• Identität, Zugriff, Eigentümerschaft oder Sicherheitseinstellungen ändern
• physische Arbeit oder einen anderen Prozess starten, der sich nicht zuverlässig zurückrufen lässt

Folgenarme, wiederkehrende Aktionen können eine begrenzte dauerhafte Freigabe nutzen. Die Grenze sollte Höchstbetrag, Empfängerkreis, erlaubtes Tool, Ablaufzeit, Rate und Gesamtzahl der Vorgänge benennen. „Für Abrechnung freigegeben“ hat keine durchsetzbare Grenze.

Auch die Freigabe braucht Schutz vor Wiederholung. Binden Sie sie an einen unveränderlichen Digest des Vorgangs und markieren Sie sie als verbraucht, wenn die Richtlinie nur eine Ausführung erlaubt. Liefert die Ausführung ein unbekanntes Ergebnis, fordern Sie keine neue Freigabe an und erstellen Sie keinen zweiten Intent. Gleichen Sie zuerst den freigegebenen Intent ab.

Der Freigabebildschirm sollte die Wiederherstellungsrealität in verständlicher Sprache nennen. „Diese Nachricht kann nach der Zustellung nicht zurückgerufen werden“ ist hilfreich. „Dieser Vorgang ist umkehrbar“ führt in die Irre, wenn die tatsächliche Wiederherstellung eine Rückerstattung ist, die Zeit braucht und auf Kontoauszügen sichtbar bleibt.

Tool-Verträge sollten den gesamten Lebenszyklus einer Auswirkung abbilden

Ein Tool-Vertrag für Agenten sollte Intent, Ausführung, Beobachtung und Kompensation als getrennte Vorgänge beschreiben. Eine einzelne Funktion, die eine Auswirkung erzeugt und success: true zurückgibt, hinterlässt zu wenig Nachweise für Wiederholungen, Freigaben oder die Reaktion auf Vorfälle.

Das folgende Richtlinienfragment ist klein genug für eine Durchsetzung und konkret genug für eine Prüfung:

tools:
  send_email:
    effect: irreversible
    approval: required
    idempotency_field: intent_id
    evidence_field: provider_message_id
    compensation: null

  capture_payment:
    effect: compensatable
    approval: required
    idempotency_field: intent_id
    evidence_field: provider_payment_id
    compensation: refund_payment

  update_draft:
    effect: local_reversible
    approval: none
    compensation: restore_version

effect sagt dem Planer, welche Wiederherstellungsklasse gilt. approval blockiert die Ausführung, bis die genauen Argumente autorisiert sind. Das Idempotenzfeld sorgt dafür, dass Wiederholungen eine Kennung wiederverwenden. Das Nachweisfeld zeigt den Betreibern, was erhalten bleiben muss. Das Kompensationsfeld verweist auf ein separates Tool, statt vorzutäuschen, der ursprüngliche Aufruf könne rückwärts laufen.

Die Ausführung sollte einen unveränderlichen Umschlag akzeptieren:

{
  "intent_id": "eff_7f31",
  "operation": "capture_payment",
  "arguments": {
    "invoice_id": "inv_2048",
    "amount_minor": 12900,
    "currency": "USD"
  },
  "approval": {
    "approval_id": "apr_662",
    "scope_hash": "sha256:8b4f...",
    "expires_at": "2026-07-27T18:00:00Z"
  }
}

Der Executor berechnet den Vorgangs-Digest, vergleicht ihn mit scope_hash, prüft das Ablaufdatum, reserviert den Intent und kontaktiert erst dann den Anbieter. Er speichert die Anfragemetadaten vor dem Aufruf und die Antwort danach. Stürzt er zwischen diesen beiden Schreibvorgängen ab, bleibt der dauerhafte Intent für den Abgleich verfügbar.

Der Executor sollte vier Bedingungen ohne Improvisation ablehnen: geänderte Argumente, abgelaufene Freigabe, Wiederverwendung eines Intents für einen anderen Vorgang und den Versuch, eine Auswirkung zu kompensieren, deren erfolgreicher Abschluss noch nicht bestätigt ist. Agenten finden gut plausible Fortsetzungen. Bei Finanz- und Kommunikationskontrollen muss ein sichtbarer Stopp einer plausiblen Vermutung vorgezogen werden.

Geben Sie der Beobachtung ein eigenes Tool, etwa get_payment_status(intent_id). Beobachtung sollte keine Auswirkung erzeugen. Die Trennung ermöglicht dem Agenten, mehrdeutige Ergebnisse aufzulösen, ohne zugleich die Berechtigung zu erhalten, die ursprüngliche Aktion zu wiederholen.

Ein fehlgeschlagener Lauf kann jede Wiederherstellungsgrenze überschreiten

Ein einzelner Agentenlauf kann Code, Datenbankdatensätze und externe Systeme auf unterschiedlichen Zeitständen zurücklassen. Wenn Sie diesen Fehler vor dem Start durchspielen, werden Lücken sichtbar, die eine allgemeine Rollback-Kontrolle verdeckt.

Nehmen wir an, ein Agent erstellt eine Mitgliederanwendung, stellt eine Änderung bereit, importiert eine Kundenliste, zieht Jahresgebühren ein und versendet Willkommens-E-Mails. Die Aufgabe wirkt einheitlich, überschreitet aber mindestens vier Wiederherstellungsgrenzen.

Um 14:00 Uhr stellt der Agent Code bereit, der die Jahresgebühr aus der falschen Spalte berechnet. Um 14:02 Uhr schreibt er 40 Zahlungs-Intents und E-Mail-Entwürfe in die Datenbank. Um 14:03 Uhr zieht ein Worker mehrere Zahlungen ein. Um 14:04 Uhr akzeptiert der E-Mail-Anbieter Willkommensnachrichten mit der falschen Gebühr. Um 14:05 Uhr stoppt das Monitoring den Worker. Einige Zahlungsaufrufe liefen aus, nachdem sie den Zahlungsdienstleister erreicht hatten. Der lokale Status verrät daher nicht, ob sie erfolgreich waren.

Die Wiederherstellung des Code-Snapshots von 13:59 Uhr stoppt die fehlerhafte Berechnung in künftigen Läufen. Sie ändert nicht die Gebühr, die in bestehende Intents kopiert wurde. Der Git-Revert dokumentiert die Quellcode-Korrektur, hat aber dieselbe Grenze.

Eine Wiederherstellung der Datenbank auf 13:59 Uhr würde die lokalen Intent-Datensätze entfernen, die Anbieterreferenzen und Idempotenzwerte enthalten. Das verschlimmert den externen Widerspruch. Die bessere Datenbankaktion ist eine logische Korrektur: Bewahren Sie die Intents, markieren Sie unsichere Vorgänge zum Abgleich und korrigieren Sie Zeilen erst nach dem Abgleich mit dem Anbieterstatus.

Das Reaktionsteam sollte dann nach Wirkungsklassen vorgehen. Es fragt jede unsichere Zahlung über ihre stabile Vorgangskennung ab. Bestätigte Einziehungen gehen in eine Prüfung für Rückerstattungen, fehlgeschlagene Versuche werden ohne Wiederholung geschlossen und ungelöste Versuche bleiben blockiert. Zugestellte E-Mails erhalten eine sorgfältig freigegebene Korrektur. Nachrichten in der Warteschlange, die den Anbieter noch nicht erreicht haben, werden storniert. Jede Kompensation erhält einen neuen Intent, der mit dem ursprünglichen verknüpft ist.

Dieses Beispiel zeigt auch, warum automatische Kompensation gefährlich sein kann. Würde das System sofort jeden lokalen Datensatz payment_unknown erstatten, könnte es Rückerstattungen für nie erfolgte Belastungen auslösen oder einen Rückerstattungsendpunkt mit der falschen Referenz aufrufen. Würde es nach einer Datenbankwiederherstellung jede fehlende E-Mail erneut senden, könnten Empfänger Duplikate erhalten. Wenn lokaler und Anbieterzustand voneinander abweichen, muss der Abgleich vor der Kompensation erfolgen.

Der Lauf ist erst abgeschlossen, wenn jeder Intent einen Endzustand wie succeeded, confirmed_failed, compensated oder manual_exception erreicht. „Die Anwendung wurde zurückgesetzt“ beschreibt nur den ersten Teil des Vorfalls.

Wiederherstellung funktioniert nur, wenn die Nachweise erhalten bleiben

Wiederherstellungskontrollen versagen, wenn ein Rollback die Datensätze löscht, die zur Klärung des Geschehenen nötig sind. Speichern Sie ein nur anhängbares Ledger für Auswirkungen außerhalb des Anwendungszustands, den routinemäßige Snapshots oder Wiederherstellungen ersetzen können. Bewahren Sie außerdem genug Nachweise des Anbieters auf, um jeden Vorgang abzugleichen.

Das Ledger sollte die Erstellung des Intents, den Argument-Digest, die Freigabe, die Ausführungs-Lease, den Versuch, das Transportergebnis, die Anbieterreferenz, den beobachteten Anbieterzustand und Kompensationsverknüpfungen erfassen. Beschränken Sie Änderungen auf Zustandsübergänge, statt Agenten alte Einträge überschreiben zu lassen. Korrekturen sollten Ereignisse hinzufügen, nicht die Historie bearbeiten.

Überwachen Sie ungelöste Zustände, nicht nur ausdrückliche Fehler. Ein outcome_unknown, das zehn Minuten bestehen bleibt, kann gefährlicher sein als eine eindeutige Ablehnung, weil ein Betreiber ihn manuell wiederholen könnte. Alarmieren Sie außerdem, wenn eine Freigabe während der Ausführung abläuft, ein Idempotenzwert mit einem anderen Argument-Digest erscheint oder eine Kompensation fehlschlägt.

Führen Sie Wiederherstellungsübungen mit absichtlich unangenehmen Fehlerpunkten durch. Beenden Sie einen Worker, nachdem der Anbieter eine Anfrage angenommen hat, aber bevor der lokale Erfolgseintrag geschrieben wurde. Stellen Sie Anwendungsdaten aus einem früheren Snapshot wieder her, während das Ledger für Auswirkungen erhalten bleibt. Lassen Sie die Freigabe zwischen Planung und Ausführung ablaufen. Machen Sie die Beobachtungs-API nicht verfügbar. Die Übung besteht, wenn das System stoppt, abgleicht und die ungelöste Entscheidung sichtbar macht, ohne die Auswirkung zu duplizieren.

Wenn Sie Koder.ai einsetzen, behandeln Sie seine Snapshots und seinen Rollback als Wiederherstellungsebene der Anwendung. Entwerfen Sie dann getrennte Kontrollen für die Datenbankhistorie und jede externe Aktion, die die Anwendung auslösen kann. Quellcode-Export, Deployment-Kontrollen und Rollback helfen, Software wiederherzustellen, während die Tool-Verträge der Anwendung weiterhin für Freigaben und Kompensation zuständig sind.

Eine Rollback-Schaltfläche sollte ihre Grenze direkt daneben benennen: Code, Konfiguration, verwaltete Daten oder externe Auswirkungen. Kann die Oberfläche diesen Satz nicht präzise formulieren, sollte sie keinen Rollback versprechen. Die ehrliche Kontrolle wirkt vielleicht weniger magisch, gibt dem Incident-Team aber das, was es um zwei Uhr morgens braucht: eine verlässliche Darstellung dessen, was sich geändert hat, was die Grenze überschritten hat und welche Aktion als Nächstes sicher ist.