SRE (साइट विश्वसनीयता इंजीनियरिंग) - वेब परियोजनाओं की उपलब्धता सुनिश्चित करने के लिए एक दृष्टिकोण। यह DevOps के लिए एक रूपरेखा माना जाता है और बताता है कि DevOps प्रथाओं को लागू करने में कैसे सफल होना है। यह लेख Google की साइट विश्वसनीयता इंजीनियरिंग से सेवा स्तर के उद्देश्यों के अध्याय 4 का अनुवाद है। मैंने स्वयं इस अनुवाद को तैयार किया और निगरानी प्रक्रियाओं को समझने के अपने अनुभव पर भरोसा किया। टेलीग्राम चैनल मॉनीटर__ और हैबरे पर आखिरी पोस्ट में मैंने मॉनिटरिंग सिस्टम पर उसी किताब के अध्याय 6 का अनुवाद भी प्रकाशित किया।

बिल्ली द्वारा अनुवाद। अच्छा पढ़ लो!

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

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

इस अध्याय में मीट्रिक मॉडलिंग, मीट्रिक चयन और मीट्रिक विश्लेषण की समस्याओं से निपटने के लिए हमारे द्वारा उपयोग किए जाने वाले दृष्टिकोण का वर्णन है। अधिकांश स्पष्टीकरण उदाहरण के बिना होंगे, इसलिए हम मुख्य बिंदुओं को स्पष्ट करने के लिए इसके कार्यान्वयन (शेक्सपियर के कार्यों की खोज) के उदाहरण में वर्णित शेक्सपियर सेवा का उपयोग करेंगे।

सेवा स्तर शब्दावली

कई पाठक शायद एसएलए की अवधारणा से परिचित हैं, लेकिन एसएलआई और एसएलओ सावधान परिभाषा के पात्र हैं, क्योंकि सामान्य तौर पर एसएलए शब्द ओवरलोड होता है और संदर्भ के आधार पर इसके कई अर्थ होते हैं। स्पष्टता के लिए, हम इन मूल्यों को अलग करना चाहते हैं।

संकेतक

SLI सेवा के स्तर का एक संकेतक है - प्रदान किए गए सेवा स्तर के एक पहलू का सावधानीपूर्वक मात्रात्मक माप।

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

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

एक अन्य प्रकार का SLI जो SRE के लिए महत्वपूर्ण है उस समय की उपलब्धता या हिस्सा है जिसके दौरान सेवा का उपयोग किया जा सकता है। इसे अक्सर सफल अनुरोधों के प्रतिशत के रूप में परिभाषित किया जाता है, जिसे कभी-कभी पीढ़ी भी कहा जाता है। (जीवन प्रत्याशा - डेटा भंडारण प्रणालियों के लिए लंबी अवधि के लिए डेटा संग्रहीत किए जाने की संभावना भी महत्वपूर्ण है।) हालांकि पहुँच क्षमता 100% असंभव है, 100% के करीब पहुंच अक्सर प्राप्त करने योग्य होती है, पहुंच मानों को संख्या "नौ" के रूप में व्यक्त किया जाता है। »प्रतिशत की उपलब्धता। उदाहरण के लिए, 99% और 99.999% की उपलब्धता को "2 नाइन" और "5 नाइन" कहा जा सकता है। Google कंप्यूट इंजन के लिए पहुंच का वर्तमान घोषित लक्ष्य "साढ़े तीन नाइन" या 99.95% है।

लक्ष्यों

SLO एक सेवा स्तर का लक्ष्य होता है: SLI द्वारा मापी जाने वाली सेवा स्तर के लिए एक लक्ष्य मान या श्रेणी का मान। SLO के लिए सामान्य मूल्य "SLI” लक्ष्य मूल्य "या" निचली सीमा ≤ SLI limit ऊपरी सीमा "है। उदाहरण के लिए, हम यह तय कर सकते हैं कि हम शेक्सपियर के कार्यों के लिए खोज परिणाम "जल्दी" वापस करेंगे, SLO के रूप में लेते हुए खोज क्वेरी के औसत विलंब का मान 100 मिलीसेकंड से कम है।

सही एसएलओ चुनना एक जटिल प्रक्रिया है। सबसे पहले, आप हमेशा एक विशिष्ट मान का चयन नहीं कर सकते। आपकी सेवा के लिए आने वाले HTTP अनुरोधों के लिए, प्रति सेकंड (QPS) अनुरोधों की संख्या का मीट्रिक मुख्य रूप से आपके उपयोगकर्ताओं को आपकी सेवा की यात्रा करने की इच्छा से निर्धारित होता है, और आप इसके लिए SLO स्थापित नहीं कर सकते।

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

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

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

समझौता

एक सेवा स्तर समझौता आपके उपयोगकर्ताओं के साथ एक स्पष्ट या अंतर्निहित अनुबंध है जिसमें वे शामिल SLOs की शुरुआत (या अनुपस्थिति) के परिणाम शामिल हैं। जब वे वित्तीय होते हैं तो परिणाम सबसे आसानी से पहचाने जाते हैं - छूट या जुर्माना - लेकिन वे अन्य रूप ले सकते हैं। एसएलओ और एसएलए के बीच अंतर के बारे में बात करने का एक आसान तरीका यह है, "एसएलओ से मुलाकात नहीं होने पर क्या होता है?" यदि कोई स्पष्ट परिणाम नहीं हैं, तो आप लगभग निश्चित रूप से एसएलओ को देखेंगे।

SRE आमतौर पर SLAs बनाने में शामिल नहीं होते हैं क्योंकि SLAs व्यवसाय और उत्पाद समाधानों से निकटता से संबंधित हैं। हालांकि, SRE, असफल SLO के परिणामों को रोकने में मदद करने में शामिल है। वे SLI निर्धारित करने में भी मदद कर सकते हैं: जाहिर है, एक समझौते में SLO को मापने का एक उद्देश्य तरीका होना चाहिए या असहमति होगी।

Google खोज एक महत्वपूर्ण सेवा का एक उदाहरण है, जिसमें जनता के लिए SLA नहीं है: हम चाहते हैं कि हर कोई यथासंभव खोज का उपयोग करें, लेकिन हमने पूरी दुनिया के साथ अनुबंध नहीं किया है। हालाँकि, अभी भी परिणाम हैं यदि खोज अनुपलब्ध है - अप्राप्यता हमारी प्रतिष्ठा में गिरावट के साथ-साथ विज्ञापन राजस्व में कमी की ओर ले जाती है। कई अन्य Google सेवाएँ, जैसे Google for Work में उपयोगकर्ताओं के साथ सेवा स्तर के स्पष्ट समझौते हैं। भले ही किसी विशेष सेवा में SLA हो, SLI और SLO को निर्धारित करना और सेवा का प्रबंधन करने के लिए उनका उपयोग करना महत्वपूर्ण है।

इतना सिद्धांत - अब अनुभव करना है।

व्यवहार में संकेतक

यह देखते हुए कि हमने यह निष्कर्ष निकाला है कि सेवा के स्तर को मापने के लिए उपयुक्त संकेतकों का चयन करना महत्वपूर्ण है, अब आप कैसे जानते हैं कि कौन से संकेतक सेवा या प्रणाली के लिए प्रासंगिक हैं?

आप और आपके उपयोगकर्ता क्या परवाह करते हैं

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

सेवा, एक नियम के रूप में, एसएलआई के संदर्भ में कई भागों में विभाजित की जा सकती है, जो उनके लिए प्रासंगिक हैं:

• कस्टम फ्रंटएंड सिस्टम, जैसे कि शेक्सपियर सेवा हमारे उदाहरण से इंटरफेस खोजती है। उन्हें सुलभ होना चाहिए, देरी नहीं करनी चाहिए और पर्याप्त बैंडविड्थ होनी चाहिए। तदनुसार, आप प्रश्न पूछ सकते हैं: क्या हम अनुरोध का उत्तर दे सकते हैं? अनुरोध का उत्तर देने में कितना समय लगा? कितने अनुरोध संसाधित किए जा सकते हैं?
• भंडारण प्रणाली। कम विलंबता, उपलब्धता और स्थायित्व उनके लिए महत्वपूर्ण हैं। संबंधित प्रश्न: डेटा को पढ़ने या लिखने में कितना समय लगता है? क्या हम डिमांड पर डेटा एक्सेस कर सकते हैं? क्या डेटा उपलब्ध है जब हमें इसकी आवश्यकता है? अध्याय 26 डेटा इंटीग्रिटी देखें: आपने जो पढ़ा है, वह इन मुद्दों की विस्तृत चर्चा के लिए लिखा है।
• डेटा प्रोसेसिंग पाइपलाइन जैसे बड़े डेटा सिस्टम, थ्रूपुट और अनुरोध प्रसंस्करण की विलंबता पर निर्भर करते हैं। प्रासंगिक प्रश्न: कितना डेटा संसाधित किया जाता है? प्रतिक्रिया जारी करने का अनुरोध प्राप्त करने से डेटा को स्थानांतरित होने में कितना समय लगता है? (सिस्टम के कुछ हिस्सों में कुछ चरणों में देरी भी हो सकती है।)

संकेतक संग्रह

एक निगरानी प्रणाली का उपयोग करके सर्वर साइड पर कई सर्विस लेवल इंडिकेटर्स को इकट्ठा करना सबसे स्वाभाविक है जैसे कि Borgmon ( अध्याय 10 टाइम सीरीज़ अलर्ट प्रैक्टिस ) या प्रोमेथियस, या बस समय-समय पर 500 की स्थिति के साथ HTTP प्रतिक्रियाओं की पहचान करने के लिए लॉग का विश्लेषण करना। कुछ सिस्टम क्लाइंट-साइड मेट्रिक्स संग्रह से सुसज्जित होने चाहिए, क्योंकि क्लाइंट साइड पर निगरानी की कमी से उपयोगकर्ताओं को प्रभावित करने वाली कई समस्याएं गायब हो सकती हैं लेकिन सर्वर-साइड मैट्रिक्स को प्रभावित नहीं करती हैं। उदाहरण के लिए, शेक्सपियर के कार्यों की खोज करने वाले हमारे परीक्षण एप्लिकेशन के बैकएंड की विलंबित प्रतिक्रिया पर ध्यान केंद्रित करने से जावास्क्रिप्ट समस्याओं के कारण उपयोगकर्ता की ओर से अनुरोधों के प्रसंस्करण में देरी हो सकती है: इस मामले में, मापना कि ब्राउज़र में प्रक्रिया में कितना समय लगेगा, यह सबसे अच्छा संकेतक है।

एकत्रीकरण

सरलता और उपयोग में आसानी के लिए, हम अक्सर कच्चे आयामों को एकत्र करते हैं। यह सावधानी से किया जाना चाहिए।

कुछ संकेतक सरल लगते हैं, उदाहरण के लिए, प्रति सेकंड प्रश्नों की संख्या, लेकिन यह भी, स्पष्ट, प्रत्यक्ष माप समय के साथ डेटा को संक्षेप में जोड़ता है। क्या माप विशेष रूप से प्रति सेकंड एक बार प्राप्त किया जाता है या क्या यह माप प्रति मिनट प्रश्नों की संख्या पर औसत है? बाद वाला विकल्प बहुत अधिक तात्कालिक संख्या को छिपा सकता है जो केवल कुछ सेकंड के लिए संग्रहीत होते हैं। एक ऐसी प्रणाली पर विचार करें जो प्रति सेकंड 200 अनुरोधों की संख्या और शेष समय के साथ 0 परोसती है। प्रति सेकंड 100 अनुरोधों के औसत मूल्य के रूप में एक स्थिरांक और तत्काल लोड के रूप में दो बार एक ही बात नहीं है। इसी तरह, औसत अनुरोध विलंबता आकर्षक लग सकता है, लेकिन यह एक महत्वपूर्ण विवरण को छिपाता है: यह संभव है कि अधिकांश अनुरोध तेजी से होंगे, लेकिन कई अनुरोध होंगे जो धीमे होंगे।

अधिकांश संकेतक औसत के बजाय वितरण के रूप में बेहतर देखे जाते हैं। उदाहरण के लिए, SLI देरी के लिए, कुछ अनुरोधों को जल्दी से संसाधित किया जाएगा, जबकि कुछ को हमेशा अधिक समय लगेगा, कभी-कभी बहुत लंबा। एक साधारण औसत इन लंबी देरी को छिपा सकता है। यह आंकड़ा एक उदाहरण दिखाता है: हालांकि एक विशिष्ट अनुरोध लगभग 50 एमएस के लिए परोसा जाता है, 5% अनुरोध 20 गुना धीमा हैं! केवल औसत विलंबता के आधार पर निगरानी और अलर्ट दिन के दौरान व्यवहार में परिवर्तन नहीं दिखाते हैं, जब वास्तव में कुछ अनुरोधों (शीर्ष लाइन) के प्रसंस्करण समय में ध्यान देने योग्य परिवर्तन होते हैं।


50, 85, 95, और 99 प्रतिशत प्रणाली की देरी। Y अक्ष लघुगणकीय प्रारूप में है।

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

सांख्यिकीय त्रुटियों पर ध्यान दें

आमतौर पर हम मूल्यों के एक औसत (अंकगणितीय माध्य) सेट के बजाय प्रतिशत के साथ काम करना पसंद करते हैं। यह हमें अधिक फैलाए गए मूल्यों पर विचार करने की अनुमति देता है, जिनमें अक्सर औसत से काफी अलग (और अधिक दिलचस्प) विशेषताएं होती हैं। कंप्यूटिंग सिस्टम की कृत्रिम प्रकृति के कारण, मीट्रिक मान अक्सर विकृत होते हैं, उदाहरण के लिए, कोई अनुरोध 0 एमएस से कम में प्रतिक्रिया प्राप्त नहीं कर सकता है, और 1000 एमएस का एक टाइमआउट का मतलब है कि टाइमआउट से अधिक मूल्यों के साथ कोई सफल प्रतिक्रिया नहीं हो सकती है। परिणामस्वरूप, हम यह स्वीकार नहीं कर सकते हैं कि माध्य और माध्य एक-दूसरे के समान या निकट हो सकते हैं!

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

संकेतक मानकीकृत करें

हम SLI के लिए सामान्य विशेषताओं को मानकीकृत करने की सलाह देते हैं ताकि आपको हर बार उनके बारे में बात न करनी पड़े। कोई भी फ़ंक्शन जो मानक टेम्पलेट्स को संतुष्ट करता है, उदाहरण के लिए, व्यक्तिगत SLI के विनिर्देश से बाहर रखा जा सकता है:

• एकत्रीकरण अंतराल: "औसतन 1 मिनट"
• एकत्रीकरण क्षेत्र: "क्लस्टर में सभी कार्य"
• कितनी बार माप लिया जाता है: "हर 10 सेकंड"
• क्या अनुरोध शामिल हैं: "ब्लैक बॉक्स निगरानी नौकरियों से HTTP GET"
• डेटा कैसे प्राप्त हुआ: "सर्वर पर मापी गई हमारी निगरानी के लिए धन्यवाद",
• डेटा एक्सेस देरी: "टाइम टू लास्ट बाइट"

प्रयास को बचाने के लिए, प्रत्येक सामान्य मीट्रिक के लिए पुन: प्रयोज्य एसएलआई टेम्पलेट्स का एक सेट बनाएं; वे हर किसी के लिए यह समझना आसान बनाते हैं कि किसी विशेष SLI का क्या अर्थ है।

लक्ष्यों का अभ्यास करें

सोचकर शुरू करें (या पता करें!) आपके उपयोगकर्ताओं को क्या परवाह है, न कि आप क्या माप सकते हैं। अक्सर, आपके उपयोगकर्ताओं को क्या परेशान करना या मापना असंभव है, इसलिए आप उनकी जरूरतों के करीब पहुंचते हैं। हालांकि, यदि आप अभी माप करना आसान है, तो आप कम उपयोगी एसएलओ प्राप्त करेंगे। नतीजतन, हमने कभी-कभी पाया कि वांछित लक्ष्यों की प्रारंभिक परिभाषा और विशिष्ट संकेतकों के साथ आगे काम करना संकेतक चुनने और फिर लक्ष्यों को प्राप्त करने से बेहतर काम करता है।

लक्ष्य निर्धारित करें

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

• Get RPC कॉल का 99% (1 मिनट से अधिक का औसत) 100 ms (सभी बैकएंड सर्वर पर मापा गया) से कम में पूरा किया जाएगा।
• Get RPC कॉल का 99% 100ms से कम में पूरा हो जाएगा।

यदि प्रदर्शन घटता का आकार महत्वपूर्ण है, तो आप कई SLO लक्ष्य निर्दिष्ट कर सकते हैं:

• 90% Get RPC कॉल 1 ms से कम में पूरी हुई।
• 99% Get RPC कॉल 10 ms से कम में पूरी हुई।
• 99.9% Get RPC कॉल 100 ms से कम में पूरी हुई।

यदि आपके उपयोगकर्ता विषम भार उत्पन्न करते हैं: बड़े पैमाने पर प्रसंस्करण (जिसके लिए बैंडविड्थ महत्वपूर्ण है) और इंटरैक्टिव प्रसंस्करण (जिसके लिए विलंब की मात्रा महत्वपूर्ण है), प्रत्येक लोड वर्ग के लिए अलग-अलग लक्ष्यों को परिभाषित करना उचित हो सकता है:

• 95% ग्राहक अनुरोध महत्वपूर्ण बैंडविड्थ हैं। RPC कॉल की गिनती प्रगति में सेट करें <1 s।
• 99% ग्राहक विलंब की मात्रा को महत्व देते हैं। ट्रैफ़िक <1 kB और चालू <10 ms के साथ RPC कॉल की गिनती सेट करें।

यह अवास्तविक और अवांछनीय है कि एसएलओ को 100% मामलों में निष्पादित किया जाएगा: यह नई कार्यक्षमता और तैनाती की शुरुआत की गति को धीमा कर सकता है और इसके लिए महंगे समाधानों की आवश्यकता होती है। इसके बजाय, त्रुटियों के बजट की अनुमति देना बेहतर है - सिस्टम के डाउनटाइम का एक अंश और इस दैनिक या साप्ताहिक मॉनिटर करें। , . ( — SLO SLO).

SLO (. 3 « » ), , , .

(SLO) - , SLI, SLO (, , SLA). , , , , . SRE . , :

,
, : , .


SLI .


, — . , , , , , .

SLO
SLO, . SLO, : , SLO, , SLO. , SLO: SLO.


SLO , . , , , , , .

SLO SRE , . SLO — . SLO , SLO , SLO . SLO — , .

SLI SLO , :

• SLI .
• SLI SLO .
• , , , .
• .

, 2 , , SLO , , 3 , . SLO ( ) .

SLO —
SLO . ( ) , , , . , , - , , , .

, :

• . SLO, . , . SLO , .
• . , , . , SLO, . , .

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

समझौतों का अभ्यास करें

SLA , - . SRE , SLO, SLA. SLO SLA. , , , SLA, .

, . - monitorim_it .