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

बिल्ली द्वारा अनुवाद। पढेर आनन्द लिनुहोस्!

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

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

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

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

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

सूचकहरू

SLI एक सेवा स्तर सूचक हो - प्रदान गरिएको सेवाको स्तरको एक पक्षको सावधानीपूर्वक परिभाषित मात्रात्मक मापन।

धेरैजसो सेवाहरूको लागि, कुञ्जी SLI लाई अनुरोध विलम्बता मानिन्छ - अनुरोधको जवाफ फर्काउन कति समय लाग्छ। अन्य सामान्य SLI मा त्रुटि दर समावेश छ, प्रायः सबै प्राप्त अनुरोधहरूको अंशको रूपमा व्यक्त गरिन्छ, र प्रणाली थ्रुपुट, सामान्यतया प्रति सेकेन्ड अनुरोधहरूमा मापन गरिन्छ। मापनहरू प्रायः एकत्रित हुन्छन्: कच्चा डाटा पहिले सङ्कलन गरिन्छ र त्यसपछि परिवर्तनको दर, औसत, वा प्रतिशतमा रूपान्तरण गरिन्छ।

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

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

उद्देश्यहरू

SLO भनेको सेवा स्तरको उद्देश्य हो: SLI द्वारा मापन गरिएको सेवा स्तरको लागि लक्षित मान वा मानहरूको दायरा। SLO को लागि सामान्य मान "SLI ≤ लक्ष्य" वा "तल्लो सीमा ≤ SLI ≤ माथिल्लो सीमा" हो। उदाहरण को लागी, हामी SLO लाई 100 मिलिसेकेन्ड भन्दा कम को औसत खोज क्वेरी विलम्बता मा सेट गरेर शेक्सपियर खोज परिणाम "छिटो" फर्काउने निर्णय गर्न सक्छौं।

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

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

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

SLO चयन र प्रकाशित गर्दा सेवाले कसरी काम गर्नेछ भन्ने बारे प्रयोगकर्ताको अपेक्षाहरू सेट गर्छ। यो रणनीतिले सेवा मालिक विरुद्ध निराधार उजुरीहरू कम गर्न सक्छ, जस्तै ढिलो कार्यसम्पादन। स्पष्ट SLO बिना, प्रयोगकर्ताहरूले प्राय: इच्छित कार्यसम्पादनको बारेमा आफ्नै अपेक्षाहरू सिर्जना गर्छन्, जसको सेवा डिजाइन र व्यवस्थापन गर्ने व्यक्तिहरूको रायसँग कुनै सरोकार नहुन सक्छ। यो अवस्थाले सेवाबाट अपेक्षाहरू बढाउन सक्छ, जब प्रयोगकर्ताहरूले गल्तीले यो सेवा वास्तवमा भन्दा बढी पहुँचयोग्य हुनेछ भन्ने विश्वास गर्छन्, र प्रयोगकर्ताहरूले यो प्रणाली वास्तवमा भन्दा कम भरपर्दो छ भन्ने विश्वास गर्दा अविश्वास पैदा गर्दछ।

सम्झौता

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

SRE सामान्यतया SLA हरू सिर्जना गर्न संलग्न हुँदैन किनभने SLA हरू व्यापार र उत्पादन निर्णयहरूसँग नजिक छन्। तथापि, SRE असफल SLO को परिणामहरू कम गर्न मद्दत गर्न संलग्न छ। तिनीहरूले SLI निर्धारण गर्न पनि मद्दत गर्न सक्छन्: स्पष्ट रूपमा, सम्झौतामा SLO मापन गर्ने उद्देश्यपूर्ण तरिका हुनुपर्छ वा त्यहाँ असहमति हुनेछ।

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

धेरै सिद्धान्त - अब अनुभव गर्न।

व्यवहारमा सूचकहरू

सेवा स्तर मापन गर्न उपयुक्त मेट्रिक्स छनोट गर्नु महत्त्वपूर्ण छ भन्ने निष्कर्षमा पुगेका छौं, सेवा वा प्रणालीको लागि कुन मेट्रिक्स महत्त्वपूर्ण छ भनेर अब तपाईं कसरी जान्नुहुन्छ?

तपाईं र तपाईंका प्रयोगकर्ताहरूले के कुराको ख्याल राख्नुहुन्छ?

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

सेवाहरूलाई सामान्यतया SLI को सन्दर्भमा धेरै भागहरूमा विभाजन गर्न सकिन्छ जुन तिनीहरूसँग सान्दर्भिक छन्:

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

सूचकहरूको सङ्कलन

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

एकत्रीकरण

सरलता र प्रयोगको सहजताको लागि, हामी प्रायः कच्चा मापनहरू जम्मा गर्छौं। यो सावधानीपूर्वक गर्नुपर्छ।

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

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

50, 85, 95, र 99 प्रतिशत प्रणाली विलम्बता। Y अक्ष लॉगरिदमिक ढाँचामा छ।

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

सांख्यिकीय त्रुटिहरूमा नोट गर्नुहोस्

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

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

मानकीकरण सूचकहरू

हामी SLI का सामान्य विशेषताहरूलाई मानकीकरण गर्न सिफारिस गर्छौं ताकि तपाईंले प्रत्येक पटक तिनीहरूको बारेमा अनुमान लगाउनु पर्दैन। मानक ढाँचाहरू पूरा गर्ने कुनै पनि विशेषतालाई व्यक्तिगत SLI को विशिष्टताबाट बहिष्कृत गर्न सकिन्छ, उदाहरणका लागि:

• एकत्रीकरण अन्तरालहरू: "औसत १ मिनेट भन्दा बढी"
• एकत्रीकरण क्षेत्रहरू: "सबै कार्यहरू क्लस्टरमा"
• कति पटक मापन गरिन्छ: "हरेक 10 सेकेन्ड"
• कुन अनुरोधहरू समावेश छन्: "HTTP कालो बक्स निगरानी कार्यहरूबाट प्राप्त गर्नुहोस्"
• डाटा कसरी प्राप्त गरिन्छ: "सर्भरमा मापन गरिएको हाम्रो निगरानीको लागि धन्यवाद"
• डाटा पहुँच विलम्बता: "समय अन्तिम बाइट"

प्रयास बचत गर्न, प्रत्येक सामान्य मेट्रिकको लागि पुन: प्रयोज्य SLI टेम्प्लेटहरूको सेट सिर्जना गर्नुहोस्; तिनीहरूले एक निश्चित SLI को अर्थ के हो भनेर बुझ्न सबैलाई सजिलो बनाउँदछ।

अभ्यासमा लक्ष्यहरू

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

लक्ष्य परिभाषित गर्नुहोस्

अधिकतम स्पष्टताको लागि, यो परिभाषित गरिनु पर्छ कि कसरी SLO मापन गरिन्छ र तिनीहरू कुन अवस्थामा मान्य छन्। उदाहरण को लागी, हामी निम्न भन्न सक्छौं (दोस्रो रेखा पहिलो जस्तै हो, तर SLI पूर्वनिर्धारित प्रयोग गर्दछ):

• गेट RPC कलहरूको ९९% (औसत १ मिनेट भन्दा बढी) १००ms भन्दा कममा पूरा हुनेछ (सबै ब्याकइन्ड सर्भरहरूमा मापन गरिएको)।
• 99% प्राप्त RPC कलहरू 100ms भन्दा कममा पूरा हुनेछन्।

यदि प्रदर्शन कर्भको आकार महत्त्वपूर्ण छ भने, तपाइँ धेरै SLO निर्दिष्ट गर्न सक्नुहुन्छ:

• 90% प्राप्त RPC कलहरू 1 ms भन्दा कममा पूरा भयो।
• 99% प्राप्त RPC कलहरू 10 ms भन्दा कममा पूरा भयो।
• 99.9% प्राप्त RPC कलहरू 100 ms भन्दा कममा पूरा भयो।

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

• 95% ग्राहक अनुरोधहरू थ्रुपुट चाहिन्छ। <1 सेकेन्ड कार्यान्वयन गरिएका RPC कलहरूको गणना सेट गर्नुहोस्।
• ९९% ग्राहकहरूले विलम्बताको ख्याल राख्छन्। ट्राफिक <99 KB र चलिरहेको <1 ms संग RPC कलहरूको गणना सेट गर्नुहोस्।

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

SLO उल्लङ्घनहरूको प्रतिशत त्रुटि बजेटसँग तुलना गर्न सकिन्छ (अध्याय 3 र खण्ड हेर्नुहोस् "त्रुटि बजेटको लागि प्रेरणा"), नयाँ रिलीजहरू कहिले डिप्लोय गर्ने निर्णय गर्ने प्रक्रियामा इनपुटको रूपमा प्रयोग गरिएको भिन्नता मानको साथ।

लक्ष्य मानहरू चयन गर्दै

चयन गरिएका SLIs, SLOs (र सम्भावित SLAs) मा प्रतिबिम्बित हुनु पर्ने उत्पादन र व्यवसायिक रुचिहरूको कारणले योजना मानहरू (SLOs) चयन गर्नु विशुद्ध प्राविधिक गतिविधि होइन। त्यसै गरी, कर्मचारी, बजारमा समय, उपकरण उपलब्धता, र वित्त पोषण सम्बन्धी मुद्दाहरूको बारेमा जानकारी आदानप्रदान गर्न आवश्यक पर्दछ। SRE यस वार्तालापको हिस्सा हुनुपर्दछ र विभिन्न विकल्पहरूको जोखिम र व्यवहार्यता बुझ्न मद्दत गर्नुपर्दछ। हामीले थप उत्पादक छलफल सुनिश्चित गर्न मद्दत गर्न सक्ने केही प्रश्नहरू लिएर आएका छौं:

हालको प्रदर्शनको आधारमा लक्ष्य छनौट नगर्नुहोस्।
प्रणालीको बल र सीमाहरू बुझ्न महत्त्वपूर्ण हुँदा, तर्क बिना मेट्रिक्स अनुकूलन गर्नाले तपाईंलाई प्रणाली कायम राख्नबाट रोक्न सक्छ: यसले महत्त्वपूर्ण पुन: डिजाइन बिना प्राप्त गर्न नसकिने लक्ष्यहरू प्राप्त गर्न वीर प्रयासहरू आवश्यक पर्दछ।

यसलाई सरल राख्नुहोस्
जटिल SLI गणनाहरूले प्रणाली प्रदर्शनमा परिवर्तनहरू लुकाउन सक्छ र समस्याको कारण पत्ता लगाउन गाह्रो बनाउन सक्छ।

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

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

पूर्णताको पछि नलाग्नुहोस्
तपाईले जहिले पनि SLO को परिभाषा र लक्ष्यहरू समयको साथ परिमार्जन गर्न सक्नुहुन्छ जब तपाईले लोड अन्तर्गत प्रणालीको व्यवहारको बारेमा थप जान्नुहुन्छ। यो एक अत्याधिक कडा लक्ष्य छनोट गर्नु भन्दा एक फ्लोटिंग लक्ष्य संग सुरु गर्न को लागी राम्रो छ कि तपाईले यो अप्राप्य फेला पर्दा आराम गर्नु पर्छ।

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

आफ्नो मापन नियन्त्रण गर्नुहोस्

SLI र SLO प्रणालीहरू व्यवस्थापन गर्न प्रयोग गरिने मुख्य तत्वहरू हुन्:

• SLI प्रणालीहरू निगरानी र मापन गर्नुहोस्।
• SLI लाई SLO सँग तुलना गर्नुहोस् र कारबाही आवश्यक छ भने निर्णय गर्नुहोस्।
• यदि कार्य आवश्यक छ भने, लक्ष्य प्राप्त गर्न के गर्न आवश्यक छ भनेर पत्ता लगाउनुहोस्।
• यो कार्य पूरा गर्नुहोस्।

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

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

तपाइँका प्रयोगकर्ताहरूका लागि यथार्थपरक अपेक्षाहरू सेट गर्न, निम्न मध्ये एक वा दुवै रणनीतिहरू प्रयोग गर्नुहोस्:

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

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

व्यवहारमा सम्झौताहरू

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

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

स्रोत: www.habr.com