प्रॉम्प्ट और संदर्भ
एक ऐसी सेवा डिज़ाइन करें जो कई सेवाओं के लिए SLOs, एरर बजट और बर्न रेट की गणना करती है और विश्वसनीयता गेट्स तथा अलर्ट ट्रिगर करती है। आप विलंबित डेटा (late data), विंडो, साइलेंस, बैकफिल और अपवादों को कैसे संभालते हैं?
यह SRE, प्लेटफ़ॉर्म, बैकएंड और सिस्टम-डिज़ाइन भूमिकाओं के लिए उपयुक्त है। Google SRE वर्कबुक एरर बजट को डिलीवरी की गति के साथ विश्वसनीयता को संतुलित करने के एक तरीके के रूप में वर्णित करती है, जबकि बर्न-रेट अलर्टिंग इस बात पर केंद्रित होती है कि वह बजट कितनी तेज़ी से समाप्त हो रहा है। डिज़ाइन को परिभाषाओं, गणना, अलर्ट, निर्णयों और ऑडिटेबिलिटी को आपस में जोड़ना होगा।
इंटरव्यूअर क्या जांच रहा है
- SLI इवेंट्स, SLO टार्गेट, अनुपालन अवधि (compliance period), एरर बजट और बर्न रेट में अंतर करना।
- यह समझाना कि तेज़ और धीमी विंडो एक-दूसरे की पूरक क्यों हैं और नॉइज़ को कैसे नियंत्रित किया जाता है।
- डिडुप्लीकेशन, विलंबित डेटा, डुप्लिकेट सैंपल, बैकफिल और वर्ज़न-नियंत्रित पुनर्गणना (versioned recomputation) को डिज़ाइन करना।
- अलर्ट को डिप्लॉयमेंट गेट्स, ऑन-कॉल प्रतिक्रिया, साइलेंस और मानवीय अपवादों से अलग करना।
- टेनेंट आइसोलेशन, क्वेरी लागत, ऐतिहासिक ट्रैसेबिलिटी और अनुमतियों के लिए सीमाएं निर्धारित करना।
- केवल डैशबोर्ड बनाने के बजाय डेटा-गुणवत्ता मेट्रिक्स और रीप्ले के साथ नीतियों को मान्य करना।
30-सेकंड उत्तर ढांचा
"मैं इस सेवा को SLO विनिर्देशों, इवेंट अंतर्ग्रहण (ingestion), विंडो एकत्रीकरण (aggregation), बजट गणना, नीति मूल्यांकन और अधिसूचना ऑडिट में विभाजित करूँगा। प्रत्येक SLO सफल और कुल इवेंट्स, टार्गेट, अनुपालन अवधि और वर्ज़न तय करता है; बर्न रेट प्रेक्षित त्रुटि दर को अनुमत त्रुटि दर से विभाजित करने पर प्राप्त होता है। एक तेज़ विंडो स्पाइक्स को पकड़ती है और एक धीमी विंडो नएपन (freshness) और सैंपल-साइज़ जांच के साथ निरंतरता की पुष्टि करती है। विलंबित या बैकफिल किया गया डेटा ऑडिट किए गए निर्णय को चुपचाप फिर से लिखने के बजाय एक वर्ज़न-नियंत्रित पुनर्गणना बनाता है।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: SLI और इवेंट अनुबंध को परिभाषित करें
एक SLO विनिर्देश सेवा का नाम, मेट्रिक प्रकार, सफल इवेंट्स, कुल इवेंट्स, टार्गेट, अनुपालन अवधि, एकत्रीकरण आयाम (aggregation dimensions) और समय क्षेत्र (timezone) को निर्दिष्ट करता है। काउंटरों को एक स्थिर डिडुप्लीकेशन कुंजी और इवेंट समय की आवश्यकता होती है। क्लाइंट कैंसलेशन, निर्भरता विफलताओं और प्लेटफ़ॉर्म दोषों को बिना किसी स्पष्ट नीति के मिश्रित नहीं किया जाना चाहिए। एक बार प्रकाशित होने के बाद, विनिर्देश को वर्ज़न दिया जाता है ताकि ऐतिहासिक गणनाएं उस समय सक्रिय वर्ज़न का उपयोग करें।
चरण 2: बजट और बर्न रेट की गणना करें
99.9% टार्गेट के लिए, अनुपालन अवधि में अनुमत त्रुटि अनुपात 0.1% है। बर्न रेट प्राप्त करने के लिए वर्तमान विंडो की त्रुटि दर को उस अनुमत दर से विभाजित करें: 1 नियोजित गति से बजट की खपत करता है, जबकि 1 से ऊपर का मान इसे तेजी से समाप्त करता है। केवल प्रतिशत को संरक्षित करने के बजाय रॉ काउंट और अंश (numerators), हर (denominators) और समय सीमाओं के साथ समुच्चय (aggregates) संग्रहीत करें ताकि परिणामों की पुनर्गणना की जा सके।
चरण 3: तेज़ और धीमी विंडो को संयोजित करें
एक तेज़ विंडो रिलीज़ स्पाइक का तुरंत पता लगाती है; एक धीमी विंडो पुष्टि करती है कि प्रभाव बना हुआ है। एक नीति दोनों विंडो की लंबाई, बर्न-रेट थ्रेशोल्ड, न्यूनतम इवेंट वॉल्यूम और आवश्यक मूल्यांकनों को रिकॉर्ड करती है। केवल तभी ट्रिगर करें जब डेटा का नयापन और हर (denominator) का आकार पर्याप्त हो। सेवाएं विभिन्न नीतियों का उपयोग कर सकती हैं, लेकिन टेम्प्लेट को हर अलर्ट को एक ही थ्रेशोल्ड में बाध्य करने के बजाय उसके उद्देश्य को स्पष्ट करना चाहिए।
चरण 4: विलंबित, डुप्लिकेट और बैकफिल किए गए डेटा को संभालें
इवेंट ID या टाइम बकेट द्वारा अंतर्ग्रहण (ingestion) को इडेम्पोटेंट बनाएं, और एक एकत्रीकरण वॉटरमार्क और सुधार वर्ज़न को सुरक्षित रखें। अनुमत विलंब के भीतर आने वाले लेट इवेंट्स पुनर्गणना को ट्रिगर करते हैं; इसके बाहर के इवेंट्स डेटा को अधूरा चिह्नित करते हैं। बैकफिल को किसी पुरानी अधिसूचना या गेट को चुपचाप नहीं बदलना चाहिए। पुराना मान, नया मान, ऑपरेटर, कारण और प्रभावित निर्णय ID रिकॉर्ड करें।
चरण 5: अलर्ट, गेट्स और अपवादों को कनेक्ट करें
अलर्ट सेवा सूचित और एस्केलेट करती है, डिप्लॉयमेंट कंट्रोलर रोक लगाता है या अनुमोदन का अनुरोध करता है, और नीति सेवा साक्ष्य-समर्थित स्थिति उत्सर्जित करती है। एक अपवाद का दायरा (scope), समाप्ति, अनुमोदक और कारण होता है। एक साइलेंस केवल अधिसूचना को रोकता है; यह बजट गणना को नहीं रोकता है। प्रत्येक गेट में SLO, विंडो, काउंट्स, नयापन और नियम वर्ज़न शामिल होते हैं ताकि निर्णय का ऑडिट किया जा सके।
चरण 6: सेवा को स्केल और निरीक्षण करें
सेवा, क्षेत्र और टेनेंट द्वारा एकत्रीकरण को शार्ड (shard) करें, उच्च-कार्डिनैलिटी आयामों को सीमित करें, और बार-बार होने वाली क्वेरीज़ को कैश करें। अंतर्ग्रहण अंतराल (ingestion lag), नुकसान, डुप्लिकेशन, एकत्रीकरण विलंब, मूल्यांकन समय, अधिसूचना सफलता और नीति त्रुटियों की निगरानी करें। विंडो को मान्य करने के लिए ऐतिहासिक घटनाओं को रीप्ले करें और एंड-टू-एंड इवेंट-टू-अलर्ट और इवेंट-टू-गेट लेटेंसी को मापने के लिए विफलताएं इंजेक्ट करें। अधूरे डेटा को स्वस्थ के रूप में रिपोर्ट करने के बजाय अज्ञात के रूप में दिखाया जाना चाहिए और एस्केलेट किया जाना चाहिए।
ट्रेड-ऑफ, सीमाएं और सूचना प्राप्ति
एरर-बजट सेवा विश्वसनीयता टार्गेट को एक ऑडिट योग्य इंजीनियरिंग निर्णय में बदल देती है। अधिक संवेदनशील बर्न-रेट थ्रेशोल्ड नॉइज़ और अलर्ट के बोझ को बढ़ाते हैं; लंबी विंडो अधिक धीमी गति से प्रतिक्रिया करती हैं। परिकलित तथ्यों, अधिसूचना कार्रवाइयों और डिप्लॉयमेंट निर्णयों को अलग रखें। ऐतिहासिक वर्ज़न को बनाए रखते हुए संशोधित पुनर्गणना की अनुमति दें। सेवा साझा साक्ष्य प्रदान करती है; यह टीम की प्राथमिकताओं का चयन नहीं करती है।
मॉडल उच्च-गुणवत्ता उत्तर
"मैं सफल और कुल इवेंट्स, टार्गेट, अनुपालन अवधि, आयामों और डिडुप्लीकेशन को कवर करने वाले एक वर्ज़न-नियंत्रित SLO विनिर्देश के साथ शुरुआत करूँगा। इडेम्पोटेंट अंतर्ग्रहण सेवा और विंडो द्वारा अंश, हर, समय सीमा और वॉटरमार्क संग्रहीत करता है। एकत्रीकरण त्रुटि दर, अनुमत त्रुटि दर और बर्न रेट की गणना करता है। नीति मूल्यांकन स्पाइक्स के लिए एक तेज़ विंडो और निरंतरता के लिए एक धीमी विंडो का उपयोग करता है, जो न्यूनतम वॉल्यूम और नएपन की जांच करता है।
अधिसूचनाएं, डिप्लॉयमेंट गेट्स और मानवीय अपवाद अलग-अलग उपभोक्ता हैं। साइलेंस अधिसूचना को दबाता है लेकिन गणना को चालू रखता है; एक गेट SLO, विंडो, काउंट्स, नियम और डेटा वर्ज़न के साथ साक्ष्य उत्सर्जित करता है; अपवाद अनुमोदित, समयबद्ध और ऑडिट योग्य होते हैं। विलंबित डेटा किसी पूर्व निर्णय को चुपचाप बदलने के बजाय एक वर्ज़न-नियंत्रित पुनर्गणना बनाता है।
बड़े पैमाने पर, मैं सेवा, क्षेत्र और टेनेंट द्वारा शार्डिंग करता हूँ, उच्च-कार्डिनैलिटी लेबल को सीमित करता हूँ, और अंतर्ग्रहण अंतराल, डुप्लिकेट, नुकसान, एकत्रीकरण विलंब और अधिसूचना सफलता की निगरानी करता हूँ। रीप्ले और फॉल्ट इंजेक्शन नीति को मान्य करते हैं। अधूरे डेटा को शून्य त्रुटियों के रूप में गिनने के बजाय अज्ञात चिह्नित किया जाता है और एस्केलेट किया जाता है।"
सामान्य गलतियां
- केवल SLO प्रतिशत संग्रहीत करना → सैंपल का आकार और सीमाएं गायब हो जाती हैं → अंश, हर, विंडो और वॉटरमार्क बनाए रखें।
- प्रत्येक सेवा के लिए एक थ्रेशोल्ड → जोखिम और ट्रैफ़िक भिन्न होते हैं → टार्गेट, वॉल्यूम और विंडो के आधार पर नीतियों का वर्ज़न बनाएं।
- साइलेंस को गणना रोकने के रूप में मानना → बजट के तथ्य खो जाते हैं → केवल सूचनाओं को दबाएं और ऑडिटिंग जारी रखें।
- विलंबित डेटा के साथ इतिहास को ओवरराइट करना → रिलीज़ निर्णयों का पुनर्निर्माण नहीं किया जा सकता है → पुनर्गणना का वर्ज़न बनाएं और पुराने तथा नए मानों को बनाए रखें।
- लापता डेटा को स्वस्थ मानना → संग्रह की विफलताएं छिप जाती हैं → अज्ञात दिखाएं और डेटा गुणवत्ता पर अलर्ट करें।
- गेट को अधिसूचना स्थिति पर निर्भर बनाना → अधिसूचना पुनः प्रयास (retries) रिलीज़ परिणामों को बदलते हैं → गेट्स अपरिवर्तनीय मूल्यांकन साक्ष्य पढ़ते हैं।
फॉलो-अप प्रश्न और उत्तर
तेज़ और धीमी दोनों विंडो का उपयोग क्यों करें?
तेज़ विंडो स्पाइक्स के लिए पहचान समय को कम करती है; धीमी विंडो क्षणिक नॉइज़ को फ़िल्टर करती है और निरंतर बजट खपत की पुष्टि करती है। साथ में वे प्रतिक्रिया गति और गलत सकारात्मक (false positives) को संतुलित करते हैं, लेकिन थ्रेशोल्ड को इवेंट वॉल्यूम के विरुद्ध मान्य किया जाना चाहिए।
बैकफिल द्वारा बर्न रेट बदलने के बाद पुराने अलर्ट का क्या होता है?
पुराने मूल्यांकन और अधिसूचना रिकॉर्ड रखें, नए डेटा वर्ज़न के साथ टैग की गई एक पुनर्गणना बनाएं, और बताएं कि क्या वर्तमान गेट बदलता है। इतिहास को न हटाएं; रिस्पॉन्डर्स को उस समय उपलब्ध तथ्यों की आवश्यकता होती है।
आप उच्च-कार्डिनैलिटी आयामों को सिस्टम पर हावी होने से कैसे रोकते हैं?
अनुमत लेबलों को सीमित करें, टियर के आधार पर टेनेंट या रूट स्लाइस का सैंपल लें, केवल मूल्यवान दृश्यों को मटीरियलाइज़ करें, और क्वेरी बजट तथा टाइमआउट लागू करें। सेवा-स्तरीय SLO को असीमित आयामों की आवश्यकता नहीं होनी चाहिए।
अपवाद गेट्स को स्थायी रूप से बायपास करने से कैसे बचते हैं?
प्रत्येक अपवाद को किसी सेवा, परिवर्तन या समय सीमा से बांधें, एक अनुमोदक और कारण की आवश्यकता रखें, और स्वचालित समाप्ति लागू करें। बाद में डिफ़ॉल्ट नीति को पुनर्स्थापित करें और एक ऑडिट मेट्रिक के रूप में अपवाद कवरेज को मापें।