Ajan yan etkileri için otomatik geri alma

Bir ajanın geri alma işlemi kodu, yapılandırmayı veya seçilmiş uygulama verilerini geri yükleyebilir. Başka bir kurumun bir isteği unutmasını sağlayamaz, teslim edilmiş bir e-postayı gelen kutusundan geri çekemez ya da kart tahsilatının ödeme işlemcisine hiç ulaşmamış gibi davranamaz. Tüm bu işlemlere “geri alma” adını veren ekipler, sonuçların önem kazandığı anda başarısız olan, rahatlatıcı bir denetim mekanizması kurar.

Güvenli tasarım dört mekanizmayı ayırır: uygulama anlık görüntüleri, Git reverts, veritabanı kurtarma ve telafi edici eylemler. Her birinin farklı bir sınırı vardır. Uygulama sınırını aşan her eylem, ajan onu yürütmeden önce kendi onayına, kanıtına, yeniden deneme kuralına ve kurtarma yoluna ihtiyaç duyar. Kimse bu yolu tek cümlede anlatamıyorsa, eylem gözetimsiz yürütmeye hazır değildir.

Geri almanın dört ayrı anlamı vardır

Geri alma, ekip hangi durumu geri yükleyeceğini ve hangi duruma dokunamayacağını açıkça adlandırdığında yararlıdır. Bu kelime genellikle birbirinden çok farklı güvenceler sunan dört mekanizmayı gizler.

Anlık görüntü, uygulamanın veya çalışma alanının kaydedilmiş bir sürümünü geri yükler. Ürüne bağlı olarak bu anlık görüntü oluşturulmuş kodu, yapılandırmayı ve seçilmiş yönetilen durumu içerebilir. Anlık görüntü sözleşmesi bunları açıkça kapsamıyorsa dış hizmetler hakkında hiçbir şey söylemez.

Git revert, önceki bir commit'teki değişiklikleri tersine çeviren yeni bir commit kaydeder. Geçmişi silmeden kaynak geçmişini onarır. Eski kod çalışırken çağırdığı hizmetlerle iletişim kurmaz.

Veritabanı kurtarma, veritabanında tutulan kayıtları değiştirir. İşlem geri alma, tek bir işlemde commit edilmemiş yazmaları atar. Yedek geri yükleme veya zaman içindeki bir noktaya kurtarma ise veritabanı kümesini daha önceki bir duruma taşıyan çok daha büyük bir işlemdir. Bu işlemlerin hiçbiri, o veritabanının dışındaki sistemleri otomatik olarak uzlaştırmaz.

Telafi edici eylem, eski bir etkiyi dengelemeyi amaçlayan yeni bir etki oluşturur. İade, tahsil edilmiş bir ödemeyi telafi eder. İptal isteği bir siparişi telafi eder. Düzeltici e-posta hatalı bir e-postanın etkisini azaltabilir, ancak ilk iletiyi ortadan kaldıramaz. Telafi, ilk eylemin gerçekleştiği yönündeki rahatsız edici gerçeği korur.

Tasarım incelemelerinde etki sahipliği tablosu kullanıyorum; çünkü kesin yanıtlar vermeyi zorunlu kılıyor:

Son sütun en önemlisidir. Ters işlem, ilk işlemin ortadan kalktığının kanıtı değildir. Denetim kayıtları, alıcı kopyaları, mutabakat kayıtları, webhooks ve fiziksel iş kalıcı olabilir.

Kod revert işlemi programı değiştirir, geçmişi değil

Kod revert işlemi gelecekteki davranışı önler veya değiştirir; eski sürümün daha önce sebep olduğu davranışı tersine çevirmez. Ekip Git, platform anlık görüntüsü veya dağıtım geri alma kullansa da bu değişmez.

Git belgeleri, git revert komutunu önceki commit'lerin getirdiği değişiklikleri tersine çeviren commit'ler kaydetmek olarak açıklar. Bu ifade tam olarak doğrudur: Git, depo içeriğine ters yama uygular. Git'in, geri alınan commit çalışırken oluşturulan e-postalar, ödemeler, bulut kaynakları, destek kayıtları veya iş ortağı API'leri hakkında bilgisi yoktur.

Bir ajanın faturalama işlevini değiştirdiğini, bunu dağıttığını ve izleme hatayı fark etmeden önce iki kez çağırdığını düşünün. Commit'i geri almak, hatalı işlevin yeniden çalışmasını durdurabilir. Ödeme işlemcisindeki iki ödeme girişimini ise bırakır. Yerel veritabanı yalnızca bir girişim kaydettiyse, revert ikinci yanıtı anlayan kod yolunu kaldırarak incelemeyi daha da zorlaştırabilir.

Dağıtım geri almanın da aynı sınırı vardır. Trafiği önceki bir derlemeye yönlendirmek yürütülebilir davranışı geri yükler. Değiştirilen derlemenin daha önce kabul ettiği istekler sonuçlarını korur. Kuyruktaki işler de dağıtımdan sağ çıkabilir ve geri yüklenen sürümde eski varsayımlarla çalışabilir.

Geri almadan önce, eski derlemenin ürettiği operasyonel kanıtları koruyun:

• Dağıtım tanımlayıcısı ve kaynak commit
• Ajan çalıştırma ve niyet tanımlayıcıları
• Kuyruk mesajı tanımlayıcıları ve kiralama durumu
• Dış istek tanımlayıcıları
• Sağlayıcı yanıtları ve zaman damgaları

Ardından yeni yürütmeyi durdurun, tamamlanmamış işlemleri uzlaştırın ve kodu geri yükleyin. Önce geri alıp sonra soru sormak, hangi etkilerin dışarı çıktığını anlamanın en kolay yolunu sık sık yok eder.

Anlık görüntü bir Git commit'inden daha kapsamlı olabilir, ancak aynı kural geçerlidir. Anlık görüntü sözleşmesi hangi kaynakları içerdiğini tam olarak belirtmelidir. Kod ve yapılandırma içeriyorsa, buna kod ve yapılandırma kurtarma mekanizması deyin. Arayüzdeki umutlu ifadelerle bunu evrensel geri alma aracına dönüştürmeyin.

Veritabanı kurtarmanın görevi insanların sandığından daha dardır

Veritabanı kurtarma, her işlem katılımcısı arasındaki iş gerçekliğini değil, veritabanı durumunu geri yükler. Bir işlem tek veritabanı içinde atomik olabilirken çevresindeki operasyon birkaç sisteme bölünmüş halde kalabilir.

Şu sırayı ele alın:

1. Ajan bir fatura satırı ekler.
2. Bir ödeme API'sini çağırır.
3. İşlemci tahsilatı kabul eder.
4. Veritabanı commit işlemi başarısız olur.

Yerel geri alma fatura satırını kaldırır. Tahsilat ise varlığını sürdürür. Uzlaştırma yapmadan tüm işlemi yeniden denemek müşteriden tekrar ödeme alabilir. Bu, klasik çift yazma hatasıdır: uygulama, işlem koordinatörü paylaşmayan sistemler arasında tek bir iş eylemini atomik yapmaya çalışmıştır.

Sırayı tersine çevirmek bunu çözmez. Uygulama önce faturayı commit edip ödeme çağrısı sonrasında başarısız olursa, veritabanında ödenmemiş bir fatura bulunur. Bu durumu incelemek daha kolaydır, ancak uygulamanın yine de payment_pending, payment_confirmed, payment_failed ve payment_unknown durumlarını ayıran bir durum makinesine ihtiyacı vardır.

PostgreSQL belgeleri, zaman içindeki bir noktaya kurtarmayı temel bir yedeği geri yüklemek ve write ahead log kayıtlarını seçilen kurtarma hedefine kadar yeniden oynatmak olarak açıklar. Bu, bir veritabanı kümesini kurtarmaya yönelik operatör prosedürüdür. Tek bir ajan çalıştırması için seçici geri alma değildir ve ödeme işlemcisinden ya da posta hizmetinden aynı zaman damgasına dönmesini isteyemez.

Veritabanını geriye taşımak ikinci bir uyumsuzluk yaratabilir. Kesintiden sonra 10:00'a geri döndüğünüzü düşünün. Bir sağlayıcı 10:07'ye kadar istek kabul etti, fakat geri yüklenen veritabanında artık bu kayıtlar bulunmuyor. “Eksik” satırları gören ajanlar yedi dakikalık işin tamamını yeniden oluşturabilir. Bu nedenle çalışanlar devam etmeden önce kurtarma, dış uzlaştırma aşaması gerektirir.

Outbox deseni tehlikeli bir boşluğu azaltır. Uygulama, iş değişikliğini ve etki niyetini aynı yerel işlem içinde commit eder:

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;

Bir çalışan daha sonra eff_7f31 kaydını alır, sağlayıcıyı sabit bir idempotency değeriyle çağırır ve sonucu kaydeder. Outbox, dış çağrıyı atomik hale getirmez. Sisteme işin amaçlandığına ilişkin kalıcı kanıt verir; bu da yeniden denemeyi ve uzlaştırmayı mümkün kılar.

Dış eylemler telafi gerektirir, bazılarının ise telafisi yoktur

Dış yan etki, sağlayıcıya özgü bir telafiye veya anlamlı bir telafinin bulunmadığını açıkça belirten bir ifadeye ihtiyaç duyar. Her eylemi geri döndürülebilir saymak, bazılarının onay gerektirdiğini kabul etmekten daha kötüdür.

E-posta en basit örnektir. Sağlayıcı iletiyi kabul etmeden önce uygulama kuyruktaki işi iptal edebilir. Kabulden sonra sağlayıcı kısa bir iç aşamada iptale izin verebilir, ancak alıcılar ve posta sistemleri arasında genel bir geri çağırma garantisi yoktur. Teslim edildikten sonra ikinci bir ileti kaydı düzeltebilir, ilk iletiyi silemez. Hassas veriler, hukuki bildirimler ve itibar kaybı ortada kalır.

Ödemelerin ekiplerin çoğu zaman “tahsil edildi” diyerek tek duruma indirdiği birkaç aşaması vardır. Provizyon harcama kapasitesini ayırır. Tahsilat, bu provizyona karşı fon hareketi talep eder. Kesinleşmemiş bir provizyonun serbest bırakılması için iptal kullanılabilir. İade ise tahsilattan sonra parayı geri veren daha sonraki bir finansal kayıt oluşturur. Bu işlemlerin zamanlaması, ücretleri, izinleri ve müşteri üzerindeki etkisi farklıdır. Genel bir undo_payment aracı, ajanın güvenle hareket etmesi için gereken bilgiyi gizler.

Diğer API'ler daha da işbirliksizdir. Bir istek stok sipariş edebilir, altyapı sağlayabilir, içerik yayımlayabilir, erişim verebilir, paket gönderebilir veya bir kişinin işe başlamasını tetikleyebilir. DELETE endpoint'i geri döndürülebilirliği kanıtlamaz. Bir kaynağı silmek; denetim günlüklerini, kopyalanmış verileri, bildirimleri, bağımlı kaynakları veya fiziksel sonuçları geride bırakabilir.

Telafiyi, dürüstçe ne başarabileceğine göre sınıflandırın:

• Tam yerel ters işlem, denetlenen durumu önceki değerine döndürür.
• Sağlayıcı iptali, tamamlanmamış işi durdurur.
• Finansal telafi, iade veya kredi oluşturur.
• Düzeltici iletişim, ilk iletinin görünür kalmasını kabul eder.
• Manuel düzeltme, bağlamı güvenli bir otomatik kurala sığmayan etkileri ele alır.

Telafi de başarısız olabilir. İade endpoint'inde zaman aşımı yaşanabilir. İptal penceresi kapanabilir. Alıcının adresi düzeltmeyi reddedebilir. Ajanın kullandığı hesabın izni olmayabilir. Bu nedenle sistem, telafiyi kendi niyet tanımlayıcısı, durumu, girişimleri, kanıtı ve onay politikası olan ayrı bir işlem olarak izlemelidir.

Özyinelemeli bir “geri almayı geri alma” özelliği oluşturmayın. Geçmişi eylem defteri olarak modelleyin. Telafi yeni bir hataya neden olursa, mevcut durumu gözden geçirdikten sonra başka bir açık eylem gerçekleştirin. Geçmiş uzar, ancak olay sırasında anlaşılabilir kalır.

İdempotency tekrarları önler, başarıyı tersine çevirmez

İdempotency, yeniden denemelerin yinelenen hedef etkiler üretmesini önler; ilk başarılı etkiyi geri almaz. Ekipler bu fikirleri sürekli birbirine karıştırır ve farkı zaman aşımından sonra keşfeder.

RFC 9110, idempotent istek yöntemini, birkaç özdeş isteğin amaçlanan etkisinin tek bir isteğinkiyle aynı olması üzerinden tanımlar. Protokol semantiği düzeyinde PUT, DELETE ve güvenli yöntemleri idempotent olarak tanımlar. POST genel olarak idempotent değildir; ancak bir API kendi sözleşmesiyle idempotency davranışı ekleyebilir.

Bu nitelendirme önemlidir. İdempotent bir DELETE, her seferinde yine yeni bir günlük kaydı, metrik veya yanıt üretebilir. Sağlayıcının idempotency uygulaması kayıtların süresini dolabilir, tanımlayıcıları tek bir hesapla sınırlayabilir, değişen parametreleri reddedebilir veya yalnızca seçili sonuçları önbelleğe alabilir. HTTP fiilinden güvence çıkarmak yerine sağlayıcı sözleşmesini okuyun.

Her etki niyeti, ilk denemesinden önce sabit bir idempotency değeri almalıdır. Aynı niyet için yeniden denemelerde bu değer yeniden kullanılır. Yeni iş niyeti yeni bir değer alır. Bunu yalnızca müşteri, tutar ve tarih gibi değişebilir parametrelerden türetmeyin; çünkü iki geçerli satın alma aynı değerleri paylaşabilir.

Zaman aşımı bir başarısızlık değil, bilinmeyen sonuçtur. Şu sırayı izleyin:

1. Denemeyi outcome_unknown olarak işaretleyin; yerine yeni bir niyet oluşturmayın.
2. Sağlayıcıyı idempotency değeri veya işlem referansıyla sorgulayın.
3. Sağlayıcı başarıyı doğrularsa, bu başarıyı yerelde kaydedin.
4. Hiçbir işlem olmadığını doğrularsa aynı değerle yeniden deneyin.
5. Yanıt veremiyorsa işlemi uzlaştırma veya insan incelemesi için bekletin.

Bu yanıt biçimi, ajana kabul ile taşıma belirsizliğini ayırmak için yeterli bilgiyi verir:

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

İdempotency değeri, desteklenen yerlerde günlüklerde, kuyruk mesajlarında, API başlıklarında ve sağlayıcı meta verilerinde taşınmalıdır. Operatörler onu sınırın her iki tarafında da arayamazsa kurtarma sırasında tahmin yürütür.

Onay, etki sınırında olmalıdır

Onay, ajan tam dış eylemi oluşturduktan sonra ve ilk geri döndürülemez istek sistemden çıkmadan önce alınmalıdır. Geniş bir görevin başında verilen onay, ajana daha sonra alıcıları, tutarları, kapsamları veya araçları değiştirmek için fazla alan bırakır.

“Bu müşterinin hesabını hallet” demek, karttan ödeme almak veya her kullanıcıya e-posta göndermek için yeterli onay değildir. Geçerli onay; somut işlemi, alıcıyı, tutarı ve para birimini, iletiyi veya yük özeti değerini, hedef hesabı, aracı, sona erme zamanını ve izin verilen deneme sayısını açıklar. Onaylanan alanlardan biri değişirse onay artık eşleşmez.

Yararlı bir politika, etkileri hangi ajanın veya modelin talep ettiğine göre değil, sonuçlarına göre sıralar. Okuma erişimi özel verileri açığa çıkarabilir, ancak dışa dönük bir eylemle aynı kurtarma sorununu oluşturmaz. E-posta taslağı hazırlamak yereldir ve geri döndürülebilir. Göndermek sınırı aşar. Ödeme teklifi oluşturmak yereldir. Fonları tahsil etmek sınırı aşar.

Şu eylemler için açık onay isteyin:

• Para hareketi yaratmak veya mali yükümlülük oluşturmak
• Bir kişiye veya dış kuruma bilgi göndermek
• Denetlenen depolamanın dışında veri yayımlamak, silmek veya ifşa etmek
• Kimlik, erişim, sahiplik veya güvenlik ayarlarını değiştirmek
• Güvenilir biçimde geri çağrılamayan fiziksel işi ya da başka bir süreci başlatmak

Düşük sonuçlu, tekrarlayan eylemlerde sınırları belirlenmiş sürekli onay kullanılabilir. Sınırda azami tutar, alıcı kümesi, izin verilen araç, sona erme zamanı, hız ve toplam işlem sayısı belirtilmelidir. “Faturalama için onaylandı” ifadesinin uygulanabilir bir sınırı yoktur.

Onay, tekrar oynatmaya karşı da korunmalıdır. Onayı işlemin değişmez özetine bağlayın ve politika yalnızca tek yürütmeye izin veriyorsa kullanıldı olarak işaretleyin. Yürütme bilinmeyen sonuç verirse yeni onay istemeyin ve ikinci bir niyet oluşturmayın. Önce onaylanmış niyeti uzlaştırın.

Onay ekranı, kurtarma gerçeğini sade bir dille ifade etmelidir. “Bu ileti teslim edildikten sonra geri çağrılamaz” ifadesi yararlıdır. Asıl kurtarma, zaman alabilen ve finansal kayıtlarda kalacak bir iadeyse “Bu işlem geri döndürülebilir” ifadesi yanıltıcıdır.

Araç sözleşmeleri tam etki yaşam döngüsünü göstermelidir

Bir ajan araç sözleşmesi niyeti, yürütmeyi, gözlemi ve telafiyi ayrı işlemler olarak açıklamalıdır. Etkiyi gerçekleştiren ve success: true döndüren tek bir işlev, yeniden denemeler, onaylar veya olay müdahalesi için çok az kanıt bırakır.

Aşağıdaki politika parçası, uygulamak için yeterince küçük ve incelemek için yeterince özeldir:

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, planlayıcıya hangi kurtarma sınıfının geçerli olduğunu söyler. approval, tam bağımsız değişkenler yetkilendirilene kadar yürütmeyi engeller. Idempotency alanı, yeniden denemelerin tek kimliği yeniden kullanmasını sağlar. Kanıt alanı, operatörlere neyin korunması gerektiğini söyler. Telafi alanı, ilk çağrının geriye doğru çalışabileceğini varsaymak yerine ayrı bir araca işaret eder.

Yürütme, değişmez bir zarf kabul etmelidir:

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

Yürütücü, işlem özetini hesaplar, bunu scope_hash ile karşılaştırır, sona erme zamanını kontrol eder, niyeti rezerve eder ve ancak bundan sonra sağlayıcıyla iletişim kurar. Çağrıdan önce istek meta verilerini, sonra da yanıtı kaydeder. Bu yazmalar arasında çökerse, kalıcı niyet uzlaştırma için erişilebilir kalır.

Yürütücü dört durumu doğaçlamadan reddetmelidir: değişmiş bağımsız değişkenler, süresi dolmuş onay, farklı bir işlem için niyetin yeniden kullanımı ve başarılı tamamlanması doğrulanmamış bir etkiyi telafi etme girişimi. Ajanlar makul görünen devam yollarını bulmakta iyidir. Mali ve iletişim denetimleri, makul bir tahmin yerine görünür bir durmayı tercih etmelidir.

Gözlem için get_payment_status(intent_id) gibi ayrı bir araç sağlayın. Gözlem bir etki oluşturmamalıdır. Ayrı tutmak, ajanın ilk eylemi yeniden deneme izni almadan belirsiz sonuçları çözmesini sağlar.

Tek bir başarısız çalıştırma tüm kurtarma sınırlarını aşabilir

Tek bir ajan çalıştırması, kodu, veritabanı kayıtlarını ve dış sistemleri zaman içinde farklı noktalarda bırakabilir. Başlatmadan önce bu hatayı adım adım incelemek, genel bir geri alma denetiminin gizlediği boşlukları ortaya çıkarır.

Bir ajanın üyelik uygulaması geliştirdiğini, değişikliği dağıttığını, müşteri listesi içe aktardığını, yıllık ücretleri tahsil ettiğini ve hoş geldiniz e-postaları gönderdiğini varsayın. Görev tek parça gibi görünür, ancak en az dört kurtarma sınırını aşar.

Saat 14:00'te ajan, yıllık ücreti yanlış sütundan hesaplayan kodu dağıtır. Saat 14:02'de veritabanına 40 ödeme niyeti ve e-posta taslağı yazar. Saat 14:03'te bir çalışan birkaç ödemeyi tahsil eder. Saat 14:04'te posta sağlayıcısı yanlış ücreti içeren hoş geldiniz mesajlarını kabul eder. Saat 14:05'te izleme çalışanı durdurur. Bazı ödeme çağrıları işlemciye ulaştıktan sonra zaman aşımına uğramıştır; dolayısıyla yerel durum başarılı olup olmadıklarını göstermez.

13:59'daki kod anlık görüntüsünü geri yüklemek, hatalı hesaplamayı gelecek çalıştırmalarda durdurur. Mevcut niyetlere kopyalanmış ücreti değiştirmez. Git commit'ini geri almak kaynak düzeltmesini belgeler, ancak aynı sınıra sahiptir.

Veritabanını 13:59'a geri yüklemek, sağlayıcı referanslarını ve idempotency değerlerini içeren yerel niyet kayıtlarını kaldırır. Bu, dış uyumsuzluğu daha da kötüleştirir. Daha iyi veritabanı eylemi mantıksal düzeltmedir: niyetleri koruyun, belirsiz işlemleri uzlaştırma için işaretleyin ve satırları yalnızca sağlayıcı durumuyla eşleştirdikten sonra düzeltin.

Müdahale ekibi daha sonra etki sınıfına göre ilerlemelidir. Sabit işlem kimliğiyle her belirsiz ödemeyi sorgular. Doğrulanmış tahsilatlar iade incelemesine gider, başarısız girişimler yeniden denenmeden kapatılır ve çözülemeyen girişimler engellenmiş halde kalır. Teslim edilen e-postalar dikkatle onaylanmış bir düzeltme alır. Sağlayıcıya henüz ulaşmamış kuyruktaki iletiler iptal edilir. Her telafi, aslına bağlı yeni bir niyet alır.

Bu örnek, otomatik telafinin neden tehlikeli olabileceğini de gösterir. Sistem her yerel payment_unknown kaydını hemen iade ederse, hiç var olmayan tahsilatlar için iade yapabilir veya yanlış referansla iade endpoint'ini çağırabilir. Veritabanı kurtarmasından sonra her eksik e-postayı yeniden gönderirse, alıcılar yinelenen iletiler alabilir. Yerel durumla sağlayıcı durumu uyuşmadığında telafiden önce uzlaştırma yapılmalıdır.

Her niyet succeeded, confirmed_failed, compensated veya manual_exception gibi terminal bir duruma ulaştığında çalıştırma tamamlanır. “Uygulama geri alındı” ifadesi olayın yalnızca ilk bölümünü açıklar.

Kurtarma ancak kanıt ayakta kalırsa işe yarar

Geri alma, ne olduğunu belirlemek için gerekli kayıtları sildiğinde kurtarma denetimleri başarısız olur. Uygulama durumundan ayrı, rutin anlık görüntülerin veya geri yüklemelerin değiştiremeyeceği yalnızca eklemeli bir etki defteri tutun ve her işlemi uzlaştıracak yeterli sağlayıcı kanıtını saklayın.

Defter; niyet oluşturmayı, bağımsız değişken özetini, onayı, yürütme kiralamasını, denemeyi, taşıma sonucunu, sağlayıcı referansını, gözlemlenen sağlayıcı durumunu ve telafi bağlantılarını kaydetmelidir. Ajanların eski kayıtların üzerine yazmasına izin vermek yerine değişiklikleri durum geçişleriyle sınırlayın. Düzeltmeler geçmişi düzenlemek yerine olay eklemelidir.

Yalnızca açık hataları değil, çözümlenmemiş durumları da izleyin. On dakika bekleyen outcome_unknown, operatör onu elle yeniden deneyebileceği için temiz bir reddedilmeden daha tehlikeli olabilir. Ayrıca yürütme sırasında bir onayın süresi dolduğunda, idempotency değeri farklı bir bağımsız değişken özetiyle göründüğünde veya telafi başarısız olduğunda uyarı verin.

Kasıtlı olarak rahatsız edici hata noktalarıyla kurtarma tatbikatları yapın. Sağlayıcı isteği kabul ettikten, ancak yerel başarı kaydından önce bir çalışanı sonlandırın. Etki defterini korurken uygulama verilerini önceki bir anlık görüntüden geri yükleyin. Planlama ile yürütme arasında onayın süresini doldurun. Gözlem API'sini kullanılamaz hale getirin. Tatbikat, sistem durduğunda, uzlaştırdığında ve etkiyi yinelemeden çözümlenmemiş kararı gösterdiğinde başarılı olur.

Koder.ai kullanırken, anlık görüntülerini ve geri alma özelliğini uygulama kurtarma katmanı olarak ele alın; ardından veritabanı geçmişi ve uygulamanın tetikleyebileceği her dış eylem için ayrı denetimler tasarlayın. Kaynak dışa aktarma, dağıtım denetimleri ve geri alma yazılımı geri yüklemeye yardımcı olurken uygulamanın araç sözleşmeleri onaylardan ve telafiden sorumlu olmaya devam eder.

Geri alma düğmesi, sınırını düğmenin yanında belirtmelidir: kod, yapılandırma, yönetilen veri veya dış etkiler. Arayüz bunu net bir cümleyle ifade edemiyorsa geri alma vaadinde bulunmamalıdır. Dürüst denetim daha az sihirli görünebilir, ancak olay ekibinin gece 2'de ihtiyaç duyduğu tek şeyi sağlar: neyin değiştiğine, neyin dışarı çıktığına ve sırada hangi eylemin güvenli olduğuna dair güvenilir bir açıklama.