9.1 साइट रिलायबिलिटी इंजीनियरिंग

अवलोकन और प्रेरणा

साइट रिलायबिलिटी इंजीनियरिंग (SRE) प्रोडक्शन सिस्टम चलाने में सॉफ़्टवेयर इंजीनियरिंग प्रथाओं को लागू करती है। संचालन को डेवलपमेंट से अलग रखा गया मैनुअल, टिकट-संचालित काम मानने के बजाय, SRE विश्वसनीयता को एक इंजीनियरिंग समस्या मानती है जिसे आप कोड, मापन, और स्पष्ट सर्विस उद्देश्यों से हल करते हैं। मूल विचार, जिसे Google ने लोकप्रिय बनाया लेकिन जो अब व्यापक है, सरल है: जो लोग सिस्टम को चालू रखते हैं उन्हें अपना अधिकांश समय बार-बार हाथ से उन्हीं विफलताओं से लड़ने के बजाय स्वचालन बनाने और सिस्टम सुधारने में बिताना चाहिए।

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

एंटरप्राइज़ और सरकारी संदर्भ अतिरिक्त वज़न जोड़ते हैं। बैंकिंग, स्वास्थ्य सेवा, और सार्वजनिक सेवाओं जैसे विनियमित उद्योग अक्सर कानूनी या संविदात्मक उपलब्धता प्रतिबद्धताएँ, ऑडिट आवश्यकताएँ, और ऐसे आउटेज के प्रति बहुत कम सहनशीलता रखते हैं जो नागरिकों या सुरक्षा को प्रभावित करते हैं। सरकारी डिजिटल सेवाएँ तेज़ी से अपने विश्वसनीयता लक्ष्यों और प्रदर्शन डेटा को खुले में प्रकाशित करती हैं। SRE आपको यह परिभाषित करने का एक कठोर, साक्ष्य-आधारित तरीका देती है कि “पर्याप्त रूप से विश्वसनीय” का क्या मतलब है, इसे ईमानदारी से मापें, और राय के बजाय डेटा के साथ नेतृत्व और निरीक्षण निकायों के सामने इंजीनियरिंग प्राथमिकताओं का बचाव करें।

यह भी देखें: अध्याय 9.2 (ऑब्ज़र्वेबिलिटी और निगरानी), अध्याय 9.3 (घटना प्रबंधन), और अध्याय 3.5 (स्केलेबिलिटी, प्रदर्शन, और लचीलापन)।

मुख्य सिद्धांत

• विश्वसनीयता सबसे महत्वपूर्ण फ़ीचर है। एक सिस्टम जो काम नहीं करता वह बेकार है चाहे उसमें कितने भी फ़ीचर हों, लेकिन पूर्ण विश्वसनीयता न तो प्राप्त करने योग्य है और न ही अपनी लागत के लायक है।
• मापने योग्य उद्देश्यों से विश्वसनीयता को परिभाषित करें। सर्विस लेवल इंडिकेटर (SLI), उद्देश्य (SLO), और समझौते (SLA) अस्पष्ट अपेक्षाओं को उन संख्याओं में बदल देते हैं जिन पर हर कोई सहमत हो सकता है।
• 100 प्रतिशत गलत लक्ष्य है। उपयोगकर्ता एक बहुत विश्वसनीय सिस्टम और एक पूर्णतः विश्वसनीय सिस्टम के बीच अंतर नहीं बता सकते, इसलिए “पर्याप्त रूप से विश्वसनीय” का लक्ष्य रखें और बाकी बजट वेलोसिटी पर खर्च करें।
• एरर बजट प्रेरणाओं को संरेखित करते हैं। SLO और 100 प्रतिशत के बीच का अंतर जोखिम के लिए एक बजट है जिसे डेवलपर्स और ऑपरेटर साझा करते हैं, तर्कों को अंकगणित से बदलते हुए।
• टॉइल दुश्मन है। दोहराव वाला, मैनुअल, स्वचालित करने योग्य परिचालन कार्य मापा, सीमित, और व्यवस्थित रूप से समाप्त किया जाना चाहिए।
• जानबूझकर स्वचालित करें। स्वचालन वह तरीका है जिससे एक छोटी टीम एक बड़े सिस्टम को संचालित करती है; इसमें निवेश करना एक प्रथम-श्रेणी इंजीनियरिंग गतिविधि है।
• दोषरहित सीखना। विफलताओं को व्यक्तियों को दंडित करने के बजाय सिस्टम और प्रक्रियाओं को सुधारने के अवसरों के रूप में माना जाता है।

सिफ़ारिशें

SLI, SLO, और SLA को जानबूझकर परिभाषित करें

उपयोगकर्ता के दृष्टिकोण से शुरू करें। एक सर्विस लेवल इंडिकेटर किसी सेवा के व्यवहार का एक मात्रात्मक माप है, जैसे 300 मिलीसेकंड से कम में सेवा किए गए अनुरोधों का अनुपात या सफल प्रतिक्रियाओं का अंश। SLI की एक छोटी संख्या चुनें जो वास्तव में उपयोगकर्ता की खुशी को दर्शाती है: उपलब्धता, विलंबता, सटीकता, और ताज़गी सामान्य हैं। एक सर्विस लेवल ऑब्जेक्टिव किसी SLI के लिए एक लक्ष्य मान या सीमा है, उदाहरण के लिए “एक चलते 28-दिन विंडो में 99.9 प्रतिशत अनुरोध सफल होते हैं।” एक सर्विस लेवल एग्रीमेंट एक वादा किए गए स्तर से जुड़े परिणामों (रिफ़ंड, जुर्माना) वाला एक अनुबंध है। अपने SLO को अपने SLA से सख्त रखें, ताकि किसी प्रतिबद्धता को तोड़ने से पहले आपको चेतावनी मिले। अपने SLO प्रकाशित करें, उन्हें त्रैमासिक समीक्षा करें, और उन्हें जीवंत दस्तावेज़ मानें जो सीखने के साथ कसते या ढीले होते हैं।

एरर बजट अपनाएँ और उन्हें लागू करें

एरर बजट है 100% minus the SLO। यदि आपका SLO 99.9 प्रतिशत है, तो आपका बजट प्रति विंडो अविश्वसनीयता का 0.1 प्रतिशत है, लगभग 43 मिनट प्रति माह। इसे नियोजित जोखिम पर खर्च करें: आक्रामक रिलीज़, प्रयोग, और नियंत्रित विफलता परीक्षण। जब बजट स्वस्थ हो, तो टीमें तेज़ी से शिप कर सकती हैं। जब यह समाप्त हो जाए, तो नीति को स्वतः विश्वसनीयता कार्य की ओर प्राथमिकताएँ स्थानांतरित करनी चाहिए और सिस्टम के ठीक होने तक जोखिम भरे परिवर्तनों को रोक देना चाहिए। एरर बजट की शक्ति यह है कि आप इस पर पहले से सहमत होते हैं, इसलिए यह आउटेज के क्षण से भावना और राजनीति को हटा देता है।

टॉइल को मापें और कम करें

टॉइल परिचालन कार्य है जो मैनुअल, दोहराव वाला, स्वचालित करने योग्य, सामरिक है, और सिस्टम के साथ कदम मिलाकर बढ़ता है। टॉइल पर खर्च किए गए SRE समय का प्रतिशत ट्रैक करें और एक सीमा तय करें, आमतौर पर लगभग 50 प्रतिशत, ताकि आपका कम से कम आधा इंजीनियरिंग समय टिकाऊ सुधारों में जाए। टॉइल-कमी परियोजनाओं का एक बैकलॉग रखें, आवृत्ति गुणा लागत से प्राथमिकता दें, और किसी दोहराए जाने वाले कार्य को खत्म करने का उतना ही जश्न मनाएँ जितना किसी नए फ़ीचर को शिप करने का। एक स्वचालन आदेश इसे स्पष्ट बनाता है: कोई भी मैनुअल प्रक्रिया जिसे आप एक निर्धारित संख्या से अधिक बार करते हैं, वह स्वचालन या स्व-सेवा टूलिंग की उम्मीदवार बन जाती है।

क्षमता की योजना बनाएँ और माँग का पूर्वानुमान लगाएँ

ऐतिहासिक रुझानों, नियोजित लॉन्च, और व्यावसायिक अनुमानों से अपने अपेक्षित लोड को मॉडल करें। जैविक विकास पूर्वानुमानों को एक-बार की घटनाओं जैसे मार्केटिंग अभियान, कर की समय-सीमा, या लाभ-नामांकन अवधि के साथ जोड़ें जो सरकार में बहुत मायने रखती हैं। पीक से ऊपर हेडरूम रखें, अपनी धारणाओं की जाँच के लिए लोड-टेस्ट करें, और जहाँ हो सके स्केलिंग को स्वचालित करें जबकि बड़ी प्रतिबद्धताओं के लिए एक इंसान-समीक्षित क्षमता योजना रखें। प्रोविज़निंग के लिए लीड टाइम ट्रैक करें ताकि कोई कमी आपको कभी अनजान न पकड़े।

विश्वसनीयता को वास्तविक लागत वाला फ़ीचर मानें

उपलब्धता का हर अतिरिक्त “नाइन” आमतौर पर पिछले वाले की तुलना में रिडंडेंसी, टेस्टिंग, और परिचालन परिष्कार में कहीं अधिक लागत लेता है। नाइन की लागत को स्पष्ट बनाएँ, ताकि उत्पाद स्वामी आँखें खुली रखकर लक्ष्य चुनें। सुचारू क्षरण के लिए डिज़ाइन करें, ताकि आंशिक विफलताएँ पूर्ण आउटेज के बजाय कम सेवा दें। SLO के अनुपात में रिडंडेंसी और फ़ेलओवर में निवेश करें, हर घटक में समान रूप से नहीं।

एक SRE संगठनात्मक मॉडल चुनें

कोई एकल सही संरचना नहीं है। एक केंद्रीकृत SRE टीम आपको संगति, गहरी विशेषज्ञता, और साझा टूलिंग देती है, लेकिन यह एक बाधा या दूसरों की समस्याओं के लिए डंपिंग ग्राउंड बन सकती है। एक एम्बेडेड मॉडल करीबी सहयोग के लिए SRE को उत्पाद टीमों के भीतर रखता है, लेकिन यह असंगति और अलगाव का जोखिम उठाता है। कई बड़े संगठन एक हाइब्रिड का उपयोग करते हैं: एक केंद्रीय प्लेटफ़ॉर्म और मानक टीम साथ ही एम्बेडेड विश्वसनीयता इंजीनियर, एक स्पष्ट सहभागिता मॉडल के साथ जो परिभाषित करता है कि कोई सेवा कब SRE समर्थन के लिए योग्य होती है और उसे पहले किस प्रोडक्शन-तैयारी मानदंड को पार करना चाहिए।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

निर्णय	फ़ायदे	नुकसान
सख्त SLO (अधिक नाइन)	उच्च उपयोगकर्ता विश्वास, अनुबंध पूरे करता है	बढ़ती लागत, धीमी फ़ीचर डिलीवरी
ढीले SLO (कम नाइन)	तेज़ शिपिंग, कम लागत	उपयोगकर्ता चर्न और SLA जुर्माने का जोखिम
केंद्रीकृत SRE	संगति, साझा विशेषज्ञता	बाधाएँ, उत्पाद से दूरी
एम्बेडेड SRE	करीबी सहयोग, संदर्भ	असंगति, स्टाफ़ करना कठिन
भारी स्वचालन निवेश	स्केल करता है, टॉइल घटाता है	अग्रिम लागत, स्वचालन खुद विफल हो सकता है

विश्वसनीयता इंजीनियरिंग वास्तव में सीमित संसाधनों को समझदारी से खर्च करने के बारे में है। एक अतिरिक्त नाइन के पीछे भागना जिसे उपयोगकर्ता महसूस भी नहीं कर सकते, ऐसा पैसा बर्बाद करता है जो फ़ीचर्स को वित्तपोषित कर सकता था या कीमतें कम कर सकता था। दूसरी दिशा में जाएँ और किसी ऐसे सिस्टम में कम-निवेश करें जिसकी विफलताएँ वास्तविक नुकसान करती हैं, और यह लापरवाही है। एरर बजट फ़्रेमवर्क ठीक इसीलिए मौजूद है कि इस ट्रेड-ऑफ़ को स्पष्ट और परक्राम्य बनाया जाए बजाय अंतर्निहित और विवादास्पद के। संगठनात्मक मॉडल का ट्रेड-ऑफ़ भी उतना ही वास्तविक है: सही उत्तर कंपनी के आकार, इंजीनियरिंग परिपक्वता, और आपकी सेवाएँ कितनी समरूप हैं इस पर निर्भर करता है।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. कौन-सा सटीक SLI यह दर्शाता है कि आपके उपयोगकर्ता वास्तव में क्या महसूस करते हैं, और क्या आप दिखा सकते हैं कि यह कोई वैनिटी मीट्रिक नहीं है? गलत इंडिकेटर चुनें और हर डैशबोर्ड हरा दिखता है जबकि उपयोगकर्ता तकलीफ़ में होते हैं, जो कि वैनिटी-SLI जाल है जिसके बारे में यह अध्याय चेतावनी देता है। चर्चा में वास्तविक डेटा लाएँ: सर्वर CPU या बैकएंड हेल्थ चेक के बजाय एक वास्तविक अनुरोध पथ (लॉगिन से डैशबोर्ड, चेकआउट से पुष्टिकरण) से एक ही उपयोगकर्ता यात्रा को मापें। एक बड़ी टीम के लिए, एक खराब SLI फैलता है: दर्जनों सेवाएँ इसे विरासत में लेती हैं, गलत चीज़ पर अलर्ट फायर होते हैं, और एरर बजट का कोई मतलब नहीं रह जाता। एंटरप्राइज़ और सरकारी सेटिंग्स में जहाँ एक SLA रिफ़ंड या नागरिक प्रभाव लेकर आता है, आपका SLI वह साक्ष्य है जिसका आप ऑडिटर्स के सामने बचाव करते हैं, इसलिए इसे सीधे उपयोगकर्ता-दृश्य सफलता तक जाना चाहिए। यदि आप संख्या से किसी उपयोगकर्ता के अनुभव तक कोई रेखा नहीं खींच सकते, तो संख्या बदल दें।

2. आपकी SRE टीम इसे ऑन-कॉल लेने से पहले किसी सेवा को क्या साबित करना होगा, और मना कौन करता है? बिना किसी प्रोडक्शन-तैयारी मानदंड के, एक केंद्रीय SRE टीम हर अस्थिर सेवा के लिए डंपिंग ग्राउंड बन जाती है और दूसरों के तकनीकी ऋण में डूब जाती है। प्रवेश मानदंड लिखें: एक स्वामित्व वाला SLO, काम करने वाली रनबुक, कार्रवाई करने योग्य अलर्ट, क्षमता हेडरूम, और एक प्रदर्शित डिप्लॉय-और-रोलबैक पथ। एक बड़े संगठन के लिए यह सहभागिता मॉडल वही है जो विश्वसनीयता टीम को एक ऐसी बाधा बनने से रोकता है जो सबको धीमा करती है। विनियमित सेटिंग्स में तैयारी समीक्षा एक नियंत्रण के रूप में भी काम करती है जिसे आप निरीक्षण निकायों को दिखा सकते हैं। तय करें कि ऑनबोर्डिंग से इनकार करने का अधिकार किसके पास है, क्योंकि जिस मानदंड को कोई लागू नहीं करता वह मानदंड नहीं है, और यह उत्तर तय करता है कि SRE स्केल करता है या विरासत में मिली पीड़ा के तहत ढह जाता है।

3. आप अपने सबसे बड़े अनुमानित पीक के लिए कितने आगे पूर्व-प्रोविज़न करते हैं, और क्या आप अपना प्रोविज़निंग लीड टाइम जानते हैं? यह मान लेना कि क्लाउड इलास्टिसिटी तत्काल और अनंत है, ठीक उन्हीं पीक के दौरान कमी को आमंत्रित करता है जो सबसे अधिक मायने रखते हैं, और वे पीक (कर की समय-सीमा, नामांकन विंडो, सेल इवेंट) वही क्षण हैं जब विफलता सबसे अधिक दिखाई देती है और सबसे महंगी होती है। संख्याएँ लाएँ: ऐतिहासिक पीक लोड, पूर्वानुमानित विकास, वह गुणक जिस तक आप लोड-टेस्ट करते हैं, और बड़ी आरक्षित क्षमता या विशेष इंस्टेंस प्राप्त करने का वास्तविक लीड टाइम। सरकारी मौसमी सेवाओं के लिए पीक सामान्य लोड से कई गुना हो सकता है और राजनीतिक रूप से अनदेखा नहीं किया जा सकता, इसलिए हफ़्तों पहले पूर्व-प्रोविज़निंग यह उम्मीद करने से बेहतर है कि ऑटोस्केलिंग कदम मिला लेगी। उत्तर को एक ठोस कैलेंडर तय करना चाहिए: आप कब लोड-टेस्ट करते हैं, कब क्षमता लॉक करते हैं, और गो निर्णय का स्वामी कौन है।

4. जब आपका एरर बजट समाप्त हो जाता है, तो वास्तव में क्या होता है, और इसे लागू करने की स्थिति किसके पास है? एक एरर बजट जिस पर समाप्त होने पर कभी कार्रवाई नहीं की जाती वह केवल सजावट है, और आउटेज का क्षण नीति पर शून्य से बातचीत करने का सबसे खराब समय है। प्रतिस्पर्धी खिंचाव वास्तविक है: एक प्रतिबद्ध लॉन्च, राजस्व की समय-सीमा, या सार्वजनिक घोषणा जोखिम भरे परिवर्तनों पर एक फ़्रीज़ के खिलाफ ज़ोरदार दबाव डालेगी। बर्न-रेट डेटा, पहले से सहमत नीति पाठ, और पिछली कुछ बार जब बजट टूटा था उसका रिकॉर्ड लाएँ, ताकि आप देख सकें कि क्या फ़्रीज़ वास्तव में लागू रहा। एक बड़ी टीम के लिए बजट तभी प्रेरणाओं को संरेखित करता है जब हर समूह उसी प्रवर्तन को विरासत में लेता है, इसलिए पहले से तय करें कि ओवरराइड पर कौन हस्ताक्षर करता है और उस अपवाद को कैसे लॉग किया जाता है। एंटरप्राइज़ और सरकारी सेटिंग्स में जहाँ एक SLA जुर्माना या नागरिक प्रभाव लेकर आता है, ओवरराइड ट्रेल एक ऑडिट कलाकृति बन जाता है, इसलिए बजट खत्म होने पर तात्कालिकता में सुधार करने के बजाय अभी जवाबदेह स्वामी का नाम रखें।

5. आपकी SRE टीम के सप्ताह का कितना हिस्सा टॉइल है, और क्या यह एक मापी गई संख्या है या एक भावना? टॉइल जिसे कोई नहीं गिनता वह चुपचाप तब तक फैलता है जब तक टीम अपना पूरा समय आग बुझाने में बिताती है और कोई टिकाऊ सुधार कार्य नहीं होता, जो ठीक वही जाल है जिससे बचने के लिए SRE मौजूद है। तनाव यह है कि टॉइल मापना अपने आप में काम है, और समय-सीमा के दबाव में इंजीनियर यह लॉग करने का विरोध करते हैं कि उनके घंटे कहाँ जाते हैं। एक ईमानदार नमूना लाएँ: टॉइल की एक साझा परिभाषा (मैनुअल, दोहराव वाला, स्वचालित करने योग्य, सामरिक, और सिस्टम के साथ स्केल होने वाला) के विरुद्ध एक या दो सप्ताह का ट्रैक किया गया समय, साथ ही आवृत्ति गुणा लागत से रैंक किए गए स्वचालन परियोजनाओं का बैकलॉग। एक बड़े संगठन के लिए 50 प्रतिशत की सीमा का कोई मतलब तभी है जब इसे टीम-दर-टीम रिपोर्ट और बचाव किया जाए, इसलिए सहमत हों कि संख्या की समीक्षा कौन करता है और जब कोई टीम इसे तोड़ती है तो क्या होता है। विनियमित और सरकारी संदर्भों में, टॉइल को सीमित करना दुर्लभ विशेषज्ञों को उस नियंत्रण और ऑडिट कार्य के लिए मुक्त करता है जिसे मैनुअल संचालन बाहर धकेल देता है, इसलिए टॉइल आँकड़े को एक क्षमता संकेत मानें जिसे नेतृत्व को देखना चाहिए।

6. आप कौन-सा SRE संगठनात्मक मॉडल चलाते हैं, और कौन-सा प्रमाण आपको बताएगा कि यह फ़िट होना बंद हो गया है? एक केंद्रीकृत टीम संगति और साझा टूलिंग देती है लेकिन एक बाधा बन सकती है; एक एम्बेडेड मॉडल संदर्भ देता है लेकिन असंगति की ओर बहक जाता है; अधिकांश बड़े संगठन जिस हाइब्रिड पर बसते हैं उसे एक स्पष्ट सहभागिता मॉडल चाहिए वरना यह दोनों की कमज़ोरियाँ विरासत में लेता है। वे संकेत लाएँ जो तनाव प्रकट करते हैं: सेवाएँ SRE समर्थन के लिए कितनी देर प्रतीक्षा करती हैं, टीमों के बीच विश्वसनीयता प्रथा कितनी भिन्न है, और क्या एम्बेडेड इंजीनियर एक पेशेवर समुदाय से कटे हुए महसूस करते हैं। सही उत्तर कंपनी के आकार, इंजीनियरिंग परिपक्वता, और आपकी सेवाएँ कितनी समरूप हैं इस पर निर्भर करता है, इसलिए पहली पसंद को स्थायी मानने के बजाय इन बदलावों के साथ इसे फिर से देखें। कई टीमों और सख्त समरूपता आवश्यकताओं वाले एक एंटरप्राइज़ या सरकारी निकाय के लिए, एक केंद्रीय मानक-और-प्लेटफ़ॉर्म समूह साथ ही एम्बेडेड विश्वसनीयता इंजीनियर आमतौर पर स्थानीय संदर्भ के खिलाफ संगति को संतुलित करता है, लेकिन तभी जब सहभागिता मॉडल और प्रोडक्शन-तैयारी मानदंड लिखे गए हों और कोई उनका स्वामी हो।

क्षेत्र लेंस

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

लघु व्यवसाय। विश्वसनीयता चलाने के लिए कोई विशेषज्ञ न होने के साथ, इसे एक अनुशासन मानें जिसे आप अपने प्लेटफ़ॉर्म के माध्यम से खरीदते हैं: कस्टम स्टैक के बजाय होस्टेड अपटाइम निगरानी, प्रबंधित डेटाबेस, और स्टेटस-पेज टूलिंग। उन लेनदेन से जुड़े एक या दो SLO तय करें जो बिल चुकाते हैं, और ईमानदारी से तय करें कि कौन-सी विफलताएँ आपको एक ग्राहक की कीमत चुकाएँगी। रेज़िलिएंस वहाँ खरीदें जहाँ यह बनाने से सस्ता हो, और परिचालन बोझ को इतना हल्का रखें कि आपके मौजूदा इंजीनियर इसे फ़ीचर कार्य के साथ-साथ उठा सकें।

एंटरप्राइज़। चुनौती कई टीमों में संगति है: एक साझा SLO शब्दावली, एक सामान्य एरर-बजट नीति, और एक प्रोडक्शन-तैयारी मानदंड जिसे SRE ऑन-कॉल लेने से पहले हर सेवा पार करती है। एक केंद्रीय प्लेटफ़ॉर्म-और-मानक समूह साथ ही एम्बेडेड विश्वसनीयता इंजीनियर बिना बाधा बने प्रथा को समरूप रखते हैं, और गवर्नेंस को एरर बजट हर जगह उसी तरह रिपोर्ट और लागू करने की आवश्यकता होती है। ऑब्ज़र्वेबिलिटी इन्फ्रास्ट्रक्चर और स्वचालन निवेश का बजट स्पष्ट रूप से बनाएँ, और विश्वसनीयता को उन मीट्रिक के साथ एक पोर्टफ़ोलियो के रूप में प्रबंधित करें जिसे नेतृत्व देख सके।

सरकार। सार्वजनिक सेवाएँ अक्सर प्रकाशित उपलब्धता लक्ष्य, वैधानिक प्रतिबद्धताएँ, और ऑडिट दायित्व लेकर चलती हैं, इसलिए SLO और एरर-बजट निर्णय ऐसे रिकॉर्ड बन जाते हैं जिनका आप निरीक्षण निकायों के सामने बचाव करते हैं। खरीद नियम सीमित कर सकते हैं कि आप किस निगरानी और होस्टिंग का उपयोग कर सकते हैं, और पारदर्शिता अपेक्षाएँ आपको विश्वसनीयता डेटा को एक सार्वजनिक स्टेटस डैशबोर्ड पर प्रकाशित करने के लिए धकेलती हैं। कर की समय-सीमा और लाभ-नामांकन विंडो जैसे अत्यधिक मौसमी पीक के लिए हफ़्तों पहले योजना बनाएँ, और एक दोषरहित पोस्टमॉर्टम संस्कृति रखें ताकि सार्वजनिक विफलताएँ व्यक्तिगत दोषारोपण के बजाय सिस्टम सुधार को चलाएँ।

उदाहरण

स्टार्टअप। एक दस-सदस्यीय स्टार्टअप एक ही वेब ऐप चलाता है और तीन इंजीनियरों में ऑन-कॉल साझा करता है। एक विश्वसनीयता टीम बनाने के बजाय जिसे वह वहन नहीं कर सकता, वह एक सार्थक SLO चुनता है: लॉगिन-से-डैशबोर्ड फ़्लो पर 99.5 प्रतिशत सफलता, जो वास्तविक उपयोगकर्ता अनुरोधों से मापी जाती है। जब एक अस्थिर थर्ड-पार्टी API उस बजट को खाना शुरू कर देता है, तो टीम अगले फ़ीचर को शिप करने के बजाय एक शुक्रवार रीट्राई और एक कैश जोड़ने में बिताती है, फिर एक साझा दस्तावेज़ में दो-पैराग्राफ का पोस्टमॉर्टम लिखती है ताकि फ़िक्स टिका रहे।

एंटरप्राइज़। एक वैश्विक भुगतान कंपनी अपने ट्रांज़ैक्शन API के लिए 99.99 प्रतिशत उपलब्धता SLO तय करती है, जो लगभग चार मिनट प्रति माह का एरर बजट देता है। एक केंद्रीय SRE प्लेटफ़ॉर्म टीम साझा ऑब्ज़र्वेबिलिटी, घटना टूलिंग, और एरर-बजट नीति की स्वामी है, जबकि एम्बेडेड विश्वसनीयता इंजीनियर हर उत्पाद समूह के भीतर काम करते हैं। जब एक नया फ़्रॉड-डिटेक्शन फ़ीचर एक सप्ताह में आधा मासिक बजट जला देता है, तो पहले से सहमत नीति गैर-महत्वपूर्ण रिलीज़ को तब तक फ़्रीज़ कर देती है जब तक विश्वसनीयता कार्य हेडरूम बहाल नहीं कर देता। अधिकारी बिना बहस के इसे स्वीकार करते हैं, क्योंकि उन्होंने पहले से नीति की पुष्टि की थी।

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

SRE पर रिटर्न तीन स्रोतों से आता है: बचा हुआ डाउनटाइम, कम परिचालन श्रम, और तेज़ सुरक्षित डिलीवरी। एक बड़ी सेवा के लिए डाउनटाइम खोए राजस्व, जुर्माने, और उपचार में प्रति घंटे हज़ारों से लाखों की लागत ले सकता है, इसलिए मामूली विश्वसनीयता लाभ भी जल्दी एक टीम की लागत चुका देते हैं। टॉइल कमी बार-बार होने वाली मैनुअल लागत को एक बार के स्वचालन निवेश में बदल देती है, इसलिए स्वामित्व की कुल लागत स्केल बढ़ने के साथ चढ़ने के बजाय गिरती है। एरर बजट व्यवसाय को तब तेज़ी से शिप करने देते हैं जब विश्वसनीयता स्वस्थ हो, वह फ़ीचर मूल्य कैप्चर करते हुए जिसे अत्यधिक सावधान संचालन मेज़ पर छोड़ देगा।

अपनाने की लागत वास्तविक है। SRE को कुशल इंजीनियरों, ऑब्ज़र्वेबिलिटी इन्फ्रास्ट्रक्चर, और सांस्कृतिक परिवर्तन की आवश्यकता है जो फ़ीचर की समय-सीमाओं के साथ प्रतिस्पर्धा करता है। लेकिन न अपनाने की लागत स्केल पर अधिक है: असीमित परिचालन हेडकाउंट, अप्रत्याशित आउटेज, स्टाफ़ बर्नआउट और अट्रिशन, और प्रतिष्ठा क्षति जिसे मापना कठिन है लेकिन सहना आसान है। नेतृत्व के सामने मामला रखने के लिए, SRE को मापने योग्य रिटर्न वाले जोखिम प्रबंधन के रूप में फ़्रेम करें। घटनाओं और मैनुअल संचालन की वर्तमान लागत, व्यावसायिक प्रतिबद्धताओं से जुड़े SLO लक्ष्य, और दोनों में अनुमानित कमी प्रस्तुत करें। तर्क को एरर बजट पर एक गवर्नेंस टूल के रूप में लंगर डालें जो नेतृत्व को विश्वसनीयता-बनाम-वेलोसिटी ट्रेड-ऑफ़ पर एक लीवर देता है।

एंटी-पैटर्न और नुकसान

• SRE को रीब्रांड किए गए संचालन के रूप में। इंजीनियरिंग समय, स्वचालन आदेश, और पीछे धकेलने के अधिकार के बिना एक ऑप्स टीम का नाम बदलना कुछ भी नहीं बदलता।
• 100 प्रतिशत का लक्ष्य रखना। पूर्ण विश्वसनीयता का पीछा करना पैसा बर्बाद करता है और उन लाभों के लिए डिलीवरी को रोकता है जिन्हें उपयोगकर्ता महसूस नहीं कर सकते।
• वैनिटी SLI। उपयोगकर्ता-दृश्य सफलता के बजाय सर्वर CPU मापना ऐसी संख्याएँ देता है जो अच्छी दिखती हैं जबकि उपयोगकर्ता तकलीफ़ में होते हैं।
• बिना दाँत वाले एरर बजट। एक बजट जिस पर समाप्त होने पर कभी अमल नहीं होता वह केवल सजावट है।
• बिना मापन के टॉइल। यदि आप टॉइल ट्रैक नहीं करते, तो यह चुपचाप टीम को निगल जाता है जब तक कोई सुधार कार्य नहीं होता।
• डंपिंग ग्राउंड के रूप में SRE। केंद्रीकृत टीमें जो बिना तैयारी मानदंड के हर अस्थिर सेवा को विरासत में लेती हैं वे दूसरों के तकनीकी ऋण में डूब जाती हैं।
• क्षमता लीड टाइम की अनदेखी। यह मान लेना कि क्लाउड इलास्टिसिटी तत्काल और अनंत है, ठीक उन्हीं पीक के दौरान कमी को आमंत्रित करता है जो सबसे अधिक मायने रखते हैं।

परिपक्वता मॉडल

स्तर 1, आरंभ करें। संचालन मैनुअल और प्रतिक्रियात्मक हैं। कोई औपचारिक SLO नहीं है, विश्वसनीयता राय का मामला है, और वही घटनाएँ बार-बार होती हैं जबकि आग बुझाना हावी रहता है। कोई भी स्वचालन आकस्मिक है, और कोई भी विश्वसनीयता को एक इंजीनियरिंग सरोकार के रूप में स्वामित्व नहीं करता।

स्तर 2, विकसित करें। कुछ सेवाओं में बुनियादी SLI और SLO और प्रारंभिक निगरानी व अलर्टिंग है, लेकिन प्रथा टीमों के बीच व्यापक रूप से भिन्न होती है। टॉइल को स्वीकार किया जाता है फिर भी मापा नहीं जाता, स्वचालन तदर्थ है, और पोस्टमॉर्टम असंगत रूप से होते हैं। विश्वसनीयता उन जेबों में सुधरती है जहाँ व्यक्ति इसे धकेलते हैं, इसलिए नहीं कि संगठन इसकी माँग करता है।

स्तर 3, मानकीकृत करें। SLI, SLO, और एक एरर-बजट नीति दस्तावेज़ीकृत हैं और टीमों में लगातार लागू होती हैं। टॉइल परिभाषित और ट्रैक किया जाता है, क्षमता योजना नियमित है, प्रोडक्शन-तैयारी समीक्षाओं वाला एक SRE सहभागिता मॉडल मौजूद है, और स्वचालन एक साइड प्रोजेक्ट के बजाय एक वित्तपोषित कार्यधारा है। विश्वसनीयता प्रथा लिखी गई है और संगठन-व्यापी लागू होती है।

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

स्तर 5, ऑर्केस्ट्रेट करें। विश्वसनीयता इंजीनियरिंग पूरे संगठन में एकीकृत और लगातार सुधारी जाती है। एरर-बजट नीति स्वचालित है और हर जगह सम्मानित है, अधिकांश संचालन स्व-सेवा हैं, क्षमता सक्रिय रूप से प्रोविज़न की जाती है, और विश्वसनीयता डेटा वेलोसिटी और स्थिरता के बीच अनुकूली ट्रेड-ऑफ़ चलाता है। संगठन नियमित रूप से SLO को फिर से दायरा देता है, टॉइल रिटायर करता है, और व्यवसाय व जोखिम की तस्वीर बदलने पर विश्वसनीयता निवेश को पुनर्संतुलित करता है।

चर्चा के लिए विचार

• जब किसी संगठन के पास उन्हें लंगर डालने के लिए कोई ऐतिहासिक विश्वसनीयता डेटा न हो, तो उसे अपने पहले SLO कैसे तय करने चाहिए?
• जब एरर बजट समाप्त हो चुका है लेकिन एक बड़ा लॉन्च प्रतिबद्ध है, तो फ़्रीज़ को ओवरराइड करने का अधिकार किसके पास है, और वह निर्णय कैसे रिकॉर्ड किया जाता है?
• आपके संगठन के लिए एक केंद्रीकृत, एम्बेडेड, या हाइब्रिड SRE मॉडल सही है, और किस चीज़ से बदलाव ट्रिगर होगा?
• उन फ़ीचर्स के मुकाबले उपलब्धता का एक अतिरिक्त नाइन आप कैसे मूल्यांकित करते हैं जिन्हें वही निवेश वित्तपोषित कर सकता था?
• आपके संदर्भ में टॉइल क्या माना जाता है, और मूल्यवान मैनुअल निर्णय और समाप्त करने योग्य दोहराव के बीच की रेखा कहाँ है?
• नागरिक-सामने वाली सरकारी सेवाओं और आंतरिक एंटरप्राइज़ टूल के बीच विश्वसनीयता लक्ष्य कैसे भिन्न होने चाहिए?

मुख्य निष्कर्ष

• SRE संचालन में सॉफ़्टवेयर इंजीनियरिंग लागू करती है, विश्वसनीयता को एक मापने योग्य, वित्तपोषित करने योग्य फ़ीचर मानते हुए।
• SLI, SLO, और SLA विश्वसनीयता को राय से सहमत संख्याओं में बदल देते हैं; SLO को SLA से सख्त रखें।
• एरर बजट विश्वसनीयता-बनाम-वेलोसिटी ट्रेड-ऑफ़ को स्पष्ट और पहले से बातचीत किया हुआ बनाकर डेवलपर्स और ऑपरेटरों को संरेखित करता है।
• टॉइल को मापें और सीमित करें, और स्वचालन को प्रथम-श्रेणी इंजीनियरिंग मानें ताकि संचालन उप-रैखिक रूप से स्केल हो।
• माँग पूर्वानुमानों से क्षमता की योजना बनाएँ और प्रोविज़निंग लीड टाइम का सम्मान करें, खासकर मौसमी पीक के लिए।
• एक SRE संगठनात्मक मॉडल जानबूझकर चुनें और एक स्पष्ट सहभागिता व प्रोडक्शन-तैयारी मानदंड परिभाषित करें।

संदर्भ और आगे पढ़ने के लिए

• Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
• Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne, The Site Reliability Workbook: Practical Ways to Implement SRE
• David N. Blank-Edelman (editor), Seeking SRE: Conversations About Running Production Systems at Scale
• Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan, The Practice of Cloud System Administration
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps