कैओस इंजीनियरिंग: जानबूझकर विनाश की कला। भाग 2

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

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

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

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

बढ़िया सवाल! हालाँकि, वह इस पांडा से विशेष रूप से परेशान नहीं दिखता...

अराजकता पांडा के साथ खिलवाड़ मत करो!

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

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

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

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

1. उत्तर अतीत में छिपा है

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

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

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

"क्या इसकी भविष्यवाणी की जा सकती थी और इसलिए दोष इंजेक्शन द्वारा इसे रोका जा सकता था?"

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

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

हालाँकि, कुछ समय तक सब कुछ ठीक था।

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

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

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

तब हमें निम्नलिखित बातें हमेशा के लिए समझ में आ गईं:

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

इस प्रकार, क्या इसका पूर्वाभास किया जा सकता था, और इसलिए समस्या का परिचय देकर इसे रोका जा सकता था?

Да, और कई मायनों में.

सबसे पहले, जैसे टूल का उपयोग करके उच्च CPU उपयोग का अनुकरण करके stress-ng या 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 में आप उपयोग कर सकते हैं प्रवाह लॉग (प्रवाह लॉग) वीपीसी एक ऐसी विधि है जो आपको वीपीसी में नेटवर्क इंटरफेस पर जाने वाले या उससे आने वाले आईपी ट्रैफिक के बारे में जानकारी एकत्र करने की अनुमति देती है। ऐसे लॉग अन्य कार्यों में भी मदद कर सकते हैं - उदाहरण के लिए, इस प्रश्न का उत्तर ढूंढना कि कुछ ट्रैफ़िक उदाहरण तक क्यों नहीं पहुंचता है।

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

एडब्ल्यूएस एक्स-रे कंसोल

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

कई एप्लिकेशन निर्भरता से जुड़ने के लिए 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 -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. अति आत्मविश्वास से सावधान रहें

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

क्या तुमने कभी सुना है अति आत्मविश्वास का प्रभाव?

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

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

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

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

चार्ली: "यह चीज़ पाँच वर्षों में नहीं गिरी है, सब कुछ ठीक है!"
क्रैश: "रुको... मैं जल्द ही वहाँ पहुँचूँगा!"

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

उपसंहार

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

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

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

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

• «कैओस इंजीनियरिंग: जानबूझकर विनाश की कला। भाग 1";
• «कुबेरनेट्स में उच्च उपलब्धता कैसे प्राप्त करें";
• «निगरानी और कुबेरनेट्स (समीक्षा और वीडियो रिपोर्ट)";
• «कुबेरनेट्स में क्यूब-प्रॉक्सी और नोड अनुपलब्धता के साथ प्रयोग'.

स्रोत: www.habr.com