सिस्टम डिज़ाइन इंटरव्यू: आप एरर बजट के साथ विश्वसनीयता और रिलीज़ की गति को कैसे संतुलित करते हैं?

प्रश्न और यह कब लागू होता है

एक इंटरव्यूअर पूछ सकता है, “सिस्टम डिज़ाइन में, आप विश्वसनीयता और रिलीज़ की गति को संतुलित करने के लिए एरर बजट का उपयोग कैसे करेंगे?” आपको यह समझाना होगा कि SLIs, SLOs और एक एरर बजट रिलीज़, रोलबैक, क्षमता (capacity) और टीम समन्वय को कैसे प्रभावित करते हैं। यह उच्च उपलब्धता (high availability), लगातार रिलीज़, या कई टीमों की निर्भरताओं से जुड़े SRE, प्लेटफ़ॉर्म, बैकएंड और सीनियर सिस्टम-डिज़ाइन इंटरव्यू के लिए उपयुक्त है।

इंटरव्यूअर क्या आकलन कर रहा है

परीक्षा यह नहीं है कि क्या आप 99.99% याद रख सकते हैं। यह इस बारे में है कि क्या आप उपयोगकर्ता-अनुभव के लक्ष्य को एक परिचालन निर्णय नियम (operational decision rule) में बदल सकते हैं। Google SRE एक एरर बजट को SLO के तहत बची हुई गुंजाइश के रूप में वर्णित करता है, जिसका उपयोग विश्वसनीयता कार्य और नवाचार के समन्वय के लिए किया जाता है; जब बजट समाप्त हो जाता है, तो विश्वसनीयता बहाल होने तक सामान्य बदलाव रोक दिए जाते हैं। इंटरव्यूअर माप की अवधि (measurement window), डेटा गुणवत्ता, प्रोग्रेसिव डिलीवरी और ऑडिट करने योग्य अपवादों को भी देखते हैं।

खुद से पूछने के लिए स्पष्टीकरण संबंधी प्रश्न

स्पष्ट करें कि उपयोगकर्ता कौन हैं, कौन सी जर्नी महत्वपूर्ण है, सर्विस की सीमा कहाँ है, और क्या लक्ष्य उपलब्धता, लेटेंसी, नवीनता (freshness) या शुद्धता है। SLO विंडो, क्षेत्रों (regions), निर्भरताओं के स्वामित्व और रोलबैक क्षमता की पुष्टि करें। यदि संख्याएं गायब हैं, तो चार सप्ताह की विंडो, 99.9% उपलब्धता और वैध उपयोगकर्ता अनुरोध द्वारा माप जैसी धारणाएं बताएं।

30-सेकंड का उत्तर ढांचा (Framework)

पाँच चरणों का उपयोग करें:

1. एक उपयोगकर्ता-दृश्यमान SLI और SLO को परिभाषित करें।
2. विंडो के एरर बजट की गणना करें और समझाएं कि इसे क्या समाप्त करता है।
3. बजट को प्रोग्रेसिव डिलीवरी, स्वचालित रोलबैक और चेंज गेट्स से जोड़ें।
4. जब बजट समाप्त हो जाए, तो सामान्य परिवर्तनों को रोकें (freeze) और सुरक्षा तथा तत्काल सुधारों के लिए स्पष्ट अपवादों के साथ विश्वसनीयता कार्य को प्राथमिकता दें।
5. अगले योजना चक्र को समायोजित करने के लिए पोस्टमॉर्टम, निर्भरता एट्रिब्यूशन और बजट रुझानों का उपयोग करें।

चरण-दर-चरण विस्तृत उत्तर

1. उपयोगकर्ता के परिणामों से SLI को परिभाषित करें

डिफ़ॉल्ट रूप से सर्वर CPU या औसत लेटेंसी को विश्वसनीयता लक्ष्य के रूप में उपयोग न करें। अनुरोध-आधारित सेवा के लिए, सफल अनुरोधों और लेटेंसी सीमा से नीचे के अनुरोधों के अनुपात को चुनें; एक एसिंक्रोनस कार्य के लिए, समय पर पूरा होना या परिणाम की नवीनता का उपयोग करें। उपयोगकर्ता को प्रभावित करने वाली विफलताओं को आंतरिक पुनः प्रयासों (internal retries) और अमान्य ट्रैफ़िक से अलग करें ताकि शोर बजट को समाप्त न करे।

2. एक व्याख्या योग्य SLO और विंडो चुनें

उदाहरण के लिए, चार सप्ताह में 99.9% सफल वैध अनुरोध लगभग 0.1% विफल होने की अनुमति देते हैं। विंडो छोटी घटनाओं और लंबे रुझानों के प्रति संवेदनशीलता को नियंत्रित करती है। कई SLO के साथ, संयोजन नियम बताएं: एक महत्वपूर्ण उपयोगकर्ता जर्नी रिलीज़ को रोक सकती है, जबकि एक द्वितीयक मीट्रिक अलर्ट और योजना को सूचित करता है। जनसंख्या और भार (weights) को समझाए बिना औसतन प्रतिशत न निकालें।

3. बजट की खपत को परिवर्तनों से जोड़ें (Attribution)

कुल बजट, बर्न रेट और कारण रिकॉर्ड करें। रिलीज़, कॉन्फ़िगरेशन, निर्भरता विफलताओं, क्षमता की कमी और गलत सकारात्मक (false positives) को अलग से टैग करें। केवल विश्वसनीय एट्रिब्यूशन ही टीम को बताता है कि कोड को ठीक करना है, क्षमता जोड़नी है, निर्भरता अनुबंध बदलना है, या मॉनिटरिंग की मरम्मत करनी है। Google की उदाहरण नीति सेवा में विफलताओं, किसी अन्य टीम के स्वामित्व वाली विफलताओं और SLO दायरे के बाहर के ट्रैफ़िक के बीच भी अंतर करती है।

4. रिलीज़ गेट्स और प्रोग्रेसिव रोलबैक डिज़ाइन करें

एक सामान्य परिवर्तन को ट्रैफ़िक के एक छोटे हिस्से या एक क्षेत्र में भेजें, त्रुटि दर, लेटेंसी और बर्न रेट का निरीक्षण करें, फिर विस्तार करें। गेट को शेष बजट और लघु-विंडो बर्न रेट दोनों की जांच करनी चाहिए; एक सुरक्षित मासिक औसत तेजी से बिगड़ती घटना को छिपा सकता है। जब व्यवहार अप्रत्याशित हो, तो रिकवरी समय को कम करने के लिए निदान से पहले रोलबैक करें। रोलबैक को आइडम्पोटेंसी (idempotency) और डेटा संगतता की भी आवश्यकता होती है।

5. परिभाषित करें कि बजट समाप्त होने के बाद क्या होता है

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

6. निर्भरता और क्रॉस-टीम स्वामित्व को संभालें

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

उच्च गुणवत्ता वाला नमूना उत्तर

इस काल्पनिक उत्तर को आपकी अपनी संख्याओं और सीमाओं से बदला जाना चाहिए:

मैं सबसे महत्वपूर्ण उपयोगकर्ता अनुरोध के लिए सफलता दर और लेटेंसी SLI को परिभाषित करूँगा। मान लीजिए कि वैध-अनुरोध सफलता SLO चार सप्ताह में 99.9% है, इसलिए एरर बजट वैध अनुरोधों का 0.1% है। मॉनिटरिंग शेष बजट, एक घंटे की बर्न रेट और विफलता एट्रिब्यूशन दिखाती है, जिसमें सेवा सीमा के बाहर ट्रैफ़िक शामिल नहीं है। रिलीज़ एक क्षेत्र में ट्रैफ़िक के एक छोटे से अंश से शुरू होती हैं और धीरे-धीरे विस्तारित होती हैं; एक बर्न थ्रेशोल्ड को पार करने से रोलआउट रुक जाता है और रोलबैक ट्रिगर हो जाता है। जब तक बजट स्वस्थ है, उत्पाद और SRE जोखिम सीमा के भीतर शिप कर सकते हैं। इसके खर्च होने के बाद, सामान्य परिवर्तन रुक जाते हैं और टीम सुरक्षा कार्य के लिए लॉग किए गए अपवादों के साथ क्षमता, परीक्षण, निर्भरता अलगाव और मूल-कारण सुधारों को प्राथमिकता देती है। हर घटना की एक निष्पक्ष (blameless) समीक्षा होती है और सुधार अगले योजना चक्र में प्रवेश करते हैं। इसलिए रिलीज़ की गति पसंद के बजाय शेष बजट और देखे गए जोखिम द्वारा नियंत्रित होती है।

सामान्य गलतियाँ

एरर बजट को विफलताएँ पैदा करने की अनुमति के रूप में मानना

बजट उपयोगकर्ता द्वारा सहन की गई विफलता स्थान का प्रतिनिधित्व करता है, न कि घटनाओं को बनाने का कोटा। उपयोगकर्ता प्रभाव, विंडो, बर्न रेट और मरम्मत स्वामित्व की व्याख्या करें।

केवल एक उपलब्धता संख्या देना

SLI, जनसंख्या और विंडो के बिना, 99.99% किसी निर्णय का मार्गदर्शन नहीं कर सकता है। वैध अनुरोध, लेटेंसी या नवीनता, और अप्रासंगिक ट्रैफ़िक को बाहर करने के नियम जोड़ें।

बजट मिस होने के बाद हमेशा के लिए रिलीज़ को फ्रीज करना

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

प्रोग्रेसिव डिलीवरी और रोलबैक संगतता की उपेक्षा करना

"मॉनिटर और रिलीज़" पर्याप्त नहीं है। ट्रैफ़िक चरणों, स्वचालित रोक स्थितियों, रोलबैक क्रम, और पुराने और नए रीड और राइट के बीच संगतता का वर्णन करें।

फॉलो-अप और उन्नत अभ्यास

SLO ठीक है, लेकिन एक घंटे की बर्न रेट अधिक है। क्या आप रिलीज़ करेंगे?

लघु-विंडो प्रवृत्ति के साथ लंबी-विंडो संतुलन की तुलना करें। यदि खपत निरंतर बनी रहती है, तो ट्रैफ़िक का विस्तार करना बंद करें, सत्यापित करें कि क्या यह वास्तविक उपयोगकर्ता प्रभाव, ट्रैफ़िक स्पाइक, या मॉनिटरिंग दोष है, और फिर तय करें कि रोलबैक करना है या नहीं।

एक बाहरी निर्भरता ने बजट खर्च कर दिया। क्या आपकी टीम को भी फ्रीज करना चाहिए?

जांचें कि क्या सर्विस कमिटमेंट में वह निर्भरता विफलता शामिल है, फिर उपयोगकर्ता जर्नी से निर्णय लें। उपयोगकर्ताओं को सुरक्षित रखें और स्वामित्व बाहरी होने पर भी डिग्रेडेशन को सक्षम करें; फ्रीज नियम को साक्ष्य-साझाकरण और एस्केलेशन के साथ पहले से सहमत होना चाहिए।

कई SLO एक साथ विफल होते हैं। आप कैसे प्राथमिकता तय करते हैं?

महत्वपूर्ण उपयोगकर्ता जर्नी, ब्लास्ट रेडियस, बर्न रेट और प्रतिवर्तीता (reversibility) द्वारा रैंक करें। पहले उस संकेतक को संबोधित करें जो घटना का विस्तार कर सकता है या रिकवरी को रोक सकता है, फिर स्थानीय प्रदर्शन के मुद्दों को, और ट्रेडऑफ़ बताएं।

बजट खर्च होने के बाद एक उत्पाद प्रबंधक आपसे रिलीज़ करने के लिए कहता है। आप कैसे प्रतिक्रिया देते हैं?

बहस को डेटा में बदलें: शेष बजट, उपयोगकर्ता प्रभाव, रोलबैक लागत और मरम्मत का समय दिखाएं। एक छोटा प्रयोग या देरी की पेशकश करें। यदि कोई वास्तविक व्यावसायिक आपातकाल बना रहता है, तो पूरी तरह से रिकॉर्ड किए गए अपवाद का उपयोग करें और विश्वसनीयता कार्य और समीक्षा शेड्यूल करें।