एजेंट साइड इफेक्ट के लिए स्वचालित रोलबैक

एजेंट रोलबैक कोड, कॉन्फ़िगरेशन या चुना हुआ एप्लिकेशन डेटा बहाल कर सकता है। वह किसी दूसरे संगठन को अनुरोध भूलने, पहुंच चुका ईमेल इनबॉक्स से खींच लेने या यह दिखाने पर मजबूर नहीं कर सकता कि कार्ड चार्ज कभी भुगतान प्रोसेसर तक पहुंचा ही नहीं। जो टीमें इन सभी कामों को «रोलबैक» कहती हैं, वे एक ऐसा सुकून देने वाला नियंत्रण बनाती हैं जो ठीक उस समय विफल होता है जब नतीजे अहम हों।

सुरक्षित डिज़ाइन चार तरीकों को अलग रखता है: एप्लिकेशन स्नैपशॉट, Git revert, डेटाबेस रिकवरी और मुआवजे वाली कार्रवाइयां। हर एक की सीमा अलग है। जो भी कार्रवाई एप्लिकेशन की सीमा पार करती है, एजेंट के चलाने से पहले उसके लिए अलग मंजूरी, सबूत, रीट्राई नियम और रिकवरी रास्ता होना चाहिए। अगर कोई उस रास्ते को एक वाक्य में नहीं बता सकता, तो कार्रवाई को बिना निगरानी चलाने का समय नहीं आया है।

रोलबैक के चार अलग अर्थ हैं

रोलबैक तभी उपयोगी है जब टीम यह नाम ले सके कि वह कौन सी स्थिति बहाल करेगी और किसे छू नहीं सकती। यह शब्द अक्सर बहुत अलग भरोसे वाले चार तरीकों को छिपा देता है।

स्नैपशॉट एप्लिकेशन या वर्कस्पेस का कैप्चर किया गया संस्करण बहाल करता है। उत्पाद के आधार पर इसमें बनाया गया कोड, कॉन्फ़िगरेशन और चुनी हुई प्रबंधित स्थिति शामिल हो सकती है। जब तक स्नैपशॉट के कॉन्ट्रैक्ट में बाहरी सेवाएं साफ तौर पर शामिल न हों, यह उनके बारे में कुछ नहीं कहता।

Git revert नया कमिट रिकॉर्ड करता है, जिसके बदलाव पहले के कमिट को उलटते हैं। यह सोर्स हिस्ट्री को हटाए बिना सुधारता है। यह उन सेवाओं से संपर्क नहीं करता जिन्हें पुराना कोड चलते समय कॉल कर चुका था।

डेटाबेस रिकवरी डेटाबेस में रखे रिकॉर्ड बदलती है। ट्रांज़ैक्शन रोलबैक एक ट्रांज़ैक्शन में अभी कमिट न हुए लेखन को छोड़ देता है। बैकअप बहाल करना या point-in-time recovery इस्तेमाल करना उससे कहीं बड़ा काम है, जो डेटाबेस क्लस्टर को पुरानी स्थिति के करीब ले जाता है। कोई भी तरीका उस डेटाबेस के बाहर के सिस्टम से अपने आप मिलान नहीं करता।

मुआवजे वाली कार्रवाई ऐसा नया असर पैदा करती है जिसका उद्देश्य पुराने असर को संतुलित करना है। रिफंड कैप्चर किए गए भुगतान का मुआवजा है। रद्द करने का अनुरोध ऑर्डर का मुआवजा है। सुधार वाला ईमेल गलत ईमेल से हुई हानि कुछ कम कर सकता है, लेकिन पहले संदेश को हटा नहीं सकता। मुआवजा इस असहज सच को बनाए रखता है कि मूल कार्रवाई हुई थी।

डिज़ाइन समीक्षा में मैं असर-स्वामित्व तालिका इस्तेमाल करता हूं, क्योंकि वह सटीक जवाब मांगती है:

आखिरी कॉलम सबसे महत्वपूर्ण है। उलटी कार्रवाई होना इस बात का सबूत नहीं कि मूल कार्रवाई गायब हो गई। ऑडिट रिकॉर्ड, प्राप्तकर्ता की कॉपी, सेटलमेंट एंट्री, webhook और भौतिक काम बने रह सकते हैं।

कोड revert प्रोग्राम बदलता है, अतीत नहीं

कोड revert आगे के व्यवहार को रोकता या बदलता है। यह उस व्यवहार को नहीं पलटता जो पुराने संस्करण से पहले ही हो चुका है। टीम Git, प्लेटफ़ॉर्म स्नैपशॉट या डिप्लॉयमेंट रोलबैक, कुछ भी इस्तेमाल करे, यह बात सच रहती है।

Git दस्तावेज़ git revert को ऐसे कमिट रिकॉर्ड करने के रूप में बताता है जो पहले के कमिट से आए बदलावों को उलटते हैं। यह शब्दावली एकदम सटीक है: Git रिपॉज़िटरी की सामग्री पर उलटा patch लगाता है। Git को उन ईमेल, भुगतानों, क्लाउड संसाधनों, सपोर्ट टिकटों या पार्टनर API की जानकारी नहीं होती जो reverted कमिट के चलते समय बने थे।

मान लें कि एजेंट बिलिंग फ़ंक्शन बदलता है, उसे डिप्लॉय करता है और मॉनिटरिंग के दोष पकड़ने से पहले उसे दो बार चलाता है। कमिट revert करने से खराब फ़ंक्शन फिर चलना रुक सकता है। प्रोसेसर पर भुगतान के दो प्रयास फिर भी रहते हैं। यदि स्थानीय डेटाबेस में केवल एक प्रयास दर्ज हुआ हो, तो revert जांच को और कठिन बना सकता है, क्योंकि वह उस कोड पथ को हटा देता है जो दूसरे उत्तर को समझता था।

डिप्लॉयमेंट रोलबैक की सीमा भी यही है। ट्रैफ़िक को पिछले build पर भेजने से चलने वाला व्यवहार बहाल होता है। बदले गए build ने जिन अनुरोधों को पहले ही स्वीकार कर लिया, उनके परिणाम बने रहते हैं। कतार में लगे job डिप्लॉयमेंट के बाद भी रह सकते हैं और बहाल संस्करण के साथ पुरानी धारणाओं पर चल सकते हैं।

Revert करने से पहले पुराने build से बने संचालन संबंधी सबूत सुरक्षित रखें:

• डिप्लॉयमेंट पहचानकर्ता और सोर्स कमिट
• एजेंट रन और इंटेंट पहचानकर्ता
• क्यू मैसेज पहचानकर्ता और lease स्थिति
• बाहरी अनुरोध पहचानकर्ता
• प्रदाता के उत्तर और समय-चिह्न

फिर नया निष्पादन रोकें, अधूरे ऑपरेशन का मिलान करें और कोड बहाल करें। पहले revert करना और बाद में सवाल पूछना अक्सर यह समझने का सबसे आसान रास्ता मिटा देता है कि कौन से असर बाहर निकल गए।

स्नैपशॉट Git कमिट से बड़ा हो सकता है, फिर भी यही नियम लागू है। स्नैपशॉट कॉन्ट्रैक्ट में ठीक-ठीक बताया होना चाहिए कि उसमें कौन से संसाधन हैं। अगर उसमें कोड और कॉन्फ़िगरेशन है, तो उसे कोड और कॉन्फ़िगरेशन रिकवरी तरीका कहें। इंटरफ़ेस में आशावादी शब्दों के सहारे उसे सबके लिए undo न बनाएं।

डेटाबेस रिकवरी का काम लोगों की सोच से छोटा है

डेटाबेस रिकवरी डेटाबेस की स्थिति बहाल करती है, लेनदेन के हर भागीदार की व्यावसायिक वास्तविकता नहीं। ट्रांज़ैक्शन एक डेटाबेस के भीतर atomic हो सकता है, जबकि उसके आसपास का ऑपरेशन कई सिस्टम में बंटा रहता है।

यह क्रम देखें:

1. एजेंट invoice पंक्ति डालता है।
2. वह payment API कॉल करता है।
3. प्रोसेसर चार्ज स्वीकार करता है।
4. डेटाबेस कमिट विफल हो जाती है।

स्थानीय रोलबैक invoice पंक्ति हटा देता है। चार्ज फिर भी मौजूद है। बिना मिलान के पूरा ऑपरेशन दोहराने पर ग्राहक से दोबारा शुल्क लिया जा सकता है। यह classic dual write failure है: एप्लिकेशन ने एक व्यावसायिक कार्रवाई को ऐसे सिस्टम में atomic बनाने की कोशिश की जो transaction coordinator साझा नहीं करते।

क्रम उलटने से समस्या हल नहीं होती। एप्लिकेशन पहले invoice कमिट करे और बाद में payment कॉल विफल हो, तो डेटाबेस में बिना भुगतान का invoice रहता है। उस स्थिति की जांच आसान है, मगर एप्लिकेशन को फिर भी ऐसी state machine चाहिए जो payment_pending, payment_confirmed, payment_failed और payment_unknown में फर्क करे।

PostgreSQL दस्तावेज़ point-in-time recovery को base backup बहाल करने और चुने हुए recovery target तक write ahead log रिकॉर्ड फिर चलाने के रूप में समझाता है। यह डेटाबेस क्लस्टर रिकवर करने की ऑपरेटर प्रक्रिया है। यह किसी एक एजेंट रन के लिए चुनिंदा undo नहीं है और न ही payment processor या mail service को उसी समय-चिह्न पर लौटने के लिए कह सकता है।

डेटाबेस को पीछे ले जाने से दूसरी असंगति बन सकती है। मान लें आउटेज के बाद आप 10:00 पर बहाल करते हैं। प्रदाता ने 10:07 तक अनुरोध स्वीकार किए, लेकिन बहाल डेटाबेस में अब उनके रिकॉर्ड नहीं हैं। जिन एजेंटों को पंक्तियां «गायब» दिखेंगी, वे पूरे सात मिनट का काम फिर बना सकते हैं। इसलिए worker दोबारा शुरू होने से पहले रिकवरी में बाहरी मिलान चरण चाहिए।

Outbox pattern एक खतरनाक खाली जगह कम करता है। एप्लिकेशन अपना व्यावसायिक बदलाव और असर इंटेंट एक ही स्थानीय ट्रांज़ैक्शन में कमिट करता है:

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 eff_7f31 को claim करता है, स्थिर idempotency मान के साथ प्रदाता को कॉल करता है और परिणाम रिकॉर्ड करता है। Outbox बाहरी कॉल को atomic नहीं बनाता। यह सिस्टम को स्थायी सबूत देता है कि काम करने का इरादा था, जिससे रीट्राई और मिलान संभव होते हैं।

बाहरी कार्रवाइयों को मुआवजा चाहिए, और कुछ का कोई मुआवजा नहीं

किसी बाहरी side effect के लिए प्रदाता-विशिष्ट मुआवजा चाहिए या साफ कथन कि कोई सार्थक मुआवजा मौजूद नहीं है। हर कार्रवाई को वापस लिया जा सकता है, ऐसा मानना इस बात को स्वीकार करने से भी बदतर है कि कुछ कार्रवाइयों में मंजूरी जरूरी है।

ईमेल सबसे सरल उदाहरण है। प्रदाता द्वारा संदेश स्वीकार करने से पहले एप्लिकेशन कतारबद्ध job रद्द कर सकता है। स्वीकार करने के बाद प्रदाता अपने छोटे आंतरिक चरण में रद्दीकरण दे सकता है, पर अलग-अलग प्राप्तकर्ताओं और मेल सिस्टम में वापस बुलाने की सामान्य गारंटी नहीं होती। डिलीवरी के बाद दूसरा संदेश रिकॉर्ड सुधार सकता है, मिटा नहीं सकता। संवेदनशील डेटा, कानूनी सूचना और प्रतिष्ठा को नुकसान का जोखिम बना रहता है।

भुगतान की कई अवस्थाएं हैं, जिन्हें टीमें अक्सर «चार्ज हुआ» में मिला देती हैं। Authorization खर्च करने की क्षमता आरक्षित करता है। Capture उस authorization के आधार पर धन स्थानांतरित करने का अनुरोध करता है। जिस authorization का सेटलमेंट नहीं हुआ, उसे void करने से वह जारी हो सकता है। Refund capture के बाद पैसा लौटाने वाली बाद की वित्तीय एंट्री बनाता है। इन कार्रवाइयों का समय, शुल्क, अनुमति और ग्राहक पर असर अलग होते हैं। सामान्य undo_payment टूल उस जानकारी को छिपा देता है जो एजेंट को सुरक्षित काम के लिए चाहिए।

दूसरे API और भी कम सहयोगी हो सकते हैं। अनुरोध inventory ऑर्डर कर सकता है, infrastructure provision कर सकता है, सामग्री प्रकाशित कर सकता है, access दे सकता है, पैकेज भेज सकता है या किसी व्यक्ति से काम शुरू करा सकता है। DELETE endpoint लौटने योग्य होने का प्रमाण नहीं है। संसाधन हटाने पर audit log, कॉपी किया हुआ डेटा, notifications, निर्भर संसाधन या भौतिक नतीजे रह सकते हैं।

मुआवजे को उसके ईमानदार परिणाम के आधार पर बांटें:

• सटीक स्थानीय उलटा नियंत्रित स्थिति को पुराने मान पर लाता है।
• प्रदाता रद्दीकरण अधूरा काम रोकता है।
• वित्तीय मुआवजा रिफंड या क्रेडिट बनाता है।
• सुधारात्मक संचार स्वीकार करता है कि पहला संदेश अब भी दिखता है।
• मैन्युअल सुधार उन असर को संभालता है जिनका संदर्भ सुरक्षित स्वचालित नियम में नहीं समा सकता।

मुआवजा भी विफल हो सकता है। Refund endpoint टाइम आउट हो सकता है। रद्दीकरण की अवधि खत्म हो सकती है। प्राप्तकर्ता का पता सुधार स्वीकार न करे। एजेंट वाला खाता अनुमति न रखता हो। इसलिए सिस्टम को मुआवजे को भी अपने इंटेंट पहचानकर्ता, स्थिति, प्रयासों, सबूत और मंजूरी नीति वाले अलग ऑपरेशन की तरह ट्रैक करना चाहिए।

«रोलबैक का रोलबैक» करने वाला recursive फीचर न बनाएं। इतिहास को कार्रवाइयों के ledger की तरह मॉडल करें। यदि मुआवजे से नई त्रुटि हो, तो वर्तमान स्थिति की समीक्षा के बाद दूसरी स्पष्ट कार्रवाई जारी करें। इतिहास लंबा होगा, फिर भी incident के दौरान समझ में आएगा।

Idempotency दोहराव रोकती है, सफलता नहीं पलटती

Idempotency रीट्राई को एक ही इच्छित असर की प्रतियां बनाने से बचाती है। यह पहली सफल कार्रवाई को undo नहीं करती। टीमें अक्सर इन बातों को मिला देती हैं और फिर टाइमआउट के बाद फर्क समझती हैं।

RFC 9110 में idempotent request method का मतलब है कि कई एक जैसे अनुरोधों का इच्छित असर एक ऐसे अनुरोध के असर जैसा हो। उसमें PUT, DELETE और safe method को protocol semantics स्तर पर idempotent बताया गया है। POST आम तौर पर idempotent नहीं है, हालांकि API अपने कॉन्ट्रैक्ट से idempotency जोड़ सकता है।

यह शर्त महत्वपूर्ण है। Idempotent DELETE भी हर बार नया log entry, metric या response बना सकता है। प्रदाता का idempotency कार्यान्वयन रिकॉर्ड की अवधि खत्म कर सकता है, पहचानकर्ता को एक खाते तक सीमित कर सकता है, बदले हुए parameter अस्वीकार कर सकता है या केवल चुने हुए परिणाम cache कर सकता है। HTTP verb देखकर गारंटी मानने के बजाय प्रदाता का कॉन्ट्रैक्ट पढ़ें।

हर effect intent को पहले प्रयास से पहले एक स्थिर idempotency मान मिलना चाहिए। उसी इंटेंट के रीट्राई में वही मान दोबारा इस्तेमाल हो। नए व्यावसायिक इंटेंट को नया मान मिले। इसे केवल ग्राहक, रकम और तारीख जैसे बदल सकने वाले parameter से न बनाएं, क्योंकि दो वैध खरीदारी में ये मान एक जैसे हो सकते हैं।

टाइमआउट विफलता नहीं, अज्ञात परिणाम होता है। यह क्रम अपनाएं:

1. प्रयास को outcome_unknown चिह्नित करें। बदले में नया इंटेंट न बनाएं।
2. Idempotency मान या ऑपरेशन संदर्भ से प्रदाता से पूछें।
3. यदि प्रदाता सफलता की पुष्टि करे, तो उसे स्थानीय रूप से दर्ज करें।
4. यदि वह बताए कि कोई ऑपरेशन नहीं हुआ, तो उसी मान के साथ दोबारा प्रयास करें।
5. यदि वह उत्तर न दे सके, तो ऑपरेशन को मिलान या मानव समीक्षा के लिए रोक दें।

यह response shape एजेंट को स्वीकृति और transport uncertainty में फर्क करने लायक जानकारी देती है:

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

जहां समर्थन हो, वहां idempotency मान को log, queue message, API header और provider metadata के साथ भेजें। अगर ऑपरेटर सीमा के दोनों ओर उसी से खोज नहीं सकते, तो रिकवरी में उन्हें अनुमान लगाना पड़ेगा।

मंजूरी असर की सीमा पर होनी चाहिए

मंजूरी एजेंट द्वारा सटीक बाहरी कार्रवाई तय करने के बाद और पहला अपरिवर्तनीय अनुरोध सिस्टम से निकलने से पहले होनी चाहिए। किसी बड़े काम की शुरुआत में मंजूरी देने पर एजेंट को बाद में प्राप्तकर्ता, रकम, दायरा या टूल बदलने की बहुत जगह मिलती है।

«इस ग्राहक का खाता संभालो» कार्ड चार्ज करने या हर उपयोगकर्ता को ईमेल भेजने की पर्याप्त मंजूरी नहीं है। मान्य मंजूरी ठोस ऑपरेशन बताती है: प्राप्तकर्ता, रकम और मुद्रा, संदेश या payload digest, लक्ष्य खाता, टूल, समाप्ति समय और अनुमत प्रयासों की संख्या। मंजूर किया गया कोई भी field बदले तो मंजूरी लागू नहीं रहती।

उपयोगी नीति असर को यह देखकर बांटती है कि परिणाम क्या होगा, न कि किस एजेंट या मॉडल ने अनुरोध किया। Read access निजी डेटा दिखा सकता है, पर उसकी रिकवरी समस्या outbound कार्रवाई जैसी नहीं होती। ईमेल का ड्राफ्ट बनाना स्थानीय और वापस लिया जा सकने वाला है। उसे भेजना सीमा पार करता है। भुगतान प्रस्ताव बनाना स्थानीय है। धन कैप्चर करना सीमा पार करता है।

इन कार्रवाइयों के लिए साफ मंजूरी मांगें:

• पैसा ले जाना या वित्तीय दायित्व बनाना
• किसी व्यक्ति या बाहरी संगठन को जानकारी भेजना
• नियंत्रित स्टोरेज के बाहर डेटा प्रकाशित, हटाना या उजागर करना
• पहचान, एक्सेस, स्वामित्व या सुरक्षा सेटिंग बदलना
• ऐसा भौतिक काम या प्रक्रिया शुरू करना जिसे भरोसे से वापस नहीं बुलाया जा सकता

कम असर वाली, बार-बार होने वाली कार्रवाई के लिए सीमित standing approval इस्तेमाल हो सकती है। सीमा में अधिकतम रकम, प्राप्तकर्ता समूह, अनुमत टूल, समाप्ति समय, दर और कुल ऑपरेशन संख्या लिखें। «बिलिंग के लिए मंजूर» की कोई लागू की जा सकने वाली सीमा नहीं है।

मंजूरी को replay से भी बचाना चाहिए। उसे ऑपरेशन के immutable digest से बांधें और जहां नीति केवल एक निष्पादन दे वहां उसे इस्तेमाल हो चुका चिह्नित करें। यदि निष्पादन का परिणाम अज्ञात हो, तो नई मंजूरी मांगकर दूसरा इंटेंट न बनाएं। पहले मंजूर इंटेंट का मिलान करें।

मंजूरी स्क्रीन पर रिकवरी का सच साधारण भाषा में लिखा होना चाहिए। «डिलीवरी के बाद यह संदेश वापस नहीं बुलाया जा सकता» उपयोगी है। «यह कार्रवाई reversible है» भ्रामक है, जब असल रिकवरी ऐसा रिफंड हो जो समय ले और वित्तीय विवरण पर बना रहे।

टूल कॉन्ट्रैक्ट में असर का पूरा जीवनचक्र दिखना चाहिए

एजेंट टूल कॉन्ट्रैक्ट में इंटेंट, निष्पादन, अवलोकन और मुआवजा अलग-अलग ऑपरेशन होने चाहिए। एक ऐसा फ़ंक्शन जो असर पैदा करे और success: true लौटा दे, रीट्राई, मंजूरी या incident response के लिए बहुत कम सबूत छोड़ता है।

नीचे दिया गया policy fragment लागू करने में छोटा और समीक्षा में पर्याप्त स्पष्ट है:

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 planner को बताता है कि कौन सा recovery class लागू है। approval तब तक निष्पादन रोकता है जब तक सटीक आर्ग्युमेंट अधिकृत न हों। Idempotency field रीट्राई में एक ही पहचान इस्तेमाल कराता है। Evidence field ऑपरेटर को बताता है कि क्या बचाकर रखना जरूरी है। Compensation field अलग टूल की ओर इशारा करता है, मूल कॉल को पीछे की ओर चलाया जा सकता है ऐसा दिखावा नहीं करता।

निष्पादन को immutable envelope स्वीकार करना चाहिए:

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

Executor ऑपरेशन digest की गणना करता है, उसे scope_hash से मिलाता है, समाप्ति समय जांचता है, इंटेंट reserve करता है और तभी प्रदाता से संपर्क करता है। वह कॉल से पहले अनुरोध metadata और बाद में उत्तर रखता है। यदि वह इन लेखनों के बीच crash हो, तो स्थायी इंटेंट मिलान के लिए उपलब्ध रहता है।

Executor को बिना अनुमान लगाए चार स्थितियां अस्वीकार करनी चाहिए: बदले हुए आर्ग्युमेंट, समाप्त मंजूरी, अलग ऑपरेशन के लिए इंटेंट का फिर उपयोग और ऐसे असर का मुआवजा देने का प्रयास जिसकी सफलता की पुष्टि नहीं हुई। एजेंट विश्वसनीय लगने वाला अगला कदम ढूंढने में अच्छे हैं। वित्तीय और संचार नियंत्रणों को भरोसेमंद अनुमान के बजाय साफ रुकना चुनना चाहिए।

अवलोकन के लिए अलग टूल दें, जैसे get_payment_status(intent_id)। अवलोकन से कोई असर पैदा नहीं होना चाहिए। इसे अलग रखने से एजेंट अस्पष्ट परिणाम सुलझा सकता है, बिना मूल कार्रवाई दोहराने की अनुमति पाए।

एक विफल रन हर रिकवरी सीमा पार कर सकता है

एक एजेंट रन में कोड, डेटाबेस रिकॉर्ड और बाहरी सिस्टम समय के अलग-अलग बिंदुओं पर रह सकते हैं। लॉन्च से पहले ऐसी विफलता को चलाकर देखने से वे खाली जगहें सामने आती हैं जिन्हें सामान्य रोलबैक नियंत्रण छिपाता है।

मान लें एजेंट सदस्यता एप्लिकेशन बनाता है, बदलाव डिप्लॉय करता है, ग्राहक सूची इंपोर्ट करता है, वार्षिक शुल्क लेता है और स्वागत ईमेल भेजता है। काम एक जैसा दिखता है, पर वह कम से कम चार रिकवरी सीमाएं पार करता है।

14:00 पर एजेंट ऐसा कोड डिप्लॉय करता है जो वार्षिक शुल्क गलत कॉलम से निकालता है। 14:02 पर वह डेटाबेस में 40 payment intent और email draft लिखता है। 14:03 पर worker कई भुगतान कैप्चर करता है। 14:04 पर मेल प्रदाता गलत शुल्क वाले स्वागत संदेश स्वीकार करता है। 14:05 पर मॉनिटरिंग worker रोक देती है। कुछ payment कॉल प्रोसेसर तक पहुंचने के बाद टाइम आउट हुए, इसलिए स्थानीय स्थिति नहीं बताती कि वे सफल हुए या नहीं।

13:59 का code snapshot बहाल करने से आगे के रन में गलत गणना रुकती है। Git commit revert स्रोत सुधार दर्ज करता है, मगर उसकी सीमा भी वही है।

डेटाबेस को 13:59 पर बहाल करने से स्थानीय intent रिकॉर्ड हट जाएंगे जिनमें provider reference और idempotency मान हैं। इससे बाहरी असंगति और बढ़ेगी। बेहतर डेटाबेस कार्रवाई तार्किक सुधार है: इंटेंट बचाए रखें, अनिश्चित ऑपरेशन को मिलान के लिए चिह्नित करें और प्रदाता की स्थिति मिलाने के बाद ही पंक्तियां सुधारें।

फिर response team को असर के प्रकार के अनुसार आगे बढ़ना चाहिए। वह हर अनिश्चित भुगतान से उसकी स्थिर ऑपरेशन पहचान के जरिए पूछती है। पुष्ट कैप्चर रिफंड समीक्षा में जाते हैं, विफल प्रयास बिना रीट्राई के बंद होते हैं और अनसुलझे प्रयास रोके रहते हैं। पहुंच चुके ईमेल को सावधानी से मंजूर किया हुआ सुधार मिलता है। जो संदेश अभी प्रदाता तक नहीं पहुंचे, वे रद्द होते हैं। हर मुआवजे को मूल से जुड़ा नया इंटेंट मिलता है।

यह उदाहरण यह भी दिखाता है कि स्वचालित मुआवजा खतरनाक क्यों हो सकता है। अगर सिस्टम हर स्थानीय payment_unknown रिकॉर्ड पर तुरंत रिफंड करे, तो वह कभी हुए ही नहीं चार्ज के लिए रिफंड दे सकता है या गलत संदर्भ से refund endpoint कॉल कर सकता है। डेटाबेस रिकवरी के बाद हर गायब ईमेल फिर भेजे तो प्राप्तकर्ताओं को डुप्लिकेट मिल सकते हैं। जहां स्थानीय और प्रदाता की स्थिति अलग हो, वहां मुआवजे से पहले मिलान जरूरी है।

रन तभी पूरा है जब हर इंटेंट succeeded, confirmed_failed, compensated या manual_exception जैसी अंतिम स्थिति में पहुंच जाए। «एप्लिकेशन रोल बैक हो गया» incident का केवल पहला हिस्सा बताता है।

रिकवरी तभी काम करती है जब सबूत बचा रहे

जब रोलबैक यह तय करने के लिए जरूरी रिकॉर्ड मिटा दे कि क्या हुआ था, तब रिकवरी नियंत्रण विफल होते हैं। Routine snapshot या restore से बदल सकने वाली एप्लिकेशन स्थिति के बाहर append-only effect ledger रखें और हर ऑपरेशन का मिलान करने के लिए पर्याप्त प्रदाता सबूत संभालें।

Ledger में इंटेंट बनना, आर्ग्युमेंट digest, मंजूरी, execution lease, प्रयास, transport result, provider reference, देखी गई provider स्थिति और compensation link दर्ज होना चाहिए। एजेंट को पुरानी एंट्री बदलने देने के बजाय बदलाव को state transition तक सीमित रखें। सुधार इतिहास संपादित करने के बजाय event जोड़ें।

सिर्फ स्पष्ट त्रुटियों पर नहीं, अनसुलझी स्थितियों पर भी नज़र रखें। दस मिनट से पड़ा outcome_unknown साफ अस्वीकृति से ज्यादा खतरनाक हो सकता है, क्योंकि ऑपरेटर उसे हाथ से दोहरा सकता है। यह भी अलर्ट करें कि निष्पादन के दौरान मंजूरी समाप्त हुई, idempotency मान अलग argument digest के साथ दिखा या मुआवजा विफल हुआ।

जानबूझकर असहज विफलता बिंदुओं के साथ रिकवरी अभ्यास चलाएं। प्रदाता के अनुरोध स्वीकार करने के बाद और स्थानीय सफलता लिखने से पहले worker बंद करें। Effect ledger बचाए रखते हुए एप्लिकेशन डेटा को पुराने स्नैपशॉट से बहाल करें। योजना और निष्पादन के बीच मंजूरी समाप्त होने दें। Observation API अनुपलब्ध कर दें। अभ्यास तब सफल है जब सिस्टम रुकता है, मिलान करता है और असर की प्रतिलिपि बनाए बिना अनसुलझा निर्णय दिखाता है।

Koder.ai इस्तेमाल करते समय उसके स्नैपशॉट और रोलबैक को एप्लिकेशन रिकवरी परत मानें। फिर डेटाबेस हिस्ट्री और एप्लिकेशन से चल सकने वाली हर बाहरी कार्रवाई के लिए अलग नियंत्रण बनाएं। Source export, deployment control और रोलबैक सॉफ़्टवेयर बहाल करने में मदद करते हैं, जबकि एप्लिकेशन के टूल कॉन्ट्रैक्ट मंजूरी और मुआवजे के मालिक बने रहते हैं।

रोलबैक बटन के पास ही उसकी सीमा लिखी होनी चाहिए: कोड, कॉन्फ़िगरेशन, प्रबंधित डेटा या बाहरी असर। यदि इंटरफ़ेस उस वाक्य को सटीक नहीं बना सकता, तो उसे रोलबैक का वादा नहीं करना चाहिए। ईमानदार नियंत्रण कम जादुई लग सकता है, पर incident team को रात 2 बजे वही चीज चाहिए: क्या बदला, क्या बाहर निकल गया और अगली कौन सी कार्रवाई सुरक्षित है, इसका भरोसेमंद ब्योरा।