अराजकता इंजीनियरिंग: जानबूझकर विनाश की कला। भाग 1

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

"लेकिन इस सब के पीछे सुंदरता अराजकता और पागलपन है।" - टेनर की दीवार

अग्निशामक । ये उच्च योग्य विशेषज्ञ हर दिन आग से लड़ते हुए अपनी जान जोखिम में डालते हैं। क्या आप जानते हैं कि फायर फाइटर बनने से पहले आपको कम से कम 600 घंटे प्रशिक्षण में बिताने होंगे? और यह सिर्फ शुरुआत है। रिपोर्टों के अनुसार, अग्निशमन अपने काम के समय का 80% तक प्रशिक्षित करते हैं।

क्यों?

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

“ऐसा लगता है जैसे वे आग के बहुत सार को भेदते हैं; लौ के लिए डॉ। फिल के ऐसे एनालॉग। " - कंप्यूटर और अंतर्ज्ञान के साथ लड़ वाइल्डफायर

लगभग। ट्रांस। : फिलिप केल्विन "फिल" मैकग्रा एक अमेरिकी मनोवैज्ञानिक, लेखक, लोकप्रिय टेलीविजन कार्यक्रम "डॉक्टर फिल" के प्रस्तुतकर्ता हैं, जिसमें प्रस्तुतकर्ता अपनी प्रतिभागियों को उनकी समस्याओं का समाधान प्रदान करता है।

एक बार सिएटल में एक बार

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

जिस तरह अग्निशामकों ने आग से लड़ने के लिए अंतर्ज्ञान विकसित किया है, जेसी बड़े पैमाने पर विनाशकारी घटनाओं का मुकाबला करने के लिए अपनी टीम को अंतर्ज्ञान विकसित करने में मदद करने वाले थे।


"गेमडे: डिस्ट्रक्शन बाय रिसिलिएशन बाय डिस्ट्रक्शन" - जेसी रॉबिंस

गेमडे को मिशन-क्रिटिकल सिस्टम में त्रुटियों को जानबूझकर पेश करके अमेज़ॅन की खुदरा साइट की लचीलापन बढ़ाने के लिए डिज़ाइन किया गया था।

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

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

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

बंदर का उदय

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

मैं अपने पसंदीदा उद्धरणों में से एक दोहराता हूं:

“असफलता अपरिहार्य है; अंततः, कोई भी प्रणाली समय के साथ दुर्घटनाग्रस्त हो जाएगी। ” - वर्नर वोगल्स

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

अतिरेक और सुशोभित गिरावट के सिद्धांतों का उपयोग करते हुए, नेटफ्लिक्स अंत उपयोगकर्ताओं को प्रभावित किए बिना विफलताओं से बचने में कामयाब रहा ।

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

लगभग। ट्रांस। : वैसे, कुबेरनेट्स के लिए क्यूब -बंदर नामक एक एनालॉग है, जिसका विकास इस साल मार्च में बंद हो गया लगता है।

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

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

"क्षेत्रीय परिणामों की नकल करने वाले एक नियमित आधार पर प्रयोगों का संचालन करके, हम विभिन्न प्रणालीगत खामियों की पहचान करने और उन्हें एक प्रारंभिक चरण में समाप्त करने में सक्षम थे।" - नेटफ्लिक्स ब्लॉग

आज, अराजकता इंजीनियरिंग के सिद्धांतों को औपचारिक रूप दिया जाता है ; उन्हें निम्नलिखित परिभाषा दी गई है:

"कैओस इंजीनियरिंग एक दृष्टिकोण है जिसमें एक उत्पादन प्रणाली पर प्रयोगों का संचालन करना शामिल है ताकि ऑपरेशन के दौरान होने वाले विभिन्न हस्तक्षेपों का सामना करने की क्षमता सुनिश्चित हो सके।" - सिद्धांतोंफचोस.ओआरजी

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

"कैओस इंजीनियरिंग विफलताओं के परिणामों को कम करने के लिए बनाया गया एक प्रयोग है।"

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

अराजकता पैदा करने के लिए आवश्यक शर्तें

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


सिस्टम में अराजकता लाने से पहले कुछ अनिवार्य तत्व (सूची संपूर्ण नहीं है)

अराजकता इंजीनियरिंग के चरणों

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

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


अराजकता इंजीनियरिंग के चरणों

1. स्थिर अवस्था

अराजकता इंजीनियरिंग के सबसे महत्वपूर्ण तत्वों में से एक सामान्य परिस्थितियों में एक प्रणाली के व्यवहार को समझ रहा है।

क्यों? यह सरल है: कृत्रिम विफलता की शुरुआत के बाद, आपको यह सुनिश्चित करना होगा कि सिस्टम एक अच्छी तरह से अध्ययन किए गए स्थिर स्थिति में वापस आ गया है और प्रयोग अब उसके सामान्य व्यवहार में हस्तक्षेप नहीं करता है।

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

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

स्थिर परिस्थितियों के उदाहरण के रूप में, आइए हम अमेज़न के अनुभव का हवाला देते हैं। कंपनी एक स्थिर स्थिति के मैट्रिक्स के रूप में और अच्छे कारण के लिए आदेशों की संख्या का उपयोग करती है। 2007 में, ग्रेग लिंडन, जो पहले अमेज़ॅन में काम करते थे, ने ए / बी परीक्षण पद्धति का उपयोग करते हुए एक प्रयोग के भाग के रूप में बात की , उन्होंने 100 एमएस की वेतन वृद्धि में साइट पर पृष्ठों के लोडिंग समय को धीमा करने की कोशिश की और पाया कि मामूली विलंब परिणाम भी राजस्व में एक गंभीर गिरावट के लिए। 100 एमएस के लोडिंग समय में वृद्धि के साथ, आदेशों की संख्या (और इसलिए बिक्री) में 1% की कमी हुई। इसीलिए स्थिर मेट्रिक्स के लिए आदेशों की संख्या एक उत्कृष्ट उम्मीदवार है।

नेटफ्लिक्स प्लेबैक की शुरुआत से जुड़े सर्वर-साइड मीट्रिक का उपयोग करता है - प्ले बटन पर क्लिक की संख्या। उन्होंने एसपीएस के व्यवहार में एक नियमितता (स्टार्ट-प्रति-सेकंड) संकेतक और सिस्टम विफलताओं की स्थिति में इसके महत्वपूर्ण उतार-चढ़ाव को देखा। मीट्रिक को "पल्स ऑफ नेटफ्लिक्स" ( पल्स ऑफ नेटफ्लिक्स ) कहा जाता है।

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

नाप, नाप और नाप फिर से

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

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

2. परिकल्पना

स्थिर स्थिति से निपटने के बाद, हम एक परिकल्पना तैयार कर सकते हैं।

• क्या होगा अगर सिफारिश तंत्र बंद हो जाता है?
• क्या होगा अगर लोड बैलेंसर गिरता है?
• यदि कैशिंग गिर जाए तो क्या होगा?
• क्या होगा अगर देरी 300 एमएस से बढ़ जाती है?
• क्या होगा अगर मास्टर बेस क्रैश हो जाए?

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

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

समस्या को सभी के लिए सामान्य बनाएं!

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

सबसे पहले, हर किसी को सवाल का अपना जवाब लिखने के लिए कहें "क्या होगा ...?" कागज के एक टुकड़े पर। आप देखेंगे कि ज्यादातर मामलों में हर किसी का अपना जवाब होगा, और आप समझेंगे कि टीम के कुछ हिस्से ने अभी भी इस तरह की समस्या के बारे में नहीं सोचा है।

इस बिंदु पर रुकें और चर्चा करें कि "क्या हुआ अगर ..." के मामले में टीम के सदस्यों के उत्पाद व्यवहार के बारे में एक अलग दृष्टिकोण है? अपनी विशिष्टताओं पर वापस जाएं और सुनिश्चित करें कि सभी लोग घटनाओं के संभावित विकास को सही ढंग से समझते हैं।

उदाहरण के लिए, अमेज़न रिटेल साइट का उल्लेख करें। क्या होगा यदि श्रेणी सेवा की दुकान मुख्य पृष्ठ पर लोड करना बंद कर देती है?



क्या मुझे 404 त्रुटि वापस करनी चाहिए? क्या पृष्ठ को लोड करने के लिए इसके लायक है, नीचे स्क्रीनशॉट के रूप में एक खाली जगह छोड़कर?



क्या यह कार्यक्षमता का हिस्सा त्यागने के लायक है और, उदाहरण के लिए, पृष्ठ का विस्तार करने और त्रुटि को छिपाने की अनुमति देता है?



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

और आखिरी वाला। कृपया एक परिकल्पना तैयार न करें, जो पहले से ज्ञात है कि यह जलाऊ लकड़ी को तोड़ देगा! प्रणाली के कुछ हिस्सों के साथ प्रयोग, आपकी राय में, स्थिर हैं - अंततः, यह प्रयोग का पूरा बिंदु है।

3. एक प्रयोग डिजाइन और चलाएं

• एक परिकल्पना चुनें;
• प्रयोग के दायरे को परिभाषित करें;
• मापा जाने वाले संबंधित संकेतकों को परिभाषित करें;
• संगठन को सूचित करें।

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

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

ईमानदारी से, अधिकांश टीमें गैर-उत्पादन वातावरण में भी चीजों को तोड़कर बहुत कुछ सीखेंगी। बस अपने स्थानीय वातावरण में docker stop database को docker stop database प्रयास करें और देखें कि क्या आप बिना परिणाम के इस समस्या से निपट सकते हैं। उच्च संभावना है कि नहीं।


डेटाबेस स्टॉप - उदाहरण

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

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

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

• प्रयोग से कितने ग्राहक प्रभावित होंगे?
• क्या कार्यक्षमता भुगतना होगा?
• किन जगहों पर होगा असर?

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


अराजकता प्रयोगों के लिए डीएनएस-आधारित कैनरी रोलआउट का एक उदाहरण

उन प्रयोगों से सावधान रहें जो एप्लिकेशन (कैश या डेटाबेस) की स्थिति को बदलते हैं या जिन्हें वापस नहीं किया जा सकता है (आसानी से या सिद्धांत रूप में)।

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

4. निरीक्षण करें और जानें

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

• समय की खोज?
• सतर्क रहने और सक्रिय कार्रवाई शुरू करने का समय?
• सार्वजनिक नोटिस का समय?
• कार्यक्षमता के आंशिक नुकसान का समय?
• आत्म-चिकित्सा की अवधि की लंबाई?
• पूर्ण या आंशिक वसूली का समय?
• संकट को समाप्त करने और स्थिर स्थिति में लौटने का समय?

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

प्रत्येक प्रयोग के लिए एक विस्तृत पोस्टमार्टम विश्लेषण करें!

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

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

COE रिपोर्ट में पाँच मुख्य भाग हैं:

1. क्या हुआ (कालानुक्रमिक क्रम)?
2. ग्राहकों पर क्या असर पड़ा?
3. त्रुटि क्यों हुई? ( पांच "क्यों?" )
4. हमने क्या सीखा?
5. भविष्य में इसे कैसे रोका जाए?

पहली नज़र में लगता है कि इन सवालों का जवाब देना अधिक कठिन है, क्योंकि आपको यह सुनिश्चित करने की ज़रूरत है कि हर समझदार / अज्ञात क्षण का सावधानीपूर्वक अध्ययन किया जाए।

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

5. सुधार और सुधार!

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

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

अराजकता इंजीनियरिंग के लाभ

इसके कई फायदे हैं। मैं दो पर प्रकाश डालूंगा, मेरी राय में, सबसे महत्वपूर्ण:

सबसे पहले, अराजकता इंजीनियरिंग सिस्टम में अज्ञात समस्याओं को हल करने और उन्हें ठीक करने से पहले उत्पादन विफलता का नेतृत्व करने में मदद करती है, कहते हैं, रविवार को सुबह 3 बजे। यही है, यह क्रैश प्रतिरोध को बढ़ाता है और वास्तव में, नींद की गुणवत्ता ।

दूसरे, कुशलतापूर्वक आयोजित अराजकता प्रयोग हमेशा प्रत्याशित की तुलना में अधिक व्यापक परिवर्तन (मुख्यतः सांस्कृतिक) का कारण बनते हैं। शायद इनमें से सबसे महत्वपूर्ण " गैर-दोषपूर्ण" संस्कृति के लिए प्राकृतिक विकास है, जब सवाल "आपने ऐसा क्यों किया?" "भविष्य में हम इससे कैसे बच सकते हैं?" नतीजतन, टीम खुश, अधिक कुशल, अधिक रुचि और सफल हो जाती है। और यह अद्भुत है!

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

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

अनुवादक से पी.एस.

अंग्रेजी में लेख का दूसरा भाग पहले ही प्रकट हो चुका है और हम इसका अनुवाद भी करेंगे यदि हम इस सामग्री के लिए हैबे के पाठकों से पर्याप्त रुचि देखते हैं - लेख पर प्रासंगिक टिप्पणियों का स्वागत है! अद्यतन (3 सितंबर): दूसरे भाग का अनुवाद भी प्रकाशित किया गया है ।

अद्यतन (19 दिसंबर): तीसरे भाग का अनुवाद उपलब्ध हो गया है।

हमारे ब्लॉग में भी पढ़ें:

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