नमस्ते।
 आज हमारे पास एसएलए पर एक छोटा सा टुटोरिअल होगा,जहाँ एसएलए पर हमने जो कुछ भी चर्चा की है, वह निरंतरता में है।
 एसएलए जैसा कि हम सेवा स्तर समझौते के लिए समझते हैं और किसी भी क्लाउड (cloud) सेवा प्रदाता और क्लाउड (cloud) सेवा उपभोक्ता के लिए यह महत्वपूर्ण है, कि इसे निष्पादित करने के लिए कोई समझौता हो या तो यह सेवा उपभोग करे या प्रदान करें।
 जैसा कि हम समझते हैं कि जब हम क्लाउड कंप्यूटिंग (Cloud Computing) का उपयोग कर रहे हैं, हम मूल रूप से तृतीय पक्ष सेवाओं पर लीवरेज कर रहे हैं, जो सेवा प्रदाता है, और आप उपभोक्ता जहाँ चीजें होस्ट की जाती हैं।
 यहाँ दोनों तरह से साइन अप करना चाहिए या हमारे पास एसएलए (SLA) होना चाहिए।
 दुर्भाग्य से ऐसा कोई मानक नहीं है, या मुझे यह कहना चाहिए कि मानक राज्य अलग-अलग सेवाओं में मानक एसएलए (SLA) रखने के लिए विकसित हो रहा है, जो कि एक प्रमुख कारण है, शायद विभिन्न प्रकार की सेवाएं हैं, विभिन्न प्रदाताओं द्वारा प्रदान किए जाते हैं।
 वे उपभोक्ता की विभिन्न श्रेणियों में हैं जिन्हें हमें विभिन्न पैमाने पर सेवाओं की आवश्यकता होती है।
 तो, कभी भी कम व्यापक दिशानिर्देश नहीं हैं जिसके द्वारा इन एसएलए (SLA) शासित होते हैं।
 इसलिए, जब भी आप किसी भी सेवा प्रदाता से सेवा लेते हैं, तो यह किसी वाणिज्यिक क्लाउड (commercial cloud) क्लाउड जैसे माइक्रोसिरिसियो या Google क्लाउड, या आईबीएम क्लाउड या अमेज़ॅन क्लाउड या किसी क्लाउड का वाणिज्यिक हो (microsirisio or Google cloud, or IBM cloud or Amazon cloud or any cloud)।
तो, आपको कुछ समझौते पर सहमत होना चाहिए।
 इसलिए, हमने अपने एसएलए (SLA) वार्ता में क्या देखा है कि इस समझौते का अर्थ यह है कि इसका गठन कैसे किया जा सकता है या इसके लिए मूलभूत आधारभूत संरचना क्या होगी।
 तो, इसके लिए मेरे मामले में हमने एसएलओ, केपीआई (SLO, KPI’s) और इतने आगे के बारे में बात की है, जो हमें इस एसएलए (SLA) को बनाने की अनुमति देता है।
 इसलिए, कुछ मामलों में यह कुछ मीट्रिक (metrics) हैं, जहाँ नीतियां संचालित होती हैं।
 जैसा कि आपका डेटा बैक पॉलिसी (policy driven right) होना चाहिए और इसी तरह से आगे बढ़ने के साथ, जहां अधिक नीतियां संचालित होती हैं और जहां कुछ समझौते पैरामीटर पर अधिक होते हैं, जैसे कि समय देखने या सीपीयू (CPU) का उपयोग या डिस्क का उपयोग क्या होता है।
 यह कुछ चीजें हैं, जो मेट्रिक्स ((metrics)हैं।
 तो, हम अब एक या दो समस्या को देखने की कोशिश करेंगे और इससे पहले हम यह देखेंगे कि विभिन्न प्रकार के एसएलए (SLA) के अधिकार में विभिन्न पैरामीटर कैसे विचार किए जाते हैं।
 विभिन्न प्रकार के व्यावसायिक जीवन में, हमने इसे मुख्य रूप से वाणिज्यिक संसाधनों (commercial providers) जैसे कि एज़ूर, आईबीएम, गूगल और अमेज़ॅन (Azure, IBM, Google and Amazon )और अन्य लोगों से इंटरनेट संसाधनों से लिया है।
 तो, विचार यह है कि वे कैसे चीजों को फ्रेम करते हैं एक तरह से।
 इसलिए, इन चीजों को देखने से पहले हम उन चीजों को देखते हैं जिसकी हमने इस स्लाइड से पहले चर्चा की है।
 जैसे कि यह प्रदाता और उपभोक्ता के बीच अनुबंध का एक औपचारिक समझौता है।
 प्रदाता पर उपभोक्ता ट्रस्ट की नींव, और कभी-कभी वीज़ा-विवेक कि प्रदाता इस उपभोक्ता को प्रदाता गारंटी प्रदान करने वाली सेवा की उपलब्धता और उपलब्धता के लिए औपचारिक आधार को परिभाषित करने के उद्देश्य से इस उपभोक्ता को कैसे रखना चाहते हैं।
 और जैसा कि हमने एसएलओ (SLO’s ) की सेवाओं और एसएलए (SLA) के लिए निष्पक्ष रूप से जटिल (miserable) स्थिति की तरह बात की है, चयन क्लाउड (cloud) प्रदाता के लिए मूलभूत एसएलओ (SLO) इस तरह से देखा गया है कि मैंने केवल एक स्लाइड रखी हैं और यह चजें वहां होंगी।
 हम इन दो समस्याओं पर चर्चा करेंगे और फिर कुछ विज्ञापनों को देखने का प्रयास करेंगें कि किस तरह से यह विज्ञापन किसी अन्य चीज को क्लाउड करता है और क्लाउड (cloud) यह कैसे देखता और कैसे इसे परिभाषित करता हैं।
 इसलिए, आइए हम एक साधारण समस्या की तरह मान लें कि क्लाउड गारंटी (cloud guarantee) सेवा की उपलब्धता 99% समय सही है।
 देर से तीसरे पक्ष के आवेदन क्लाउड (cloud) में एक महीने के अंत में दिन में 12 घंटे चलते हैं और यह पाया गया कि अक्सर 0.75 घंटे का आबादी है।
 पता लगाएं कि प्रदाता ने प्रारंभिक उपलब्धता गारंटी का उल्लंघन किया है या नहीं।
 इसलिए, यह एसएलए (SLA) में 99 प्रतिशत समय के रूप में देता है, देर से तीसरे पक्ष के एक महीने के दिन के अंत में 12 घंटे के लिए क्लाउड (cloud) कहते हैं की यह 10.75 है और आप यह जानना चाहते हैं कि प्रदाता ने प्रारंभिक उपलब्धता गारंटी का उल्लंघन किया है या नहीं।
 तो, यह एक समस्या है जहा कुल समय जिसके लिए आवेदन एक महीने में चलाने के लिए 12 क्रॉस (cross) 33, 360 घंटे के बराबर है।
 अब, हम आबादी का समय 10.75 घंटे कहते हैं, यह घोषित किया गया है और यह दिया भी गया है।
 इसलिए, सेवा अवधि 360 शून्य से 10.75 घंटे (360 minus 10.75 hours) के बराबर होती है।
 तो, 1 शून्य से 10.75 के बराबर प्रतिशत उपलब्धता 34 9.25 से 100 में जो 96.9 2 है (percentage availability equal to 1 minus 10.75 by 349.25 into 100 which is 96.92)।
 तो, यह प्रतिशत उपलब्धता होगी जिसकी आप सीधे गणना कर सकते हैं।
 तो, यह प्रारंभिक सेवा गारंटी 99 प्रतिशत थी? तो, इसलिए अंतिम सेवा गारंटी के रूप में है।
 इसलिए, अंतिम सेवा उपलब्धता प्रारंभिक सेवा गारंटी से कम है।
 तो, हम क्या निष्कर्ष निकाल सकते हैं कि सेवा क्लाउड सेवा प्रदाता सीएसपी (service cloud service provider CSP )अगर हम कहते हैं कि एसएलए (SLA) ठीक है।
 तो, यह एक बहुत ही सरल अंकगणितीय अधिकार है, लेकिन हम क्या देखते हैं कि अगर हम इस तरह की चीजों को माप सकते हैं, उपलब्धता के संबंध में।
 हम मूल रूप से इस एसएलए (SLA) उल्लंघन की गणना कर सकते हैं।
 यदि एसएलए (SLA) का एक सेट है जिसे प्रत्येक घटक (component) के लिए हर चीज में देखा जाना चाहिए, तो हम इस तरह की सरल गणना कर सकते हैं और कुछ मामलों में यह थोड़ा जटिल भी हो सकता है, जब आप कुछ पता लगाने के लिए कुछ सांख्यिकीय विश्लेषण (statistical analysis ) करना चाहते हैं।
 और फिर आप कह सकते हैं कि यहाँ एसएलए (SLA) का उल्लंघन है या एसएलए (SLA) को सम्मानित किया गया है या नहीं।
 इसलिए, इस तरह हम इसकी गणना कर सकते हैं, कि क्या यह एसएलए (SLA) संतुष्ट है या नहीं।
 तो, यह बहुत सीधी चिज मालुम पड़ती है, लेकिन हकीकत में यह इतनी सीधी चिज नहीं है।
 मैं अलग-अलग समय पर अलग-अलग प्रकार की उपलब्धता कैसे प्राप्त कर सकता हूं, क्योंकि इस मामले के लिए मैं कह सकता हूं कि अगर मैं एक वाणिज्यिक माना जाता हूं तो उदाहरण के लिए एक बैंकिंग संगठन ले सकते हैं।
 तो, एसएलए (SLA) के बारे में, मैं कह सकता हूं कि मेरे चरम घंटों (peak hours ) के दौरान जो 9 से 1700 घंटे है , मुझे 99.9 प्रतिशत की उपलब्धता की आवश्यकता है।
 जबकि, 700 से ज्यादा घंटों में मै उन्हें अलग-अलग पैमाने पर विभाजित कर सकता हूं।
 मैं कह सकता हूं कि इस घंटों में 700 से 1700 तक मेरे पास 99 प्रतिशत हो सकते हैं, जबकि 1 9 00 से अगले दिन 0800 घंटों तक मैं अभी भी 9 7 कह सकता हूं प्रतिशत, और 0800 से 0900 घंटे मैं कह सकता हूं कि यह फिर से 99 प्रतिशत है।
 अब मैं यह कह सकता हूँ की उपलब्धता आवश्यकताओं भी भिन्नता के साथ बदलती है, समय के आधार पर।
 इसलिए, हमारी आवश्यकता के आधार पर चीजें हमारे जैसे संस्थान की तरह होंगी, मैं कह सकता हूं कि अगर मेरी प्रयोगशालाएं 2 से 5 के बीच चल रही हैं या सुबह 2 से 6 और सुबह 8 से 12 तक हैं।
 तो, उन प्रयोगशाला घंटे के दौरान मुझे उपलब्धता का एक उच्च प्रतिशत की आवश्यकता होती है।
 हालांकि, चोटी के घंटों (peak hours ) या शाम के घंटों के दौरान मुझे बहुत पुन: उपयोग की आवश्यकता हो सकती है।
 क्योंकि, आप जितनी अधिक सेवाओं के लिए भुगतान करते हैं, उतना ही आप इसके लिए भुगतान करते हैं।
 इसलिए, इसकी आवश्यकता है।
 यह देखने के लिए और अधिक जटिल गणना भी हो सकती है।
 तो, इसी प्रकार हम एक और समस्या को देख सकते हैं, जो कि पिछले के दूसरे हिस्से का थोड़ा सा विस्तार है।
 इसलिए, हम एक परिदृश्य पर विचार करते हैं जहां एक कंपनी एक्स (company x), जहा company x प्रदाता पी से क्लाउड सेवा (cloud services) का उपयोग करना चाहते हैं।
 तो, एक कंपनी एक्स है जो एक प्रदाता पी का उपयोग करना चाहता है जैसे कि आईआईटी खड़गपुर (IIT Kharagpur) को बाहरी एक या किसी भी चीज़ से एक बार और क्लाउड सेवा (cloud services) को सही करना है।
 सेवा स्तर समझौता व्यापार शुरू करने के लिए 2 पार्टियों के बीच वार्ता की गारंटी देता है।
 इसलिए, इससे पहले सेवा स्तर की गारंटी इस तरह की होती है जैसे सेवा की अवधि में उपलब्धता गारंटी 99.5 9 5 प्रतिशत है।
 तो, सेवा अवधि यह 99.9 5 प्रतिशत समय होना चाहिए।
 उपलब्धता अवधि 30 दिन अधिकतम सेवा घंटे प्रति दिन 12 घंटे है और लागत प्रति दिन 50 डॉलर है।
 इसलिए, यह एक प्रकार का समझौता या आवश्यकता का प्रकार है और औपचारिक आवश्यकता जो सेवा प्रदाता और सेवा प्रदाता के भीतर सहमत हो गई है।
 इसलिए, यदि यह सही नहीं होती है तो क्रेडिट के साथ सेवा प्रदान की जाती है।
 तो, एक और हिस्सा है जैसे कि यदि प्रदाता गारंटीकृत स्तर पर सेवा प्रदान करने में विफल रहता है, जिसके लिए यह सहमति हुई है और उपभोक्ता चार्ज कर रहा है, तो इस प्रकार दंड का भुगतान करना होगा।
 इसलिए, जुर्माना (penalty) जो लगेगा वह जुर्माना धन (money detents) के हिसाब से हो सकता है।
 या जुर्माना कुछ अतिरिक्त गणना घंटे देने या डेटा या किसी भी तरह के मामले में हो सकता है, इस मामले में उपलब्धता मासिक कनेक्टिविटी अप टाइम सेवा स्तर को मासिक अप की तरह दे सकती है समय प्रतिशत 99.9 5 प्रतिशत से कम है, लेकिन 99 प्रतिशत से अधिक 99 प्रतिशत से अधिक है तो सेवा सवारी 10 प्रतिशत हो सकती है।
 जबकि, यह 99 प्रतिशत से कम है तो सेवा क्रेडिट 25 प्रतिशत सही होना चाहिए।
 हालांकि, हकीकत में यह पाया गया है कि सेवा अवधि के दौरान क्लाउड सर्वर 5 आउटेज का समर्थन करता है।
 इन निम्नलिखित अवधि के दौरान, एक 5 घंटे 30 मिनट है, एक 1 घंटे 30 मिनट है, एक 15 मिनट और 2 घंटे 25 मिनट प्रत्येक दिन अलग-अलग होता है।
 इसलिए, यह सामान्य सेवा की गारंटी देता है, जहां सही उल्लंघन किया गया है और अगर तब तक एसएलए (SLA) वार्ता का सम्मान नहीं किया जाता है, तो हमें इस क्लाउड सेवाओं को खरीदने के लिए देय प्रभावी लागत की गणना करने की आवश्यकता है।
 तो, यह है कि हमें यह जांचने की ज़रूरत है कि उपभोक्ता द्वारा इस क्लाउड सेवाओं (cloud services) के लिए सही तरीके से भुगतान करने की आवश्यकता है।
 तो, हम यह जानना चाहते थे।
 तो, फिर बस जल्दी से दोहराने के लिए।
 इसलिए, कुछ गारंटीएं हैं 99.9 5 प्रतिशत सेवा अवधि 30 दिन, अधिकतम चीजें 12 घंटे 50 डॉलर, और 99.9 5 प्रतिशत से कम सेवाएं प्रदान नहीं करने के लिए कुछ दंड हैं, लेकिन 99 प्रतिशत के बराबर से अधिक 10 प्रतिशत और 99 प्रतिशत से कम 25 प्रतिशत है।
 और 5 आउटेज 5 घंटे 30 मिनट, 1 घंटा 30 मिनट, 15 मिनट और 2 घंटे 25 मिनट हैं।
 मेरा मतलब है कि क्लाउड सेवाओं को खरीदने के लिए देय प्रभावी लागत।
 इसलिए, हमें फिर से एक मुश्किल समस्या पर काम नहीं करना है, लेकिन यह हमें एक विचार देता है कि चीजें कैसे काम करती हैं।
 तो, सेवा अवधि की अवधि (service period duration )30 दिन के लिए 12 घंटे है।
 तो, कुल मिलाकर, हमारे पास कुल घंटों हैं, या 360 घंटों की लागत है जो हमने प्रति दिन 50 अमेरिकी डॉलर देखा है।
 इसलिए, कुल लागत इसलिए सेवा बातचीत के समय यह है कि डॉलर 50 क्रॉस (cross) 30 या यह जुर्माना है।
 इसलिए, ये तथ्य हैं कि हमने प्रति दिन 30 दिन की सेवा अवधि दी है, हम 12 घंटे का उपयोग कर रहे हैं, कुल सेवा समय की उम्मीद है कि यह 50 डॉलर प्रति दिन सेवा बातचीत के समय कुल लागत है, 15 से 30, 50, 1500 डॉलर।
 अब, कुल सेवा समय के नीचे 5 घंटे और 30 मिनट प्लस, 1 घंटा 30 मिनट और 15 मिनट, साथ ही 2 घंटे 25 मिनट सही है।
 इसलिए, यदि आप जोड़ते हैं, तो यह 9 घंटे 25 मिनट है।
 तो, यह चीजों के लिए कुल आबादी का समय या कुल डाउन टाइम है।
 इसलिए, हम 1 मिनट के बराबर सेवा उपलब्धता कह सकते हैं।
 हमने पहले भी देखा है और यह मानक बात 1 शून्य डाउनटाइम अपटाइम (1 minus downtime by uptime )के बराबर है जो हम कह सकते हैं की 1 मिनट 9 घंटे 25 मिनट 360 घंटे 100 इतनी प्रतिशत है।
 तो, यह हमारा कुल अनुमानित समय था और यह आउटेज या डाउनटाइम (outage or the downtime) है, इसलिए 1 मिनट से कम समय तक और उसे नीचे और इसलिए, हमारे पास 97.385 प्रतिशत है और यह ठीक है।
 हम सेवा उपलब्धता की गणना 97.385 प्रतिशत के रूप में करते हैं जो डेटा उपलब्ध डेटा के मुताबिक है।
 तो, हम मासिक अप टाइम प्रतिशत देखते हैं 97.385 जिसकी हमने गणना की है और जो 99 प्रतिशत से कम है।
 न केवल 99.5 प्रतिशत, बल्कि 99 प्रतिशत की तरह।
 इसलिए, सेवा क्रेडिट उपलब्ध है, जिसके कारण हम जो भी सेवा बातचीत (service negotiation ) या एसएलए (SLA) के दौरान कुल लागत का 25 प्रतिशत है।
 तो, यह कुल लागत है क्योंकि हमने 1500 की गणना की है।
 तो, यह डॉलर 375 है अथवा डॉलर 1500 के बराबर सेवा खरीदने के लिए देय प्रभावी लागत देय है, डॉलर के मुकाबले 375 डॉलर, डॉलर 1125 के बराबर है।
 तो, यह प्रभावी लागत (effective cost) है।
 तो, हम आउटेज के आधार पर क्या देखते हैं, कि यदि आप समस्या 2 को देखते हैं तो यह पहली समस्या का अर्थ का थोड़ा विस्तार है।
 लेकिन यह वास्तव में चीजें सही होती है।
 इसलिए, हमें इन चीजों की गणना या लाग (log ) करने की जरुरत है, इसी प्रकार से।
 यह अप समय (up time) के संबंध में है और इसका मतलब यह हो सकता है कि यह सायद टोटल डाउन (total down ) नहीं हो सकता है, लेकिन उपलब्धता बैंड की चौड़ाई (availability band width ) हो सकती है, नेटवर्क में उपलब्धता धीमी हो सकती है और इन प्रकार की चीजे हो सकती है।
 यह कुछ अन्य पहलुओं पर निर्भर करता है, जो हमेशा सीधे-साधा नहीं होते हैं, लेकिन ऐसा करने में बहुत सारे जटिल विचार हैं।
 तो हमने इस 2 समस्या में क्या प्रयास किया।
 तो, हमने दिखाया है कि कैसे एक एसएलए (SLA) गारंटी की गणना की जा सकती है,या किसी प्रकार के तरीके में देखा जा सकता है कि इसकी गणना कैसे की जा सकती है और यह देखा जा सकता है कि एसएलए (SLA) का उल्लंघन हो रहा है या नहीं है।
 इसलिए, मुझे विश्वास है कि यह आपको व्यापक माध्यम बोर्ड विचार (broad means, board idea )या चीजों की एक विस्तृत माध्यम देगा।
 तो अब क्या देखेंगे कि अलग-अलग आधार प्रथाएं क्या हैं या अलग-अलग घटक (components) क्या हैं जो हमने गणना की है, उप समय (up time)के अंतर्गतहै।
 तो, एक सेल (cell) के विभिन्न घटक क्या हैं जिन्हें प्राथमिक रूप से वाणिज्यिक क्लाउड (commercial cloud) द्वारा माना जाता है? तो, बस कुछ और चीजें देखते हैं।
 तो, क्लाउड सेवा प्रदाता (cloud services) )के लिए एसएलए (SLA) पहले से ही हमने देखा है।
 ऐसे में कुछ पहलुओं जिन्हें हम वाणिज्यिक क्लाउड (commercial cloud) के मामले में हाइलाइट करना चाहते हैं, जो मासिक अवधि के लिए लागू होने वाली चीजें हैं, जिसका मतलब कैलेंडर माह के लिए है और जिसमें सेवा क्रेडिट ओड (odd) है, जब आप एक सेवा के ग्राहक हैं।
 इसलिए, यह लागू सेवा अवधि समान रूप से लागू है अथवा लागू मासिक सेवा शुल्क सही है।
 तो, डाउनटाइम (downtime) की अवधारणा जैसे हमने सेवा विशिष्ट शर्तों में सेवाओं को देखा है।
 त्रुटि कोड (Error code) का अर्थ है कि ऑपरेशन विफल रहा है, जैसे कि http स्थिति कोड 5xx या कुछ ऐसा ही।
 इसलिए, सेवाओं में एक त्रुटि कोड होना चाहिए अन्यथा आपको पिनपॉइंट (pinpoint)करने में प्रयास करना मुश्किल होगा, हम इस प्रकार की चीज़ों में विफल रहे हैं।
 बाहरी कनेक्टिविटी एक बिडरेक्शनल नेटवर्क यातायात(bidirectional network traffic) समर्थन है, जैसे http या https के लिए प्रोटोकॉल को सार्वजनिक आईपी (public IP )प्राप्त किया जा सकता है और इसी तरह, आगे और आगे, जहां वे बाहरी कनेक्टिविटी घटना का मतलब है किसी भी एकल या घटना का एक सेट जिसके परिणामस्वरूप डाउन टाइम (downtime) होता है।
 प्रबंधन पोर्टल (Management portal) का अर्थ है कि इसके द्वारा प्रदान किया गया तरंग इंटरफ़ेस मूल रूप से माइक्रोसॉफ्ट एज़ूर (Microsoft azure )के लिए है।
 इसलिए, जिसके माध्यम से उपभोक्ता उस प्रबंधन पोर्टल (Management portal) जैसी सेवाओं का प्रबंधन कर सकता है।
 सेवा क्रेडिट अगर कोई विफलता है, कि इस समस्या में हमने कितना क्रेडिट दिया होगा।
 सेवा स्तर का अर्थ है, एसएलए (SLA) में बताई गई प्रदर्शन गलतियों का कहना है, और खुद के अजीब होने के कारण, यह सेवा सेवा संसाधन की डिलीवरी को पूरा करने के लिए सहमत है।
 सफलता कोड जैसे हमने विफलता कोड देखा है, हमारे पास http में एक सफलता कोड है, हम जानते हैं कि 2xx सफलता कोड है।
 समर्थन विंडो (Support windows) उस अवधि की अवधि (period of time ) का संदर्भ देती है, जिसके दौरान अलग-अलग उत्पाद सेवाओं के साथ संगतता (compatibility) पर सेवा सुविधाएं समर्थित होती हैं।
 तो, एक समर्थन खिड़की (Support windows) है, जहां कुछ चीजें होंगीं।
 इसके साथ-साथ कुछ अतिरिक्त परिभाषाएं हैं, जैसे उपलब्धता सेट अलग-अलग गिरावट डोमेन पर तैनात 2 या अधिक वर्चुअल मशीन को संदर्भित करता है (virtual machine deployed across different fall domains)।
 इसलिए, यह विफलता के एक बिंदु (single point) से बचने के लिए एक ही समय में डाउन टाइम के लिए नहीं जाएगा।
 वेब और वेब भूमिका और कार्यकर्ता भूमिका (web and web role and worker role ) के लिए उपयोग किए गए गणना संसाधनों के लिए क्लाउड सेवा (cloud services) संदर्भकर्ता है।
 फॉल्ट डोमेन (Fault domain) उन सर्वरों का संग्रह है, जो सामान्य संसाधन साझा करते हैं अथवा जो शक्ति और नेटवर्क कनेक्टिविटी हैं।
 किरायेदार, एक या अधिक भूमिकाओं का प्रतिनिधित्व करता है, जो एक या अधिक भूमिका उदाहरणों में से एक है और जो इसे एक ही पैकेज में तैनात किया गया है, जिसे हमने देखा है कि यह एक कार्यकर्ता भूमिका (worker role) हो सकता है, या फिर यह एक वेब भूमिका (web role) प्रकार की बात हो सकती है।
 अपडेट डोमेन (Update domain), इस मामले में एक सेट को संदर्भित करता है, माइक्रोसॉफ्ट एज़ूर (Microsoft azure) उदाहरणों में जो मंच अद्यतन समवर्ती रूप से लागू होते हैं (platform update are concurrently applied) अथवा आभासी मशीन (virtual machine ) जिसे हम जानते हैं।
 वीनेट (VNet), यह एक आभासी निजी नेटवर्क है और यह भी ज्ञात है कि वेब भूमिका और कार्यकर्ता भूमिका है।
 इसलिए, ये कुछ अतिरिक्त परिभाषाएं हैं जिनका उपयोग एसएलए (SLA) गणनाओं के लिए सेवा स्तर के लिए किया जाता है।
 तो, जैसा कि हमने यहां देखा है, यहां हमारे उदाहरण में यदि आप क्लाउड सेवाओं (cloud services) के लिए मासिक अप टाइम गणना और सेवा स्तर देख सकते हैं, तो उन परिभाषाओं का उपयोग करके मासिक उपलब्ध मिनटों के दौरान कुल एकत्रित मिनट सभी इंटरफेसिंग (interfacing) भूमिकाओं के लिए एक बिलिंग अवधि और अलग-अलग अद्यतन डोमेन में तैनात 2 या अधिक उदाहरण समान रूप से डाउन टाइम, यह है कि अधिकतम उपलब्ध मिनटों के मुकाबले अधिकतम उपलब्ध मिनट न्यूनतम समय है।
 हमने यहां सही गणना की है।
 तो, यह बात है और सेवा स्क्रिप्ट क्रेडिट नियम (service script credit rules)हो सकते हैं, जैसा कि हमने देखा है, 99.9 5 प्रतिशत इन्ही प्रकार के वाल्वस (valves) में हमने उपयोग किया है।
 इसी तरह, यह गणना और सेवा क्लाउड सेवाओं (cloud services)को विकसित करने के लिए है।
 इसी तरह हम वीएमएस (VMS) के लिए कर सकते हैं।
 इसलिए, वीएमएस (VMS) जैसे मैं बुनियादी ढांचा (infrastructure service) सेवा चाहता हूं और वर्चुअल मशीनों (virtual machines) को समान रूप से आवंटित किया जाता है।
 इसलिए, अधिकतम उपलब्ध मिनट कुल जमा समय बिलिंग अवधि है।
 डाउन टाइम (down time) की इसी तरह हम गणना कर सकते हैं।
 और हमारे पास कई अलग-अलग प्रकार के सेवा क्रेडिट हो सकते हैं।
 तो, यह कहने का मतलब है कि यह एक अलग प्रकार का स्तर हो सकता है, जो यह एक आईएएसएस (IaaS) स्तर पर हो सकता है, यह किसी भी सास (SaaS) लेबल का पासा (PaaS) स्तर हो सकता है।
 यदि स्टोरेज डाउनटाइम या एक्सेस क्षमता समस्या इतनी आगे है, तो मेरे पास भंडारण स्तर (access ability problem )के रूप में हो सकता है।
 इसलिए, इसे स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता है की जब हम इस तरह की चीज करना चाहते हैं तो सही तरीके से पालन करने के लिए हमें आवश्यक पता होना चाहिये की सर्वोत्तम प्रथाओं या नियम क्या हैं।
 तो, इस तरह हम अनुसरण करने वाले कुछ सर्वोत्तम प्रथाओं को देखते हैं।
 तो, क्लाउड मानक कस्टम काउंसिल (cloud standard custom council right), क्लाउड (cloud) उपभोक्ता को 7 चरणों के साथ प्रदान करता है, जब उन्हें एसएलए (SLA) की मूल्यांकन करते समय उन्हें लेना चाहिए, जैसे कि 20 अप्रैल, 12 को उनके दस्तावेज़ में भी प्रदान किया जाता है।
 तो, क्लाउड (cloud) अभिनेताओं (actors)की पहचान करें।
 एनआईएसटी वास्तुकला (NIST architecture) के अनुसार अभिनेता कौन हैं? इसलिए, ये अभिनेता, उपभोक्ता, निर्माता या प्रदाता, वाहक, दलाल और लेखा परीक्षक हैं।
 तो, यह 5 अभिनेता हैं, एनआईएसटी के अनुसार।
 इसलिए, हमें व्यापार स्तर की नीतियों का सही मूल्यांकन करने की आवश्यकता है।
 यह महत्वपूर्ण है कि डेटा (डेटा) पॉलिसी एसएलए (SLA) कम से कम सेवाओं की गारंटी होगी, इस अतिरिक्त उपयोग के तहत कवर नहीं किया गया है, भुगतान जुर्माना उप अनुबंध सेवाएं, लाइसेंस सॉफ्टवेयर, उद्योग विशिष्ट मानकों (payment penalty sub contract services, license software, industry specific standards ) और ये चीजों के विभिन्न पहलू हैं।
 तो, जब हम सरल एसएलए (SLA) के बारे में चर्चा कर रहे हैं तो वास्तव में चीजें अधिक जटिल हैं, जैसे डेटा नीति क्या होनी चाहिए, जो कवर किए गए हैं, यदि सेवाओं का उप-अनुबंध है तो क्या नीतियां होनी चाहिए, चाहे आप लाइसेंस सॉफ़्टवेयर लाइसेंसिंग तंत्र (license software licensing mechanisms )का उपयोग कर रहे हैं।
 चूंकि ज्यादातर मामलों में, हम इनका उपयोग करने का प्रयास करते हैं, हम अलग-अलग लाइसेंस सॉफ़्टवेयर का उपयोग कर रहे हैं, और वे लाइसेंसिंग लागत इत्यादि न केवल उस लाइसेंसिंग अवधि में खेलते (play) हैं, और कुछ अन्य चीजें भी खेलती(play) हैं।
 फिर हमें यह समझने की जरूरत है, कि हम कौन सा स्तर संचालन देख रहे हैं, सास पास या आईएएसएस (SaaS PaaS or IaaS), क्योंकि विभिन्न प्रकार की चीजें विभिन्न प्रकार की सेवाओं के विभिन्न प्रकार की आवश्यकता होती हैं।
 कुछ मामलों में सास (SaaS)को नियंत्रित करने या मापने के लिए बहुत आसान है, लेकिन हमें यह देखने की ज़रूरत है कि हम किस प्रकार की सेवाओं पर लाभ उठा रहे हैं, भले ही हमारे पास इस तरह की सेवाएं हों।
 इसलिए, हमें यह समझने की जरूरत है कि सास, पास, आईएएसएस (SaaS PaaS or IaaS)किस बारे में हैं और यहाँ किस प्रकार का क्लाउड (cloud) चल रहा है, चाहे वह सार्वजनिक निजी या हाइब्रिड (public private or hybrid) हो।
 एसएलए (SLA) में नियम और शर्त नियंत्रण चर की जटिलता पर निर्भर करती है, जो प्रदान करता है कि प्रदाता उपभोक्ता या सेवा उपभोक्ताओं को देता है।
 तो अब उपभोक्ता को उपलब्धता इत्यादि की गणना करने की आवश्यकता है।
 इसलिए, नियंत्रित नियंत्रण चर (controlled control variables ) प्रदान किए जाते हैं, जैसे कि मैं कहता हूं कि यह मुझे सीपीयू अप टाइम (CPU up time ) इत्यादि देता है या अलग-अलग उपयोग समय या हार्ड देता है जो डिस्क पैरामीटर (disc parameters) का उपयोग करता है।
 तो, ये प्रदान किए गए विभिन्न नियंत्रण पैरामीटर हैं।
 अब, इस पैरामीटर की अधिक जटिलता इस बात पर निर्भर करती है, कि आप किस स्तर के संचालन कर रहे हैं और जहां आप चीजें चला रहे हैं, जैसे आईएएएस, स्पेस या सास (IaaS, space or SaaS) या यह हाइब्रिड या आपका सार्वजनिक या निजी है।
 इसलिए, अन्य चीजें एक है, कि मेट्रिक जो हम चर्चा कर रहे हैं, यह पहचानने के लिए कि प्रदर्शन उद्देश्यों को सही तरीके से प्राप्त करने के लिए मीट्रिक का उपयोग किस प्रकार किया जाना चाहिए।
 उपलब्धता प्रतिक्रिया मीट्रिक पर कुछ उदाहरण उपलब्धता एसएलए में उपलब्धता और अन्य प्रकार की चीजों जैसे मीट्रिक (metric ) नाम की तरह हैं और कुछ अन्य बाधाएं भी हो सकती हैं कि इन आंकड़ों के संग्रह की आवृत्ति भी महत्वपूर्ण है या नहीं।
 अगला पहलू सुरक्षा है, जैसे क्लाउड (cloud) के लिए महत्वपूर्ण सुरक्षा पैरामीटर पर विचार करें, जिसमें संपत्ति संवेदनशीलता शामिल है, कानूनी विनियामक आवश्यकताओं (including asset sensitivity, legal regulatory requirements ) हैं, जैसे कि मैं कह सकता हूं कि वह डेटा इन विशेष भौगोलिक सीमाओं (geographically boundary) के भीतर या इस प्रकार की चीजों के भीतर रहेंगे।
 क्लाउड प्रदाता सुरक्षा क्षमताओं क्लाउड प्रदाता (Cloud provider security capabilities ) की क्षमता प्रदान करने की क्षमता क्या है।
 सेवा प्रबंधन आवश्यकता की पहचान करने के लिए हमारे पास सेवा प्रबंधन की आवश्यकता है।
 तो, उदाहरण के लिए निगरानी और रिपोर्ट की जानी चाहिए, प्रदर्शन (performance application ) लोड करें या सही ढंग से क्या किया जाना चाहिए।
 आपको बिल मीटर होने की क्या ज़रूरत है।
 गति, परीक्षण, मांग लचीलापन (speed, testing, demand flexibility )और संसाधन कैसे बदला जाता है, इस तरह कितनी तेजी से प्रावधान होना चाहिए।
 तो, प्रावधान कैसे है, मॉनिटर करने और रिपोर्ट करने की आवश्यकता और मीटर के प्रकार की चीज़ों को देखने की आवश्यकता है।
 और फिर विफलता के लिए तैयार और प्रबंधन करें यह एक और महत्वपूर्ण निकास है।
 निर्धारित किया गया है कि किस तरह के उपाय प्रदान किए जाने चाहिए उदाहरण के लिए, सेवा क्रेडिट और देयता सीमा क्या हैं।
 तो, प्रदाता बिंदु पर विचार करने के लिए कितना सेवा क्रेडिट प्रदान करता है और प्रदाता पर मेरी देनदारियां क्या हैं, और इसके लिए उपभोक्ता किस पर हस्ताक्षर कर रहा है।
 आवश्यकता होने पर आपदा रिकवरी योजना (disaster recovery plan )कैसे काम करेगी और निकास खंड प्रत्येक क्लाउड एसएलए अधिकार का हिस्सा होना चाहिए (exit clause should be a part of every cloud SLA )।
 या तो उपभोक्ता या प्रदाता के रिश्ते को समाप्त करना चाहता है।
 तो, एसएलए (SLA), क्या है यह एक समझौता है।
 तो, एक्जिट क्लॉज का क्या कारण होना चाहिए, उपभोक्ता को बाहर निकलने के लिए किसी समय पर या प्रदाताओं का कहना है, कि मैं उस चीज़ को प्रदान करने में सक्षम नहीं हूं।
 तो, यह बात में होना चाहिए।
 तो, हम क्या कहते हैं कि यह कुछ आवश्यक सर्वोत्तम प्रथाओं में से कुछ यह हैं, या एसएलए (SLA) इत्यादि को तैयार करते समय हमें कुछ सर्वोत्तम प्रथाओं को ध्यान में रखना चाहिए।
 क्लाउड एक्टर्स (cloud actors) की पहचान करना, व्यवसाय स्तर की नीतियों का मूल्यांकन करना, इस प्रकार की सेवाओं को समझना, अलग-अलग मैट्रिक्स की सुरक्षा क्षमता क्या है और उपभोक्ता की सुरक्षा आवश्यकता, और प्रदाता की क्षमता की आवश्यकता है।
 सेवा प्रबंधन आवश्यकताओं, और विफलता का प्रबंधन कैसे करें या विफलता के लिए उपाय क्या होना चाहिए।
 इसलिए, हमने यह कोशिश की है की जैसे हम एसएलए (SLA) का विस्तार भेजते हैं, हमने पहले भी चर्चा की है।
 तो, हम यह देने का प्रयास करते हैं, कि चीजों के लिए अलग-अलग पहलू हैं और इस बात को करने का प्रयास करें जिसे हमने सरल एसएलए (SLA) से संबंधित समस्या को भी देखा है की यह कैसे हो सकता है और इस प्रकार की एसएलए (SLA) की गणना कैसे की जाती है, हालांकि समस्याएं बहुत सरल होती हैं, लेकिन यह हमें एक विचार देता है, कि आप इस तरह की चीजों के दृष्टिकोण को कैसे अवगत करा सकते हैं।
 तो, हम इस एसएलए (SLA) ट्यूटोरियल का यहां निष्कर्ष निकाल कर अंत करते हैं।
 धन्यवाद।