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

बिल्ली द्वारा अनुवाद. मन लगाकर पढ़ाई करो!

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

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

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

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

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

संकेतक

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

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

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

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

लक्ष्यों

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

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

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

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

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

समझौता

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

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

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

इतने सारे सिद्धांत - अब अनुभव करने के लिए।

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

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

आपको और आपके उपयोगकर्ताओं को किस बात की परवाह है?

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

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

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

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

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

एकत्रीकरण

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

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

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

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

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

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

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

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

संकेतकों का मानकीकरण करें

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

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

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

व्यवहार में लक्ष्य

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

अपने लक्ष्य परिभाषित करें

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

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

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

• 90% आरपीसी कॉल 1 एमएस से भी कम समय में पूरी हो जाती हैं।
• 99% आरपीसी कॉल 10 एमएस से भी कम समय में पूरी हो जाती हैं।
• 99.9% आरपीसी कॉल 100 एमएस से भी कम समय में पूरी हो जाती हैं।

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

• 95% ग्राहक अनुरोधों के लिए थ्रूपुट की आवश्यकता होती है। निष्पादित RPC कॉल की गिनती सेट करें <1 s.
• 99% ग्राहक विलंबता की परवाह करते हैं। ट्रैफ़िक <1 KB और चलने वाले <10 एमएस के साथ RPC कॉल की गिनती सेट करें।

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

एसएलओ उल्लंघनों के प्रतिशत की तुलना त्रुटि बजट से की जा सकती है (अध्याय 3 और अनुभाग देखें)। "त्रुटि बजट के लिए प्रेरणा"), उस प्रक्रिया में इनपुट के रूप में उपयोग किए जाने वाले अंतर मान के साथ जो यह तय करता है कि नई रिलीज़ को कब तैनात करना है।

लक्ष्य मानों का चयन करना

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

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

इसे सरल रखें
जटिल एसएलआई गणनाएं सिस्टम प्रदर्शन में बदलावों को छिपा सकती हैं और समस्या का कारण ढूंढना कठिन बना सकती हैं।

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

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

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

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

अपने माप को नियंत्रित करें

एसएलआई और एसएलओ सिस्टम को प्रबंधित करने के लिए उपयोग किए जाने वाले प्रमुख तत्व हैं:

• एसएलआई सिस्टम की निगरानी और माप करें।
• एसएलआई की एसएलओ से तुलना करें और निर्णय लें कि क्या कार्रवाई की आवश्यकता है।
• यदि कार्रवाई की आवश्यकता है, तो पता लगाएं कि लक्ष्य प्राप्त करने के लिए क्या करने की आवश्यकता है।
• यह क्रिया पूर्ण करें.

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

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

अपने उपयोगकर्ताओं के लिए यथार्थवादी अपेक्षाएँ निर्धारित करने के लिए, निम्नलिखित में से एक या दोनों युक्तियों का उपयोग करें:

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

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

व्यवहार में समझौते

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

अनुवाद को अंत तक पढ़ने के लिए धन्यवाद. निगरानी के बारे में मेरे टेलीग्राम चैनल की सदस्यता लें मॉनिटरिम_इट и माध्यम पर ब्लॉग.

स्रोत: www.habr.com