पेमेंट इंसिडेंट का पहला घंटा और शिफ्ट हैंडओवर

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

पहले 10 मिनट: कमान तय कीजिए और दायरा समझिए

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

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

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

10–20 मिनट: नुकसान का बढ़ना रोकिए

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

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

20–40 मिनट: अज्ञात नतीजों की सूची पर काम कीजिए

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

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

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

अलग-अलग लोगों को अलग जानकारी दीजिए

अंदरूनी अपडेट का उदाहरण: «10:25 UTC। रूट A पर कन्फ़र्मेशन में देरी। नए सबमिशन रोक दिए गए हैं। अज्ञात नतीजे वाले 12 ट्रांज़ैक्शन की जाँच चल रही है। तकनीकी लीड कतार जाँच रहा है, फ़ाइनेंस ऑपरेटर रिकॉर्ड का मिलान कर रहा है। अगला अपडेट 10:40 UTC पर।» यहाँ संख्याएँ और समय उदाहरण के लिए हैं; असली संदेश में सिर्फ़ जाँचा हुआ डेटा इस्तेमाल कीजिए।

कस्टमर के लिए संदेश का उदाहरण: «कुछ पेमेंट के कन्फ़र्मेशन में देरी हो रही है। अगर आपका ऑर्डर प्रोसेसिंग दिखा रहा है, तो अभी दोबारा पेमेंट न करें। हम प्रभावित ट्रांज़ैक्शन की जाँच कर रहे हैं। अगला अपडेट 10:40 UTC पर दिया जाएगा।» ऐसा टेक्स्ट तभी ठीक है जब प्रोसेसिंग का स्टेटस सच में दिखता हो और बताया गया कदम चुने गए पेमेंट मेथड के लिए सुरक्षित हो। जब तक रिकंसिलिएशन पूरा नहीं हुआ, दोबारा डेबिट न होने का वादा मत कीजिए।

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

40–60 मिनट: रिकवरी जाँचिए और बचा हुआ काम सौंपिए

• नए अनुमत ट्रांज़ैक्शन अपेक्षित चरणों से गुज़र रहे हैं।
• कतार सच में घट रही है; उसके पुराने आइटम बिना मालिक के नहीं छूटे हैं।
• अनिश्चित ट्रांज़ैक्शन सुलझा लिए गए हैं या खास ज़िम्मेदार लोगों को सौंपे गए हैं।
• दोहरे क्रेडिट, छूटे हुए रिकॉर्ड और लेजर की गड़बड़ियाँ जाँच ली गई हैं।
• सपोर्ट टीम को मौजूदा स्टेटस और वादा किए गए अगले अपडेट की जानकारी है।

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

एक नहीं, दो अंतिम बिंदु

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

इंसिडेंट के दौरान सिर्फ़ एरर ही नहीं, पैसे का एक्सपोज़र भी गिनिए। काल्पनिक 12 अज्ञात ट्रांज़ैक्शन 10 यूरो के हों या 10,000 यूरो के, दोनों पर अलग स्तर का ध्यान चाहिए। रकम को करेंसी और देनदारी के प्रकार के हिसाब से समूहित कीजिए; कन्वर्ज़न के नियमों के बिना उन्हें एक सुंदर संख्या में मत जोड़िए। उन ट्रांज़ैक्शन को अलग से चिह्नित कीजिए जिनके लिए सामान दिया जा चुका है या पेआउट का वादा हो चुका है।

शिफ्ट हैंडओवर: समझ की जाँच

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

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