प्रॉम्प्ट और संदर्भ
सर्विस का 99.99% उपलब्धता SLO और 0.01% मासिक एरर बजट है। यूज़र-विज़िबल विफलताएं बजट से अधिक हो चुकी हैं, फिर भी एक प्रमुख अनुबंध नवीनीकरण (renewal) को प्रभावित करने वाला फ़ीचर रिलीज़ के इंतज़ार में है। समझाइए कि आप संकेतकों (indicators) को कैसे परिभाषित करेंगे, यह कैसे सत्यापित करेंगे कि बजट वास्तव में समाप्त हो चुका है, यह कैसे तय करेंगे कि किन बदलावों को रोकना है, और एक स्वस्थ रिलीज़ गति कैसे बहाल करेंगे।
Google SRE एरर बजट को एक SLO द्वारा अनुमत विफलता की गुंजाइश मानता है: जब तक यह बचा रहता है, टीमें उचित सीमा के भीतर रिलीज़ कर सकती हैं; इसके समाप्त होने के बाद, सामान्य रूप से बदलाव फ्रीज़ कर दिए जाते हैं, सिवाय तत्काल सुरक्षा फ़िक्स और वर्तमान विफलता के समाधानों के। यह जोखिम से जुड़े निर्णयों के लिए एक इनपुट है, न कि बिना शर्त प्रोडक्ट पर लगाया गया कोई प्रतिबंध।
इंटरव्यूअर क्या जांच रहा है
एक मजबूत उत्तर यूज़र-केंद्रित SLIs से शुरू होता है और बजट की खपत को रिलीज़, रोलबैक और रिकवरी समय से जोड़ता है। इस बात पर प्रश्नों की अपेक्षा करें कि सर्वर मेट्रिक्स यूज़र उपलब्धता को गलत तरीके से क्यों प्रस्तुत कर सकते हैं, एक संक्षिप्त स्पाइक को निरंतर बर्न (burn) से कैसे अलग किया जाए, कौन से साक्ष्य अपवाद को उचित ठहराते हैं, और फ्रीज़ को कौन हटा सकता है।
"सभी डेवलपमेंट को रोक देना" सुरक्षा, डेटा अखंडता (data integrity) और अनुपालन (compliance) दायित्वों की अनदेखी करता है। "बिजनेस महत्वपूर्ण है, इसलिए रिलीज़ कर दो" जोखिम की एक साझा समझ और भाषा को त्याग देता है।
पहले स्पष्ट करने योग्य प्रश्न
यूज़र प्रभाव और मेट्रिक सीमा
पुष्टि करें कि SLIs वास्तविक यूज़र यात्राओं (user journeys) से आते हैं और उनमें क्लाइंट्स, निर्भरताएं (dependencies) और महत्वपूर्ण वर्कफ़्लो शामिल हैं। रिक्वेस्ट विफलताओं, लेटेंसी, गलत डेटा और अनुपलब्धता को अलग-अलग करें; एक अकेला औसत टेल लेटेंसी (tail latency) या किसी एक ग्राहक वर्ग पर पड़ने वाले गंभीर प्रभाव को छिपा सकता है।
बजट विंडो और बर्न रेट
स्पष्ट करें कि बजट मासिक, त्रैमासिक या रोलिंग है, साथ ही वर्तमान बर्न रेट और अनिश्चितता क्या है। शेष बजट को केवल एक प्रतिशत दिखाने के बजाय इस बात का उत्तर देना चाहिए कि "हम इसे कब तक बनाए रख सकते हैं?"
मूल्य और रिलीज़ जोखिम
राजस्व (revenue), अनुपालन और सुरक्षा मूल्य का आकलन करें। क्या फ़ीचर को कैनरी (canary) रिलीज़ किया जा सकता है, रोलबैक किया जा सकता है, या चुनिंदा टेनेंट्स (tenants) तक सीमित किया जा सकता है? सत्यापन-योग्य मूल्य और रिकवरी मार्ग के बिना, ग्राहक का दबाव जोखिम का साक्ष्य नहीं माना जा सकता।
30-सेकंड का उत्तर
"मैं सबसे पहले यूज़र-साइड SLIs, SLO विंडो और बर्न की पुष्टि करता हूं, और जांचता हूं कि सिग्नल निरंतर है या कोई इंस्ट्रूमेंटेशन त्रुटि है। यदि बजट वास्तव में समाप्त हो गया है, तो मैं गैर-ज़रूरी रिलीज़ को रोकता हूं और क्षमता तथा इंजीनियरिंग प्रयासों को SLO बहाल करने, कारणों को ठीक करने और मॉनिटरिंग को मान्य करने में लगाता हूं। सुरक्षा, अनुपालन या इंसिडेंट-मिटिगेशन से जुड़े बदलाव तब अपवाद हो सकते हैं जब वे छोटे, प्रतिवर्ती (reversible) हों और उनका एक स्पष्ट ओनर हो। प्रमुख-ग्राहक फ़ीचर के लिए, मैं टेनेंट आइसोलेशन या विलंबित कैनरी का प्रयास करूंगा, और फिर आगे बढ़ने का निर्णय लेने के लिए जोखिम समीक्षा का उपयोग करूंगा। एक बार सहमत बजट मार्जिन वापस आ जाने पर, मैं धीरे-धीरे रिलीज़ को फिर से खोलूंगा और समीक्षा करूंगा कि क्या SLO वास्तविक यूज़र मूल्य का प्रतिनिधित्व करता है।"
चरण-दर-चरण समाधान
चरण 1: SLIs को यूज़र परिणामों के रूप में परिभाषित करें
जहाँ तक संभव हो क्लाइंट या एज डेटा का उपयोग करके महत्वपूर्ण वर्कफ़्लो के लिए सफलता दर, एंड-टू-एंड लेटेंसी और सटीकता को परिभाषित करें। स्पष्ट करें कि एक मान्य रिक्वेस्ट क्या मानी जाएगी, मेंटेनेंस विंडो क्या होगी और टेनेंट विभाजन कैसा होगा। यदि उपयोगकर्ताओं को एक्सपोर्ट पूरा होने की चिंता है, तो केवल API 200 पर निर्भर रहने के बजाय एक जॉब-कम्प्लीशन SLI बनाएं।
चरण 2: बजट और बर्न की गणना करें
99.99% उपलब्धता लक्ष्य चुनी गई विंडो में 0.01% विफलता अनुपात की अनुमति देता है; मिनटों की संख्या विंडो और गणना पद्धति पर निर्भर करती है। शेष बजट, बर्न रेट और अनिश्चितता की गणना के लिए एक ही क्वेरी का उपयोग करें और डेटा विलंब को लेबल करें। किसी विसंगति पर कार्रवाई करने से पहले, डुप्लिकेट गणना, अनुपलब्ध टेलीमेट्री और निर्भरता एट्रिब्यूशन की जांच करें।
चरण 3: रिलीज़ गेट्स स्थापित करें
जब बजट स्वस्थ हो, तब भी सामान्य रिलीज़ के लिए रोलबैक और मॉनिटरिंग की आवश्यकता होती है। जैसे-जैसे यह समाप्ति के करीब पहुंचे, समीक्षा का स्तर बढ़ाएं और बैच तथा कैनरी एक्सपोज़र को कम करें। एक बार समाप्त हो जाने पर, गैर-ज़रूरी बदलावों को फ्रीज़ कर दें; केवल इंसिडेंट फ़िक्स, डेटा-इंटीग्रिटी कार्य, गंभीर सुरक्षा, या रोलबैक साक्ष्य वाले अनुपालन परिवर्तनों की अनुमति दें। मौखिक सहमति पर निर्भर रहने के बजाय इस गेट को टूलींग और एक उत्तरदायित्व मैट्रिक्स (responsibility matrix) में कोड करें।
चरण 4: किसी अपवाद का मूल्यांकन करें
प्रत्येक अपवाद के लिए, यूज़र लाभ, जोखिम, प्रभावित टेनेंट्स, प्रतिशत, रोलबैक शर्त और अवलोकन विंडो (observation window) को रिकॉर्ड करें। एक ही टेनेंट तक आइसोलेशन, शैडो ट्रैफ़िक या आंतरिक यूज़र्स उपयोगी साक्ष्य हैं। प्रोडक्ट, बदलाव का ओनर और SRE मिलकर स्वीकृति देते हैं; केवल बिक्री का वादा अकेले निर्णय नहीं ले सकता।
चरण 5: पूर्णता के पीछे भागने से पहले विश्वसनीयता बहाल करें
फ्रीज़ के दौरान, रिकवरी SLO, बजट मार्जिन और समय सीमा के साथ मूल कारणों (root causes), क्षमता सीमाओं और मॉनिटरिंग अंतरालों को ठीक करें। यदि लक्ष्य लंबी अवधि के असामान्य प्रयासों को मजबूर करता है, तो समीक्षा के दौरान इसे समायोजित करें, लेकिन किसी रिलीज़ को संभव बनाने के लिए विंडो को न बदलें और न ही पिछली विफलताओं को बाहर निकालें।
चरण 6: ग्राहकों और टीमों के साथ संवाद करें
प्रभावित वर्कफ़्लो, समय सीमा, शमन उपायों (mitigations) और अगले अपडेट के बारे में बताएं। ग्राहक फ़ीचर के लिए एक सत्यापन-योग्य विकल्प या शेड्यूल प्रदान करें; अप्रमाणित रिकवरी समय का वादा न करें। प्रोडक्ट और इंजीनियरिंग के बीच राजनीतिक बातचीत और खींचतान को कम करने के लिए आंतरिक रूप से एक ही बजट डैशबोर्ड, इंसिडेंट टाइमलाइन और ओनर सूची का उपयोग करें।
चरण 7: रिकवरी को नियंत्रित (govern) करें
जब बजट सहमत सीमा तक पहुंच जाए, तो छोटे बैचों से शुरुआत करते हुए चरणों में रिलीज़ को फिर से खोलें। विफल बदलावों, पहचान में देरी, रोलबैक अवधि और ग्राहक प्रभाव की समीक्षा करें। यदि SLO यूज़र मूल्य का प्रतिनिधित्व नहीं करता है, तो डेटा-समर्थित बदलाव का प्रस्ताव दें। त्रैमासिक जोखिम समीक्षा के लिए फ्रीज़, अपवाद, अनुमोदन और परिणाम रिकॉर्ड बनाए रखें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं केवल "बिक्री का काम ज़रूरी है" या "बजट शून्य है" के आधार पर कोई पूर्ण निर्णय नहीं लूंगा। मैं इंस्ट्रूमेंटेशन और डुप्लिकेट गणना त्रुटियों को बाहर करते हुए, यूज़र-साइड SLIs, सांख्यिकीय विंडो, डेटा अखंडता और बर्न रेट को मान्य करूंगा। यदि बजट वास्तव में समाप्त हो चुका है, तो मैं गैर-ज़रूरी रिलीज़ को फ्रीज़ कर दूंगा और रिकवरी, सुधार और मॉनिटरिंग में निवेश करूंगा। सुरक्षा, अनुपालन, डेटा मरम्मत और इंसिडेंट मिटिगेशन के लिए अपवाद का अनुरोध किया जा सकता है।
यदि प्रमुख ग्राहक वाले फ़ीचर को आगे बढ़ाना ही है, तो मैं टेनेंट्स को आइसोलेट करूंगा, एक छोटी कैनरी का उपयोग करूंगा, स्वचालित रोलबैक जोड़ूंगा और एक अवलोकन विंडो परिभाषित करूंगा। लाभ, जोखिम और रोकने की शर्तों को रिकॉर्ड करने के साथ प्रोडक्ट, चेंज ओनर और SRE संयुक्त रूप से अनुमोदन करेंगे। बजट रिकवर होने के बाद, मैं धीरे-धीरे फ्रीज़ हटाऊंगा और लक्ष्यों या प्रक्रिया को बदलने से पहले समीक्षा करूंगा कि क्या SLO वास्तविक यूज़र परिणामों को मापता है।
सामान्य गलतियाँ
- गलती: बजट समाप्त होने के बाद हर बदलाव को फ्रीज़ कर देना। → यह विफल क्यों होता है: सुरक्षा, डेटा मरम्मत और इंसिडेंट मिटिगेशन में देरी हो सकती है। → सुधार: सीमित अपवाद, अनुमोदक और रोलबैक साक्ष्य परिभाषित करें।
- गलती: केवल औसत सर्वर लेटेंसी का उपयोग करना। → यह विफल क्यों होता है: यह क्लाइंट विफलताओं, टेल लेटेंसी और प्रमुख-टेनेंट के अनुभव को अनदेखा कर देता है। → सुधार: यूज़र यात्राओं के आधार पर एंड-टू-एंड SLIs परिभाषित करें।
- गलती: रिलीज़ को संभव बनाने के लिए SLO विंडो को बदलना या विफलताओं को बाहर करना। → यह विफल क्यों होता है: बजट तुलना करने की क्षमता खो देता है और जोखिम को छिपाता है। → सुधार: वर्तमान विंडो बनाए रखें और बाद के परिवर्तनों के लिए औपचारिक गवर्नेंस का उपयोग करें।
- गलती: एक सफल कैनरी को पूर्ण रिलीज़ का प्रमाण मानना। → यह विफल क्यों होता है: एक्सपोज़र, निर्भरताएं और टेल जोखिम भिन्न होते हैं। → सुधार: स्वचालित रोलबैक के साथ धीरे-धीरे विस्तार करें।
फ़ॉलो-अप प्रश्न और उत्तर
फ़ॉलो-अप 1: 99.99% कितना बजट दर्शाता है?
चुनी गई विंडो में अनुमत विफलता अनुपात 0.01% है। इसे मिनटों में बदलने के लिए विंडो, गणना विधि, और यह जानने की आवश्यकता है कि मेट्रिक रिक्वेस्ट-आधारित है या समय-आधारित। मुख्य बात यह है कि बिना शर्त कोई संख्या प्रस्तुत करने के बजाय विंडो को स्पष्ट किया जाए।
फ़ॉलो-अप 2: क्या सेल्स द्वारा वादा किया गया फ़ीचर एक अपवाद है?
केवल व्यावसायिक मूल्य ही अपवाद नहीं देता। यूज़र, राजस्व या अनुपालन प्रभाव दिखाएं; आइसोलेशन, कैनरी, रोलबैक और अवलोकन साक्ष्य प्रदान करें; और संयुक्त अनुमोदन प्राप्त करें। यदि एक्सपोज़र को कम नहीं किया जा सकता है, तो फ़ीचर में देरी करें और एक वैकल्पिक समाधान पेश करें।
फ़ॉलो-अप 3: क्या होगा यदि बजट गणना गलत हो सकती है?
समानांतर रूप से टेलीमेट्री कवरेज, डुप्लिकेट गणना, समय विलंब, निर्भरता एट्रिब्यूशन और क्लाइंट नमूनों की जांच करते हुए उच्च जोखिम वाले रिलीज़ को फ्रीज़ करें। सुधार के बाद पुनर्गणना करें, लेकिन परिणाम अनिश्चित होने पर एक्सपोज़र न बढ़ाएं।
फ़ॉलो-अप 4: SLO को कब बदलना चाहिए?
इसे तब बदलें जब स्थिर संचालन और समीक्षा डेटा से पता चले कि लक्ष्य यूज़र मूल्य, लागत या क्षमता से मेल नहीं खाता है। पहले पुराने लक्ष्य, नए लक्ष्य, प्रभाव और अनुमोदक को रिकॉर्ड करें। कोई आउटेज या रिलीज़ का दबाव तदर्थ (ad-hoc) रूप से लक्ष्य को कम करने का कारण नहीं हो सकता।
फ़ॉलो-अप 5: आपको कैसे पता चलेगा कि फ्रीज़ समाप्त हो गया है?
रिकवरी की शर्तों को पहले से परिभाषित करें: अवलोकन विंडो के लिए SLI लक्ष्य को पूरा करता है, बजट एक निश्चित सीमा तक फिर से बन गया है, मूल कारणों के सुधार सत्यापित हैं, और रोलबैक काम करता है। फिर तुरंत पूरी गति पर लौटने के बजाय एक छोटे बैच के साथ शुरुआत करें और मॉनिटरिंग जारी रखें।