प्रॉम्प्ट और लागू संदर्भ
09:10 पर, एक क्षेत्र (region) में चेकआउट ख़राब हो जाता है: 5xx 0.3% से बढ़कर 5.2% हो जाता है, p95 लेटेंसी 280 मिलीसेकंड से बढ़कर 2.6 सेकंड हो जाती है, और एक रिलीज़ 10 मिनट पहले ही पूरी हुई है। डेटा हानि की कोई पुष्टि नहीं हुई है। बताएं कि आप पहले 30 मिनट के दौरान गंभीरता का आकलन कैसे करेंगे, प्रभाव को कैसे सीमित करेंगे, स्कोप को कैसे संकीर्ण करेंगे, परिकल्पनाओं का परीक्षण कैसे करेंगे, रिकवरी को कैसे सत्यापित करेंगे, और मूल-कारण विश्लेषण (root-cause analysis) के लिए साक्ष्य कैसे सुरक्षित रखेंगे।
यह सॉफ्टवेयर इंजीनियरों, SREs, DevOps इंजीनियरों, प्लेटफॉर्म इंजीनियरों और तकनीकी सहायता इंजीनियरों के लिए एक क्रॉस-लेयर समस्या निवारण (troubleshooting) प्रश्न है। यह किसी क्लाइंट, सर्विस, डेटाबेस, नेटवर्क या थर्ड-पार्टी डिपेंडेंसी पर सीधे दोष मढ़ने का काम नहीं करता है। मुख्य कौशल ऑपरेशनल जोखिम को नियंत्रित करते हुए लक्षण से विफलता की सीमा (failure boundary) तक पहुंचने के लिए साक्ष्यों का उपयोग करना है।
समय, एरर दरें और लेटेंसी इंटरव्यू परिदृश्य के इनपुट हैं, सार्वभौमिक चेतावनी सीमाएं (alert thresholds) नहीं। सर्विस बहाली को मूल-कारण के प्रमाण से अलग रखें। एक गंभीर इंसिडेंट के दौरान, कोई टीम लॉग, ट्रेस सैंपल और परिवर्तन इतिहास को संरक्षित करते हुए परीक्षण किए गए प्रतिवर्ती शमन (reversible mitigation) का उपयोग कर सकती है। मूल-कारण के दावे के लिए अभी भी ऐसे साक्ष्य की आवश्यकता होती है जो प्रतिस्पर्धी परिकल्पनाओं में अंतर स्पष्ट करे।
इंटरव्यूअर क्या मूल्यांकन करता है
पहला संकेत एक सटीक समस्या विवरण है। “सिस्टम धीमा है” कार्रवाई को निर्देशित नहीं कर सकता। एक मजबूत उत्तर अपेक्षित बनाम वास्तविक व्यवहार, शुरू होने का समय, प्रभावित उपयोगकर्ताओं और क्षेत्रों, निरंतर बनाम आंतरायिक विफलता (intermittent failure), व्यावसायिक नुकसान, डेटा अखंडता और सुरक्षा जोखिम को स्थापित करता है। वे तथ्य यह निर्धारित करते हैं कि इंसिडेंट घोषित करना है या नहीं।
दूसरा संकेत प्राथमिकतीकरण (prioritization) है। जब उपयोगकर्ताओं को सक्रिय रूप से विफलता का सामना करना पड़ रहा हो, तो तत्काल लक्ष्य प्रभाव को सुरक्षित रूप से कम करना होता है। रोलबैक, फीचर को डिसेबल करना, ट्रैफिक शिफ्ट करना या डिग्रेडेशन भी किसी इंसिडेंट को बढ़ा सकता है यदि डेटाबेस परिवर्तन असंगत हो, फ़ॉलबैक क्षमता अपर्याप्त हो, या प्रोटोकॉल अलग हो गए हों। चुने गए शमन के लिए शर्तें, अनुमोदक (approver), रिवर्सल पाथ और रिकवरी संकेतों का उल्लेख करें।
तीसरा संकेत परिकल्पना-आधारित निदान (hypothesis-driven diagnosis) है। लॉग, मेट्रिक्स और ट्रेस साक्ष्य के प्रकार हैं, अपने आप में कोई क्रम नहीं। एक मजबूत उत्तर गलत साबित करने योग्य (falsifiable) परिकल्पनाओं की एक छोटी सूची प्रस्तावित करता है, यह अनुमान लगाता है कि प्रत्येक क्या साक्ष्य उत्पन्न करेगी, और सबसे कम जोखिम वाली जांच चुनता है जो उन्हें अलग करती है। शुरुआत के समय के करीब एक रिलीज़ किसी एक परिकल्पना की प्राथमिकता बढ़ाती है; सामयिक सहसंबंध (temporal correlation) कार्य-कारण संबंध (causation) को साबित नहीं करता है।
चौथा संकेत इंसिडेंट समन्वय (incident coordination) है। यदि कई लोग एक साथ कॉन्फ़िगरेशन बदलते हैं, इंस्टेंस रीस्टार्ट करते हैं, या वर्बोज़ लॉगिंग सक्षम करते हैं, तो वे स्थिति को बदल देते हैं और एट्रिब्यूशन को नष्ट कर देते हैं। एक परिपक्व उत्तर इंसिडेंट लीड, ऑपरेटर और कम्युनिकेटर को नामित करता है, असंबंधित परिवर्तनों को फ्रीज करता है, और प्रत्येक कार्रवाई और देखे गए परिणाम को रिकॉर्ड करता है। किसी दिए गए समय पर केवल एक स्पष्ट रूप से अधिकृत पाथ ही प्रोडक्शन को बदलता है।
अंत में, इंटरव्यूअर एक सत्यापन लूप (verification loop) की तलाश करता है। एरर दर गिर सकती है क्योंकि ट्रैफ़िक कम हो गया था, और एक रीस्टार्ट अस्थायी रूप से किसी लीक को छिपा सकता है। रिकवरी की तुलना एक स्वस्थ नियंत्रण (healthy control) से करें, लेटेंसी, एरर, संतृप्ति (saturation), बैकलॉग और व्यावसायिक सफलता का निरीक्षण करें, फिर डुप्लिकेट शुल्क और छूटे हुए ऑर्डर का अलग से मिलान (reconciliation) करें। तत्काल रिकवरी और दीर्घकालिक रोकथाम के लिए अलग-अलग निकास मानदंड (exit criteria) की आवश्यकता होती है।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- क्या यह कार्यप्रणाली (methodology) संबंधी प्रॉम्प्ट है या पिछले अनुभव का प्रॉम्प्ट है? कार्यप्रणाली प्रॉम्प्ट के लिए दिए गए परिदृश्य का उपयोग करें। यदि इंटरव्यूअर अनुभव के बारे में पूछता है, तो एक सत्यापन योग्य इंसिडेंट पर स्विच करें, व्यक्तिगत अधिकार और टीम की भूमिकाओं की पहचान करें, और मनगढ़ंत प्रोडक्शन कार्य न बताएं।
- उपयोगकर्ता पर क्या प्रभाव और गंभीरता है? कम वॉल्यूम वाला आंतरिक टूल अवलोकन की अनुमति दे सकता है। व्यापक चेकआउट विफलता, डेटा क्षति, या सुरक्षा घटना के लिए तत्काल एस्केलेशन, प्रतिबंधित परिवर्तन और एक बड़ी प्रतिक्रिया टीम की आवश्यकता होती है।
- क्या डेटा या सुरक्षा से समझौता हो सकता है? केवल लेटेंसी के मामले में, आंशिक ट्रैफ़िक सुरक्षित रह सकता है। संभावित डुप्लिकेट चार्जिंग, अनधिकृत पहुंच, या डेटा करप्शन के लिए राइट्स (writes) को रोकने या पाथ को अलग करने की आवश्यकता होती है और यह रिकवरी के लिए अनुमोदन के स्तर को बढ़ाता है।
- रिलीज़ में क्या शामिल था? कोड, कॉन्फ़िगरेशन, डेटाबेस माइग्रेशन, डिपेंडेंसी वर्ज़न और इन्फ्रास्ट्रक्चर के अलग-अलग रोलबैक जोखिम होते हैं। असंगत स्कीमा राइट्स के बाद किसी एप्लिकेशन को रोल बैक करने से इंसिडेंट और खराब हो सकता है।
- स्वस्थ नियंत्रण (healthy control) कहाँ है? कोई अन्य क्षेत्र (region), पुराने वर्ज़न का इंस्टेंस, बिना फीचर वाला टेनेंट, या उसी क्षेत्र के अन्य एंडपॉइंट्स वर्ज़न, क्षेत्र, इनपुट और डिपेंडेंसी कारणों को अलग कर सकते हैं। बिना किसी नियंत्रण के, एक कम जोखिम वाला सिंथेटिक अनुरोध या केवल-पढ़ने योग्य (read-only) जांच बनाएं।
- मेरी भूमिका और अधिकार क्या है? इंसिडेंट लीड के पास वैश्विक स्थिति की जानकारी होती है, ऑपरेटर सिस्टम को संशोधित करता है, और कम्युनिकेटर हितधारकों को अपडेट करता है। एक अन्वेषक को प्रोडक्शन अधिकार से आगे बढ़ने के बजाय साक्ष्य प्रस्तुत करना चाहिए और मामले को आगे बढ़ाना चाहिए।
- कौन से शमन (mitigations) सुरक्षित माने जाते हैं? क्षमता, स्थिति संगतता और रिवर्सल चरणों की पुष्टि होने के बाद ही फीचर फ़्लैग, ट्रैफ़िक शिफ्ट, एक स्थिर स्टैक, डिग्रेडेशन और रोलबैक विकल्प होते हैं।
30-सेकंड उत्तर का ढाँचा
“मैं सबसे पहले स्कोप, डेटा जोखिम और गंभीरता स्थापित करता हूँ, इंसिडेंट घोषित करता हूँ और आवश्यकता पड़ने पर असंबंधित परिवर्तनों को फ्रीज करता हूँ। जब उपयोगकर्ता प्रभावित होते हैं, तो मैं पर्याप्त क्षमता वाला एक परीक्षण किया गया, प्रतिवर्ती शमन चुनता हूँ और साक्ष्य सुरक्षित रखता हूँ। मैं समय, क्षेत्र, वर्ज़न, अनुरोध कोहोर्ट (request cohorts) और डिपेंडेंसी की तुलना करता हूँ; कुछ गलत साबित होने योग्य परिकल्पनाएँ लिखता हूँ; स्कोप के लिए मेट्रिक्स, धीमी सीमा के लिए ट्रेस और विशिष्ट विफलता के लिए लॉग का उपयोग करता हूँ। मैं एक समय में एक प्रलेखित वेरिएबल को बदलता हूँ। रिकवरी के लिए स्वस्थ SLIs, व्यावसायिक सफलता, खाली हुए बैकलॉग और डेटा मिलान की आवश्यकता होती है, जिसके बाद मूल-कारण और रोकथाम का कार्य होता है।”
यह शुरुआती ढाँचा क्रम स्थापित करता है। एक गहन उत्तर में निर्णय की शर्तों और उस साक्ष्य का भी उल्लेख होना चाहिए जो आपको किसी परिकल्पना को छोड़ने पर मजबूर करेगा।
चरण-दर-चरण गहन उत्तर
एक लक्षण अनुबंध (symptom contract) से शुरुआत करें ताकि टीम एक ही समस्या की जांच करे:
- अपेक्षित और वास्तविक: आधार रेखा (baseline) 5xx 0.3% है और p95 280 मिलीसेकंड है; वर्तमान मान 5.2% और 2.6 सेकंड हैं।
- समय: रिलीज़ के 10 मिनट पहले समाप्त होने के बाद 09:10 पर पता चला; वास्तविक शुरुआत का पता लगाएं और देखें कि क्या विफलता निरंतर है।
- स्कोप: वर्तमान में एक क्षेत्र की पुष्टि हुई है; एंडपॉइंट, वर्ज़न, टेनेंट, डिवाइस और अनुरोध इनपुट द्वारा विभाजन जारी रखें।
- प्रभाव: असफल चेकआउट और व्यावसायिक नुकसान की गणना करें, और निर्धारित करें कि क्या कोई उपयोगकर्ता वर्कअराउंड मौजूद है।
- अखंडता (Integrity): डुप्लिकेट शुल्क, बिना ऑर्डर के शुल्क के मामले, छूटे हुए इवेंट और अनधिकृत पहुंच की अलग से जांच करें। “पुष्टि नहीं हुई” का अर्थ “अनुपस्थिति साबित होना” नहीं है।
यदि प्रभाव इंसिडेंट सीमा को पार करता है, तो एक समन्वय तल (coordination plane) स्थापित करें। इंसिडेंट लीड प्राथमिकताओं और निर्णय लॉग को बनाए रखता है; ऑपरेटर प्रोडक्शन परिवर्तन करता है; कम्युनिकेटर एक निश्चित अंतराल पर उपयोगकर्ता प्रभाव, ज्ञात तथ्य, वर्तमान कार्रवाई और अगले अपडेट का समय पोस्ट करता है। असंबंधित रिलीज़ को फ्रीज करें। टाइमलाइन, डैशबोर्ड स्नैपशॉट, प्रतिनिधि ट्रेस आईडी, परिवर्तन वर्ज़न और प्रत्येक हस्तक्षेप को रिकॉर्ड करें। साक्ष्य संरक्षित करने से शमन में बाधा नहीं आनी चाहिए, लेकिन बिना सोचे-समझे रीस्टार्ट करने से इन-मेमोरी साक्ष्य मिट जाते हैं और बाद के अवलोकन बदल जाते हैं।
आगे निदान करने से पहले निर्णय लें कि क्या शमन (mitigation) करना है। एक स्पष्ट तुलना का उपयोग करें: क्या वर्तमान नुकसान शमन के सबसे बड़े संभावित जोखिम से अधिक है? जब डेटा क्षति संभव हो तो राइट्स रोकें या पाथ को अलग करें। जब हालिया परिवर्तन सुरक्षित रूप से प्रतिवर्ती हो और स्थिर लक्ष्य के पास पर्याप्त क्षमता हो तो रोल बैक करें या ट्रैफ़िक शिफ्ट करें। जब स्कीमा, संदेश प्रारूप, या बाहरी प्रभाव बदल गए हों तो फीचर फ़्लैग, रेट लिमिट, या अनुकूलता पाथ को प्राथमिकता दें। प्रत्येक शमन के लिए एक अपेक्षित संकेत, अवलोकन विंडो और पूर्ववत (undo) कार्रवाई की आवश्यकता होती है।
निदान की शुरुआत तुलनाओं (contrasts) से करें, सबसे बड़ी लॉग फ़ाइल से नहीं। एक ऐसी सीमा खोजें जहाँ पाँच आयामों में केवल एक पक्ष अस्वस्थ हो:
- समय: शुरुआत के समय के आसपास कौन सा कोड, कॉन्फ़िगरेशन, प्रमाणपत्र, ट्रैफ़िक और डिपेंडेंसी स्थिति बदली?
- क्षेत्र (Region): क्या वही वर्ज़न अन्य जगहों पर स्वस्थ है, और क्या प्रभावित क्षेत्र में पुराना वर्ज़न भी अस्वस्थ है?
- वर्ज़न: एक ही क्षेत्र के भीतर, क्या पुराने और नए इंस्टेंस में एरर दर और लेटेंसी में भिन्नता है?
- अनुरोध: क्या विफलता एंडपॉइंट, टेनेंट, भुगतान विधि, डिवाइस वर्ज़न या इनपुट आकार द्वारा केंद्रित है?
- डिपेंडेंसी: क्या धीमा समय क्लाइंट, एज, एप्लिकेशन, डेटाबेस, कैश या थर्ड-पार्टी कॉल में जमा होता है?
संभावित कारणों को चैट में छोड़ने के बजाय परिकल्पना बहीखाता (hypothesis ledger) में रखें:
| परिकल्पना | सच होने पर भविष्यवाणी | सबसे कम जोखिम वाली जांच | परिणाम दिशा कैसे बदलता है |
|---|---|---|---|
| नई रिलीज़ रिग्रेशन | इन-रीजन नया वर्ज़न विफल होता है जबकि पुराना वर्ज़न स्वस्थ है | वर्ज़न के अनुसार SLIs को विभाजित करें और उसी इनपुट के लिए ट्रेस की तुलना करें | दोनों वर्ज़न का विफल होना इसकी प्राथमिकता को कम करता है |
| क्षेत्रीय कॉन्फ़िगरेशन या डिपेंडेंसी | वही वर्ज़न केवल एक क्षेत्र में विफल होता है | कॉन्फ़िगरेशन डाइजेस्ट और डाउनस्ट्रीम स्पैन लेटेंसी की तुलना करें | कहीं और विफलता इनपुट या वैश्विक डिपेंडेंसी की ओर पुनर्निर्देशित करती है |
| ट्रिगर करने वाला अनुरोध कोहोर्ट | एरर एक वर्णनीय अनुरोध समूह में क्लस्टर होते हैं | गैर-संवेदनशील फ़ील्ड पर विभाजित करें और एक संशोधित (redacted) सैंपल को फिर से चलाएं | समान वितरण साझा संसाधनों की ओर पुनर्निर्देशित करता है |
| क्षमता या कतारबद्धता (Queuing) | संतृप्ति, कतारें और टेल लेटेंसी एक साथ बढ़ते हैं | ट्रैफ़िक, समवर्तीता (concurrency), पूल प्रतीक्षा और संसाधन पर्सेंटाइल की तुलना करें | निष्क्रिय संसाधन लॉक, टाइमआउट या डिपेंडेंसी की ओर पुनर्निर्देशित करते हैं |
संभावना, उपयोगकर्ता प्रभाव, उत्तर देने में लगने वाले समय और प्रोडक्शन जोखिम के आधार पर जांच का क्रम तय करें। मेट्रिक्स यह पता लगाते हैं कि समस्या कब और कहाँ शुरू होती है। डिस्ट्रीब्यूटेड ट्रेस दिखाते हैं कि एक अनुरोध कहाँ समय व्यतीत करता है। संरचित (structured) लॉग विशिष्ट एरर, पुनः प्रयास (retries) और स्थिति परिवर्तनों की व्याख्या करते हैं। कोड, कॉन्फ़िगरेशन और डिप्लॉयमेंट इतिहास बताते हैं कि क्या बदला। एक लॉग लाइन पूरी आबादी का प्रतिनिधित्व नहीं कर सकती है, जबकि एक समग्र (aggregate) एक स्टेट मशीन की व्याख्या नहीं कर सकता है; अनुरोध आईडी और उसी समय विंडो के माध्यम से उन्हें सहसंबंधित करें।
प्रति प्रयोग एक वेरिएबल बदलें और लिखें कि परिणाम परिकल्पना को कैसे गलत साबित करेगा। एक पुराने कॉन्फ़िगरेशन के माध्यम से एक सीमित सिंथेटिक अनुरोध भेजना इनपुट से कॉन्फ़िगरेशन को अलग कर सकता है। पूरे प्रोडक्शन में वर्बोज़ लॉग सक्षम करने से I/O और लेटेंसी बढ़ सकती है, संवेदनशील डेटा उजागर हो सकता है, और विफलता का स्वरूप बदल सकता है। एक स्वस्थ प्रतिकृति, स्टेजिंग, या सीमित ट्रैफ़िक का उपयोग करके सबसे संभावित, सबसे सुरक्षित और सबसे अधिक विभेदक परीक्षण पहले चलाएं। जब सुरक्षित पुनरुत्पादन असंभव हो, तो सहसंबंध को निश्चितता में बदलने के बजाय “सबसे संभावित कारण” की भाषा बनाए रखें।
किसी सुधार या शमन के बाद, कार्रवाई से स्वतंत्र संकेतों के साथ पुष्टि करें: 5xx, p50/p95/p99, सफल चेकआउट दर, संसाधन संतृप्ति, कनेक्शन-पूल और कतार बैकलॉग, डाउनस्ट्रीम एरर, पुनः प्रयास और चेतावनी स्थिति। कम से कम एक स्वस्थ क्षेत्र या स्थिर वर्ज़न की तुलना करें और सामान्य भिन्नता को कवर करने के लिए पर्याप्त लंबी पूर्व निर्धारित विंडो का निरीक्षण करें। डुप्लिकेट, छूटे हुए और अटके हुए मामलों के लिए भुगतान के साथ ऑर्डर का मिलान करें। उपयोगकर्ता के परिणामों के ठीक होने, बैकलॉग खत्म होने और अखंडता जांच पास होने के बाद ही शमन समाप्त करें।
स्थिरीकरण के बाद मूल-कारण विश्लेषण पूरा करें। प्रत्यक्ष ट्रिगर, प्रभाव को बढ़ाने वाली तकनीकी स्थितियों और पहचान में देरी करने वाले प्रक्रिया अंतरालों को अलग करें। रोकथाम वस्तुओं के लिए एक मालिक, समय सीमा और सत्यापन विधि की आवश्यकता होती है: कैनरी क्षेत्रीय कॉन्फ़िगरेशन, सिंथेटिक डिपेंडेंसी जांच, एंड-टू-एंड अनुरोध आईडी, स्वचालित फ़ॉलबैक मानदंड, या एक पूर्वाभ्यास रनबुक। दो परीक्षण किए गए सुधार दस बिना स्वामित्व वाली सिफारिशों की तुलना में अधिक उपयोगी हैं।
उच्च-गुणवत्ता वाला नमूना उत्तर
नीचे दिए गए सभी जांच निष्कर्ष और संख्याएं काल्पनिक इंटरव्यू परिदृश्य डेटा हैं। वे एक मौखिक उत्तर का प्रदर्शन करते हैं और कोई वास्तविक इंसिडेंट या सार्वभौमिक सीमाएं नहीं हैं।
“मैं इसे एक सक्रिय चेकआउट इंसिडेंट मानूंगा। 5xx 0.3% से बढ़कर 5.2% हो गया, p95 280 मिलीसेकंड से 2.6 सेकंड हो गया, और उपयोगकर्ता अभी भी विफल हो रहे हैं। मैं तुरंत डुप्लिकेट शुल्क, छूटे हुए ऑर्डर और सुरक्षा जोखिम की जांच करूंगा; जब तक उन्हें खारिज नहीं किया जाता, ‘डेटा हानि की कोई पुष्टि नहीं’ सुरक्षा का दावा नहीं है। मैं असंबंधित रिलीज़ को फ्रीज कर दूंगा, एक इंसिडेंट लीड, एक प्रोडक्शन ऑपरेटर और एक कम्युनिकेटर सौंपूंगा, और ट्रेस सैंपल और परिवर्तन रिकॉर्ड को सुरक्षित रखूंगा।
हालिया रिलीज़ एक उच्च-प्राथमिकता वाली परिकल्पना है, कोई निष्कर्ष नहीं। मैं प्रभावित क्षेत्र में पुराने और नए इंस्टेंस की तुलना करूंगा, फिर दूसरे नियंत्रण के रूप में एक स्वस्थ क्षेत्र का उपयोग करूंगा। मान लीजिए कि प्रभावित क्षेत्र v42 में 5.4% 5xx है और v41 में 5.0% है, जबकि दूसरे क्षेत्र में v42 में 0.4% है। यह केवल-कोड-वर्ज़न वाले स्पष्टीकरण को कमजोर करता है और एक क्षेत्रीय कॉन्फ़िगरेशन या डिपेंडेंसी समस्या की संभावना को बढ़ाता है।
इसके बाद मैं उसी चेकआउट कोहोर्ट के ट्रेस का निरीक्षण करूंगा। मान लीजिए कि 91% विफलताएं भुगतान-टोकन सर्विस कॉल में टाइमआउट हो जाती हैं, जहाँ p95 प्रभावित क्षेत्र में 2.3 सेकंड और स्वस्थ क्षेत्र में 180 मिलीसेकंड है। चेंज लॉग से पता चलता है कि क्षेत्रीय कॉन्फ़िगरेशन v17 को 09:00 बजे रिलीज़ किया गया था और उस कॉल को एक नए प्रॉक्सी पाथ पर स्थानांतरित कर दिया गया था। मैं प्रतिनिधि साक्ष्य को सुरक्षित रखूंगा, v17-से-v16 संगतता, रोलबैक अधिकार, और मौजूदा कनेक्शन व्यवहार की पुष्टि करूंगा, फिर केवल उस क्षेत्रीय कॉन्फ़िगरेशन को वापस लौटा दूंगा (revert)। मैं एक साथ कोड रोल बैक, रीस्टार्ट और स्केल नहीं करूंगा।
रिवर्ट के बाद एक ग्रीन डैशबोर्ड अपर्याप्त है। मान लीजिए कि अगले 15 मिनट में 5xx गिरकर 0.4% हो जाता है, p95 गिरकर 320 मिलीसेकंड हो जाता है, कतारें खाली हो जाती हैं, और चेकआउट वॉल्यूम ठीक हो जाता है। ऑर्डर-टू-पेमेंट मिलान में कोई डुप्लिकेट शुल्क, छूटे हुए ऑर्डर या अटकी हुई स्थितियां भी नहीं मिलती हैं। नियंत्रित कॉन्फ़िगरेशन रिवर्सल और उन स्वतंत्र संकेतों से प्रॉक्सी पाथ को प्रत्यक्ष ट्रिगर के रूप में समर्थन मिलता है। मैं अभी भी स्टेजिंग में इसे पुनरुत्पादित करूंगा और पूछूंगा कि क्षेत्रीय कॉन्फ़िगरेशन में कैनरी और डिपेंडेंसी-लेटेंसी गार्डरेल का अभाव क्यों था।
रोकथाम में क्षेत्रीय कॉन्फ़िगरेशन के लिए एक छोटा ट्रैफ़िक रोलआउट, प्रति-क्षेत्र सिंथेटिक जांच और भुगतान टोकनाइजेशन के लिए टेल-लेटेंसी अलर्ट, एरर और लेटेंसी दोनों को कवर करने वाले स्वचालित फ़ॉलबैक मानदंड, और कॉन्फ़िगरेशन रोलबैक और डेटा मिलान के लिए एक रनबुक शामिल होगी। प्रत्येक आइटम को एक मालिक, नियत तारीख और स्वीकृति के रूप में एक इंसिडेंट अभ्यास मिलता है।”
सामान्य गलतियाँ
- हालिया रिलीज़ को मूल कारण घोषित करना → ट्रैफ़िक, प्रमाणपत्र या डाउनस्ट्रीम परिवर्तन इसके साथ मेल खा सकते हैं → वर्ज़न और क्षेत्र नियंत्रण बनाएं, फिर एक ऐसी जांच चलाएं जिसकी भविष्यवाणी विफल हो सके।
- पहले प्रत्येक लॉग खोलना → समय, स्कोप और परिकल्पनाओं के बिना, अधिक डेटा अधिक अप्रासंगिक विसंगतियां पैदा करता है → लक्षण को मापें, फिर घटक और कोहोर्ट को संकीर्ण करने के लिए मेट्रिक्स और ट्रेस का उपयोग करें।
- बिना शर्त रोलबैक करना → स्कीमा, संदेश या स्थिति परिवर्तन के बाद एक पुराना वर्ज़न असंगत हो सकता है → शमन चुनने से पहले स्थिति संगतता, क्षमता और रिवर्सल पाथ की जांच करें।
- हर किसी को समाधान आज़माने की अनुमति देना → समवर्ती परिवर्तन एट्रिब्यूशन को नष्ट करते हैं और इंसिडेंट का विस्तार कर सकते हैं → भूमिकाएं सौंपें और एक रिकॉर्ड किए गए प्राधिकरण के माध्यम से प्रोडक्शन परिवर्तनों को रूट करें।
- रीस्टार्ट को मूल कारण कहना → रीस्टार्ट करना कतारों, कनेक्शनों या मेमोरी को रीसेट करता है और केवल यह साबित करता है कि स्थिति साफ़ हो गई थी → पता लगाएं कि वह स्थिति क्या पैदा करती है और देखें कि क्या यह फिर से जमा होती है।
- केवल औसत लेटेंसी की जांच करना → एक गंभीर रूप से विफल होने वाली टेल लेटेंसी माध्य (mean) में गायब हो सकती है → प्रभावित कोहोर्ट द्वारा विभाजित एरर, लेटेंसी पर्सेंटाइल, ट्रैफ़िक और संतृप्ति का निरीक्षण करें।
- जोखिम जांच के बिना वर्बोज़ लॉग सक्षम करना → लॉगिंग से I/O और लेटेंसी बढ़ सकती है या संवेदनशील फ़ील्ड उजागर हो सकते हैं → स्वचालित शटऑफ़ के साथ इंस्टेंस, अवधि और फ़ील्ड को सीमित करें।
- डैशबोर्ड ठीक होने के बाद डेटा मिलान को छोड़ देना → टाइमआउट पुनः प्रयासों से डुप्लिकेट शुल्क, छूटे हुए ऑर्डर या बैकलॉग हो सकते हैं → व्यावसायिक रिकॉर्ड और बाहरी प्रभावों का स्पष्ट रूप से मिलान करें।
- समीक्षा को “निगरानी में सुधार” के साथ समाप्त करना → कोई मीट्रिक, मालिक, सीमा या परीक्षण न होने का अर्थ है कोई सत्यापन योग्य सुधार नहीं → निष्पादन योग्य क्रियाएं बनाएं और उन्हें अभ्यास या दोष इंजेक्शन (fault injection) के माध्यम से स्वीकार करें।
अनुवर्ती प्रश्न और उत्तर
अनुवर्ती 1: रोलबैक पूरा हो गया है, लेकिन इंसिडेंट में सुधार नहीं हुआ है। आगे क्या?
रिकॉर्ड करें कि रोलबैक पूरा हो गया है और सत्यापित करें कि ट्रैफ़िक वास्तव में पुराने वर्ज़न तक पहुंच रहा है; अन्यथा “रोलबैक विफल” अपने आप में एक डिप्लॉयमेंट-सिस्टम दोष हो सकता है। यदि पुराना वर्ज़न अस्वस्थ रहता है, तो कोड-रिग्रेशन परिकल्पना को कम प्राथमिकता दें और क्षेत्रीय कॉन्फ़िगरेशन, डिपेंडेंसी स्पैन, प्रमाणपत्र, DNS, ट्रैफ़िक मिश्रण और साझा संसाधनों की तुलना करें। नए वर्ज़न को तुरंत फिर से डिप्लॉय न करें जब तक कि इसे पुनर्स्थापित करने का कोई स्पष्ट लाभ और मूल्यांकित जोखिम न हो।
अनुवर्ती 2: यदि डेटा करप्शन का संदेह हो तो क्या बदलता है?
रोकथाम (containment) को उच्च प्राथमिकता मिलती है। प्रासंगिक राइट्स को रोकें, प्रभावित टेनेंट को अलग करें, या केवल-पढ़ने योग्य (read-only) मोड में प्रवेश करें; ऑडिट लॉग और कच्चे इवेंट सुरक्षित रखें; और रिकवरी अनुमोदन में डेटा या सुरक्षा मालिकों की आवश्यकता रखें। प्रतियों या अलग किए गए डेटा पर मरम्मत को मान्य करें, प्रभावित सीमा की सूची बनाएं, इसका मिलान करें और एक प्रतिवर्ती सुधार का उपयोग करें। केवल ग्रीन सर्विस प्रतिक्रियाएं राइट्स को फिर से खोलने का अधिकार नहीं देती हैं।
अनुवर्ती 3: क्या होगा यदि बिखरे हुए लॉग हैं लेकिन कोई डिस्ट्रीब्यूटेड ट्रेसिंग नहीं है?
सीमा का अनुमान लगाने के लिए गेटवे एक्सेस लॉग, टाइमस्टैम्प, इंस्टेंस, अनुरोध प्रकार और मौजूदा सहसंबंध फ़ील्ड का उपयोग करें। प्रत्येक चरण के माध्यम से एक ज्ञात पहचानकर्ता के साथ एक कम जोखिम वाला सिंथेटिक अनुरोध भेजें। पूरे प्रोडक्शन में अनुरोध बॉडी प्रिंट करना शुरू न करें। इंसिडेंट के बाद, महत्वपूर्ण सीमाओं पर एक एज-टू-डिपेंडेंसी अनुरोध आईडी के साथ लेटेंसी, स्थिति और वर्ज़न फ़ील्ड जोड़ें; अनुपलब्ध अवलोकनीयता (observability) एक मालिक और स्वीकृति परीक्षण के साथ एक प्रभाव-वर्धक स्थिति है।
अनुवर्ती 4: कई टीमें जोर देती हैं कि दोष किसी और के सिस्टम में है। आप कैसे आगे बढ़ते हैं?
इंसिडेंट लीड संगठनात्मक दोष के बजाय उपयोगकर्ता प्रभाव द्वारा घटक जांच सौंपता है। हर कोई एक समयरेखा और परिकल्पना बहीखाता से काम करता है और परीक्षण योग्य भविष्यवाणियां और साक्ष्य प्रस्तुत करता है, जैसे “इस अनुरोध ने 120 मिलीसेकंड में हमारी सर्विस को सफलतापूर्वक छोड़ दिया, जबकि अगले स्पैन में दो सेकंड लगे।” प्रोडक्शन प्राधिकरण एकल रहता है, और कम्युनिकेटर तथ्यों को समेकित करता है ताकि प्रत्येक टीम स्वतंत्र रूप से सिस्टम को परिवर्तित न करे।
अनुवर्ती 5: समस्या आंतरायिक है और इसे विश्वसनीय रूप से पुनरुत्पादित नहीं किया जा सकता है। आप मूल कारण कैसे बताते हैं?
पहले सुरक्षित निष्क्रिय साक्ष्य का विस्तार करें: सफलताओं और विफलताओं का नमूना लें, वर्ज़न और इनपुट आयामों को बनाए रखें, और संसाधन और डिपेंडेंसी स्थिति को कैप्चर करें। परिकल्पनाओं को अलग करने वाले प्राकृतिक नियंत्रणों की तलाश करें। निश्चितता के लिए जोखिम भरी प्रोडक्शन स्थितियां बनाए बिना, अलगाव में दोष इंजेक्शन (fault injection) या ट्रैफ़िक रीप्ले का उपयोग करें। यदि साक्ष्य केवल संभावना का समर्थन करता है, तो सबसे संभावित कारक और शेष अज्ञात बताएं, फिर गार्डरेल और अवलोकनीयता जोड़ें जो पुनरावृत्ति पर प्रभाव को कम करते हैं।