PSP आउटेज: बिना डुप्लिकेट के बैकअप पर जाना और वापस लौटना

PSP फेलओवर का एक आम दृश्य: मुख्य PSP फिर से जवाब देने लगा है, और ड्यूटी इंजीनियर ट्रैफ़िक उस पर वापस भेज देता है। एक मिनट बाद ऑटोमेशन फिर से बैकअप चालू कर देता है। जब तक टीम यह पता लगाती है कि रूट को कौन नियंत्रित कर रहा है, पहले के कुछ पेमेंट अज्ञात नतीजे के साथ अटके रह जाते हैं। यह अभ्यास के लिए एक काल्पनिक परिदृश्य है: फेलओवर में नए प्रयास, अधूरे ट्रांज़ैक्शन और मुख्य रूट पर सुरक्षित वापसी, तीनों शामिल होने चाहिए।

एक काल्पनिक उदाहरण से स्विचिंग को समझिए

प्लेटफ़ॉर्म ने एक अनुमत पेमेंट मेथड के लिए रूट A और B पहले से जोड़ रखे हैं। 14:05 पर A पर टाइमआउट बढ़ने लगते हैं। टीम A पर नई रिक्वेस्ट सीमित करती है और B की उपयुक्तता जाँचती है। ऑर्डर R-902 पहले ही A से भेजा जा चुका है, लेकिन जवाब नहीं आया: वह रिकंसिलिएशन में रहता है। ऑर्डर R-903 अभी भेजा नहीं गया: सामान्य जाँचों के बाद, अगर उसके पैरामीटर इस रूट के अनुकूल हैं, तो उसे B से भेजा जा सकता है।

R-902 के लिए आइडेम्पोटेंसी key को बस B में कॉपी करके सुरक्षा को साझा मान लेना ठीक नहीं। प्रस्तावित आर्किटेक्चर में प्रयासों का एक ही अंदरूनी लॉग होता है, और नई फ़ाइनेंशियल कार्रवाई की अनुमति तभी मिलती है जब पिछली का नतीजा तय हो जाए या प्रोवाइडर की दी हुई सुरक्षित प्रक्रिया पूरी हो। सपोर्ट टीम इंतज़ार की वजह देखती है और कस्टमर को बिना नियंत्रण के दोबारा पेमेंट करने की सलाह नहीं देती।

पहले समस्या की श्रेणी तय कीजिए

तकनीकी अनुपलब्धता, रिक्वेस्ट की गलती, अतिरिक्त ऑथेंटिकेशन की माँग और ट्रांज़ैक्शन पर पाबंदी — इन सबके लिए अलग फैसले चाहिए। HTTP कोड अपने आप में हमेशा बिज़नेस नतीजा नहीं बताता। उदाहरण के लिए, Stripe सलाह देता है कि 500 जवाब वाले ऑपरेशन के नतीजे को अनिश्चित माना जाए और नई key से कोशिश करने से पहले मूल रिक्वेस्ट का हाल पता किया जाए। एरर वाला जवाब इस बात का सबूत नहीं कि कोई फ़ाइनेंशियल असर नहीं हुआ।

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

बैकअप रास्ता पहले से तैयार होना चाहिए

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

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

Adyen की डिक्लाइन वजहों की सूची इश्यूअर की अनुपलब्धता, ऑथेंटिकेशन की गलतियों, फ्रॉड के शक और प्रतिबंधित ट्रांज़ैक्शन में फ़र्क करती है। यह इस बात का ठोस उदाहरण है कि «हर डिक्लाइन को आगे भेज दो» जैसा एक नियम क्यों बहुत मोटा है। बैकअप को AML/KYC की शर्तों, सैंक्शन की पाबंदियों, एंटी-फ्रॉड या ट्रांज़ैक्शन को अस्वीकार्य मानने के फैसले को बायपास नहीं करना चाहिए। विवादित वजह को ज़िम्मेदार विशेषज्ञ के पास भेजिए।

रिकवरी के दौरान लोड सीमित रखिए

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

AWS समझाता है कि रीट्राई ओवरलोड को कैसे बढ़ाते हैं और क्यों बढ़ते अंतराल के साथ थोड़ा रैंडम फ़र्क, जिसे jitter कहते हैं, उपयोगी है। पेमेंट सर्विस के लिए यह पूरी कतार को एक साथ बड़े पैमाने पर दोबारा चलाने के खिलाफ़ तर्क है। रीट्राई को नियंत्रित करने की एक जगह तय कीजिए और जाँचिए कि SDK अपने छिपे हुए रीट्राई तो नहीं जोड़ रहे।

मुख्य रूट पर वापसी भी नियंत्रण माँगती है। लिखिए कि वापसी की अनुमति कौन देता है, रिकवरी के कौन-से संकेत ज़रूरी हैं और दोबारा स्विच होने से कैसे रोकें। A और B की साझा निर्भरताएँ पता कीजिए: दो अलग कॉन्ट्रैक्ट अपने आप में इन्फ़्रास्ट्रक्चर की स्वतंत्रता साबित नहीं करते। उपलब्धता को सिर्फ़ बाहरी स्टेटस के हरे संकेत से नहीं, अंदरूनी मेट्रिक्स से भी मिलाइए।

बैकअप की कीमत स्विच के बाद दिखती है

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

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

मुख्य रूट पर वापसी भी एक रिलीज़ है

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

अलग से तय कीजिए कि जब लोग रिकवरी कर रहे हों, तब ऑटोमैटिक स्विच का क्या होगा। एक साथ रूट बदलने वाले दो मैकेनिज़्म उतार-चढ़ाव पैदा कर सकते हैं और प्रयोग को समझ से बाहर बना सकते हैं। फैसलों के लॉग में दिखना चाहिए कि इस समय रूट को कौन नियंत्रित कर रहा है। अभ्यास तब सफल माना जाता है जब टीम बैकअप पर जाना, वापस लौटना और अनिश्चित पेमेंट की बची हुई सूची बंद करना, तीनों जानती है।

अभ्यास की रिपोर्ट में तीन संख्याएँ रखिए: बैकअप से गुज़रे नए ट्रांज़ैक्शन; अनिर्धारित नतीजे वाले पुराने ट्रांज़ैक्शन; पुष्ट दोहरे फ़ाइनेंशियल असर। ऊँचे कन्वर्ज़न के बावजूद दूसरी संख्या को मालिक चाहिए, और तीसरी अगर शून्य नहीं है तो वजह का विश्लेषण ज़रूरी है।