🚔 🛂 👩‍👦‍👦 एक बड़े वितरित प्रणाली का संचालन: मैंने जो सीखा 🙌🏻 🤷🏿 ✊🏼

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

मैं आपके ध्यान में उबर के एक इंजीनियर द्वारा लिखे गए लेख का अनुवाद लाता हूं।

* * *

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

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

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

हम ऐसे विषयों पर बात करेंगे:

निगरानी
ड्यूटी (ऑन-कॉल), विसंगति का पता लगाने और अधिसूचना।
विफलताएं और घटना प्रबंधन।
पोस्ट मॉर्टम, घटना विश्लेषण और निरंतर सुधार की संस्कृति।
विफलता, संसाधन नियोजन और ब्लैकबॉक्स परीक्षण।
एसएलओ, एसएलए और उन पर रिपोर्टिंग।
एक स्वतंत्र टीम के रूप में।
स्थायी निवेश के रूप में विश्वसनीयता।
उपयोगी सामग्री।

निगरानी

यह समझने के लिए कि क्या प्रणाली स्वस्थ है, हमें इस प्रश्न का उत्तर देने की आवश्यकता है: “क्या यह सही ढंग से काम करता है? "। इसके लिए, सिस्टम के महत्वपूर्ण भागों के बारे में जानकारी एकत्र करना महत्वपूर्ण है। और जब आपने कई सर्वरों और विभिन्न डेटा केंद्रों में विभिन्न सेवाओं से युक्त सिस्टम वितरित किए हैं, तो यह तय करना मुश्किल हो सकता है कि आपको वास्तव में किन प्रमुख बिंदुओं को ट्रैक करने की आवश्यकता है।

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

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

प्रतिक्रिया में देरी की निगरानी के बारे में कुछ और कहा जा सकता है। उत्पादन सेवाओं का लक्ष्य अधिकांश अंतिम उपयोगकर्ताओं के लिए उनका उपयोग करने का आनंद लेना है। और औसत देरी को मापना सबसे अच्छा समाधान नहीं है, क्योंकि औसत मूल्य बड़ी देरी के साथ कम संख्या में अनुरोधों को छिपा सकता है। पी 95, पी 99 या पी 999 को मापना बहुत बेहतर है - 95 वें, 99 वें या 99.9 वें प्रतिशत के अनुरोधों के लिए देरी। ये संख्याएँ प्रश्नों के उत्तर देने में मदद करती हैं, जैसे " 99% आगंतुकों के लिए अनुरोध कितना तेज़ होगा?" "(P99) या" 1000 में से एक आगंतुक के लिए अनुरोध कितना धीमा होगा? "(P999)। यदि आप विवरण में रुचि रखते हैं, तो आप इस लेख को पढ़ सकते हैं ।

पी 95 और पी 99 के लिए ग्राफ। ध्यान दें कि इस समापन बिंदु के लिए औसत विलंब 1 सेकंड से कम है, और 1% अनुरोधों में 2 सेकंड लगते हैं। और अधिक - यह औसत मूल्य को मापते समय नहीं देखा जाता है।

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

व्यापार मेट्रिक्स की निगरानी करना। निगरानी सेवाएँ हमें उनकी समग्र स्थिति के बारे में बताती हैं। लेकिन अकेले डेटा की निगरानी के अनुसार, हम यह नहीं कह सकते हैं कि क्या सेवाएं ठीक से काम कर रही हैं या नहीं, क्या व्यवसाय के दृष्टिकोण से सब कुछ सही तरीके से संसाधित किया गया है। भुगतान प्रणाली के मामले में, मुख्य सवाल यह है: “ क्या लोग किसी विशिष्ट भुगतान पद्धति का उपयोग करके यात्राएं कर सकते हैं? "। निगरानी में सबसे महत्वपूर्ण चरणों में से एक है इस सेवा द्वारा बनाई और संसाधित की गई व्यावसायिक घटनाओं की पहचान करना और उन्हें ट्रैक करना।

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

ड्यूटी, एनोमली डिटेक्शन और अलर्ट

सिस्टम की वर्तमान स्थिति की जांच करने के लिए निगरानी एक महान उपकरण है। लेकिन यह केवल विफलताओं का पता लगाने और उन लोगों को सचेत करने के लिए सड़क पर एक कदम है जो इस मामले में कुछ करना चाहिए।

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

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

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

विलनियस में उब डेवलपर अनुभव टीम द्वारा बनाई गई कॉल ड्यूटी पैनल का एक उदाहरण ।

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

विफलताएं और घटना प्रबंधन

कल्पना कीजिए: आप एक सप्ताह के लिए एक ड्यूटी इंजीनियर हैं। आधी रात को आप पेजर पर एक संदेश जगाते हैं। यदि उत्पादन में विफलता हुई है तो आप जाँच कर रहे हैं। अरे, ऐसा लगता है जैसे सिस्टम का एक हिस्सा दुर्घटनाग्रस्त हो गया है। अब क्या? मॉनिटरिंग और अलर्ट बस काम किया।

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

रक्षा की पहली पंक्ति मानक प्रतिक्रिया प्रक्रियाओं की रनबुक हैंसरल समस्या निवारण चरणों का वर्णन करें। यदि कंपनी के पास ऐसी सूचियां हैं और सक्रिय रूप से समर्थित है, तो सिस्टम के बारे में कर्तव्य इंजीनियर के एक सतही विचार से समस्या होने की संभावना नहीं है। समस्याओं को हल करने के नए तरीकों के लिए सूचियों को अद्यतित और अद्यतन रखा जाना चाहिए।

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

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

पोस्ट मॉर्टम, घटना विश्लेषण और निरंतर सुधार की संस्कृति

एक घटना की रिपोर्ट एक महत्वपूर्ण विशेषता है कि एक टीम विफलता के परिणामों का सामना कैसे करती है। क्या स्थिति लोगों की चिंता करती है? क्या वे थोड़ा शोध करते हैं, या अवलोकन पर प्रयास की एक अद्भुत राशि खर्च करते हैं, उत्पाद को रोकते हैं और सुधार करते हैं?

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

मैंने उबर में इस एरर हैंडलिंग पैटर्न का इस्तेमाल किया।

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

क्यों कोई समस्या है? -> कोड के हिस्से के रूप में बग अपलोड किया गया था।
किसी ने बग क्यों नहीं पकड़ा? -> समीक्षा करने वाले ने यह नहीं देखा कि कोड बदलने से ऐसी समस्या हो सकती है।
, ? --> .
? --> .
? --> .
: . , .

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

उन संगठनों में जो विश्वसनीयता के बारे में गंभीर हैं, सबसे गंभीर घटनाओं का विश्लेषण और अनुभवी इंजीनियरों द्वारा समाप्त किया जाता है। यह सुनिश्चित करने के लिए कंपनी स्तर पर इंजीनियरिंग का प्रबंधन करना भी आवश्यक है कि सुधार किए जा सकते हैं - खासकर यदि वे समय लेने या अन्य काम में हस्तक्षेप करते हैं। एक रात में एक विश्वसनीय प्रणाली नहीं बनाई जा सकती है: निरंतर पुनरावृत्तियों की आवश्यकता होगी। घटनाओं से सीखे गए पाठों के आधार पर निरंतर सुधार की एक कंपनी संस्कृति से उत्पन्न होने वाले परिवर्तन।

विफलता, संसाधन नियोजन और ब्लैकबॉक्स परीक्षण

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

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

सबसे आम विफलता परिदृश्य मैं आया था कि सेवा में विफल रहने की स्थिति में वैश्विक यातायात को संभालने के लिए नए डेटा सेंटर में पर्याप्त संसाधन नहीं हैं। मान लीजिए, सेवा A एक डेटा केंद्र में काम करता है और दूसरे में सेवा B। संसाधन की खपत 60% होने दें - प्रत्येक डेटा केंद्र में दसियों या सैकड़ों वर्चुअल मशीनें स्पिन होती हैं, और 70% की सीमा तक पहुंचने पर अलर्ट शुरू हो जाता है। डेटा सेंटर A से डेटा सेंटर B तक का सभी ट्रैफ़िक विफल रहा। दूसरा डेटा सेंटर नई मशीनों को तैनात किए बिना लोड में इतनी वृद्धि का सामना नहीं कर सकता है। हालांकि, इसमें बहुत समय लग सकता है, इसलिए अनुरोध ढेर होने और छोड़ने लगते हैं। अवरोधन अन्य सेवाओं को प्रभावित करना शुरू कर देता है, जिससे अन्य प्रणालियों के कैस्केड की विफलता होती है जो प्राथमिक विफलता से संबंधित नहीं हैं।

एक संभावित स्थिति जहां असफलता समस्याओं की ओर ले जाती है।

एक अन्य लोकप्रिय विफलता परिदृश्य में रूटिंग स्तर पर समस्याएं, नेटवर्क बैंडविड्थ या पीठ के दबाव के साथ समस्याएं शामिल हैं । डेटा केंद्रों का विफल होना एक ऐसा विकास है जो किसी भी विश्वसनीय वितरित प्रणाली को उपयोगकर्ताओं पर कोई प्रभाव डाले बिना करना चाहिए। मैं जोर देता हूं - यह होना चाहिए , यह विकास वितरित वेब सिस्टम की विश्वसनीयता की जांच के लिए सबसे उपयोगी अभ्यासों में से एक है।

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

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

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

फेलओवर विफलता और मैनुअल रोलबैक के दौरान ब्लैकबॉक्स परीक्षण का एक उदाहरण।

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

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

एसएलओ, एसएलए और उन पर रिपोर्टिंग

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

एसएलओ मेट्रिक	उपश्रेणी	सेवा मूल्य
प्रदर्शन	न्यूनतम बैंडविड्थ	प्रति सेकंड 500 अनुरोध
		2 500
		50-90
	p99	500-800
		0,5 %
		99,9 %

व्यापार के स्तर पर SLO । या कार्यात्मक एसएलओ, यह सेवाओं पर अमूर्तता है। वे कस्टम या व्यावसायिक मीट्रिक कवर करते हैं। उदाहरण के लिए, व्यावसायिक स्तर पर एक एसएलओ यह हो सकता है: एक यात्रा को पूरा करने के 1 मिनट के भीतर 99.99% प्राप्तियां मेल होने की उम्मीद है। इस SLO की तुलना सेवा स्तर पर SLO के साथ की जा सकती है (उदाहरण के लिए, भुगतान प्रणाली की देरी या मेल चेक भेजने की प्रणाली के साथ), और इसे अलग से मापा जा सकता है।

एसएलए - सेवा स्तर समझौता । यह एक सेवा प्रदाता और उसके उपभोक्ता के बीच एक अधिक सामान्य समझौता है। आमतौर पर, कई SLO एक SLA बनाते हैं। उदाहरण के लिए, 99.99% के स्तर पर भुगतान प्रणाली की उपलब्धता SLA हो सकती है, जो प्रत्येक संगत प्रणाली के लिए विशिष्ट SLO में विभाजित है।

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

और यह हमें एक और विषय की ओर ले जाता है: ऐसे संगठन जो बड़े वितरित सिस्टम संचालित करते हैं, जल्दी या बाद में इन प्रणालियों की विश्वसनीयता सुनिश्चित करने के लिए लोगों को आवंटित करने की आवश्यकता होती है। चलो SRE टीम के बारे में बात करते हैं - साइट विश्वसनीयता इंजीनियरिंग।

एक स्वतंत्र टीम के रूप में

अवधि साइट विश्वसनीयता इंजीनियरिंग गया था 2003 के आसपास गूगल द्वारा गढ़ा, और आज वहाँ की तुलना में अधिक 1,500 एसआरई इंजीनियरों हैं। जैसे-जैसे उत्पादन पर्यावरण का संचालन अधिक जटिल कार्य बनता जा रहा है, और अधिक स्वचालन की आवश्यकता है, यह जल्द ही एक पूर्ण कार्य बन जाएगा। ऐसा तब होता है जब कंपनियां महसूस करती हैं कि इंजीनियर लगभग पूरे दिन उत्पादन वातावरण के स्वचालन पर काम करते हैं: सिस्टम जितना महत्वपूर्ण और अधिक विफल होता है, उतनी ही जल्दी एसआरई एक अलग स्थिति बन जाती है।

तेजी से बढ़ती प्रौद्योगिकी कंपनियों ने अक्सर एक SRE टीम की स्थापना की, जिस पर वे अपने लिए योजना बनाते हैं। उबेर में, 2015 में ऐसी टीम बनाई गई थी।इसका लक्ष्य प्रणाली की जटिलता का प्रबंधन करना था। अन्य कंपनियों में, एसआरई टीमों का आवंटन एक अलग बुनियादी ढांचे की टीम के निर्माण से जुड़ा हो सकता है। जब कंपनी इस स्तर तक बढ़ती है कि सेवा की विश्वसनीयता सुनिश्चित करने के लिए इंजीनियरों की एक महत्वपूर्ण संख्या पर ध्यान देने की आवश्यकता होती है, तो यह एक अलग टीम बनाने का समय है।

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

यह देखते हुए कि सभी कंपनियों की अपनी समस्याएं हैं, जिनके समाधान के लिए वे SRE की भर्ती करते हैं, विभिन्न कंपनियों में ऐसी टीमों की अलग-अलग संरचनाएँ होती हैं। यहां तक कि नाम अलग-अलग हो सकते हैं: यह एक ऑपरेशन सेवा, प्लेटफॉर्म इंजीनियरिंग या बुनियादी ढांचा सेवा हो सकती है। Google ने सेवाओं की विश्वसनीयता सुनिश्चित करने पर दो अनिवार्य पठन पुस्तकें प्रकाशित की हैं । वे स्वतंत्र रूप से उपलब्ध हैं और एसआरई के विषय के अधिक गहन अध्ययन के लिए जानकारी का एक उत्कृष्ट स्रोत हैं।

स्थायी निवेश के रूप में विश्वसनीयता

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

वितरित प्रणालियों में एक ही जीवन चक्र होता है, सिवाय इसके कि उन्हें न केवल नई सुविधाओं में, बल्कि स्केलिंग को ध्यान में रखते हुए अधिक निवेश की आवश्यकता होती है। जब सिस्टम पर लोड बढ़ता है, तो आपको अधिक डेटा स्टोर करना होगा, अधिक इंजीनियर सिस्टम पर काम करते हैं, आपको लगातार इसके सामान्य कामकाज का ध्यान रखना होगा। जो लोग पहली बार वितरित सिस्टम बनाते हैं, उनमें से कई उन्हें मशीन की तरह कुछ मानते हैं: एक बार जब आप ऐसा कर लेते हैं, तो हर कुछ महीनों में कुछ रखरखाव करना पर्याप्त होता है। वास्तविकता से तुलना करना कठिन है।

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

एक विश्वसनीय वितरित प्रणाली को बनाए रखने के लिए टीम के लिए, संगठन को लगातार अपने कामकाज में निवेश करना चाहिए, साथ ही उन प्लेटफार्मों के काम में भी, जिन पर सिस्टम बनाया गया है।

उपयोगी सामग्री

यद्यपि लेख लंबा निकला, यह केवल सबसे सतही क्षणों को प्रस्तुत करता है। वितरित वितरित प्रणालियों की सुविधाओं के बारे में अधिक जानने के लिए, मैं इन स्रोतों की सिफारिश करता हूं:

पुस्तकें

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

साइटें

वृद्धि पत्रिका के ऑन-कॉल संस्करण : अमेज़न, ड्रॉपबॉक्स, फेसबुक, गूगल और नेटफ्लिक्स पर घटना प्रतिक्रिया प्रक्रियाओं पर लेखों की एक श्रृंखला।
वितरित सिस्टम बनाना सीखना - AWS इंजीनियर का लेख जो इस सवाल का जवाब देता है कि "बड़े वितरित सिस्टम कैसे बनाएं?

हैकर न्यूज़ के इस लेख पर टिप्पणियाँ देखें ।

एक बड़े वितरित प्रणाली का संचालन: मैंने जो सीखा