Rollback otomatis untuk dampak samping agen

Rollback agen dapat memulihkan kode, konfigurasi, atau data aplikasi tertentu. Namun, tindakan itu tidak dapat membuat organisasi lain melupakan permintaan, menarik email yang sudah terkirim dari kotak masuk, atau berpura-pura bahwa tagihan kartu tidak pernah sampai ke pemroses pembayaran. Tim yang menyebut semua operasi ini sebagai "rollback" membangun kontrol yang terasa menenangkan, tetapi gagal saat dampaknya benar-benar penting.

Desain yang aman memisahkan empat mekanisme: snapshot aplikasi, Git revert, pemulihan database, dan tindakan kompensasi. Masing-masing memiliki batas yang berbeda. Setiap tindakan yang melintasi batas aplikasi memerlukan persetujuan, bukti, aturan percobaan ulang, dan jalur pemulihan sendiri sebelum agen menjalankannya. Jika tidak ada yang dapat menjelaskan jalur tersebut dalam satu kalimat, tindakan itu belum siap dijalankan tanpa pengawasan.

Rollback memiliki empat makna yang berbeda

Rollback hanya berguna saat tim menyebutkan keadaan yang akan dipulihkan dan keadaan yang tidak dapat disentuhnya. Kata ini biasanya menyembunyikan empat mekanisme dengan jaminan yang sangat berbeda.

Snapshot memulihkan versi aplikasi atau workspace yang telah ditangkap. Bergantung pada produknya, snapshot tersebut dapat mencakup kode yang dibuat, konfigurasi, dan state terkelola tertentu. Snapshot tidak menjelaskan layanan di luar sistem kecuali kontraknya secara eksplisit mencakup layanan tersebut.

Git revert mencatat commit baru yang perubahannya membalikkan commit sebelumnya. Tindakan ini memperbaiki riwayat sumber tanpa menghapus riwayat itu. Git tidak menghubungi layanan yang dipanggil kode lama saat kode itu berjalan.

Pemulihan database mengubah catatan yang disimpan database. Rollback transaksi membuang penulisan yang belum di-commit dalam satu transaksi. Memulihkan backup atau memakai point-in-time recovery adalah operasi yang jauh lebih besar, yang mengembalikan cluster database mendekati keadaan sebelumnya. Keduanya tidak otomatis merekonsiliasi sistem di luar database tersebut.

Tindakan kompensasi menciptakan dampak baru untuk mengimbangi dampak lama. Refund mengompensasi pembayaran yang telah ditangkap. Permintaan pembatalan mengompensasi pesanan. Email koreksi dapat mengurangi dampak email yang keliru, tetapi tidak dapat menghapus pesan pertama. Kompensasi mempertahankan kenyataan yang tidak nyaman bahwa tindakan awal memang terjadi.

Saya memakai tabel kepemilikan dampak saat peninjauan desain karena tabel ini memaksa jawaban yang tepat:

Kolom terakhir paling penting. Operasi kebalikan bukan bukti bahwa dampak awal telah hilang. Catatan audit, salinan penerima, entri penyelesaian, webhook, dan pekerjaan fisik mungkin tetap ada.

Revert kode mengubah program, bukan masa lalu

Revert kode mencegah atau mengubah perilaku di masa depan, bukan membalikkan perilaku yang sudah ditimbulkan versi lama. Hal ini tetap berlaku, baik tim memakai Git, snapshot platform, maupun rollback deployment.

Dokumentasi Git menjelaskan git revert sebagai tindakan yang merekam commit untuk membalikkan perubahan yang diperkenalkan oleh commit sebelumnya. Frasa itu tepat: Git menerapkan patch kebalikan pada isi repositori. Git tidak mengetahui email, pembayaran, sumber daya cloud, tiket dukungan, atau API mitra yang dibuat saat commit yang dibalik itu berjalan.

Misalkan agen mengubah fungsi penagihan, men-deploy-nya, lalu memanggilnya dua kali sebelum pemantauan menemukan cacatnya. Membalikkan commit dapat menghentikan fungsi yang salah agar tidak berjalan lagi. Namun, dua percobaan pembayaran tetap ada di pemroses. Jika database lokal hanya mencatat satu percobaan, revert bahkan dapat mempersulit penyelidikan dengan menghapus jalur kode yang memahami respons kedua.

Rollback deployment memiliki batas yang sama. Mengarahkan lalu lintas kembali ke build sebelumnya memulihkan perilaku yang dapat dijalankan. Permintaan yang sudah diterima build yang diganti tetap membawa konsekuensinya. Pekerjaan antrean juga dapat bertahan setelah deployment dan menjalankan asumsi lama terhadap versi yang dipulihkan.

Sebelum melakukan revert, simpan bukti operasional yang dihasilkan build lama:

• Identitas deployment dan commit sumber
• Identitas proses dan intent agen
• Identitas pesan antrean dan status lease
• Identitas permintaan eksternal
• Respons penyedia dan timestamp

Setelah itu, hentikan eksekusi baru, rekonsiliasi operasi yang belum selesai, lalu pulihkan kode. Melakukan revert lebih dulu dan baru bertanya kemudian sering menghapus cara termudah untuk memahami dampak mana yang sudah keluar dari sistem.

Snapshot dapat mencakup lebih luas daripada Git commit, tetapi aturan yang sama tetap berlaku. Kontrak snapshot harus menyebutkan dengan tepat sumber daya yang dicakupnya. Jika snapshot mencakup kode dan konfigurasi, sebut sebagai mekanisme pemulihan kode dan konfigurasi. Jangan mengubahnya menjadi tombol batal universal lewat kata-kata penuh harapan di antarmuka.

Pemulihan database lebih sempit daripada yang sering diasumsikan

Pemulihan database memulihkan state database, bukan kenyataan bisnis di setiap pihak dalam transaksi. Sebuah transaksi dapat bersifat atomik di dalam satu database, sementara operasi di sekitarnya tetap terpecah di beberapa sistem.

Pertimbangkan urutan berikut:

1. Agen memasukkan baris invoice.
2. Agen memanggil API pembayaran.
3. Pemroses menerima tagihan.
4. Commit database gagal.

Rollback lokal menghapus baris invoice. Tagihan tetap ada. Mengulangi seluruh operasi tanpa rekonsiliasi dapat menagih pelanggan lagi. Ini adalah kegagalan dual write klasik: aplikasi berusaha membuat satu tindakan bisnis atomik di beberapa sistem yang tidak berbagi koordinator transaksi.

Membalik urutannya tidak menyelesaikan masalah. Jika aplikasi meng-commit invoice terlebih dahulu lalu panggilan pembayaran gagal, database berisi invoice yang belum dibayar. Keadaan ini lebih mudah diperiksa, tetapi aplikasi tetap memerlukan state machine yang membedakan payment_pending, payment_confirmed, payment_failed, dan payment_unknown.

Dokumentasi PostgreSQL menjelaskan point-in-time recovery sebagai pemulihan backup dasar dan pemutaran ulang write ahead log sampai target pemulihan yang dipilih. Ini adalah prosedur operator untuk memulihkan cluster database. Ini bukan pembatalan selektif untuk satu proses agen, dan tidak dapat meminta pemroses pembayaran atau layanan email kembali ke timestamp yang sama.

Mengembalikan database ke masa lalu dapat menciptakan ketidakcocokan kedua. Bayangkan database dipulihkan ke pukul 10.00 setelah gangguan. Penyedia menerima permintaan hingga pukul 10.07, tetapi database yang dipulihkan tidak lagi memuat catatannya. Agen yang melihat baris "hilang" mungkin membuat ulang seluruh pekerjaan selama tujuh menit. Karena itu, pemulihan memerlukan tahap rekonsiliasi eksternal sebelum worker berjalan kembali.

Pola outbox mengurangi satu celah berbahaya. Aplikasi meng-commit perubahan bisnis dan intent dampak dalam transaksi lokal yang sama:

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 kemudian mengambil eff_7f31, memanggil penyedia dengan nilai idempotensi yang stabil, dan mencatat hasilnya. Outbox tidak membuat panggilan eksternal menjadi atomik. Outbox memberi sistem bukti tahan lama bahwa pekerjaan memang dimaksudkan, sehingga percobaan ulang dan rekonsiliasi dapat dilakukan.

Tindakan eksternal memerlukan kompensasi, dan sebagian tidak memilikinya

Dampak samping eksternal memerlukan kompensasi khusus penyedia atau pernyataan eksplisit bahwa tidak ada kompensasi yang bermakna. Menganggap semua tindakan dapat dibalik lebih berbahaya daripada mengakui bahwa sebagian tindakan memerlukan persetujuan.

Email adalah contoh paling sederhana. Sebelum penyedia menerima pesan, aplikasi mungkin dapat membatalkan pekerjaan antrean. Setelah diterima, penyedia mungkin mengizinkan pembatalan pada tahap internal singkat, tetapi tidak ada jaminan penarikan kembali secara umum di seluruh penerima dan sistem email. Setelah terkirim, pesan kedua dapat memperbaiki catatan, bukan menghapus pesan pertama. Data sensitif, pemberitahuan hukum, dan kerugian reputasi tetap terekspos.

Pembayaran memiliki beberapa state yang sering diringkas tim menjadi "tertagih". Otorisasi mencadangkan kapasitas belanja. Capture meminta pemindahan dana berdasarkan otorisasi tersebut. Void dapat melepaskan otorisasi yang belum diselesaikan. Refund menciptakan entri keuangan baru yang mengembalikan uang setelah capture. Operasi ini memiliki waktu, biaya, izin, dan dampak pelanggan yang berbeda. Alat undo_payment yang umum menyembunyikan informasi yang dibutuhkan agen agar dapat bertindak dengan aman.

API lain bahkan kurang kooperatif. Sebuah permintaan dapat memesan inventaris, menyediakan infrastruktur, menerbitkan konten, memberi akses, mengirim paket, atau memicu seseorang untuk mulai bekerja. Endpoint DELETE tidak membuktikan bahwa tindakan itu dapat dibalik. Menghapus sumber daya dapat menyisakan log audit, data yang disalin, notifikasi, sumber daya yang bergantung, atau konsekuensi fisik.

Klasifikasikan kompensasi berdasarkan capaian yang benar-benar dapat dipenuhi:

• Kebalikan lokal yang tepat mengembalikan state terkontrol ke nilai sebelumnya.
• Pembatalan penyedia menghentikan pekerjaan yang belum selesai.
• Kompensasi keuangan membuat refund atau kredit.
• Komunikasi korektif mengakui bahwa pesan pertama tetap terlihat.
• Pemulihan manual menangani dampak yang konteksnya tidak dapat dimasukkan ke aturan otomatis yang aman.

Kompensasi juga dapat gagal. Endpoint refund mungkin timeout. Jendela pembatalan mungkin tertutup. Alamat penerima mungkin menolak koreksi. Akun yang digunakan agen mungkin tidak memiliki izin. Karena itu, sistem harus melacak kompensasi sebagai operasi lain dengan identitas intent, status, percobaan, bukti, dan kebijakan persetujuannya sendiri.

Jangan membangun fitur "rollback atas rollback" yang bersifat rekursif. Modelkan riwayat sebagai ledger tindakan. Jika kompensasi menimbulkan kesalahan baru, lakukan tindakan eksplisit lain setelah meninjau keadaan saat ini. Riwayatnya memang lebih panjang, tetapi tetap mudah dipahami saat insiden terjadi.

Idempotensi menghentikan pengulangan, bukan membalikkan keberhasilan

Idempotensi melindungi percobaan ulang agar tidak menghasilkan dampak yang sama lebih dari sekali. Idempotensi tidak membatalkan dampak pertama yang berhasil. Tim sering mencampurkan kedua konsep ini, lalu baru memahami perbedaannya setelah timeout terjadi.

RFC 9110 mendefinisikan metode permintaan idempoten berdasarkan dampak yang dimaksud dari beberapa permintaan identik yang sama dengan satu permintaan tersebut. RFC ini menyebut PUT, DELETE, dan metode aman sebagai idempoten pada tingkat semantik protokol. POST secara umum tidak idempoten, meskipun API dapat menambahkan perilaku idempotensi melalui kontraknya sendiri.

Batasan ini penting. DELETE yang idempoten tetap dapat menghasilkan entri log, metrik, atau respons baru setiap kali dipanggil. Penerapan idempotensi penyedia juga dapat kedaluwarsa, membatasi identitas ke satu akun, menolak parameter yang berubah, atau menyimpan cache hanya untuk hasil tertentu. Bacalah kontrak penyedia, jangan menyimpulkan jaminan hanya dari kata kerja HTTP.

Setiap intent dampak harus mendapat satu nilai idempotensi yang stabil sebelum percobaan pertama. Percobaan ulang untuk intent yang sama memakai ulang nilai itu. Intent bisnis baru mendapat nilai baru. Jangan membuatnya hanya dari parameter yang dapat berubah seperti pelanggan, jumlah, dan tanggal, karena dua pembelian sah dapat memiliki nilai yang sama.

Timeout menghasilkan outcome yang tidak diketahui, bukan kegagalan. Gunakan urutan ini:

1. Tandai percobaan sebagai outcome_unknown, jangan membuat intent pengganti.
2. Tanyakan penyedia dengan nilai idempotensi atau referensi operasi.
3. Jika penyedia mengonfirmasi keberhasilan, catat keberhasilan itu secara lokal.
4. Jika penyedia mengonfirmasi tidak ada operasi, ulangi dengan nilai yang sama.
5. Jika penyedia tidak dapat menjawab, tahan operasi untuk rekonsiliasi atau peninjauan manusia.

Bentuk respons ini memberi agen informasi yang cukup untuk membedakan penerimaan dari ketidakpastian transport:

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

Nilai idempotensi harus mengalir melalui log, pesan antrean, header API, dan metadata penyedia jika didukung. Jika operator tidak dapat mencarinya di kedua sisi batas sistem, mereka akan menebak saat pemulihan.

Persetujuan berada di batas dampak

Persetujuan harus terjadi setelah agen membentuk tindakan eksternal yang tepat dan sebelum permintaan pertama yang tak dapat dibalik keluar dari sistem. Persetujuan di awal tugas yang luas memberi agen terlalu banyak ruang untuk mengubah penerima, jumlah, cakupan, atau alat di kemudian hari.

"Tangani akun pelanggan ini" bukan persetujuan yang memadai untuk menagih kartu atau mengirim email ke setiap pengguna. Persetujuan yang valid menjelaskan operasi konkret: penerima, jumlah dan mata uang, ringkasan pesan atau payload, akun tujuan, alat, masa berlaku, dan jumlah percobaan yang diizinkan. Jika salah satu bidang yang disetujui berubah, persetujuan itu tidak lagi cocok.

Kebijakan yang baik mengurutkan dampak berdasarkan konsekuensi, bukan berdasarkan agen atau model yang memintanya. Akses baca tetap dapat mengekspos data pribadi, tetapi tidak menimbulkan masalah pemulihan yang sama dengan tindakan keluar. Menyusun draf email bersifat lokal dan dapat dibalik. Mengirimnya melintasi batas sistem. Membuat proposal pembayaran bersifat lokal. Menangkap dana melintasi batas sistem.

Wajibkan persetujuan eksplisit untuk tindakan yang:

• Memindahkan uang atau menciptakan kewajiban keuangan
• Mengirim informasi kepada seseorang atau organisasi luar
• Menerbitkan, menghapus, atau mengungkapkan data di luar penyimpanan terkontrol
• Mengubah identitas, akses, kepemilikan, atau pengaturan keamanan
• Memulai pekerjaan fisik atau proses lain yang tidak dapat ditarik kembali dengan andal

Tindakan berulang dengan dampak rendah dapat memakai persetujuan berkelanjutan yang dibatasi. Batasnya harus menyebut jumlah maksimum, kumpulan penerima, alat yang diizinkan, waktu kedaluwarsa, laju, dan jumlah operasi keseluruhan. "Disetujui untuk penagihan" tidak memiliki batas yang dapat ditegakkan.

Persetujuan juga perlu perlindungan terhadap pemutaran ulang. Ikat persetujuan pada digest operasi yang tidak dapat diubah dan tandai sebagai sudah dipakai saat kebijakan hanya mengizinkan satu eksekusi. Jika eksekusi menghasilkan outcome yang tidak diketahui, jangan meminta persetujuan baru dan membuat intent kedua. Rekonsiliasi intent yang sudah disetujui terlebih dahulu.

Layar persetujuan harus menyatakan kenyataan pemulihan dengan bahasa biasa. "Pesan ini tidak dapat ditarik kembali setelah terkirim" berguna. "Operasi ini dapat dibalik" menyesatkan jika pemulihan sebenarnya berupa refund yang mungkin membutuhkan waktu dan tetap tercatat pada laporan keuangan.

Kontrak alat harus menampilkan seluruh siklus hidup dampak

Kontrak alat agen harus menjelaskan intent, eksekusi, observasi, dan kompensasi sebagai operasi terpisah. Satu fungsi yang menghasilkan dampak lalu mengembalikan success: true menyisakan terlalu sedikit bukti untuk percobaan ulang, persetujuan, atau respons insiden.

Fragmen kebijakan berikut cukup kecil untuk ditegakkan dan cukup spesifik untuk ditinjau:

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 memberi tahu perencana kelas pemulihan yang berlaku. approval memblokir eksekusi sampai argumen yang tepat diotorisasi. Kolom idempotensi membuat percobaan ulang memakai satu identitas. Kolom bukti memberi tahu operator apa yang harus dipertahankan. Kolom kompensasi mengarah ke alat terpisah, bukan berpura-pura panggilan awal dapat dijalankan mundur.

Eksekusi harus menerima envelope yang tidak dapat diubah:

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

Eksekutor menghitung digest operasi, membandingkannya dengan scope_hash, memeriksa masa berlaku, mencadangkan intent, dan baru kemudian menghubungi penyedia. Eksekutor menyimpan metadata permintaan sebelum panggilan dan respons setelahnya. Jika eksekutor berhenti di antara kedua penulisan itu, intent yang tahan lama tetap tersedia untuk rekonsiliasi.

Eksekutor harus menolak empat kondisi tanpa berimprovisasi: argumen berubah, persetujuan kedaluwarsa, intent dipakai ulang untuk operasi lain, dan upaya mengompensasi dampak yang keberhasilannya belum dikonfirmasi. Agen pandai menemukan kelanjutan yang tampak masuk akal. Kontrol keuangan dan komunikasi harus memilih penghentian yang terlihat daripada tebakan yang tampak masuk akal.

Berikan observasi alat tersendiri, seperti get_payment_status(intent_id). Observasi tidak boleh menciptakan dampak. Memisahkannya memungkinkan agen menyelesaikan outcome ambigu tanpa diberi izin mengulangi tindakan awal.

Satu proses gagal dapat melintasi setiap batas pemulihan

Satu proses agen dapat meninggalkan kode, catatan database, dan sistem eksternal pada titik waktu yang berbeda. Menelusuri kegagalan tersebut sebelum peluncuran akan mengungkap celah yang disembunyikan kontrol rollback umum.

Anggap agen membuat aplikasi keanggotaan, men-deploy perubahan, mengimpor daftar pelanggan, menagih biaya tahunan, dan mengirim email selamat datang. Tugas ini terdengar menyatu, tetapi melintasi setidaknya empat batas pemulihan.

Pada pukul 14.00, agen men-deploy kode yang menghitung biaya tahunan dari kolom yang salah. Pada pukul 14.02, agen menulis 40 intent pembayaran dan draf email ke database. Pada pukul 14.03, worker menangkap beberapa pembayaran. Pada pukul 14.04, penyedia email menerima pesan selamat datang yang mencantumkan biaya keliru. Pada pukul 14.05, pemantauan menghentikan worker. Beberapa panggilan pembayaran timeout setelah mencapai pemroses, sehingga status lokal tidak menunjukkan apakah panggilan tersebut berhasil.

Memulihkan snapshot kode pukul 13.59 menghentikan perhitungan yang salah pada proses mendatang. Snapshot itu tidak mengubah biaya yang sudah disalin ke intent yang ada. Membalikkan commit Git mendokumentasikan perbaikan kode, tetapi memiliki batas yang sama.

Memulihkan database ke pukul 13.59 akan menghapus catatan intent lokal yang memuat referensi penyedia dan nilai idempotensi. Hal ini memperburuk ketidakcocokan eksternal. Tindakan database yang lebih baik adalah koreksi logis: pertahankan intent, tandai operasi yang tidak pasti untuk rekonsiliasi, dan koreksi baris hanya setelah state penyedia cocok.

Tim respons kemudian harus bertindak berdasarkan kelas dampak. Tim menanyakan setiap pembayaran yang tidak pasti menggunakan identitas operasi yang stabil. Capture yang dikonfirmasi masuk ke peninjauan refund, percobaan gagal ditutup tanpa diulang, dan percobaan yang belum terselesaikan tetap diblokir. Email yang telah terkirim menerima koreksi yang disetujui dengan cermat. Pesan antrean yang belum mencapai penyedia dibatalkan. Setiap kompensasi mendapat intent baru yang ditautkan ke tindakan awal.

Contoh ini juga menunjukkan mengapa kompensasi otomatis dapat berbahaya. Jika sistem langsung melakukan refund atas setiap catatan lokal payment_unknown, sistem mungkin menerbitkan refund untuk tagihan yang tidak pernah ada atau memanggil endpoint refund dengan referensi yang salah. Jika sistem mengirim ulang setiap email yang hilang setelah pemulihan database, penerima dapat menerima duplikat. Rekonsiliasi harus mendahului kompensasi setiap kali state lokal dan state penyedia tidak cocok.

Proses selesai hanya saat setiap intent mencapai state akhir seperti succeeded, confirmed_failed, compensated, atau manual_exception. "Aplikasi telah di-rollback" hanya menjelaskan bagian pertama dari insiden.

Pemulihan hanya berhasil jika buktinya tetap ada

Kontrol pemulihan gagal saat rollback menghapus catatan yang diperlukan untuk menentukan apa yang terjadi. Simpan ledger dampak append-only di luar state aplikasi yang dapat digantikan oleh snapshot atau pemulihan rutin, dan pertahankan cukup bukti dari penyedia untuk merekonsiliasi setiap operasi.

Ledger harus mencatat pembuatan intent, digest argumen, persetujuan, lease eksekusi, percobaan, hasil transport, referensi penyedia, state penyedia yang diamati, dan tautan kompensasi. Batasi perubahan pada transisi state, jangan izinkan agen menimpa entri lama. Koreksi harus menambahkan peristiwa, bukan mengedit riwayat.

Pantau state yang belum terselesaikan, bukan hanya kesalahan eksplisit. outcome_unknown yang bertahan selama sepuluh menit dapat lebih berbahaya daripada penolakan yang jelas karena operator mungkin mengulanginya secara manual. Beri peringatan juga saat persetujuan kedaluwarsa selama eksekusi, nilai idempotensi muncul dengan digest argumen berbeda, atau kompensasi gagal.

Lakukan latihan pemulihan dengan titik kegagalan yang sengaja dibuat sulit. Hentikan worker setelah penyedia menerima permintaan tetapi sebelum penulisan keberhasilan lokal. Pulihkan data aplikasi dari snapshot sebelumnya sambil mempertahankan ledger dampak. Biarkan persetujuan kedaluwarsa di antara perencanaan dan eksekusi. Buat API observasi tidak tersedia. Latihan dinyatakan berhasil saat sistem berhenti, melakukan rekonsiliasi, dan menampilkan keputusan yang belum terselesaikan tanpa menduplikasi dampak.

Saat memakai Koder.ai, perlakukan snapshot dan rollback-nya sebagai lapisan pemulihan aplikasi, lalu rancang kontrol terpisah untuk riwayat database dan setiap tindakan eksternal yang dapat dipicu aplikasi. Ekspor sumber, kontrol deployment, dan rollback membantu memulihkan perangkat lunak, sementara kontrak alat aplikasi tetap menangani persetujuan dan kompensasi.

Tombol rollback harus menyebutkan batasnya di samping tombol: kode, konfigurasi, data terkelola, atau dampak eksternal. Jika antarmuka tidak dapat membuat kalimat itu tepat, antarmuka tersebut tidak boleh menjanjikan rollback. Kontrol yang jujur mungkin tampak kurang ajaib, tetapi memberi tim insiden satu hal yang mereka butuhkan pada pukul 02.00: penjelasan tepercaya tentang apa yang berubah, apa yang sudah keluar dari sistem, dan tindakan mana yang aman dilakukan selanjutnya.