प्रश्न और दायरा
पूरे क्षेत्र में आउटेज के बाद सिंगल-रीजन SaaS के लिए रिकवरी डिज़ाइन करें। व्यवसाय को अधिकतम एक घंटे के डेटा नुकसान (RPO) और चार घंटे के भीतर सेवा बहाली (RTO) की आवश्यकता है। मान लें कि पीक पर 1,000 अनुरोध प्रति सेकंड एक साक्षात्कार का अनुमान है, न कि कोई मापा गया प्रोडक्शन तथ्य; एप्लिकेशन स्टेटलेस है, प्राथमिक डेटाबेस रिलेशनल है, और ऑब्जेक्ट स्टोरेज में उपयोगकर्ता अपलोड शामिल हैं।
डिज़ाइन को डेटा, एप्लिकेशन कोड, कॉन्फ़िगरेशन, सीक्रेट्स, रूटिंग और ऑपरेटर एक्सेस को पुनर्स्थापित करना होगा। इसे दूषित (corrupted) प्राइमरी डेटा को रिकवरी क्षेत्र में आँख मूंदकर कॉपी होने से भी रोकना चाहिए। "हमारे पास बैकअप हैं" एक पूर्ण उत्तर नहीं है: बैकअप आवृत्ति, रीस्टोर समय, फ़ेलओवर प्राधिकरण, और ड्रिल्स से प्राप्त साक्ष्य उद्देश्यों से मेल खाने चाहिए।
साक्षात्कारकर्ता क्या जांच रहा है
सिस्टम-डिज़ाइन साक्षात्कार हैंडबुक डिजास्टर रिकवरी को एक साक्षात्कार-शैली RPO/RTO समस्या के रूप में प्रस्तुत करता है और स्पष्ट विफलता डोमेन, रिकवरी विकल्प और परिचालन प्रमाण की अपेक्षा करता है। AWS RPO और RTO को व्यावसायिक आवश्यकताओं द्वारा निर्धारित रिकवरी उद्देश्यों के रूप में परिभाषित करता है, फिर परिभाषित रणनीतियों, परीक्षण, कॉन्फ़िगरेशन-ड्रिफ्ट प्रबंधन और ऑटोमेशन की सिफारिश करता है।
एक मजबूत उत्तर:
- RPO को रेप्लिकेशन या बैकअप आवृत्ति में बदलता है और लैग (lag) को मापता है;
- RTO को रीस्टोर, प्रमोशन, डिप्लॉयमेंट, रूटिंग और सत्यापन बजट में बदलता है;
- डेटा प्लेन रिकवरी को कंट्रोल-प्लेन क्रियाओं से अलग करता है जो अनुपलब्ध हो सकती हैं;
- डिफ़ॉल्ट रूप से मल्टी-रीजन का नाम देने के बजाय लागत और लक्ष्य के आधार पर पायलट लाइट, वार्म स्टैंडबाय, या एक्टिव/एक्टिव चुनता है;
- दूषित डेटा और पुराने कॉन्फ़िगरेशन सहित रीस्टोर और फ़ेलओवर का पूर्वाभ्यास करता है।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या RPO भुगतान, प्रोफाइल और अपलोड पर समान रूप से लागू होता है? टियरिंग महत्वपूर्ण रिकॉर्ड्स को एनालिटिक्स की तुलना में अधिक सख्त उद्देश्य दे सकती है।
- क्या आपदा एक क्षेत्रीय नुकसान है, एक खराब डिप्लॉयमेंट है, या लॉजिकल करप्शन है? रेप्लिकेशन पहले मामले में मदद करता है लेकिन दूसरे को कॉपी कर सकता है; रोलबैक के लिए पॉइंट-इन-टाइम बैकअप आवश्यक हैं।
- क्या फ़ेलओवर के दौरान राइट्स (writes) जारी रहने चाहिए? यदि हाँ, तो राइट अथॉरिटी और संघर्ष नीति चुनें; यदि नहीं, तो केवल-पढ़ने (read-only) योग्य रिकवरी विंडो शुद्धता को सरल बनाती है।
- क्या चार घंटे का RTO हेल्थ-चेक सफलता, ग्राहक ट्रैफ़िक, या पूर्ण सुविधा समानता (feature parity) के आधार पर मापा जाता है? रनबुक में उस मील के पत्थर (milestone) का नाम होना चाहिए।
- क्या रिकवरी अकाउंट और कंट्रोल प्लेन को स्वतंत्र रूप से संचालित किया जा सकता है? पूर्व-प्रावधानित (pre-provisioned) कोटा, क्रेडेंशियल्स, इमेज और DNS एक्सेस यह निर्धारित कर सकते हैं कि लक्ष्य प्राप्त करने योग्य है या नहीं।
30-सेकंड उत्तर ढांचा
"मैं वर्कलोड को टियर करूंगा, व्यावसायिक RPO/RTO को मापने योग्य बनाऊंगा, और एसिंक्रोनस क्रॉस-रीजन डेटाबेस और ऑब्जेक्ट रेप्लिकेशन के साथ-साथ पॉइंट-इन-टाइम बैकअप का उपयोग करूंगा। इन्फ्रास्ट्रक्चर-एज़-कोड वाला एक पायलट-लाइट क्षेत्र चार घंटे के RTO में फिट बैठता है यदि रीस्टोर और प्रमोशन बजट के भीतर रहते हैं। रनबुक एक ज्ञात-अच्छे डेटा बिंदु को बढ़ावा देती है, एप्लिकेशन को डिप्लॉय करती है, रूटिंग स्विच करती है, अखंडता और स्मोक जांच चलाती है, और स्थिति की सूचना देती है। त्रैमासिक ड्रिल्स प्रत्येक चरण को मापती हैं, बैकअप रीस्टोरेशन को सत्यापित करती हैं, कॉन्फ़िगरेशन ड्रिफ्ट का पता लगाती हैं, और यदि मापी गई रिकवरी अब फिट नहीं बैठती है तो उद्देश्य को अपडेट करती हैं।"
चरण-दर-चरण विस्तृत उत्तर
1. उद्देश्यों को रिकवरी बजट में बदलें
RPO ≤ 1 घंटे के लिए, अधिकतम स्वीकृत रेप्लिकेशन लैग या बैकअप अंतराल एक घंटा है। उस सीमा से नीचे एक अलर्ट सेट करें, उदाहरण के लिए जब लैग 45 मिनट के करीब पहुंच जाए, और करप्शन से उबरने के लिए पॉइंट-इन-टाइम स्नैपशॉट रखें। सार्वभौमिक रेप्लिकेशन आवृत्ति का दावा न करें; स्रोत वर्कलोड को मापें और एक मार्जिन चुनें।
RTO ≤ 4 घंटे के लिए, एक ठोस बजट आवंटित करें: पहचान और घोषणा, डेटा प्रमोशन, एप्लिकेशन डिप्लॉयमेंट, रूटिंग, स्मोक टेस्ट और एक रिज़र्व। यदि रनबुक को डेटाबेस रीस्टोर करने के लिए 20 मिनट, इमेज डिप्लॉय करने के लिए 30 मिनट और ट्रैफ़िक स्विच करने के लिए 10 मिनट की आवश्यकता होती है, तो ये ड्रिल्स में सत्यापित करने योग्य धारणाएं हैं, गारंटी नहीं।
2. रिकवरी टोपोलॉजी चुनें
बैकअप और रीस्टोर सबसे सस्ता है लेकिन इसके लिए बुनियादी ढांचे के पुनर्निर्माण की आवश्यकता होती है और आमतौर पर इसमें सबसे बड़ा RTO होता है। पायलट लाइट रेप्लिकेटेड डेटा और कोर रिकवरी संसाधनों को तैयार रखता है जबकि एप्लिकेशन क्षमता बंद रहती है; यह चार घंटे के लक्ष्य के लिए एक उचित शुरुआती बिंदु है। वार्म स्टैंडबाय एक कम क्षमता वाले कार्यात्मक स्टैक को चालू रखता है और अधिक लागत पर रिकवरी को छोटा करता है। एक्टिव/एक्टिव फ़ेलओवर समय को कम करता है लेकिन क्रॉस-रीजन राइट संघर्ष, ट्रैफ़िक स्टीयरिंग जटिलता और सबसे बड़े परिचालन क्षेत्र को जोड़ता है।
चयन उद्देश्य का अनुसरण करता है: चार घंटे के लक्ष्य के लिए एक्टिव/एक्टिव लागत का भुगतान तब तक न करें जब तक कि व्यावसायिक प्रभाव इसे उचित न ठहराए। रिकवरी अकाउंट में इन्फ्रास्ट्रक्चर-एज़-कोड, कंटेनर इमेज, स्कीमा और कॉन्फ़िगरेशन को वर्शन-नियंत्रित रखें ताकि डिप्लॉयमेंट प्रतिलिपि प्रस्तुत करने योग्य हो।
3. डेटा को सुरक्षित और पुनर्प्राप्त करें
रिलेशनल परिवर्तनों को अलग क्षेत्र में एसिंक्रोनस रूप से रेप्लिकेट करें और लैग की निगरानी करें। केवल उसी प्रतिकृति (replica) को प्रमोट करें जिसकी लॉग स्थिति और अखंडता जांच RPO को संतुष्ट करती है। आकस्मिक विलोपन, रैंसमवेयर और दूषित राइट्स को संभालने के लिए एक अलग खाते या क्षेत्र में अपरिवर्तनीय (immutable), पॉइंट-इन-टाइम बैकअप संग्रहीत करें। वर्शनिंग के साथ ऑब्जेक्ट डेटा को रेप्लिकेट करें और ऑब्जेक्ट काउंट और चेकसम सत्यापित करें।
रनबुक चयनित रिकवरी टाइमस्टैम्प को रिकॉर्ड करती है, आवश्यकता पड़ने पर राइट्स को फ़्रीज़ या ड्रेन करती है, डेटा स्टोर को प्रमोट करती है, और किसी भी स्वीकृत राइट हानि का मिलान करती है। यदि भुगतान रिकॉर्ड को शून्य डेटा हानि की आवश्यकता है, तो उन्हें एक अलग टियर और संभवतः सिंक्रोनस रेप्लिकेशन की आवश्यकता है; यह दावा न करें कि एक घंटे का उद्देश्य हर डोमेन को कवर करता है।
4. सर्विंग पाथ को पुनर्प्राप्त करें
अपरिवर्तनीय इमेज और इन्फ्रास्ट्रक्चर कोड से एप्लिकेशन को डिप्लॉय करें। रिकवरी क्षेत्र में DNS या वैश्विक रूटिंग हेल्थ चेक, सीक्रेट्स एक्सेस, सर्विस कोटा और ऑब्जर्वेबिलिटी को पहले से बनाएं। डेटाबेस कनेक्टिविटी, माइग्रेशन, प्रमाणीकरण और एक प्रतिनिधि रीड/राइट स्मोक टेस्ट पास होने के बाद ही ट्रैफ़िक रूट करें।
फ़ेलओवर कंट्रोल पाथ को न्यूनतम रखें। AWS नोट करता है कि डेटा-प्लेन संचालन आमतौर पर आपदा के दौरान कंट्रोल-प्लेन संचालन की तुलना में अधिक उपलब्ध होते हैं; एक डिज़ाइन जो आउटेज के बाद कंट्रोल प्लेन के माध्यम से प्रत्येक संसाधन बनाने पर निर्भर करता है, वह अपने RTO से चूक सकता है।
5. रनबुक को निष्पादन के लिए सुरक्षित बनाएं
परिभाषित करें कि आपदा की घोषणा कौन कर सकता है, डेटा को कौन प्रमोट करता है, और ट्रैफ़िक को कौन मंजूरी देता है। प्रत्येक क्रिया के लिए एक आइडेम्पोटेंट कमांड, एक स्टॉप स्थिति, और एक रोलबैक या फ़ेलबैक योजना के साथ एक मोनोटोनिक स्टेप लॉग का उपयोग करें। रूटिंग परिवर्तनों से पहले और बाद में ग्राहक स्थिति अपडेट प्रकाशित करें। रिकवरी के दौरान, यदि क्षमता कम हो जाती है तो गैर-महत्वपूर्ण सुविधाओं को अक्षम करें और चुने गए रिकवरी बिंदु का ऑडिट ट्रेल सुरक्षित रखें।
6. ड्रिल्स और मेट्रिक्स के साथ मान्य करें
अनुसूचित रीस्टोर परीक्षण, क्षेत्रीय गेम डेज़ (game days), और कॉन्फ़िगरेशन-ड्रिफ्ट जांच चलाएं। पहचान, निर्णय, रीस्टोर, प्रमोशन, डिप्लॉयमेंट, रूटिंग, स्मोक-टेस्ट और स्थिरीकरण अवधि को अलग-अलग मापें। रीस्टोर की गई पंक्ति संख्या, चेकसम, अनुमतियां, कतारें और बैकग्राउंड जॉब्स सत्यापित करें। एक विफल बैकअप, पुराना सीक्रेट, अपर्याप्त कोटा और आंशिक प्रतिकृति लैग इंजेक्ट करें; प्रत्येक को एक कार्रवाई योग्य अलर्ट या एक प्रलेखित स्टॉप उत्पन्न करना चाहिए।
स्वीकृति परीक्षण साक्ष्य है: नवीनतम ड्रिल का मापा गया RPO और RTO, अनसुलझे अंतराल और जिम्मेदार व्यक्ति। रीस्टोर के बिना एक दस्तावेज़ केवल एक परिकल्पना है।
उच्च गुणवत्ता वाला नमूना उत्तर
"एक घंटे के RPO और चार घंटे के RTO के लिए, मैं एसिंक्रोनस क्रॉस-रीजन डेटाबेस और ऑब्जेक्ट रेप्लिकेशन, अपरिवर्तनीय पॉइंट-इन-टाइम बैकअप और इन्फ्रास्ट्रक्चर-एज़-कोड द्वारा प्रबंधित एक पायलट-लाइट क्षेत्र का उपयोग करूंगा। मैं पहचान, डेटा प्रमोशन, एप्लिकेशन डिप्लॉयमेंट, DNS या वैश्विक रूटिंग और स्मोक टेस्ट के लिए समय आरक्षित करूंगा, फिर त्रैमासिक ड्रिल्स में उन समयों को साबित करूंगा। फ़ेलओवर रनबुक एक ज्ञात-अच्छे रिकवरी बिंदु का चयन करती है, केवल अखंडता जांच के बाद प्रमोट करती है, अपरिवर्तनीय इमेज डिप्लॉय करती है, प्रमाणीकरण और प्रतिनिधि राइट्स को मान्य करती है, और फिर ट्रैफ़िक को स्थानांतरित करती है। यदि प्राइमरी में लॉजिकल करप्शन है, तो केवल रेप्लिकेशन असुरक्षित है, इसलिए रनबुक पहले के समय को रीस्टोर करती है। महत्वपूर्ण भुगतान डेटा सख्त उद्देश्यों के साथ एक अलग टियर होगा। मैं मापे गए लैग, रिकवरी अवधि, ड्रिफ्ट निष्कर्ष और अगले सुधारात्मक जिम्मेदार व्यक्ति की रिपोर्ट करूंगा।"
सामान्य गलतियाँ
- बिना उद्देश्यों के "मल्टी-रीजन" कहना → लागत और जटिलता असीमित हैं → RPO/RTO और सेवा टियर से टोपोलॉजी प्राप्त करें।
- रेप्लिकेशन को बैकअप मानना → करप्शन या विलोपन तुरंत रेप्लिकेट हो सकता है → अपरिवर्तनीय पॉइंट-इन-टाइम प्रतियां रखें और रीस्टोर का परीक्षण करें।
- कोड और कॉन्फ़िगरेशन को अनदेखा करना → पुनर्प्राप्त डेटा के पास सेवा देने के लिए कोई स्टैक नहीं है → रिकवरी खाते में इमेज, स्कीमा, सीक्रेट्स एक्सेस, कोटा और IaC को वर्शन करें।
- DNS परिवर्तन को रिकवरी मानना → ट्रैफ़िक एक अस्वस्थ या असत्यापित सिस्टम तक पहुंचता है → RTO में प्रमोशन, स्मोक टेस्ट और स्थिरीकरण शामिल करें।
- एक अनुपलब्ध कंट्रोल प्लेन पर निर्भर रहना → आउटेज के दौरान ऑटोमेशन लक्ष्य नहीं बना सकता है → महत्वपूर्ण रिकवरी संसाधनों को पहले से प्रावधानित करें और पाथ का अभ्यास करें।
- कभी ड्रिल न चलाना → बैकअप, कोटा और रनबुक्स पुराने हो सकते हैं → इंजेक्ट की गई विफलताओं के साथ रीस्टोर और फ़ेलओवर को नियमित रूप से मापें।
फॉलो-अप और प्रतिक्रियाएं
शून्य के RPO के लिए क्या बदलता है?
एसिंक्रोनस रेप्लिकेशन अब लक्ष्य को पूरा नहीं करता है। एक सिंक्रोनस राइट अथॉरिटी को परिभाषित करें या उत्पाद-स्तरीय राइट स्टॉप स्वीकार करें; फिर विलंबता, कोरम और क्षेत्रीय विभाजन व्यवहार का पुनर्मूल्यांकन करें।
आप लॉजिकल करप्शन से कैसे उबरते हैं?
दूषित प्रतिकृति के प्रमोशन को रोकें, एक स्वच्छ पॉइंट-इन-टाइम बैकअप की पहचान करें, एक अलग वातावरण में रीस्टोर करें, इनवेरिएंट्स को मान्य करें, और केवल अनुमोदित परिवर्तनों को फिर से चलाएं (replay)। एक स्वस्थ क्षेत्र स्वस्थ डेटा साबित नहीं करता है।
वार्म स्टैंडबाय की तुलना में पायलट लाइट क्यों चुनें?
पायलट लाइट स्थिर-अवस्था लागत को कम करता है और चार घंटे के लक्ष्य में फिट बैठता है जब डिप्लॉयमेंट और स्केल-अप मापा जाता है। वार्म स्टैंडबाय तब उचित होता है जब RTO बजट प्रावधान को अवशोषित नहीं कर सकता है या जब कम क्षमता वाले ट्रैफ़िक को तुरंत शुरू करना आवश्यक हो।
आप कॉन्फ़िगरेशन ड्रिफ्ट को कैसे रोकते हैं?
वर्शन किए गए IaC से रिकवरी क्षेत्र को रेंडर करें, वांछित और देखे गए संसाधनों की तुलना करें, इमेज, स्कीमा, सीक्रेट, कोटा और रूटिंग अंतरों पर अलर्ट करें, और प्रत्येक ड्रिल में ड्रिफ्ट जांच शामिल करें।