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

मांजरीचे भाषांतर. वाचनाचा आनंद घ्या!

खरोखर कोणते निर्देशक महत्त्वाचे आहेत आणि त्यांचे मोजमाप आणि मूल्यमापन कसे करावे हे समजत नसल्यास सेवा व्यवस्थापित करणे अशक्य आहे. यासाठी, आम्ही आमच्या वापरकर्त्यांना आमच्या अंतर्गत API किंवा सार्वजनिक उत्पादनांपैकी एक वापरत असला तरीही, आम्ही त्यांना विशिष्ट स्तरावरील सेवा परिभाषित करतो आणि प्रदान करतो.

सर्व्हिस लेव्हल इंडिकेटर्स (SLI), सर्व्हिस लेव्हल उद्दिष्टे (SLO) आणि सर्व्हिस लेव्हल अॅग्रीमेंट्स (SLAs) समजून घेण्यासाठी आम्ही आमची अंतर्ज्ञान, अनुभव आणि वापरकर्त्यांच्या इच्छेचा वापर करतो. ही परिमाणे मुख्य मेट्रिक्सचे वर्णन करतात ज्याचे आम्ही परीक्षण करू इच्छितो आणि आम्ही अपेक्षित गुणवत्ता प्रदान करू शकत नसल्यास आम्ही प्रतिक्रिया देऊ. शेवटी, योग्य मेट्रिक्स निवडल्याने काही चूक झाल्यास योग्य कृतींचे मार्गदर्शन करण्यात मदत होते आणि SRE टीमला सेवेच्या आरोग्यावर विश्वास देखील मिळतो.

हा धडा मेट्रिक मॉडेलिंग, मेट्रिक निवड आणि मेट्रिक विश्लेषणाच्या समस्या सोडवण्यासाठी वापरत असलेल्या दृष्टिकोनाचे वर्णन करतो. बहुतेक स्पष्टीकरण उदाहरणांशिवाय असेल, म्हणून आम्ही मुख्य मुद्दे स्पष्ट करण्यासाठी त्याच्या अंमलबजावणी उदाहरणामध्ये वर्णन केलेल्या शेक्सपियर सेवेचा वापर करू.

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

अनेक वाचक कदाचित SLA च्या संकल्पनेशी परिचित असतील, परंतु SLI आणि SLO या संज्ञा काळजीपूर्वक व्याख्येच्या पात्र आहेत कारण सर्वसाधारणपणे SLA हा शब्द ओव्हरलोड केलेला आहे आणि संदर्भानुसार त्याचे अनेक अर्थ आहेत. स्पष्टतेसाठी, आम्हाला ही मूल्ये वेगळी करायची आहेत.

निर्देशक

SLI हे सेवा स्तर सूचक आहे - प्रदान केलेल्या सेवेच्या पातळीच्या एका पैलूचे काळजीपूर्वक परिभाषित परिमाणवाचक माप.

बर्‍याच सेवांसाठी, की SLI ही विनंती विलंब मानली जाते - विनंतीला प्रतिसाद देण्यासाठी किती वेळ लागतो. इतर सामान्य SLI मध्ये त्रुटी दर समाविष्ट आहे, बहुतेक वेळा प्राप्त झालेल्या सर्व विनंत्यांचा एक अंश म्हणून व्यक्त केला जातो आणि सिस्टम थ्रूपुट, सामान्यत: प्रति सेकंद विनंत्यांमध्ये मोजले जाते. मोजमाप अनेकदा एकत्रित केले जातात: कच्चा डेटा प्रथम संकलित केला जातो आणि नंतर बदल दर, सरासरी किंवा टक्केवारीमध्ये रूपांतरित केला जातो.

तद्वतच, SLI थेट स्वारस्याच्या सेवा पातळीचे मोजमाप करते, परंतु काहीवेळा फक्त संबंधित मेट्रिक मोजण्यासाठी उपलब्ध असते कारण मूळ मिळवणे किंवा त्याचा अर्थ लावणे कठीण असते. उदाहरणार्थ, क्लायंट-साइड लेटन्सी हे सहसा अधिक योग्य मेट्रिक असते, परंतु असे काही वेळा असतात जेव्हा लेटन्सी फक्त सर्व्हरवर मोजली जाऊ शकते.

SRE साठी महत्त्वाचा असलेला SLI चा आणखी एक प्रकार म्हणजे उपलब्धता, किंवा सेवा वापरता येणारा कालावधी. अनेकदा यशस्वी विनंत्यांचा दर म्हणून परिभाषित केले जाते, ज्याला काहीवेळा उत्पन्न म्हणतात. (आजीवन-विस्तारित कालावधीसाठी डेटा राखून ठेवला जाण्याची शक्यता-डेटा स्टोरेज सिस्टमसाठी देखील महत्त्वाची आहे.) जरी 100% उपलब्धता शक्य नसली तरी, 100% च्या जवळ उपलब्धता अनेकदा साध्य करता येते; उपलब्धता मूल्ये म्हणून व्यक्त केली जातात "नऊ" ची संख्या » उपलब्धतेची टक्केवारी. उदाहरणार्थ, 99% आणि 99,999% उपलब्धता "2 नाइन" आणि "5 नाईन्स" म्हणून लेबल केली जाऊ शकते. Google Compute Engine चे वर्तमान सांगितलेले उपलब्धता लक्ष्य "साडेतीन नऊ" किंवा 99,95% आहे.

उद्दीष्टे

SLO हे सेवा पातळीचे उद्दिष्ट आहे: SLI द्वारे मोजले जाणारे सेवा स्तरासाठी लक्ष्य मूल्य किंवा मूल्यांची श्रेणी. SLO साठी एक सामान्य मूल्य "SLI ≤ लक्ष्य" किंवा "लोअर लिमिट ≤ SLI ≤ वरची मर्यादा" आहे. उदाहरणार्थ, SLO ला 100 मिलीसेकंदांपेक्षा कमी सरासरी शोध क्वेरी लेटन्सीवर सेट करून आम्ही शेक्सपियर शोध परिणाम “जलद” परत करू असे ठरवू शकतो.

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

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

पुन्हा, हे पहिल्या दृष्टीक्षेपात दिसते त्यापेक्षा अधिक संदिग्ध आहे: तुम्ही गणनेतून QPS पूर्णपणे वगळू नये. वस्तुस्थिती अशी आहे की QPS आणि लेटन्सी एकमेकांशी घट्टपणे संबंधित आहेत: उच्च QPS मुळे बर्‍याचदा उच्च विलंब होतो आणि सेवा सामान्यत: जेव्हा विशिष्ट लोड थ्रेशोल्डवर पोहोचतात तेव्हा कार्यक्षमतेत तीव्र घट अनुभवते.

SLO निवडणे आणि प्रकाशित करणे ही सेवा कशी कार्य करेल याबद्दल वापरकर्त्याच्या अपेक्षा सेट करते. ही रणनीती सेवा मालकाविरुद्ध निराधार तक्रारी कमी करू शकते, जसे की मंद कामगिरी. स्पष्ट SLO शिवाय, वापरकर्ते अनेकदा इच्छित कार्यप्रदर्शनाबद्दल त्यांच्या स्वतःच्या अपेक्षा निर्माण करतात, ज्याचा सेवा डिझाइन आणि व्यवस्थापित करणार्‍या लोकांच्या मतांशी काहीही संबंध नसतो. ही परिस्थिती सेवेकडून वाढलेल्या अपेक्षांना कारणीभूत ठरू शकते, जेव्हा वापरकर्ते चुकून विश्वास करतात की सेवा प्रत्यक्षात आहे त्यापेक्षा अधिक प्रवेशयोग्य असेल आणि जेव्हा वापरकर्ते विश्वास ठेवतात की सिस्टम वास्तविक आहे त्यापेक्षा कमी विश्वासार्ह आहे.

करार

सेवा स्तर करार हा तुमच्या वापरकर्त्यांसोबतचा एक सुस्पष्ट किंवा निहित करार आहे ज्यामध्ये ते समाविष्ट असलेल्या SLO ला भेटण्याचे (किंवा न भेटण्याचे) परिणाम समाविष्ट असतात. जेव्हा ते आर्थिक असतात-सवलत किंवा दंड-परंतु ते इतर स्वरूपाचे असू शकतात तेव्हा त्याचे परिणाम सहज ओळखले जातात. SLO आणि SLA मधील फरकाबद्दल बोलण्याचा एक सोपा मार्ग म्हणजे "SLOs पूर्ण न झाल्यास काय होईल?" कोणतेही स्पष्ट परिणाम नसल्यास, आपण जवळजवळ निश्चितपणे SLO पहात आहात.

SRE सामान्यत: SLA तयार करण्यात गुंतलेला नाही कारण SLA व्यवसाय आणि उत्पादन निर्णयांशी जवळून जोडलेले आहेत. SRE, तथापि, अयशस्वी SLO चे परिणाम कमी करण्यात मदत करण्यात गुंतलेले आहे. ते SLI निर्धारित करण्यात देखील मदत करू शकतात: स्पष्टपणे, करारामध्ये SLO मोजण्यासाठी एक वस्तुनिष्ठ मार्ग असणे आवश्यक आहे किंवा मतभेद असतील.

Google शोध हे सार्वजनिक SLA नसलेल्या महत्त्वाच्या सेवेचे उदाहरण आहे: प्रत्येकाने शक्य तितक्या कार्यक्षमतेने शोध वापरावा अशी आमची इच्छा आहे, परंतु आम्ही जगाशी करार केलेला नाही. तथापि, शोध अनुपलब्ध असल्यास त्याचे परिणाम अजूनही आहेत - अनुपलब्धतेमुळे आमची प्रतिष्ठा कमी होते तसेच जाहिरात महसूल कमी होतो. Google for Work सारख्या इतर अनेक Google सेवांमध्ये वापरकर्त्यांसोबत स्पष्ट सेवा स्तर करार आहेत. एखाद्या विशिष्ट सेवेला SLA आहे की नाही याची पर्वा न करता, SLI आणि SLO परिभाषित करणे आणि सेवा व्यवस्थापित करण्यासाठी त्यांचा वापर करणे महत्त्वाचे आहे.

इतका सिद्धांत - आता अनुभवण्यासाठी.

सराव मध्ये निर्देशक

सेवा पातळी मोजण्यासाठी योग्य मेट्रिक्स निवडणे महत्त्वाचे आहे असा आम्ही निष्कर्ष काढला आहे, सेवा किंवा सिस्टमसाठी कोणते मेट्रिक्स महत्त्वाचे आहेत हे आता तुम्हाला कसे कळेल?

तुम्हाला आणि तुमच्या वापरकर्त्यांना कशाची काळजी आहे?

तुम्हाला प्रत्येक मेट्रिकचा SLI म्हणून वापर करण्याची गरज नाही ज्याचा तुम्ही मॉनिटरिंग सिस्टममध्ये मागोवा घेऊ शकता; वापरकर्त्यांना सिस्टममधून काय हवे आहे हे समजून घेणे तुम्हाला अनेक मेट्रिक्स निवडण्यात मदत करेल. खूप जास्त इंडिकेटर निवडल्याने महत्त्वाच्या निर्देशकांवर लक्ष केंद्रित करणे कठीण होते, तर कमी संख्या निवडल्याने तुमच्या सिस्टमचा मोठा भाग दुर्लक्षित राहू शकतो. प्रणालीच्या आरोग्याचे मूल्यांकन करण्यासाठी आणि समजून घेण्यासाठी आम्ही सामान्यत: अनेक प्रमुख संकेतकांचा वापर करतो.

सेवा सामान्यतः SLI च्या संदर्भात अनेक भागांमध्ये विभागल्या जाऊ शकतात जे त्यांच्याशी संबंधित आहेत:

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

निर्देशकांचा संग्रह

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

एकत्रीकरण

साधेपणा आणि वापर सुलभतेसाठी, आम्ही अनेकदा कच्ची मोजमाप एकत्रित करतो. हे काळजीपूर्वक केले पाहिजे.

काही मेट्रिक्स साध्या वाटतात, जसे की प्रति सेकंद विनंत्या, परंतु हे वरवर पाहता सरळ मापन देखील कालांतराने डेटा एकत्रित करते. मोजमाप विशेषत: प्रति सेकंद एकदा प्राप्त होते किंवा प्रति मिनिट विनंत्यांच्या संख्येवर मोजमाप सरासरी केले जाते? नंतरचा पर्याय फक्त काही सेकंद टिकणार्‍या विनंत्यांची जास्त तात्काळ संख्या लपवू शकतो. एक प्रणाली विचारात घ्या जी प्रति सेकंद 200 विनंत्या सम संख्येसह आणि उर्वरित वेळेत 0 देते. प्रति सेकंद 100 विनंत्या सरासरी मूल्याच्या रूपात स्थिरांक आणि दोनदा तात्कालिक भार समान गोष्टी नाहीत. त्याचप्रमाणे, सरासरी क्वेरी लेटन्सी आकर्षक वाटू शकतात, परंतु ते एक महत्त्वाचा तपशील लपवते: हे शक्य आहे की बहुतेक क्वेरी जलद असतील, परंतु अशा अनेक क्वेरी असतील ज्या हळू असतील.

बहुतेक निर्देशक सरासरी ऐवजी वितरण म्हणून चांगले पाहिले जातात. उदाहरणार्थ, SLI लेटेंसीसाठी, काही विनंत्यांवर त्वरीत प्रक्रिया केली जाईल, तर काही नेहमी जास्त वेळ घेतील, कधी कधी जास्त वेळ. एक साधी सरासरी हे दीर्घ विलंब लपवू शकते. आकृती एक उदाहरण दर्शवते: जरी एक सामान्य विनंती पूर्ण करण्यासाठी अंदाजे 50 ms घेते, तरी 5% विनंत्या 20 पट हळू असतात! केवळ सरासरी विलंबतेवर आधारित निरीक्षण आणि सतर्कता दिवसभरातील वर्तनातील बदल दर्शवत नाही, जेव्हा काही विनंत्या (सर्वोच्च ओळ) प्रक्रियेच्या वेळेत लक्षणीय बदल होतात.

50, 85, 95, आणि 99 पर्सेंटाइल सिस्टम लेटन्सी. Y अक्ष लॉगरिदमिक स्वरूपात आहे.

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

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

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

आधीच्या चाचणीशिवाय, आणि विशिष्ट मानक गृहीतके आणि अंदाजे धारण केल्याशिवाय, आमचा डेटा सामान्यतः वितरित केला जातो असा निष्कर्ष न काढण्याची आम्ही काळजी घेतो. वितरण अपेक्षेप्रमाणे नसल्यास, ऑटोमेशन प्रक्रिया जी समस्येचे निराकरण करते (उदाहरणार्थ, जेव्हा ते आउटलियर्स पाहते, तेव्हा ते उच्च विनंती प्रक्रियेच्या विलंबांसह सर्व्हरला रीस्टार्ट करते) कदाचित ते खूप वेळा करत असेल किंवा पुरेसे नसते (दोन्ही नाहीत. खुप छान).

मानकीकृत निर्देशक

आम्ही SLI साठी सामान्य वैशिष्ट्यांचे मानकीकरण करण्याची शिफारस करतो जेणेकरून तुम्हाला प्रत्येक वेळी त्यांच्याबद्दल अंदाज लावावा लागणार नाही. मानक नमुन्यांचे समाधान करणारे कोणतेही वैशिष्ट्य वैयक्तिक SLI च्या तपशीलातून वगळले जाऊ शकते, उदाहरणार्थ:

• एकत्रीकरण मध्यांतर: "सरासरी 1 मिनिटापेक्षा जास्त"
• एकत्रीकरण क्षेत्र: "क्लस्टरमधील सर्व कार्ये"
• किती वेळा मोजमाप घेतले जाते: “प्रत्येक 10 सेकंदाला”
• कोणत्या विनंत्या समाविष्ट आहेत: "ब्लॅक बॉक्स मॉनिटरिंग जॉब्समधून HTTP प्राप्त करा"
• डेटा कसा मिळवला जातो: "सर्व्हरवर मोजलेल्या आमच्या मॉनिटरिंगबद्दल धन्यवाद"
• डेटा ऍक्सेस लेटन्सी: "लास्ट बाइटची वेळ"

प्रयत्न वाचवण्यासाठी, प्रत्येक सामान्य मेट्रिकसाठी पुन्हा वापरता येण्याजोग्या SLI टेम्पलेट्सचा संच तयार करा; ते प्रत्येकासाठी विशिष्ट SLI म्हणजे काय हे समजून घेणे देखील सोपे करतात.

सराव मध्ये ध्येय

तुमचे वापरकर्ते कशाची काळजी घेतात, तुम्ही काय मोजू शकता याचा विचार करून (किंवा शोधून!) सुरुवात करा. बर्‍याचदा तुमचे वापरकर्ते ज्याची काळजी घेतात ते मोजणे कठीण किंवा अशक्य असते, त्यामुळे तुम्ही त्यांच्या गरजा पूर्ण करता. तथापि, आपण फक्त मोजण्यासाठी जे सोपे आहे त्यापासून प्रारंभ केल्यास, आपल्याला कमी उपयुक्त SLO मिळतील. परिणामी, आम्हाला कधीकधी असे आढळून आले आहे की सुरुवातीला इच्छित उद्दिष्टे ओळखणे आणि नंतर विशिष्ट निर्देशकांसह कार्य करणे हे निर्देशक निवडण्यापेक्षा आणि नंतर उद्दिष्टे साध्य करण्यापेक्षा चांगले कार्य करते.

तुमची उद्दिष्टे परिभाषित करा

जास्तीत जास्त स्पष्टतेसाठी, SLO कसे मोजले जातात आणि ते कोणत्या परिस्थितीत वैध आहेत हे परिभाषित केले पाहिजे. उदाहरणार्थ, आम्ही खालील म्हणू शकतो (दुसरी ओळ पहिल्यासारखीच आहे, परंतु SLI डीफॉल्ट वापरते):

• गेट RPC कॉलचे 99% (सरासरी 1 मिनिटापेक्षा जास्त) 100ms पेक्षा कमी वेळेत पूर्ण होतील (सर्व बॅकएंड सर्व्हरवर मोजले जातात).
• गेट RPC कॉलपैकी 99% 100ms पेक्षा कमी वेळेत पूर्ण होतील.

कार्यप्रदर्शन वक्रांचा आकार महत्त्वाचा असल्यास, तुम्ही एकाधिक SLO निर्दिष्ट करू शकता:

• 90% RPC कॉल 1 एमएस पेक्षा कमी वेळेत पूर्ण होतात.
• 99% RPC कॉल 10 एमएस पेक्षा कमी वेळेत पूर्ण होतात.
• 99.9% RPC कॉल 100 एमएस पेक्षा कमी वेळेत पूर्ण होतात.

जर तुमचे वापरकर्ते विषम वर्कलोड्स व्युत्पन्न करत असतील: मोठ्या प्रमाणात प्रक्रिया (ज्यासाठी थ्रूपुट महत्वाचे आहे) आणि परस्पर प्रक्रिया (ज्यासाठी विलंब महत्वाचा आहे), प्रत्येक लोड वर्गासाठी स्वतंत्र उद्दिष्टे परिभाषित करणे फायदेशीर ठरेल:

• 95% ग्राहक विनंत्यांना थ्रुपुट आवश्यक आहे. अंमलात आणलेल्या RPC कॉलची संख्या सेट करा <1 s.
• ९९% क्लायंट विलंबतेची काळजी घेतात. रहदारी <99 KB आणि चालू <1 ms सह RPC कॉलची संख्या सेट करा.

SLO 100% वेळेत पूर्ण केले जातील असा आग्रह धरणे हे अवास्तव आणि अवांछनीय आहे: यामुळे नवीन कार्यक्षमता आणि उपयोजन सादर करण्याची गती कमी होऊ शकते आणि महाग उपाय आवश्यक आहेत. त्याऐवजी, एरर बजेटला परवानगी देणे चांगले आहे - सिस्टम डाउनटाइमची टक्केवारी अनुमत आहे - आणि या मूल्याचे दररोज किंवा साप्ताहिक निरीक्षण करा. वरिष्ठ व्यवस्थापनाला मासिक किंवा त्रैमासिक मूल्यमापन हवे असेल. (एरर बजेट दुसर्‍या SLO शी तुलना करण्यासाठी फक्त एक SLO आहे.)

SLO उल्लंघनांची टक्केवारी त्रुटी बजेटशी तुलना केली जाऊ शकते (धडा 3 आणि विभाग पहा "एरर बजेटसाठी प्रेरणा"), नवीन प्रकाशन कधी उपयोजित करायचे हे ठरवणाऱ्या प्रक्रियेसाठी इनपुट म्हणून वापरलेल्या फरक मूल्यासह.

लक्ष्य मूल्ये निवडत आहे

निवडलेल्या SLIs, SLOs (आणि शक्यतो SLAs) मध्ये उत्पादित आणि व्यावसायिक हितसंबंधांमुळे नियोजन मूल्ये (SLOs) निवडणे ही पूर्णपणे तांत्रिक क्रिया नाही. त्याचप्रमाणे, कर्मचारी, बाजारासाठी लागणारा वेळ, उपकरणांची उपलब्धता आणि वित्तपुरवठा यासंबंधीच्या समस्यांबाबत माहितीची देवाणघेवाण करावी लागेल. SRE हा या संभाषणाचा भाग असावा आणि विविध पर्यायांमधील जोखीम आणि व्यवहार्यता समजून घेण्यात मदत करावी. आम्ही काही प्रश्नांसह आलो आहोत जे अधिक फलदायी चर्चा सुनिश्चित करण्यात मदत करू शकतात:

सध्याच्या कामगिरीवर आधारित ध्येय निवडू नका.
प्रणालीची बलस्थाने आणि मर्यादा समजून घेणे महत्त्वाचे असले तरी, तर्कविना मेट्रिक्सचे रुपांतर करणे तुम्हाला सिस्टम राखण्यापासून रोखू शकते: महत्त्वपूर्ण पुनर्रचना केल्याशिवाय साध्य होणारी उद्दिष्टे साध्य करण्यासाठी वीर प्रयत्नांची आवश्यकता असेल.

सोपे ठेवा
जटिल SLI गणना प्रणाली कार्यक्षमतेतील बदल लपवू शकते आणि समस्येचे कारण शोधणे कठीण बनवू शकते.

निरपेक्ष टाळा
विलंब न वाढवता अनिश्चित काळासाठी वाढणारा भार हाताळू शकेल अशी प्रणाली असणे मोहक असले तरी, ही आवश्यकता अवास्तव आहे. अशा आदर्शांपर्यंत पोहोचणारी प्रणाली डिझाइन आणि तयार करण्यासाठी बराच वेळ लागेल, ऑपरेट करणे महाग असेल आणि जे कमी काहीही करतील अशा वापरकर्त्यांच्या अपेक्षांसाठी खूप चांगले असेल.

शक्य तितक्या कमी SLO वापरा
सिस्टम विशेषतांचे चांगले कव्हरेज सुनिश्चित करण्यासाठी पुरेशी संख्या SLO निवडा. तुम्ही निवडलेल्या SLO चे संरक्षण करा: तुम्ही विशिष्ट SLO नमूद करून प्राधान्यक्रमांबद्दल कधीही वाद जिंकू शकत नसाल, तर कदाचित त्या SLO चा विचार करणे योग्य नाही. तथापि, सर्व सिस्टीम विशेषता SLO साठी अनुकूल नाहीत: SLO वापरून वापरकर्त्याच्या आनंदाची पातळी मोजणे कठीण आहे.

परिपूर्णतेचा पाठलाग करू नका
तुम्ही नेहमी SLO च्या व्याख्या आणि उद्दिष्टे कालांतराने परिष्कृत करू शकता कारण तुम्ही लोड अंतर्गत सिस्टमच्या वर्तनाबद्दल अधिक जाणून घेता. अवास्तव कठोर ध्येय निवडण्यापेक्षा आपण कालांतराने परिष्कृत कराल अशा तरंगत्या उद्दिष्टासह प्रारंभ करणे चांगले आहे जे आपल्याला अप्राप्य वाटत असताना शिथिल करावे लागेल.

SREs आणि उत्पादन विकासकांसाठी कामाला प्राधान्य देण्यासाठी SLO हे प्रमुख चालक असू शकतात आणि असावेत कारण ते वापरकर्त्यांसाठी चिंता दर्शवतात. एक चांगला SLO हे विकास कार्यसंघासाठी उपयुक्त अंमलबजावणी साधन आहे. परंतु जर संघाने अति आक्रमक SLO साध्य करण्यासाठी वीर प्रयत्न केले तर खराब रचना केलेल्या SLO मुळे वाया जाऊ शकते किंवा SLO खूप कमी असल्यास खराब उत्पादन होऊ शकते. SLO एक शक्तिशाली लीव्हर आहे, त्याचा हुशारीने वापर करा.

तुमचे मोजमाप नियंत्रित करा

SLI आणि SLO हे सिस्टीम व्यवस्थापित करण्यासाठी वापरलेले प्रमुख घटक आहेत:

• SLI प्रणालींचे निरीक्षण करा आणि मापन करा.
• SLI ची SLO शी तुलना करा आणि कारवाई आवश्यक आहे का ते ठरवा.
• कृती आवश्यक असल्यास, ध्येय साध्य करण्यासाठी काय करावे लागेल ते शोधा.
• ही क्रिया पूर्ण करा.

उदाहरणार्थ, जर चरण 2 दर्शविते की विनंतीची वेळ संपत आहे आणि काही केले नाही तर काही तासांत SLO खंडित होईल, तर पायरी 3 मध्ये सर्व्हर CPU बद्ध आहेत या गृहितकाची चाचणी करणे आणि अधिक सर्व्हर जोडणे लोडचे वितरण करेल. SLO शिवाय, कारवाई करायची की नाही (किंवा केव्हा) हे तुम्हाला माहीत नसते.

SLO सेट करा - नंतर वापरकर्त्याच्या अपेक्षा सेट केल्या जातील
SLO प्रकाशित केल्याने सिस्टम वर्तनासाठी वापरकर्त्याच्या अपेक्षा सेट केल्या जातात. वापरकर्ते (आणि संभाव्य वापरकर्ते) अनेकदा सेवा वापरण्यासाठी योग्य आहे की नाही हे समजून घेण्यासाठी त्यांच्याकडून काय अपेक्षा करावी हे जाणून घ्यायचे असते. उदाहरणार्थ, फोटो सामायिकरण वेबसाइट वापरू इच्छिणारे लोक, जरा कमी उपलब्धतेच्या बदल्यात दीर्घायुष्य आणि कमी किमतीचे वचन देणारी सेवा वापरणे टाळू शकतात, जरी तीच सेवा संग्रहण रेकॉर्ड व्यवस्थापन प्रणालीसाठी आदर्श असू शकते.

तुमच्या वापरकर्त्यांसाठी वास्तववादी अपेक्षा सेट करण्यासाठी, खालीलपैकी एक किंवा दोन्ही युक्त्या वापरा:

• सुरक्षिततेचा मार्जिन ठेवा. वापरकर्त्यांना जे जाहिरात केले जाते त्यापेक्षा कठोर अंतर्गत SLO वापरा. हे आपल्याला समस्यांना बाहेरून दृश्यमान होण्यापूर्वी प्रतिक्रिया देण्याची संधी देईल. SLO बफर तुम्हाला रिलीझ स्थापित करताना सुरक्षितता मार्जिन ठेवण्याची परवानगी देतो जे सिस्टम कार्यक्षमतेवर परिणाम करतात आणि डाउनटाइमसह वापरकर्त्यांना निराश न करता सिस्टम राखणे सोपे आहे याची खात्री करते.
• वापरकर्त्याच्या अपेक्षा ओलांडू नका. वापरकर्ते तुम्ही काय ऑफर करता त्यावर आधारित असतात, तुम्ही काय म्हणता त्यावर नाही. तुमच्या सेवेची वास्तविक कामगिरी नमूद केलेल्या SLO पेक्षा खूपच चांगली असल्यास, वापरकर्ते सध्याच्या कामगिरीवर अवलंबून राहतील. आपण हेतुपुरस्सर सिस्टम बंद करून किंवा हलके भारांखाली कार्यप्रदर्शन मर्यादित करून अतिनिर्भरता टाळू शकता.

प्रणाली किती चांगल्या प्रकारे अपेक्षांची पूर्तता करते हे समजून घेणे, प्रणालीला गती देण्यासाठी आणि ती अधिक सुलभ आणि लवचिक बनवण्यासाठी गुंतवणूक करायची की नाही हे ठरवण्यास मदत करते. वैकल्पिकरित्या, जर एखादी सेवा खूप चांगली कामगिरी करत असेल, तर काही कर्मचारी वेळ इतर प्राधान्यक्रमांवर खर्च केला पाहिजे, जसे की तांत्रिक कर्ज फेडणे, नवीन वैशिष्ट्ये जोडणे किंवा नवीन उत्पादने सादर करणे.

व्यवहारात करार

SLA तयार करण्यासाठी व्यवसाय आणि कायदेशीर संघांनी त्याचे उल्लंघन केल्याचे परिणाम आणि दंड परिभाषित करणे आवश्यक आहे. SRE ची भूमिका त्यांना SLA मध्ये समाविष्ट असलेल्या SLOs पूर्ण करण्यासाठी संभाव्य आव्हाने समजून घेण्यात मदत करणे आहे. SLO तयार करण्याच्या बहुतेक शिफारसी SLA ला देखील लागू होतात. तुम्ही वापरकर्त्यांना जे वचन देता त्यामध्ये पुराणमतवादी असणे शहाणपणाचे आहे कारण तुमच्याकडे जितके जास्त असेल तितके अवास्तव किंवा पूर्ण करणे कठीण वाटणारे SLA बदलणे किंवा काढून टाकणे कठीण आहे.

अनुवाद शेवटपर्यंत वाचल्याबद्दल धन्यवाद. मॉनिटरिंगबद्दल माझ्या टेलिग्राम चॅनेलची सदस्यता घ्या मॉनिटरिम_इट и मध्यम वर ब्लॉग.

स्त्रोत: www.habr.com