प्रॉम्प्ट और संदर्भ
इंटरव्यूअर पूछता है: “हमारा B2B SaaS डेटा को दो रीजन में रेप्लिकेट करता है। क्या प्राइमरी रीजन के विफल होने पर ग्राहकों को स्विच ट्रिगर करने में सक्षम होना चाहिए?” यह मान लें कि ग्राहक सीधे अंतर्निहित डेटाबेस को संचालित नहीं कर सकते हैं, और प्रोडक्ट को टेनेंट आइसोलेशन, डेटा रेजिडेंसी और ऑडिटेबिलिटी बनाए रखनी होगी। यह प्लेटफॉर्म प्रोडक्ट मैनेजर, इंफ्रास्ट्रक्चर प्रोडक्ट मैनेजर और टेक्निकल प्रोग्राम मैनेजर इंटरव्यू के लिए उपयुक्त है।
यह परीक्षण प्रोडक्ट की सीमाएं तय करने से संबंधित है, न कि इस त्वरित प्रतिक्रिया से कि “ऑटोमेशन तेज़ होता है।” AWS अत्यधिक रेजिलिएंस के लिए मल्टी-रीजन डिज़ाइनों को स्थापित करता है लेकिन चेतावनी देता है कि क्रॉस-रीजन डिपेंडेंसी स्थिति को कमजोर करती हैं; Google Cloud का कहना है कि रिकवरी को डिज़ाइन, निर्मित और परीक्षण किया जाना चाहिए; Azure इस विकल्प को व्यावसायिक आवश्यकताओं, RTO, RPO, लागत और जटिलता के इर्द-गिर्द तैयार करता है।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप “ग्राहक नियंत्रण चाहते हैं” को मापने योग्य RTO, RPO, रेजिडेंसी और अनुपालन आवश्यकताओं में बदल सकते हैं?
- क्या आप प्लेटफॉर्म-ऑटोमैटिक, ऑपरेटर-अनुमोदित और ग्राहक-अनुरोधित स्विचिंग के बीच अंतर कर सकते हैं?
- क्या आप रेप्लिकेशन लैग, स्प्लिट-ब्रेन, DNS कैशिंग, कोटा और गलत संकेतों से जुड़े विफलता मोड के नाम बता सकते हैं?
- एक मजबूत उत्तर इस ऑपरेशन को प्री-चेक, अनुमोदन, रिहर्सल, ऑडिट और फेलबैक के साथ टेनेंट कंट्रोल प्लेन तक सीमित करता है। एक कमजोर उत्तर केवल एक बुनियादी फेलओवर बटन प्रदान करता है।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
हम किस विफलता का समाधान कर रहे हैं?
सिंगल-टेनेंट एप्लिकेशन विफलता को आइसोलेशन या पुनरारंभ द्वारा संभाला जा सकता है; पूरे रीजनल आउटेज का मामला क्रॉस-रीजन स्विचिंग के लिए होता है। यदि आवश्यकता केवल लेटेंसी की है, तो मल्टी-रीजन एक सरल मल्टी-AZ डिज़ाइन से बेहतर नहीं हो सकता है।
RTO और RPO क्या हैं?
असिंक्रोनस रेप्लिकेशन में नवीनतम राइट्स का नुकसान हो सकता है। शून्य-RPO की आवश्यकता को एक सामान्य असिंक्रोनस रेप्लिका बटन द्वारा पूरा नहीं किया जा सकता है। RTO वार्म कैपेसिटी निर्धारित करता है; RPO निर्धारित करता है कि क्या रेप्लिकेशन लैग स्वीकार्य है।
कौन सा डेटा मूल रीजन छोड़ सकता है?
रेजिडेंसी, एन्क्रिप्शन कीज़, बैकअप और लॉग्स पात्र लक्ष्य रीजन को बदलते हैं। एक “सेकेंडरी रीजन” अपने आप एक अनुपालन वाला रीजन नहीं बन जाता।
एक 30-सेकंड का उत्तर
“मैं प्रत्येक टेनेंट के उपलब्धता लक्ष्य, स्वीकार्य डेटा हानि और रेजिडेंसी बाधाओं के आधार पर अनुभव को स्तरित करूंगा। प्लेटफॉर्म को सामान्य रूप से मजबूत स्वास्थ्य संकेतों से स्वचालित रूप से या ऑपरेटर के अनुमोदन के साथ स्विच करना चाहिए; केवल वे टेनेंट जो प्री-चेक पास करते हैं, उन्हें सीधे रेप्लिका को प्रमोट करने के बजाय एक ऑडिटेड स्विच अनुरोध सबमिट करना चाहिए। अनुरोध रेप्लिकेशन लैग, लक्ष्य कैपेसिटी, कीज़, वर्ज़न और डिपेंडेंसी की जांच करता है, फिर राइट्स को फ्रीज या ड्रेन करता है। स्विच के बाद, हम त्रुटियों, राइट स्थिति और RPO की निगरानी करते हैं, और फेलबैक मानदंडों के पूरा होने के बाद ही सामान्य संचालन बहाल करते हैं। मैं टेनेंट्स के एक छोटे समूह के साथ रिहर्सल करूंगा, रिकवरी समय, गलत स्विच और ग्राहक प्रभाव की तुलना करूंगा, और फिर पहुंच का विस्तार करने का निर्णय लूंगा।”
चरण-दर-चरण समाधान
- प्रोडक्ट अनुबंध को परिभाषित करें। रीजनल फेलओवर को टेनेंट-स्कोप्ड डिजास्टर-रिकवरी ऑपरेशन के रूप में मानें। लक्षित RTO, अधिकतम RPO, अनुपलब्ध सुविधाएं, मूल्य और ग्राहक जिम्मेदारियों का उल्लेख करें। जो रेप्लिका अनुबंध को पूरा नहीं कर सकती, उसे तैयार के रूप में नहीं दिखाया जाना चाहिए।
- तीन नियंत्रण स्तर बनाएं। प्लेटफॉर्म ऑटोमेशन स्पष्ट रीजनल स्वास्थ्य संकेतों के अनुकूल है; ऑपरेटर अनुमोदन व्यावसायिक प्रभाव वाली साझा डिपेंडेंसी के अनुकूल है; ग्राहक अनुरोध को नीति द्वारा मूल्यांकित एक सीमित कमांड बनाना चाहिए। ग्राहकों को सीधे DNS संपादित नहीं करना चाहिए, डेटाबेस को प्रमोट नहीं करना चाहिए, या कतारों को फिर से नहीं चलाना चाहिए।
- प्री-चेक चलाएं। रेप्लिका कैच-अप समय, लक्ष्य कोटा, एप्लिकेशन वर्ज़न, की उपलब्धता, कतार बैकलॉग, बाहरी डिपेंडेंसी और रेजिडेंसी को सत्यापित करें। एक विफल जांच को ऑपरेशन स्वीकार करने से पहले एक कार्रवाई योग्य कारण लौटाना चाहिए।
- राइट अथॉरिटी को सुरक्षित रखें। प्राइमरी में राइट्स को रोकें या ड्रेन करें, अंतिम पुष्ट स्थिति को रिकॉर्ड करें, और ठीक एक राइट अथॉरिटी को प्रमोट करें। असिंक्रोनस रेप्लिकेशन द्वारा निर्मित अज्ञात विंडो को प्रदर्शित करें; “रेप्लिकेटेड” का अर्थ शून्य हानि नहीं है।
- सत्यापित करें और फेलबैक करें। लॉगिन, रीड, राइट, जॉब्स और ऑडिट के लिए सिंथेटिक लेनदेन का उपयोग करें। त्रुटि दर, रेप्लिकेशन स्थिति, कतार की आयु और टेनेंट सफलता की निगरानी करें। फेलबैक से पहले, विपरीत दिशा में कैच-अप करें और टकरावों का रिहर्सल करें ताकि रिकवरी से दो राइटर न बनें।
- एक रोलआउट चुनें। आंतरिक या इच्छुक टेनेंट्स के लिए रीड-ओनली सिमुलेशन से शुरुआत करें, फिर ऑपरेटर-अनुमोदित स्विचिंग करें, और बाद में ही ऑटोमेशन पर विचार करें। एक निर्धारित रोक स्थिति पर रुकें: गलत स्विच, RPO उल्लंघन, अपर्याप्त लक्ष्य कैपेसिटी, या ऑडिट साक्ष्य की कमी।
मॉडल उत्तर
मैं ग्राहकों को सीधे कोई बुनियादी बटन नहीं दूंगा। सबसे पहले मैं पुष्टि करूंगा कि क्या उन्हें क्रॉस-रीजन RTO की आवश्यकता है, वे किस RPO को स्वीकार कर सकते हैं, और कौन सी रेजिडेंसी बाधाएं लागू होती हैं। प्रोडक्ट “फेलओवर का अनुरोध करें” प्रदर्शित कर सकता है, लेकिन अनुरोध को टेनेंट नीति, रेप्लिकेशन स्थिति, लक्ष्य कैपेसिटी, वर्ज़न, की और डिपेंडेंसी जांच पास करनी होगी।
स्विच के दौरान, प्लेटफॉर्म प्राइमरी में राइट्स को फ्रीज या ड्रेन करता है, अंतिम पुष्ट स्थिति रिकॉर्ड करता है, एक राइट रेप्लिका को प्रमोट करता है, और अपेक्षित नुकसान विंडो व अनुपलब्ध सुविधाओं को बताता है। बाद में, सिंथेटिक लेनदेन रीड्स, राइट्स, जॉब्स और ऑडिट को सत्यापित करते हैं। हम प्रति टेनेंट त्रुटियों, रेप्लिकेशन स्थिति और रिकवरी समय को मापते हैं। फेलबैक केवल तभी शुरू होता है जब रिवर्स कैच-अप यह साबित कर दे कि कोई स्प्लिट-ब्रेन नहीं है।
मैं आंतरिक टेनेंट्स के साथ रिहर्सल करूंगा, ऑपरेटर अनुमोदन जोड़ूंगा, और केवल साक्ष्य अच्छे होने के बाद ही ऑटोमेशन पर विचार करूंगा। यदि गलत स्विच, RPO, या कैपेसिटी प्री-चेक किसी सीमा को पार करते हैं, तो ग्राहक-ट्रिगर पहुंच को अक्षम करें और ऑडिट ट्रेल को बनाए रखें। यह डिजास्टर-रिकवरी का जोखिम उन पर स्थानांतरित किए बिना ग्राहकों को दृश्यता और सीमित नियंत्रण देता है।
सामान्य गलतियां
- मल्टी-रीजन को स्वचालित उपलब्धता के रूप में मानना → प्रमोशन, डिपेंडेंसी और फेलबैक की उपेक्षा करता है → प्रति घटक RTO/RPO, रिहर्सल और फेलबैक का दस्तावेजीकरण करें।
- ग्राहकों को सीधे डेटाबेस प्रमोट करने देना → स्प्लिट-ब्रेन या क्रॉस-टेनेंट प्रभाव का जोखिम उठाता है → नीति द्वारा निष्पादित एक ऑडिटेड टेनेंट कमांड प्रदर्शित करें।
- केवल रीजनल स्वास्थ्य की जांच करना → DNS स्वास्थ्य यह साबित नहीं करता है कि डेटा, कीज़ या कोटा तैयार हैं → रेप्लिकेशन स्थिति, कैपेसिटी, वर्ज़न, कीज़ और डिपेंडेंसी शामिल करें।
- शून्य डेटा हानि का वादा करना → असिंक्रोनस रेप्लिकेशन में एक अपुष्ट विंडो होती है → RPO बताएं, अंतिम पुष्ट स्थिति रिकॉर्ड करें, और संभावित नुकसान सीमा दिखाएं।
- फेलबैक को छोड़ना → रिकवर किया गया प्राइमरी दोहरे राइट्स और ड्रिफ्ट बना सकता है → रिवर्स कैच-अप, टकराव का पता लगाना और चरणबद्ध फेलबैक डिज़ाइन करें।
फॉलो-अप और उत्तर
क्या होगा यदि ग्राहक को शून्य RPO की आवश्यकता हो?
स्पष्ट करें कि असिंक्रोनस रेप्लिकेशन शून्य RPO प्रदान नहीं कर सकता है। सिंक्रोनस रेप्लिकेशन या व्यावसायिक स्तर के दोहरे राइट्स का मूल्यांकन करें, फिर लेटेंसी, उपलब्धता, लागत और कंसिस्टेंसी की पुनर्गणना करें। यदि लक्ष्य अभी भी पूरा नहीं किया जा सकता है, तो इसे एक मापने योग्य अधिकतम-हानि विंडो से बदलें।
क्या होगा यदि कोई गलत स्वास्थ्य संकेत ऑटोमेशन को ट्रिगर करता है?
एकाधिक संकेतों, एक न्यूनतम अवधि और एक मानव निरस्तीकरण (abort) विंडो की आवश्यकता रखें। उच्च-मूल्य वाले टेनेंट्स के लिए, प्रमोशन से पहले एक फ्रीज और प्री-चेक की गई स्थिति में प्रवेश करें। प्रत्येक निर्णय को रिकॉर्ड करें और गलत-स्विच दर व रिकवरी समय का उपयोग करके सीमाओं को ट्यून करें।
क्या होगा यदि अनुरोध के बाद लक्ष्य रीजन में कोई कैपेसिटी न हो?
कोटा और कैपेसिटी की पहले से जांच करें, और महत्वपूर्ण टेनेंट्स के लिए एक बजट या ऑटोस्केलिंग योजना आरक्षित करें। विफलता पर, कारण लौटाएं और प्राइमरी स्थिति को बनाए रखें; केवल बटन की सफलता में सुधार के लिए किसी अप्रस्तुत रीजन में स्विच न करें।
क्या आउटेज के दौरान रेजिडेंसी नियमों में छूट दी जा सकती है?
अपवाद मानकर न चलें। टेनेंट अनुबंध और नीति में अनुमत रीजन, एन्क्रिप्शन कीज़ और लॉग सीमाओं को रखें। यदि सीमा पार आवाजाही प्रतिबंधित है, तो समान रीजन में मल्टी-AZ रेजिलिएंस या एक स्पष्ट डिग्रेडेड मोड की पेशकश करें।