SLA ले तपाईंलाई बचाउनेछ भनेर सोच्न बन्द गर्नुहोस्। यो आश्वस्त गर्न र सुरक्षाको गलत भावना सिर्जना गर्न आवश्यक छ।

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

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

होस्टरहरूले प्रायः SLA को सार्वजनिक संस्करणमा के लेख्छन् जुन उनीहरूले जनतालाई देखाउँछन्? ठीक छ, पहिलो रेखा होस्टरको "विश्वसनीयता" शब्द हो - यी सामान्यतया 98 देखि 99,999% सम्मका संख्याहरू हुन्। वास्तवमा, यी संख्याहरू मार्केटरहरूको सुन्दर आविष्कार मात्र हुन्। एक पटक, जब होस्टिंग जवान र महँगो थियो, र क्लाउडहरू विशेषज्ञहरूका लागि मात्र सपना थिए (साथै सबैका लागि ब्रॉडब्यान्ड पहुँच), होस्टिङ अपटाइम सूचक अत्यन्त, अत्यन्त महत्त्वपूर्ण थियो। अब, जब सबै आपूर्तिकर्ताहरूले एउटै उपकरणहरू प्रयोग गर्छन्, प्लस वा माइनस, एउटै ब्याकबोन नेटवर्कहरूमा बस्छन् र उही सेवा प्याकेजहरू प्रस्ताव गर्छन्, अपटाइम सूचक बिल्कुल अतुलनीय छ।

के त्यहाँ "सही" SLA पनि छ?

निस्सन्देह, त्यहाँ SLA को आदर्श संस्करणहरू छन्, तर ती सबै गैर-मानक कागजातहरू हुन् र दर्ता गरिएका छन् र ग्राहक र आपूर्तिकर्ता बीच म्यानुअल रूपमा निष्कर्षमा छन्। यसबाहेक, यस प्रकारको SLA प्रायः सेवाहरूको सट्टा कुनै प्रकारको सम्झौता कार्यको चिन्ता गर्दछ।

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

त्यो हो, "सही SLA" = "सेवाहरूको प्रावधानको लागि पर्याप्त सम्झौता" र स्थितिमा नियन्त्रण दिन्छ। तर यो तब मात्र सम्भव छ जब "समान बराबर" काम गर्दछ।

वेबसाइटमा के लेखिएको छ र वास्तविकतामा के पर्खिरहेको छ दुई फरक कुरा हुन्

सामान्यतया, हामीले थप छलफल गर्ने सबै कुरा सामान्य मार्केटिङ चालहरू र सावधानीको परीक्षण हो।

यदि हामीले लोकप्रिय घरेलु होस्टहरू लियौं भने, एउटा प्रस्ताव अर्को भन्दा राम्रो छ: 25/8 समर्थन, सर्भर अपटाइम 99,9999999% समय, कम्तिमा रूसमा तिनीहरूको आफ्नै डाटा केन्द्रहरूको गुच्छा। कृपया डाटा केन्द्रहरूको बारेमा बिन्दु सम्झनुहोस्, हामी केहि पछि फिर्ता आउनेछौं। यस बीचमा, आउनुहोस् आदर्श त्रुटि सहिष्णुता तथ्याङ्कको बारेमा कुरा गरौं र उसको सर्भर अझै पनि "0,0000001% असफलता" मा पर्दा एक व्यक्तिले के सामना गर्छ।

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

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

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

जे होस्, यो बुझ्नु महत्त्वपूर्ण छ कि तपाईंले ईन्जिनियरिङ् टोलीमा कहिल्यै पहुँच प्राप्त गर्नुहुन्न, प्रायः तपाईंलाई समर्थनको पहिलो लाइनद्वारा रोकिन्छ, जो तपाईंसँग पत्राचार गर्छन् जबकि वास्तविक ईन्जिनियरहरूले स्थिति ठीक गर्ने प्रयास गर्छन्। परिचित सुनिन्छ?

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

एकै समयमा, ठूला ग्राहकहरू, वास्तवमा, SLA भित्र क्षतिपूर्तिको बारेमा वास्ता गर्दैनन्। "SLA क्षतिपूर्ति" भनेको उपकरण डाउनटाइमको अनुपातमा ट्यारिफ भित्रको पैसा फिर्ता हो, जसले सम्भावित मौद्रिक र प्रतिष्ठाको क्षतिको १% पनि कभर गर्दैन। यस अवस्थामा, ग्राहकको लागि यो धेरै महत्त्वपूर्ण छ कि समस्याहरू कुनै प्रकारको "शुल्क पुन: गणना" भन्दा सकेसम्म चाँडो समाधान गरिन्छ।

"विश्वभरका धेरै डाटा केन्द्रहरू" चिन्ताको कारण हो

हामीले सेवा प्रदायकमा ठूलो संख्यामा डाटा सेन्टरहरू भएको अवस्थालाई छुट्टै कोटीमा राखेका छौं, किनभने माथि वर्णन गरिएका स्पष्ट सञ्चार समस्याहरूका अतिरिक्त, गैर-स्पष्ट समस्याहरू पनि उत्पन्न हुन्छन्। उदाहरणका लागि, तपाईंको सेवा प्रदायकसँग "उनीहरूको" डेटा केन्द्रहरूमा पहुँच छैन।

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

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

तसर्थ, यदि तपाईंले सम्झौता र SLA मा भएका सुन्दर शब्दहरूलाई विश्वसनीयता र सेवाको बारेमा मात्र होइन, तर सेवा प्रदायकको समस्याहरू द्रुत रूपमा समाधान गर्ने क्षमतालाई पनि महत्त्व दिनुहुन्छ भने, तपाईंले सीधै सुविधाहरूको मालिकसँग काम गर्नुपर्छ। वास्तवमा, यसले डाटा सेन्टरसँग प्रत्यक्ष अन्तरक्रिया समावेश गर्दछ।

हामी किन विकल्पहरू विचार गर्दैनौं जब धेरै DCs वास्तवमा एक कम्पनीको हुन सक्छ? खैर, त्यहाँ धेरै, धेरै कम त्यस्ता कम्पनीहरू छन्। एक, दुई, तीन साना डाटा केन्द्र वा एक ठूलो एक सम्भव छ। तर एक दर्जन DC, जसमध्ये आधा रूसी संघमा छन्, र दोस्रो युरोपमा, लगभग असम्भव छ। यसको मतलब तपाईले कल्पना गर्नु भन्दा धेरै धेरै रिसेलर कम्पनीहरू छन्। यहाँ एउटा सरल उदाहरण हो:

गुगल क्लाउड सेवा डेटा केन्द्रहरूको संख्या अनुमान गर्नुहोस्। युरोपमा तीमध्ये ६ मात्रै छन्। लन्डन, एम्स्टर्डम, ब्रसेल्स, हेलसिंकी, फ्रान्कफर्ट र जुरिचमा। त्यो हो, सबै मुख्य राजमार्ग बिन्दुहरूमा। किनभने डाटा सेन्टर महँगो, जटिल र धेरै ठूलो परियोजना हो। अब "रूस र युरोपभरि एक दर्जन डेटा केन्द्रहरू" भएको मस्कोको कतैबाट होस्टिंग कम्पनीहरूलाई सम्झनुहोस्।

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

यदि तपाईलाई आपूर्तिकर्ताको संगठनात्मक संरचना र क्षमताहरूको बुझाइ छैन भने यसले हामीलाई एक पटक फेरि सम्झाउँछ कि SLA बेकार छ।

के अन्तमा

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

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

सबै भन्दा पहिले, यो सेवा विक्रेता सुविधा/डेटा केन्द्र को प्रत्यक्ष मालिक हो कि भनेर निर्धारण गर्न आवश्यक छ। सेतो लेबल मोडेल प्रयोग गर्ने धेरै पुनर्विक्रेताहरूले आफ्नो स्थिति लुकाउन सक्दो प्रयास गर्छन्, र यस अवस्थामा तपाईंले केही अप्रत्यक्ष संकेतहरू खोज्न आवश्यक छ। उदाहरणका लागि, यदि "तिनीहरूको युरोपेली DCs" का केही विशिष्ट नाम र लोगोहरू छन् जुन आपूर्तिकर्ता कम्पनीको नामबाट भिन्न छन्। वा यदि शब्द "साझेदारहरू" कतै देखा पर्दछ। साझेदारहरू = सेतो लेबल ९५% केसहरूमा।

अर्को, तपाई आफैंलाई कम्पनीको संरचनासँग परिचित हुन आवश्यक छ, वा अझ राम्रो, व्यक्तिगत रूपमा उपकरणहरू हेर्नुहोस्। डाटा सेन्टरहरू मध्ये, भ्रमणको अभ्यास वा कम्तिमा आफ्नो वेबसाइट वा ब्लगमा भ्रमण लेखहरू नयाँ होइन (हामीले यस्तो लेख्यौं। पटक и два), जहाँ तिनीहरू फोटो र विस्तृत विवरणहरूको साथ आफ्नो डेटा केन्द्रको बारेमा कुरा गर्छन्।

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

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

किनभने एक सामान्य SLA ले तपाईंलाई मद्दत गर्दैन। तर सुविधाहरूको मालिकसँग काम गर्दै, र पुनर्विक्रेता होइन, सम्भावित समस्याहरूको समाधानलाई महत्त्वपूर्ण रूपमा गति दिनेछ।

स्रोत: www.habr.com