Automatyczny rollback skutków ubocznych agenta

Rollback agenta może przywrócić kod, konfigurację lub wybrane dane aplikacji. Nie sprawi jednak, że inna organizacja zapomni o żądaniu, nie wycofa dostarczonego e-maila ze skrzynki ani nie uda, że obciążenie karty nigdy nie dotarło do operatora płatności. Zespoły, które wszystkie te operacje nazywają „rollbackiem”, tworzą uspokajającą kontrolę, która zawodzi właśnie wtedy, gdy skutki mają znaczenie.

Bezpieczny projekt rozdziela cztery mechanizmy: snapshoty aplikacji, reverty Git, odzyskiwanie bazy danych i działania kompensujące. Każdy działa w innej granicy. Każde działanie przekraczające granicę aplikacji potrzebuje własnego zatwierdzenia, dowodów, zasad ponawiania i ścieżki odzyskiwania, zanim agent je wykona. Jeśli nikt nie potrafi opisać tej ścieżki jednym zdaniem, działanie nie jest gotowe do bezobsługowego wykonania.

Rollback ma cztery odrębne znaczenia

Rollback jest przydatny tylko wtedy, gdy zespół nazwie stan, który przywróci, oraz stan, którego nie może dotknąć. To słowo zwykle ukrywa cztery mechanizmy o bardzo różnych gwarancjach.

Snapshot przywraca zapisaną wersję aplikacji lub obszaru roboczego. W zależności od produktu może obejmować wygenerowany kod, konfigurację i wybrany zarządzany stan. Nie mówi nic o usługach zewnętrznych, chyba że umowa snapshotu wyraźnie je obejmuje.

Git revert zapisuje nowy commit, którego zmiany odwracają wcześniejszy commit. Naprawia historię kodu źródłowego, nie usuwając tej historii. Nie kontaktuje się z usługami wywołanymi przez stary kod podczas działania.

Odzyskiwanie bazy danych zmienia rekordy przechowywane w bazie. Rollback transakcji odrzuca niezatwierdzone zapisy w jednej transakcji. Przywrócenie kopii zapasowej lub odzyskiwanie do punktu w czasie to znacznie większa operacja, która przesuwa klaster bazy danych w stronę wcześniejszego stanu. Żadna z nich nie uzgadnia automatycznie systemów poza tą bazą.

Działanie kompensujące tworzy nowy skutek, który ma zrównoważyć stary. Zwrot kompensuje pobraną płatność. Prośba o anulowanie kompensuje zamówienie. E-mail korygujący może ograniczyć skutki błędnej wiadomości, lecz nie usunie pierwszej. Kompensacja zachowuje niewygodną prawdę, że pierwotne działanie nastąpiło.

Podczas przeglądów projektu stosuję tabelę odpowiedzialności za skutki, ponieważ wymusza precyzyjne odpowiedzi:

Ostatnia kolumna ma największe znaczenie. Operacja odwrotna nie dowodzi, że pierwotna zniknęła. Mogą pozostać zapisy audytowe, kopie odbiorców, wpisy rozliczeniowe, webhooki i skutki fizyczne.

Revert kodu zmienia program, a nie przeszłość

Revert kodu zapobiega przyszłemu działaniu lub je zmienia, nie odwraca zachowania, które stara wersja już wywołała. Dotyczy to zarówno Git, snapshotu platformy, jak i rollbacku wdrożenia.

Dokumentacja Git opisuje git revert jako rejestrowanie commitów, które odwracają zmiany wprowadzone przez wcześniejsze commity. To precyzyjne sformułowanie: Git stosuje odwrotną łatę do zawartości repozytorium. Git nie wie nic o e-mailach, płatnościach, zasobach chmurowych, zgłoszeniach wsparcia ani API partnerów utworzonych podczas działania cofniętego commitu.

Załóżmy, że agent zmienia funkcję rozliczeniową, wdraża ją i wywołuje dwukrotnie, zanim monitoring wykryje błąd. Cofnięcie commitu może zatrzymać kolejne uruchomienia błędnej funkcji. W operatorze pozostaną jednak dwie próby płatności. Jeśli lokalna baza zapisała tylko jedną próbę, revert może nawet utrudnić dochodzenie, usuwając ścieżkę kodu, która rozumiała drugą odpowiedź.

Rollback wdrożenia ma tę samą granicę. Przekierowanie ruchu do wcześniejszego buildu przywraca zachowanie wykonywalne. Żądania zaakceptowane wcześniej przez zastąpiony build zachowują swoje skutki. Zadania w kolejce mogą też przetrwać wdrożenie i wykonać stare założenia wobec przywróconej wersji.

Przed revertem zachowaj dowody operacyjne utworzone przez stary build:

• Identyfikator wdrożenia i commit źródłowy
• Identyfikatory uruchomienia agenta i intencji
• Identyfikatory komunikatów kolejki i status dzierżawy
• Identyfikatory żądań zewnętrznych
• Odpowiedzi dostawcy i znaczniki czasu

Następnie zatrzymaj nowe wykonania, uzgodnij nieukończone operacje i przywróć kod. Najpierw cofnąć, a dopiero potem zadawać pytania, często oznacza zniszczyć najprostszą drogę do ustalenia, które skutki wydostały się poza system.

Snapshot może być szerszy niż commit Git, ale obowiązuje ta sama zasada. Umowa snapshotu musi dokładnie określać, jakie zasoby obejmuje. Jeśli obejmuje kod i konfigurację, nazwij go mechanizmem odzyskiwania kodu i konfiguracji. Nie przedstawiaj go jako uniwersalnego cofania za pomocą życzeniowego opisu w interfejsie.

Odzyskiwanie bazy danych ma węższe zadanie, niż ludzie zakładają

Odzyskiwanie bazy danych przywraca stan bazy, a nie rzeczywistość biznesową u wszystkich uczestników transakcji. Transakcja może być atomowa w jednej bazie, gdy otaczająca operacja pozostaje podzielona między kilka systemów.

Rozważ taką sekwencję:

1. Agent dodaje wiersz faktury.
2. Wywołuje API płatności.
3. Operator akceptuje obciążenie.
4. Commit bazy danych kończy się błędem.

Lokalny rollback usuwa wiersz faktury. Obciążenie nadal istnieje. Ponowienie całej operacji bez uzgodnienia stanu może ponownie obciążyć klienta. To klasyczna awaria podwójnego zapisu: aplikacja próbowała uczynić jedno działanie biznesowe atomowym w systemach, które nie współdzielą koordynatora transakcji.

Odwrócenie kolejności nie rozwiązuje problemu. Jeśli aplikacja najpierw zatwierdzi fakturę, a potem wywołanie płatności się nie powiedzie, baza zawiera nieopłaconą fakturę. Ten stan łatwiej sprawdzić, lecz aplikacja nadal potrzebuje maszyny stanów rozróżniającej payment_pending, payment_confirmed, payment_failed i payment_unknown.

Dokumentacja PostgreSQL wyjaśnia odzyskiwanie do punktu w czasie jako przywrócenie bazowej kopii zapasowej i odtworzenie rekordów write ahead log do wybranego celu odzyskiwania. To procedura operatora służąca do odzyskania klastra bazy danych. Nie jest selektywnym cofnięciem jednego uruchomienia agenta i nie może poprosić operatora płatności ani usługi pocztowej o powrót do tego samego znacznika czasu.

Cofnięcie bazy może stworzyć drugą niespójność. Wyobraź sobie przywrócenie stanu do 10:00 po awarii. Dostawca akceptował żądania do 10:07, lecz przywrócona baza nie zawiera już ich rekordów. Agenci, którzy widzą „brakujące” wiersze, mogą odtworzyć wszystkie siedem minut pracy. Dlatego odzyskiwanie wymaga fazy zewnętrznego uzgodnienia przed wznowieniem workerów.

Wzorzec outbox ogranicza jedną niebezpieczną lukę. Aplikacja zatwierdza zmianę biznesową i intencję skutku w tej samej lokalnej transakcji:

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;

Worker później przejmuje eff_7f31, wywołuje dostawcę ze stabilną wartością idempotencji i zapisuje wynik. Outbox nie czyni wywołania zewnętrznego atomowym. Dostarcza trwały dowód, że praca była zamierzona, dzięki czemu możliwe są ponowienia i uzgodnienie.

Działania zewnętrzne potrzebują kompensacji, a niektóre jej nie mają

Zewnętrzny skutek uboczny potrzebuje kompensacji zależnej od dostawcy albo jasnego stwierdzenia, że sensowna kompensacja nie istnieje. Traktowanie każdego działania jako odwracalnego jest gorsze od przyznania, że niektóre działania wymagają zatwierdzenia.

E-mail to najprostszy przykład. Zanim dostawca przyjmie wiadomość, aplikacja może anulować zadanie w kolejce. Po przyjęciu dostawca może umożliwić anulowanie przez krótki wewnętrzny etap, lecz nie istnieje ogólna gwarancja odwołania u wszystkich odbiorców i systemów pocztowych. Po dostarczeniu druga wiadomość może skorygować zapis, ale nie usunie pierwszej. Wrażliwe dane, zawiadomienia prawne i szkoda reputacyjna pozostają ujawnione.

Płatności mają kilka stanów, które zespoły często zbijają w jedno „obciążono”. Autoryzacja rezerwuje możliwość wydania środków. Capture zleca przepływ środków w ramach tej autoryzacji. Void może zwolnić autoryzację, która nie została rozliczona. Refund tworzy późniejszy zapis finansowy zwracający pieniądze po capture. Te operacje różnią się terminem, opłatami, uprawnieniami i wpływem na klienta. Ogólne narzędzie undo_payment ukrywa informacje, których agent potrzebuje, by działać bezpiecznie.

Inne API współpracują jeszcze mniej. Żądanie może zamawiać zapasy, udostępniać infrastrukturę, publikować treść, nadawać dostęp, wysyłać paczkę lub uruchamiać pracę człowieka. Endpoint DELETE nie dowodzi odwracalności. Usunięcie zasobu może pozostawić logi audytowe, skopiowane dane, powiadomienia, zależne zasoby albo fizyczne skutki.

Klasyfikuj kompensację według tego, co może uczciwie osiągnąć:

• Dokładna lokalna operacja odwrotna przywraca kontrolowany stan do wcześniejszej wartości.
• Anulowanie u dostawcy zatrzymuje pracę, która nie została ukończona.
• Kompensacja finansowa tworzy zwrot lub uznanie.
• Komunikat korygujący przyznaje, że pierwsza wiadomość pozostaje widoczna.
• Ręczne usunięcie skutków obsługuje działania, których kontekst nie mieści się w bezpiecznej regule automatycznej.

Kompensacja również może się nie powieść. Endpoint zwrotu może przekroczyć limit czasu. Okno anulowania może się zamknąć. Adres odbiorcy może odrzucić korektę. Konto używane przez agenta może nie mieć uprawnień. Dlatego system musi śledzić kompensację jako kolejną operację, z własnym identyfikatorem intencji, statusem, próbami, dowodami i polityką zatwierdzania.

Nie buduj rekurencyjnej funkcji „cofnij cofnięcie”. Modeluj historię jako księgę działań. Jeśli kompensacja wywoła nowy błąd, wydaj kolejne jawne działanie po sprawdzeniu bieżącego stanu. Historia będzie dłuższa, ale pozostanie zrozumiała podczas incydentu.

Idempotencja zatrzymuje powtórzenia, lecz nie odwraca sukcesu

Idempotencja chroni przed tym, by ponowienia tworzyły zduplikowane zamierzone skutki, nie cofa jednak pierwszego udanego skutku. Zespoły regularnie zacierają tę różnicę, a potem odkrywają ją po timeoutcie.

RFC 9110 definiuje idempotentną metodę żądania przez zamierzony skutek kilku identycznych żądań, taki sam jak jednego żądania. Wskazuje PUT, DELETE i metody bezpieczne jako idempotentne na poziomie semantyki protokołu. POST zasadniczo nie jest idempotentny, choć API może dodać takie zachowanie w ramach własnej umowy.

To zastrzeżenie ma znaczenie. Idempotentne DELETE może nadal za każdym razem utworzyć nowy wpis logu, metrykę lub odpowiedź. Implementacja idempotencji dostawcy może też wygasać rekordy, ograniczać identyfikatory do jednego konta, odrzucać zmienione parametry albo przechowywać w cache tylko wybrane wyniki. Czytaj umowę dostawcy, zamiast wyciągać gwarancje z czasownika HTTP.

Każda intencja skutku powinna otrzymać jedną stabilną wartość idempotencji przed pierwszą próbą. Ponowienia tej samej intencji używają jej ponownie. Nowa intencja biznesowa dostaje nową wartość. Nigdy nie wyprowadzaj jej wyłącznie ze zmiennych parametrów, takich jak klient, kwota i data, ponieważ dwa prawidłowe zakupy mogą mieć te same wartości.

Timeout oznacza nieznany wynik, a nie porażkę. Zastosuj tę sekwencję:

1. Oznacz próbę jako outcome_unknown, nie twórz zastępczej intencji.
2. Zapytaj dostawcę za pomocą wartości idempotencji lub referencji operacji.
3. Jeśli dostawca potwierdzi sukces, zapisz go lokalnie.
4. Jeśli potwierdzi brak operacji, ponów próbę z tą samą wartością.
5. Jeśli nie potrafi odpowiedzieć, wstrzymaj operację do uzgodnienia lub przeglądu przez człowieka.

Taki format odpowiedzi daje agentowi dość informacji, by odróżnić przyjęcie od niepewności transportowej:

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

Wartość idempotencji powinna przechodzić przez logi, komunikaty kolejki, nagłówki API i metadane dostawcy, jeśli są obsługiwane. Jeśli operatorzy nie potrafią wyszukać jej po obu stronach granicy, podczas odzyskiwania będą zgadywać.

Zatwierdzenie należy do granicy skutku

Zatwierdzenie musi nastąpić po tym, jak agent utworzy dokładne działanie zewnętrzne, i przed wysłaniem z systemu pierwszego nieodwracalnego żądania. Zatwierdzenie na początku szerokiego zadania daje agentowi zbyt dużo swobody późniejszej zmiany odbiorców, kwot, zakresów lub narzędzi.

„Obsłuż konto tego klienta” nie wystarcza jako zgoda na obciążenie karty czy wysłanie e-maila do każdego użytkownika. Ważne zatwierdzenie opisuje konkretną operację: odbiorcę, kwotę i walutę, skrót wiadomości lub payloadu, konto docelowe, narzędzie, termin wygaśnięcia i dozwoloną liczbę prób. Jeśli zmieni się dowolne zatwierdzone pole, zatwierdzenie przestaje pasować.

Przydatna polityka porządkuje skutki według konsekwencji, a nie według tego, który agent lub model o nie poprosił. Dostęp do odczytu może nadal ujawniać prywatne dane, ale nie stwarza takiego samego problemu odzyskiwania jak działanie wychodzące. Szkic e-maila jest lokalny i odwracalny. Jego wysłanie przekracza granicę. Utworzenie propozycji płatności jest lokalne. Pobranie środków przekracza granicę.

Wymagaj jawnego zatwierdzenia dla działań, które:

• Przenoszą pieniądze lub tworzą zobowiązanie finansowe
• Wysyłają informacje do osoby albo organizacji zewnętrznej
• Publikują, usuwają lub ujawniają dane poza kontrolowanym magazynem
• Zmieniają tożsamość, dostęp, własność lub ustawienia bezpieczeństwa
• Uruchamiają pracę fizyczną albo inny proces, którego nie da się wiarygodnie odwołać

Działania o niewielkich skutkach, wykonywane wielokrotnie, mogą korzystać z ograniczonego stałego zatwierdzenia. Granica powinna określać maksymalną kwotę, zestaw odbiorców, dozwolone narzędzie, czas wygaśnięcia, tempo i łączną liczbę operacji. „Zatwierdzono dla rozliczeń” nie ma egzekwowalnej granicy.

Zatwierdzenie potrzebuje także ochrony przed ponownym użyciem. Powiąż je z niezmiennym skrótem operacji i oznacz jako wykorzystane, gdy polityka dopuszcza tylko jedno wykonanie. Jeśli wykonanie zwróci nieznany wynik, nie proś o nowe zatwierdzenie ani nie twórz drugiej intencji. Najpierw uzgodnij zatwierdzoną intencję.

Ekran zatwierdzania powinien prostym językiem określać prawdę o odzyskiwaniu. „Tej wiadomości nie można odwołać po dostarczeniu” jest użyteczne. „Ta operacja jest odwracalna” wprowadza w błąd, gdy faktyczne odzyskanie polega na zwrocie, który może potrwać i pozostać na wyciągach finansowych.

Kontrakty narzędzi powinny pokazywać pełny cykl życia skutku

Kontrakt narzędzia agenta powinien opisywać intencję, wykonanie, obserwację i kompensację jako osobne operacje. Jedna funkcja, która wywołuje skutek i zwraca success: true, zostawia zbyt mało dowodów na potrzeby ponowień, zatwierdzeń lub reakcji na incydent.

Poniższy fragment polityki jest dość mały, by go egzekwować, i dość konkretny, by go oceniać:

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 mówi planerowi, która klasa odzyskiwania ma zastosowanie. approval blokuje wykonanie, dopóki dokładne argumenty nie zostaną zatwierdzone. Pole idempotencji sprawia, że ponowienia korzystają z jednej tożsamości. Pole dowodowe wskazuje operatorom, co musi przetrwać. Pole kompensacji wskazuje osobne narzędzie, zamiast udawać, że pierwotne wywołanie może zostać uruchomione wstecz.

Wykonanie powinno przyjmować niezmienną kopertę:

{
  "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"
  }
}

Wykonawca oblicza skrót operacji, porównuje go z scope_hash, sprawdza wygaśnięcie, rezerwuje intencję i dopiero wtedy kontaktuje się z dostawcą. Zapisuje metadane żądania przed wywołaniem, a odpowiedź po nim. Jeśli ulegnie awarii między tymi zapisami, trwała intencja pozostanie dostępna do uzgodnienia.

Wykonawca powinien odrzucać bez improwizowania cztery warunki: zmienione argumenty, wygasłe zatwierdzenie, użycie intencji ponownie dla innej operacji oraz próbę kompensacji skutku, którego pomyślnego zakończenia nie potwierdzono. Agenci dobrze znajdują pozornie wiarygodne dalsze kroki. Kontrole finansowe i komunikacyjne muszą przedkładać widoczne zatrzymanie nad wiarygodne zgadywanie.

Daj obserwacji osobne narzędzie, na przykład get_payment_status(intent_id). Obserwacja nie powinna tworzyć skutku. To rozdzielenie pozwala agentowi wyjaśnić niejednoznaczne wyniki bez otrzymania zgody na ponowienie pierwotnego działania.

Jedno nieudane uruchomienie może przekroczyć każdą granicę odzyskiwania

Pojedyncze uruchomienie agenta może pozostawić kod, rekordy bazy danych i systemy zewnętrzne w różnych momentach czasu. Przejście przez taką awarię przed startem ujawnia luki, które ukrywa ogólna kontrola rollbacku.

Załóżmy, że agent tworzy aplikację członkowską, wdraża zmianę, importuje listę klientów, pobiera opłaty roczne i wysyła powitalne e-maile. Zadanie brzmi spójnie, ale przekracza co najmniej cztery granice odzyskiwania.

O 14:00 agent wdraża kod, który oblicza roczną opłatę na podstawie niewłaściwej kolumny. O 14:02 zapisuje w bazie 40 intencji płatności i szkiców e-maili. O 14:03 worker pobiera kilka płatności. O 14:04 dostawca poczty przyjmuje wiadomości powitalne z błędną opłatą. O 14:05 monitoring zatrzymuje workera. Część wywołań płatności przekroczyła limit czasu po dotarciu do operatora, więc lokalny status nie wskazuje, czy się powiodły.

Przywrócenie snapshotu kodu z 13:59 zatrzymuje błędne obliczenie w przyszłych uruchomieniach. Nie zmienia opłaty skopiowanej do istniejących intencji. Revert commitu Git dokumentuje korektę kodu źródłowego, ale ma tę samą granicę.

Przywrócenie bazy danych do 13:59 usunęłoby lokalne rekordy intencji zawierające referencje dostawcy i wartości idempotencji. Pogorszyłoby to zewnętrzną niespójność. Lepszym działaniem na bazie jest korekta logiczna: zachowaj intencje, oznacz niepewne operacje do uzgodnienia i poprawiaj wiersze dopiero po dopasowaniu stanu dostawcy.

Zespół reagujący powinien następnie postępować według klasy skutku. Pyta o każdą niepewną płatność za pomocą jej stabilnej tożsamości operacji. Potwierdzone pobrania trafiają do przeglądu zwrotów, nieudane próby zostają zamknięte bez ponawiania, a nierozstrzygnięte próby pozostają zablokowane. Dostarczone e-maile otrzymują starannie zatwierdzoną korektę. Wiadomości w kolejce, które nie dotarły do dostawcy, są anulowane. Każda kompensacja dostaje nową intencję połączoną z pierwotną.

Ten przykład pokazuje też, dlaczego automatyczna kompensacja bywa niebezpieczna. Gdy system natychmiast zwróci każdą lokalną pozycję payment_unknown, może wydać zwroty za obciążenia, które nigdy nie istniały, albo wywołać endpoint zwrotu z błędną referencją. Jeśli po odzyskaniu bazy wyśle ponownie każdy brakujący e-mail, odbiorcy mogą dostać duplikaty. Uzgodnienie musi poprzedzać kompensację zawsze, gdy stan lokalny i stan dostawcy się różnią.

Uruchomienie jest zakończone dopiero wtedy, gdy każda intencja osiągnie stan końcowy, taki jak succeeded, confirmed_failed, compensated lub manual_exception. „Aplikacja została cofnięta” opisuje tylko pierwszą część incydentu.

Odzyskiwanie działa tylko wtedy, gdy dowody przetrwają

Kontrole odzyskiwania zawodzą, gdy rollback usuwa rekordy potrzebne do ustalenia, co się stało. Przechowuj księgę skutków tylko do dopisywania, poza stanem aplikacji, który rutynowe snapshoty lub przywracanie mogą zastąpić, i zachowuj wystarczające dowody od dostawcy, by uzgodnić każdą operację.

Księga powinna zapisywać utworzenie intencji, skrót argumentów, zatwierdzenie, dzierżawę wykonania, próbę, wynik transportu, referencję dostawcy, zaobserwowany stan dostawcy i połączenia kompensacji. Ogranicz zmiany do przejść stanów, zamiast pozwalać agentom nadpisywać stare wpisy. Korekty powinny dodawać zdarzenia, a nie edytować historię.

Monitoruj stany nierozstrzygnięte, nie tylko jawne błędy. outcome_unknown, który trwa dziesięć minut, może być groźniejszy niż jednoznaczne odrzucenie, ponieważ operator może ponowić go ręcznie. Alarmuj także, gdy zatwierdzenie wygasa w trakcie wykonania, wartość idempotencji pojawia się z innym skrótem argumentów albo kompensacja się nie powiedzie.

Prowadź ćwiczenia odzyskiwania z celowo niewygodnymi punktami awarii. Zatrzymaj workera po tym, jak dostawca przyjmie żądanie, ale przed lokalnym zapisem sukcesu. Przywróć dane aplikacji z wcześniejszego snapshotu, zachowując księgę skutków. Pozwól zatwierdzeniu wygasnąć między planowaniem a wykonaniem. Unieruchom API obserwacji. Ćwiczenie jest zaliczone, gdy system zatrzymuje się, uzgadnia stan i pokazuje nierozstrzygniętą decyzję bez powielania skutku.

Korzystając z Koder.ai, traktuj jego snapshoty i rollback jako warstwę odzyskiwania aplikacji, a następnie zaprojektuj osobne kontrole dla historii bazy danych i każdego działania zewnętrznego, które aplikacja może uruchomić. Eksport kodu źródłowego, kontrole wdrożeń i rollback pomagają przywrócić oprogramowanie, a kontrakty narzędzi aplikacji nadal odpowiadają za zatwierdzanie i kompensację.

Przycisk rollbacku powinien wskazywać obok swoją granicę: kod, konfigurację, zarządzane dane albo skutki zewnętrzne. Jeśli interfejs nie potrafi ująć tego zdania precyzyjnie, nie powinien obiecywać rollbacku. Uczciwa kontrola może wyglądać mniej magicznie, ale daje zespołowi reagującemu na incydent to, czego potrzebuje o drugiej w nocy: wiarygodny opis tego, co się zmieniło, co wydostało się poza system i które następne działanie jest bezpieczne.