6.1 सेवा स्तर संकेतक, लक्ष्य, और त्रुटि बजट

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

साइट विश्वसनीयता इंजीनियरिंग (SRE), Google में अग्रणी और Site Reliability Engineering पुस्तक में दस्तावेज़ीकृत अनुशासन, ने एक शब्दावली का योगदान दिया जिस पर यह विषय सीधे बनता है: एक सेवा स्तर संकेतक (SLI) एक सेवा के स्वास्थ्य का सीधे मापा गया संकेत है, अनुरोध विलंबता, त्रुटि दर, उपलब्धता। एक सेवा स्तर लक्ष्य (SLO) उस संकेतक के लिए लक्ष्य सीमा है, उदाहरण के लिए 99.9% अनुरोध 200 मिलीसेकंड के भीतर सफल होते हैं। और एक त्रुटि बजट अनुमत कमी है, विफल होने की अनुमति वाले 0.1% अनुरोध, इसे समाप्त करने के लिए एक दोष नहीं बल्कि एक ख़र्च करने योग्य संसाधन के रूप में माना जाता है जिसे जान-बूझकर जोखिम लेने के लिए उपयोग किया जा सकता है: एक जोखिम भरा परिवर्तन शिप करना, एक प्रयोग चलाना, या बस यह स्वीकार करना कि पूर्ण विश्वसनीयता न तो प्राप्त करने योग्य है और न ही, एक निश्चित बिंदु से परे, इसकी लागत के लायक़।

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

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

प्रमुख सिद्धांत

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

सिफ़ारिशें

ऐसे SLI चुनें जो वास्तविक उपयोगकर्ता अनुभव को दर्शाते हैं

ऐसे संकेतक चुनें जो वास्तविक उपयोगकर्ता अनुभव के जितना संभव हो सके क़रीब मापे जाते हैं: एज या लोड बैलेंसर पर मापी गई अनुरोध सफलता दर और विलंबता, केवल आंतरिक सेवा स्वास्थ्य जाँचें नहीं जो उपयोगकर्ताओं द्वारा वास्तविक समस्याओं का अनुभव करते हुए “स्वस्थ” रिपोर्ट कर सकती हैं। एक SLI जो ऐसा कुछ मापता है जिसे उपयोगकर्ता वास्तव में कभी नोटिस नहीं करता, एक आंतरिक घटक तकनीकी रूप से ऊपर है जबकि समग्र अनुरोध अभी भी विफल हो जाता है, ग़लत चीज़ माप रहा है चाहे इसे इंस्ट्रूमेंट करना कितना भी आसान हो।

उपयोगकर्ता वास्तव में क्या चाहते हैं इसके आधार पर SLO लक्ष्य निर्धारित करें, एक मनमानी गोल संख्या नहीं

“99.99% अपटाइम” जैसा एक लक्ष्य केवल इसलिए निर्धारित करने की सजगता का विरोध करें क्योंकि यह प्रभावशाली रूप से कठोर लगता है। इसके बजाय, शोध करें कि उपयोगकर्ता वास्तव में किस विश्वसनीयता स्तर को नोटिस करते हैं और परवाह करते हैं, ऐतिहासिक घटना डेटा, उपयोगकर्ता शोध, और विश्वसनीयता के हर अतिरिक्त वृद्धि को प्राप्त करने की प्रदर्शित लागत से सूचित, क्योंकि 99.9% से 99.99% तक जाना अक्सर 99% से 99.9% तक जाने से कहीं अधिक इंजीनियरिंग प्रयास की लागत लेता है, घटते और अंततः नगण्य उपयोगकर्ता-अनुभव योग्य लाभ के लिए।

त्रुटि बजट को समाप्ति के लिए एक पूर्व-निर्धारित प्रतिक्रिया वाला एक ख़र्च करने योग्य संसाधन मानें

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

जान-बूझकर, सूचित जोखिम निर्णय लेने के लिए त्रुटि बजट का उपयोग करें

एक स्वस्थ, ख़र्च न किया गया त्रुटि बजट जमा करने की चीज़ नहीं है; यह उचित जोखिम लेने की अनुमति है, ऊँचे लेकिन स्वीकार्य जोखिम वाला एक परिवर्तन शिप करना, एक अराजकता इंजीनियरिंग प्रयोग चलाना (साथी software-engineering-guide पुस्तक का अराजकता इंजीनियरिंग विषय इसे सीधे कवर करता है), या एक अधिक जोखिम भरा आर्किटेक्चर परिवर्तन स्वीकार करना, क्योंकि बजट विशेष रूप से जान-बूझकर ख़र्च किए जाने के लिए मौजूद है, अछूता संरक्षित रखने के लिए नहीं। एक त्रुटि बजट जो कभी ख़र्च नहीं होता वह या तो एक अत्यधिक रूढ़िवादी टीम या वास्तविक प्राप्त विश्वसनीयता के सापेक्ष बहुत ढीले ढंग से निर्धारित एक SLO का सुझाव देता है, दोनों जाँच करने लायक़।

समय-समय पर SLO की समीक्षा और संशोधन करें, जड़ता पर नहीं, प्रमाण पर आधारित

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

समझौते: लाभ और हानि

दृष्टिकोण	लाभ	हानि
कोई औपचारिक SLO नहीं (अंतर्निहित “जितना संभव हो उतना विश्वसनीय”)	स्थापित करने में कोई ओवरहेड नहीं	गति और स्थिरता के बीच अंतहीन, अनाधारित बातचीत; कोई साझा नियम नहीं
आकांक्षापूर्ण, बहुत उच्च SLO (99.99%+)	विश्वसनीयता के बारे में गंभीरता का संकेत देता है	अक्सर अनावश्यक लागत; उपयोगकर्ता वास्तव में जो नोटिस करते हैं उससे आगे घटते प्रतिफल
प्रमाण-आधारित, उपयोगकर्ता-अनुभव-आधारित SLO	वास्तविक मूल्य को दर्शाता है; बचाव योग्य और प्राप्त करने योग्य	सही ढंग से निर्धारित करने के लिए वास्तविक डेटा और विश्लेषण की आवश्यकता
पूर्व-निर्धारित समाप्ति प्रतिक्रिया के साथ त्रुटि बजट	तदर्थ बातचीत हटाता है; वस्तुनिष्ठ, तेज़ निर्णय लेना	पूर्व-निर्धारित नियम का वास्तव में सम्मान करने के लिए संगठनात्मक ख़रीद-इन और अनुशासन की आवश्यकता

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

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

1. क्या हमारा वर्तमान SLO इस बारे में प्रमाण में आधारित है कि उपयोगकर्ता वास्तव में क्या नोटिस करते हैं, या इसे आकांक्षापूर्ण रूप से निर्धारित किया गया था क्योंकि एक उच्च संख्या उचित रूप से गंभीर महसूस हुई? यदि आप कर सकते हैं तो अपने वर्तमान लक्ष्य की उत्पत्ति ट्रेस करें, और ईमानदारी से आँकें कि क्या यह वास्तविक उपयोगकर्ता शोध या केवल इंजीनियरिंग अंतर्ज्ञान को दर्शाता है।

2. क्या हमारे पास त्रुटि-बजट समाप्ति के लिए एक पूर्व-निर्धारित, सहमत प्रतिक्रिया है, या क्या समझौते को हर बार होने पर फिर से बहस किया जाता है? यदि ईमानदार उत्तर बाद वाला है, तो वह अंतर अगली घटना के दबाव में बहस को मजबूर करने से पहले बंद करने लायक़ है।

3. क्या हमारा त्रुटि बजट कभी वास्तव में जान-बूझकर ख़र्च किया जाता है, एक गणना किए गए-जोखिम परिवर्तन या एक प्रयोग पर, या क्या यह केवल घटनाओं के माध्यम से दुर्घटनावश उपभोग किया जाता है? एक बजट जो कभी जान-बूझकर ख़र्च नहीं किया जाता वह एक अत्यधिक सतर्क टीम को इंगित कर सकता है जो उन वैध अवसरों को चूक रही है जिन्हें बजट सक्षम करने के लिए मौजूद है।

4. क्या हमारे SLI वास्तविक उपयोगकर्ता अनुभव से मापे जाते हैं, या आंतरिक प्रणाली स्वास्थ्य से जो उपयोगकर्ता वास्तव में जो अनुभव करते हैं उसे नहीं दर्शा सकता? अपने वर्तमान इंस्ट्रूमेंटेशन को इस विशिष्ट भेद के विरुद्ध जाँचें; यह अन्यथा परिपक्व विश्वसनीयता कार्यक्रमों में भी एक सामान्य अंतर है।

5. हमने आख़िरी बार वर्तमान प्रमाण के विरुद्ध अपने SLO की समीक्षा कब की, और क्या कुछ बदला है, उपयोगकर्ता अपेक्षाएँ, प्रणाली आर्किटेक्चर, व्यावसायिक प्राथमिकताएँ, जो इसे संशोधित करने को न्यायोचित ठहराए? यदि आप एक हाल की समीक्षा याद नहीं कर सकते, तो वह अनुपस्थिति स्वयं चर्चा करने लायक़ है।

6. हमारे वर्तमान SLO को विश्वसनीयता की एक अतिरिक्त “नौ” से ऊपर ले जाने में इंजीनियरिंग प्रयास में हमें क्या लागत आएगी, और क्या वह लागत किसी वास्तविक उपयोगकर्ता लाभ द्वारा न्यायोचित होगी? यह ठोस लागत-लाभ फ़्रेमिंग आकांक्षा-बनाम-प्राप्ति-योग्यता तनाव को अमूर्त प्राथमिकता की बजाय वास्तविक संख्याओं में आधारित करने में मदद करती है।

क्षेत्र दृष्टिकोण

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

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

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

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

उदाहरण

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

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

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

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

कुल स्वामित्व लागत में एक साक्ष्य-आधारित लक्ष्य को सही ढंग से निर्धारित करने का विश्लेषण प्रयास और पूर्व-निर्धारित समाप्ति प्रतिक्रिया का सम्मान करने का अनुशासन शामिल है यहाँ तक कि किसी भी तरह एक विशेष रूप से वांछित विशेषता को शिप करने के दबाव में भी। वह अनुशासन लागत वास्तविक है, लेकिन यह एक अनसुलझी, दीर्घकालिक बातचीत की चल रही लागत से कहीं कम है जो हर योजना चक्र में अनिश्चित काल तक संगठनात्मक ऊर्जा का उपभोग करती है।

विरोधी-पैटर्न और नुक़सान

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

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

• स्तर 1, आरंभ: विश्वसनीयता लक्ष्य अंतर्निहित या आकांक्षापूर्ण हैं, बिना किसी परिभाषित औपचारिक SLO, SLI, या त्रुटि बजट के।
• स्तर 2, विकास: कुछ सेवाओं का एक अनौपचारिक SLO है, लेकिन SLI वास्तविक उपयोगकर्ता अनुभव को नहीं दर्शा सकते और कोई पूर्व-निर्धारित समाप्ति नीति नहीं है।
• स्तर 3, मानकीकरण: महत्वपूर्ण सेवाओं में वास्तविक उपयोगकर्ता-अनुभव SLI और एक पूर्व-निर्धारित त्रुटि-बजट समाप्ति नीति के साथ प्रमाण-आधारित SLO लगातार स्थापित किए जाते हैं।
• स्तर 4, प्रबंधन: त्रुटि बजट को सक्रिय रूप से और जान-बूझकर गणना किए गए जोखिम-लेने पर ख़र्च किया जाता है, और SLO को एक नियमित, प्रमाण-आधारित कादेंस पर समीक्षा और संशोधित किया जाता है।
• स्तर 5, संयोजन: SLO और त्रुटि बजट को गति और स्थिरता को संतुलित करने के साझा, वस्तुनिष्ठ तंत्र के रूप में संगठन-व्यापी एकीकृत किया जाता है, और संगठन उन विशिष्ट निर्णयों की ओर इशारा कर सकता है जो फ्रेमवर्क ने सक्षम किए जिन्हें एक अनाधारित बातचीत उतनी प्रभावी रूप से हल नहीं करती।

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

1. क्या हमारा वर्तमान SLO प्रमाण में आधारित है, या आकांक्षा में?
2. क्या हमारे पास त्रुटि-बजट समाप्ति के लिए एक पूर्व-निर्धारित प्रतिक्रिया है जिसका हम वास्तव में दबाव में सम्मान करेंगे?
3. हमने अंतिम बार एक गणना किए गए जोखिम पर एक स्वस्थ त्रुटि बजट कब जान-बूझकर ख़र्च किया?
4. क्या हमारे SLI वास्तविक उपयोगकर्ता अनुभव मापते हैं या सुविधाजनक आंतरिक स्वास्थ्य जाँचें?
5. हमारे SLO को एक अतिरिक्त “नौ” से बढ़ाने में हमें क्या लागत आएगी, और क्या वह लागत न्यायोचित होगी?

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

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

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

• Site Reliability Engineering: How Google Runs Production Systems, by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds. (SLI, SLO, और त्रुटि बजट को परिभाषित करने वाला आधारभूत पाठ)।
• The Site Reliability Workbook, by Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne, eds. (SLO और त्रुटि बजट लागू करने पर व्यावहारिक मार्गदर्शन)।
• Implementing Service Level Objectives, by Alex Hidalgo (SLO डिज़ाइन और संचालन के लिए एक व्यापक, अभ्यासकर्ता-केंद्रित मार्गदर्शिका)।
• Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim (विश्वसनीयता प्रथा और डिलीवरी प्रदर्शन के बीच संबंध)।