Wenn der Agent falsch lag: Umkehrbarkeit ohne Rollback-Schicht

Die Frage, die Teams stellen, sobald Agenten Tickets lösen, CRM-Datensätze aktualisieren und Kunden-E-Mails senden, lautet nicht mehr, wie ein Fehler erkannt wird. Sie lautet, was passiert, nachdem der Fehler bereits ausgeführt wurde. Ein Agent entscheidet, dass ein Kundenanliegen gelöst ist. Er schließt das Ticket, aktualisiert das CRM, mailt dem Kunden und stößt einen nachgelagerten Workflow an. Die Erkennung ist der einfache Teil. Jemand muss trotzdem jedes System finden, das die Aktion berührt hat, entscheiden, welcher Zustand vorher galt, und ihn wiederherstellen.

Ich bin den Rollback-Weg gegangen und wieder zurückgekommen. Diese Seite beschreibt, was ihn ersetzt hat.

Die Aktionsliste enthält bereits etwas, das niemand umkehren kann

Die E-Mail ist draußen. Sie können eine Korrektur senden, aber der Kunde hat die erste gelesen, und keine Snapshot-Schicht kauft das zurück. Dasselbe gilt für eine ausgelöste Zahlung, eine Bestellung, die einem Lieferanten bestätigt wurde, eine Nachricht in einem Kanal mit zweihundert Leuten. Eine Rollback-Schicht ist für die drei Aktionen in der Liste gebaut, die ohnehin umkehrbar waren, und sie schweigt zu der einen, die es nicht war.

Das ist die erste Trennung, und es ist die, die zählt: nicht nach System, sondern danach, ob die Aktion von innen zurückgenommen werden kann.

Systemübergreifendes Rollback setzt einen Zustand voraus, den es nie gab

Der zweite Grund, warum der Rollback-Weg endet, ist leiser. Rollback über Systeme hinweg setzt voraus, dass es einen einzigen vorherigen Zustand gab, den man wiederherstellen kann. In der Praxis widersprachen sich das Ticketboard und das CRM schon, bevor der Agent je lief: Das CRM sagte aktiv, das neueste Ticket sagte blockiert, und beide hatten für ihr eigenes Feld recht. Den vorherigen Zustand wiederherzustellen stellt einen Widerspruch wieder her, und jetzt trägt er einen Zeitstempel, der sagt, der Agent habe es getan.

Was das Team braucht, ist nicht der alte Zustand. Es ist der Nachweis, was der Agent geändert hat, mit dem Wert, von dem er es geändert hat, pro Feld, pro System.

Die Trennung, die funktioniert

Umkehrbar innerhalb eines Systems. Ein Ticketstatus, ein CRM-Feld, ein Seitenabschnitt, ein Work Item. Diese werden direkt geschrieben, und der Datensatz trägt seinen vorherigen Wert. Das Zurücknehmen ist ein einziger Schreibzugriff, und die Person, der der Datensatz gehört, kann ihn in dem Werkzeug ausführen, in dem sie ohnehin arbeitet.

Verlässt das Haus oder berührt Geld. Eine Kunden-E-Mail, eine Zahlung, eine Bestellung, ein öffentlicher Beitrag. Diese laufen nie als Seiteneffekt. Sie werden zu einem Vorschlag, der an einer Stelle auf eine Person wartet, als Karte in dem Chat, den das Team ohnehin benutzt, mit der Textstelle und dem exakten Inhalt. Die Warteschlange ist langweilig, und sie ist der einzige Grund, warum die Aufräum-Nachmittage aufgehört haben.

Die Regel für die Trennung ist nicht das Werkzeug und nicht das System. Es ist die Antwort auf eine Frage: Wenn das falsch war, kann eine Person es aus unseren eigenen Systemen heraus mit einem Schreibzugriff zurücksetzen?

Kompensation, nie Löschung

Eine bestätigte Aktion, die sich als falsch herausstellt, wird nie aus dem Trail gelöscht. Sie bekommt eine kompensierende Aktion mit eigenem Beleg, und beide bleiben nebeneinander sichtbar. Ein Audit liest die Entscheidung, den Fehler und die Korrektur in einer Zeilengruppe. Das ist der Unterschied zwischen einem System, das geprüft werden kann, und einem, dem man glauben muss.

Eine Verfeinerung, die es wert ist, behalten zu werden, von einem Praktiker, der dieses Modell gegengelesen hat: Eine abgelehnte Aktion hat zwei Enden, nicht eines. Entweder wurde sie abgelehnt und als sauber verifiziert, also lief nichts Nachgelagertes, oder sie wurde abgelehnt und ist ungeklärt, weil ein Webhook feuerte, bevor die Ablehnung ankam. Der dritte Zustand ist der, der einen Verantwortlichen braucht, und er braucht eine eigene Zeile.

Was ein Beleg festhalten muss

Der Beleg ist das Artefakt, von dem alles oben abhängt. Zu jedem freigegebenen Schreibzugriff hält er fest:

• wer freigegeben hat, und wann;
• den exakten Schreibzugriff, in den Argumenten, die gelaufen sind, nicht in der Zusammenfassung, die der Agent vorgeschlagen hat;
• den Datensatz, in dem er gelandet ist, mit Link;
• den vorherigen Wert, wo es einen gab;
• den aufgelösten Kunden, das Projekt oder die Entscheidung, unter der er abgelegt wurde;
• die Textstelle, aus der der Vorschlag gebaut wurde.

Mit diesen sechs Feldern ist das Zurücknehmen eines Schreibzugriffs innerhalb eines Systems mechanisch, die Kompensation eines externen eine dokumentierte Entscheidung, und das Security-Review liest Belege, statt Fragen zu stellen.

Was sich für das Team ändert

Die nicht umkehrbare Klasse wird eine Warteschlange statt fünf Werkzeuge. Freigaben dauern Sekunden, weil die Karte die Textstelle und den Schreibzugriff trägt. Die umkehrbare Klasse läuft ohne Tipp weiter, mit dem vorherigen Wert an jedem Datensatz. Und der Nachmittag, der früher dafür draufging zu rekonstruieren, was der Agent berührt hat, findet nicht statt, weil der Trail es bereits sagt.