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

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

"यदि आप योजना तैयार करने में विफल रहे, तो आप असफल होने की योजना बनाते हैं।" - बेंजामिन फ्रैंकलिन

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

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

बड़ा अच्छा सवाल! हालाँकि, वह इस पांडा से परेशान नहीं है ...


अराजकता पांडा के साथ गड़बड़ मत करो!

संक्षिप्त उत्तर : अनुरोध पथ पर महत्वपूर्ण सेवाओं के लिए लक्ष्य।

एक लंबा लेकिन अधिक समझदार उत्तर : यह समझने के लिए कि अराजकता के साथ प्रयोग कहाँ शुरू करें, तीन क्षेत्रों पर ध्यान दें:

1. विफलताओं के इतिहास को देखें और पैटर्न की पहचान करें;
2. महत्वपूर्ण निर्भरता पर निर्णय लें;
3. तथाकथित का उपयोग करें। अति आत्मविश्वास प्रभाव ।

यह मजाकिया है, लेकिन उसी सफलता के साथ यह हिस्सा "आत्म-ज्ञान और ज्ञानोदय के लिए यात्रा" कहा जा सकता है । इसमें, हम कुछ शांत उपकरणों के साथ "खेलना" शुरू करेंगे।

1. उत्तर भूतकाल में है

अगर आपको याद है, तो पहले भाग में मैंने सुधार-सुधार की अवधारणा (COE) की शुरुआत की थी - जिस विधि से हम अपने प्रक्षेपास्त्रों का विश्लेषण करते हैं: प्रौद्योगिकी, प्रक्रिया या संगठन में चूक - उनके कारण को समझने के लिए और भविष्य में दोहराव को रोकने के लिए। । सामान्य तौर पर, यह शुरू होना चाहिए।

"वर्तमान को समझने के लिए, आपको भूतकाल को जानना होगा।" - कार्ल सागन

विफलताओं के इतिहास को देखें, एसओई या पोस्टमॉर्टेम में टैग लगाएं और उन्हें वर्गीकृत करें। सामान्य पैटर्न की पहचान करें जो अक्सर समस्याओं का कारण बनता है, और प्रत्येक SOE के लिए अपने आप से निम्नलिखित प्रश्न पूछें:

"यह पूर्वाभास किया जा सकता है, और इसलिए एक खराबी की शुरुआत से रोका गया था?"

मुझे अपने करियर की शुरुआत में एक असफलता याद है। अगर हम सरल अराजकता प्रयोगों के एक जोड़े को आसानी से रोका जा सकता था:

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

हालांकि, कुछ समय के लिए सब कुछ क्रम में था।

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

अचानक, अन्य सभी उदाहरणों ने भी स्वास्थ्य जांच को विफल करना शुरू कर दिया।

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

तब हमने हमेशा निम्नलिखित बिंदुओं को समझा:

• लंबे समय तक एक नया उदाहरण बनाते समय सॉफ़्टवेयर स्थापित करने के लिए, अपरिवर्तनीय दृष्टिकोण और गोल्डन एएमआई को वरीयता देना बेहतर होता है।
• कठिन परिस्थितियों में, स्वास्थ्य-जांच और ईएलबी की प्रतिक्रियाओं को पूर्वता लेना चाहिए - आखिरी चीज जो आप करना चाहते हैं वह शेष उदाहरणों के लिए जीवन को कठिन बना देता है।
• स्थानीय स्वास्थ्य परीक्षण (कुछ सेकंड के लिए भी) बहुत मदद करता है।
• एक कठिन परिस्थिति में, क्रोन कार्यों और अन्य गैर-महत्वपूर्ण प्रक्रियाओं को न चलाएं - सबसे महत्वपूर्ण कार्यों के लिए संसाधनों को बचाएं।
• ऑटोसालिंग करते समय, छोटे उदाहरणों का उपयोग करें। 10 छोटी प्रतियों का एक समूह 4 बड़े लोगों से बेहतर है; यदि एक उदाहरण गिरता है, तो पहले मामले में 10% ट्रैफ़िक को 9 बिंदुओं पर वितरित किया जाएगा, दूसरे में - तीन बिंदुओं के साथ ट्रैफ़िक का 25%।

तो, क्या यह पूर्वाभास हो सकता है, और इसलिए समस्या को शुरू करने से रोका जा सकता है?

हाँ , और कई मायनों में।

सबसे पहले, stress-ng या cpuburn जैसे उपकरणों के साथ उच्च CPU उपयोग का अनुकरण cpuburn :

 ❯ stress-ng --matrix 1 -t 60s 

तनाव एनजी

दूसरे, wrk और इसी तरह की अन्य उपयोगिताओं का उपयोग कर ओवरलोडिंग:

 ❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health 

प्रयोग अपेक्षाकृत सरल हैं, लेकिन वे वास्तविक असफलता के तनाव का अनुभव किए बिना विचार के लिए अच्छा भोजन प्रदान कर सकते हैं।

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


क्या यह एक सपना था, या यह वास्तव में हुआ था?

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

फिर सबसे बड़ी श्रेणी के साथ सबसे सामान्य पैटर्न पर स्विच करें।

2. एक निर्भरता नक्शा बनाएँ

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

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

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

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

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

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

आप netstat , एक कमांड-लाइन उपयोगिता जैसे प्रोग्राम का उपयोग कर सकते हैं जो सिस्टम पर सभी नेटवर्क कनेक्शन (सक्रिय सॉकेट) की एक सूची प्रदर्शित करता है। उदाहरण के लिए, सभी वर्तमान कनेक्शन प्रदर्शित करने के लिए, टाइप करें:

 ❯ netstat -a | more 

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

आप AWS X-Ray का भी उपयोग कर सकते हैं। एक्स-रे आपको अनुरोधों का विस्तृत, "अंत" (एंड-टू-एंड) अवलोकन प्राप्त करने की अनुमति देता है क्योंकि वे आवेदन के माध्यम से आगे बढ़ते हैं, और आवेदन के मूल घटकों का एक नक्शा भी बनाते हैं । यदि आपको निर्भरता की पहचान करने की आवश्यकता है तो यह बहुत सुविधाजनक है।


AWS एक्स-रे कंसोल

एक नेटवर्क निर्भरता नक्शा केवल एक आंशिक समाधान है। हां, यह दर्शाता है कि कौन सा एप्लिकेशन किसके साथ जुड़ा हुआ है, लेकिन अन्य निर्भरताएं हैं।

कई एप्लिकेशन निर्भरता से जुड़ने के लिए DNS का उपयोग करते हैं, जबकि अन्य सेवा खोज तंत्र या यहां तक ​​कि कॉन्फ़िगरेशन फ़ाइलों में हार्ड-कोडित आईपी पते का उपयोग कर सकते हैं (उदाहरण के लिए, /etc/hosts )।

उदाहरण के लिए, आप iptables का उपयोग करके एक ब्लैकहोल डीएनएस बना सकते हैं और देख सकते हैं कि क्या टूटता है। ऐसा करने के लिए, निम्न कमांड दर्ज करें:

 ❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS" 

ब्लैक होल डीएनएस

यदि आपको /etc/hosts या अन्य कॉन्फ़िगरेशन फ़ाइलों में आईपी पते मिलते हैं, जिनके बारे में आपको कुछ भी पता नहीं है (हाँ, दुर्भाग्य से, ऐसा होता है), iptables फिर से बचाव में आ सकते हैं। कहते हैं कि आप 8.8.8.8 पाते हैं और यह नहीं जानते कि यह Google के सार्वजनिक DNS सर्वर का पता है। iptables का उपयोग करके iptables आप निम्न आदेशों का उपयोग करके इस पते पर आने वाले और जाने वाले ट्रैफ़िक को बंद कर सकते हैं:

 ❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8" ❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8" 

पहुँच बंद करें

पहला नियम Google के सार्वजनिक DNS से ​​सभी पैकेट गिराता है: ping काम करता है, लेकिन पैकेट वापस नहीं किया जाता है। दूसरा नियम Google के सार्वजनिक DNS की दिशा में आपके सिस्टम से आने वाले सभी पैकेटों को छोड़ देता है - ping जवाब में हमें ऑपरेशन की अनुमति नहीं है ।

नोट: इस विशेष मामले में, whois 8.8.8.8 का उपयोग करना बेहतर होगा, लेकिन यह केवल एक उदाहरण है।

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


यदि आप एक लाल गोली चुनते हैं, तो आप वंडरलैंड में बने रहेंगे और मैं दिखाऊंगा कि खरगोश का छेद कितना गहरा है

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

एक निर्भरता मानचित्र का निर्माण अक्सर एक बहुत लंबा अभ्यास होता है। मैंने हाल ही में एक क्लाइंट के साथ बात की थी कि मैंने एक उपकरण को विकसित करने में लगभग 2 साल बिताए हैं, जो एक अर्ध-स्वचालित मोड में, सैकड़ों माइक्रोसर्विस और टीमों के लिए निर्भरता मानचित्र बनाता है।

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

3. अहंकार से सावधान रहें

"जो कोई भी सपने देखता है, वह उस पर विश्वास करता है।" - डेमोस्थनीज

क्या आपने कभी ओवर कॉन्फिडेंस के प्रभाव के बारे में सुना है?

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


वृत्ति और अनुभव के आधार पर ...

अपने स्वयं के अनुभव से, मैं कह सकता हूं कि यह विकृति एक महान संकेत है जहां अराजकता इंजीनियरिंग शुरू करना है।

आत्मविश्वासी ऑपरेटर से सावधान रहें:

चार्ली: "यह बात लगभग पाँच साल तक नहीं रही, सब कुछ ठीक है!"
असफलता: "रुको ... मैं जल्द ही आऊंगा!"

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

संक्षेप में देना

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

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

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

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

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