तो, आप अपनी क्लाउड सेवा की विश्वसनीयता का आकलन करने का प्रयास कर रहे हैं

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

आमतौर पर, एक संभावित उपयोगकर्ता, "99.95% मासिक अपटाइम SLA" के बारे में पढ़ने के बाद, बहुत प्रसन्न होता है - 30 दिनों के लिए प्रति माह 21 मिनट से अधिक के लिए कोई डाउनटाइम की गारंटी बहुत अच्छा लगता है।

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

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

मान लीजिए कि एक इमेज प्रोसेसिंग सेवा विंडोज एज़्योर पर चलती है और डेटा स्टोर करने के लिए कोड और एज़्योर स्टोरेज को निष्पादित करने के लिए एज़्योर क्लाउड सर्विसेज से तथाकथित वेब और वर्कर भूमिकाओं का उपयोग करती है। बहुत बढ़िया। हम क्लाउड सेवाओं पर SLA खोलते हैं और हम देखते हैं कि TL; DR; भूमिका की उपलब्धता की गारंटी प्रति माह 99.95% की गारंटी है (बशर्ते कि प्रत्येक भूमिका में कम से कम दो उदाहरण हों)। हम Azure Storage पर SLA खोलते हैं और हम देखते हैं कि TL; DR; कम से कम 99.9% संग्रहण अनुरोधों के प्रदर्शन की गारंटी है। यदि गुणवत्ता स्तर गारंटी के अनुरूप नहीं है, तो आपको समर्थन से संपर्क करने की आवश्यकता है - और फिर आपूर्तिकर्ता पैसे का हिस्सा लौटा देगा।

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

निम्नलिखित मौलिक रूप से महत्वपूर्ण है: यहां तक ​​कि सबसे खराब स्थिति में, आपको अपेक्षाकृत कम धनराशि वापस कर दी जाएगी जो कवर करेगी ... लेकिन यह कुछ भी कवर नहीं करेगी, क्योंकि यह उपभोग की गई सेवा की लागत के एक हिस्से से बंधा हुआ है, और क्लाउड सेवाओं का उपयोग करने की लागत की तुलना में बहुत कम है, उदाहरण के लिए, कर्मचारी पारिश्रमिक जो सेवा प्रदाता के समर्थन से संपर्क करेगा। एसएलए का अर्थ तीन निनों के साथ बहुत सरल है: "प्रिय उपयोगकर्ताओं, यह एक बहुत ही विश्वसनीय सेवा है, हम बहुत मेहनत करते हैं, बीएफ AFRAID और इसका उपयोग करते हैं, हम अगले महीने की 10 तारीख तक बिल देंगे," एसएलए अनिवार्य रूप से सेवा से अपेक्षाएं रखता है, जो बहुत महत्वपूर्ण है। यदि उपलब्धता की गारंटी होती है, उदाहरण के लिए, समय का 15%, सेवा से अपेक्षाएं मौलिक रूप से भिन्न होंगी।

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

तदनुसार, कॉपी में हर किसी के साथ कुछ बैठकों और दो सप्ताह के पत्राचार के बाद, हम सब कुछ गुणा कर सकते हैं और यह तय कर सकते हैं कि हम क्या पेशकश कर सकते हैं, उदाहरण के लिए, सेवा महीने के दौरान 99.9% समय के लिए चालू है। ऐसी SLA तैयार करने के बाद, हम अपने उपयोगकर्ताओं को बताते हैं कि "हमारी सेवा विश्वसनीय है, इसका उपयोग करें, सब कुछ ठीक हो जाएगा, और यदि नहीं, तो हम इसे बहुत तेज़ी से ठीक करेंगे, PANIC के बिना"।

आप ऐसे SLA को प्रकाशित करते हैं और कुछ समय बाद यह निष्कासित होता है ...

... आप महसूस करते हैं कि आपको कुछ बेहद कष्टप्रद त्रुटि के लिए तुरंत एक प्रकाशन प्रकाशित करने की आवश्यकता है। या आपको बुनियादी ढांचे के स्तर पर सेटिंग्स को बदलने की आवश्यकता है। या सेवा ने स्वयं महसूस किया कि लोड बढ़ गया था, और यह तय किया कि स्केलिंग के लिए एक आदेश जारी करना आवश्यक था।

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

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

हम अपने SLA के शब्दांकन पर लौटते हैं। जाहिर है, आपको किसी तरह से स्केलिंग और प्रकाशन अपडेट जैसे संचालन की आवश्यकता को दूर करने की आवश्यकता है, और इसे अपने एसएलए में ध्यान में रखें। और हां, हमारी सेवा को लगता है कि उपयोगकर्ताओं से छवियों की एक बड़ी (और अग्रिम में अज्ञात) प्रक्रिया को जल्दी से पर्याप्त करना होगा, और इसके लिए यह पैमाने पर होना चाहिए। और इन आवश्यक कार्यों के लिए "सहायक" प्रबंधन सेवा के उपयोग की आवश्यकता होती है।

फिर इस प्रबंधन सेवा के एसएलए को देखना तर्कसंगत है ताकि यह समझा जा सके कि इससे क्या उम्मीद की जानी चाहिए।

विंडोज एज़्योर में, प्रबंधन एपीआई का उपयोग बुनियादी ढांचे के प्रबंधन के लिए किया जाता है (प्रबंधन पोर्टल और cmdlets भी इसके माध्यम से काम करते हैं)। तो, प्रबंधन एपीआई सेवा के SLA खोलें और ...

... लेकिन नहीं, इस दस्तावेज़ से परिचित होना संभव नहीं होगा, क्योंकि यह बस मौजूद नहीं है। और Amazon EC2 में SLA इंफ्रास्ट्रक्चर मैनेजमेंट सर्विस भी नहीं है।

रुको ... ओह SHI ~

हां, हमने सेवा में SLA की पूरी कमी को लगभग अनदेखा कर दिया है, जिस पर हमारी सेवा काफी निर्भर करती है। यह केवल कोड अपडेट के बारे में नहीं है (जो देरी से प्रतीत होता है, लेकिन वास्तव में कभी-कभी उन्हें बहुत तत्काल प्रकाशित करने की आवश्यकता होती है) - पैमाने की क्षमता की लगातार आवश्यकता होती है।

प्रबंधन सेवा के लिए कोई SLA क्यों नहीं है? कोई केवल अटकलें लगा सकता है।

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

इसके बजाय, हम यह मान सकते हैं कि उपयोगकर्ता प्रबंधन सेवा को एक महत्वपूर्ण सेवा नहीं मानते हैं और "मुख्य" सेवाओं के लिए वर्तमान SLA योगों से काफी संतुष्ट हैं।

वैकल्पिक रूप से, एक यह मान सकता है, और एक ही समय में (और यह रोटी के बिना संभव है) ।

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

दिमित्री मेश्चेरीकोव,
डेवलपर उत्पाद विभाग