अराजकता ईन्जिनियरिङ्: जानाजानी विनाश को कला। भाग 2

नोट। अनुवाद।: यो लेख AWS टेक्नोलोजी प्रचारक एड्रियन हर्नस्बीबाट लेखहरूको एक ठूलो श्रृंखला जारी राख्छ, जसले IT प्रणालीहरूमा असफलताहरूको नतिजालाई कम गर्न प्रयोगको महत्त्वलाई सरल र स्पष्ट रूपमा व्याख्या गर्न सेट गर्दछ।

"यदि तपाइँ योजना तयार गर्न असफल हुनुभयो भने, तपाइँ असफल हुने योजना बनाउनुहुन्छ।" - बेन्जामिन फ्रैंकलिन

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

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

महान प्रश्न! यद्यपि, उनी यस पाण्डाबाट खासै चिन्तित देखिँदैनन् ...

अराजकता पान्डा संग गडबड नगर्नुहोस्!

छोटो उत्तर: अनुरोध मार्गमा महत्वपूर्ण सेवाहरूलाई लक्षित गर्नुहोस्।

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

1. हेर दुर्घटना इतिहास र ढाँचाहरू पहिचान गर्नुहोस्;
2. निर्णय गर्नुहोस् महत्वपूर्ण निर्भरताहरू;
3. तथाकथित प्रयोग गर्नुहोस् अत्यधिक आत्मविश्वास प्रभाव.

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

1. जवाफ विगतमा छ

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

"वर्तमान बुझ्नको लागि, तपाईंले अतीतलाई जान्न आवश्यक छ।" - कार्ल सागन

असफलताहरूको इतिहास हेर्नुहोस्, तिनीहरूलाई COE वा पोस्टमार्टमहरूमा ट्याग गर्नुहोस् र तिनीहरूलाई वर्गीकृत गर्नुहोस्। प्रायः समस्याहरू निम्त्याउने सामान्य ढाँचाहरू पहिचान गर्नुहोस्, र प्रत्येक COE को लागि, आफैलाई निम्न प्रश्न सोध्नुहोस्:

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

मलाई मेरो करियरको सुरुमा एउटा असफलता याद छ। यदि हामीले केही साधारण अराजकता प्रयोगहरू गरेको भए यसलाई सजिलै रोक्न सकिन्थ्यो:

सामान्य अवस्थामा, ब्याकएन्ड उदाहरणहरूले स्वास्थ्य जाँचहरूमा प्रतिक्रिया दिन्छ लोड ब्यालेन्सर (ELB))। ELB ले स्वस्थ उदाहरणहरूमा अनुरोधहरू पुन: निर्देशित गर्न यी जाँचहरू प्रयोग गर्दछ। जब यो एक उदाहरण "अस्वास्थ्यकर" हो भनेर थाहा हुन्छ, ELB ले अनुरोधहरू पठाउन रोक्छ। एक दिन, सफल मार्केटिङ अभियान पछि, ट्राफिकको मात्रा बढ्यो र ब्याकएन्डहरूले स्वास्थ्य जाँचहरूमा सामान्य भन्दा ढिलो प्रतिक्रिया दिन थाले। भन्नु पर्छ कि यी स्वास्थ्य जाँचहरू थिए गहिरो, त्यो हो, निर्भरता को स्थिति जाँच गरियो।

तर, केही समयको लागि सबै ठीक थियो।

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

अचानक, अन्य सबै उदाहरणहरू पनि स्वास्थ्य परीक्षण असफल हुन थाले।

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

त्यसपछि हामीले सँधै निम्न बुँदाहरू बुझ्यौं:

• नयाँ उदाहरण सिर्जना गर्दा सफ्टवेयर स्थापना गर्न लामो समय लाग्छ; अपरिवर्तनीय दृष्टिकोणलाई प्राथमिकता दिनु राम्रो हुन्छ र गोल्डेन AMI.
• कठिन परिस्थितिहरूमा, स्वास्थ्य-जाँचहरू र ELBs को प्रतिक्रियाहरूलाई प्राथमिकता दिनु पर्छ - तपाईंले चाहानु भएको अन्तिम कुरा बाँकी उदाहरणहरूको लागि जीवनलाई जटिल बनाउनु हो।
• स्वास्थ्य जाँचको स्थानीय क्यासिङले धेरै मद्दत गर्छ (केही सेकेन्डका लागि पनि)।
• कठिन परिस्थितिमा, क्रोन कार्यहरू र अन्य गैर-महत्वपूर्ण प्रक्रियाहरू नचलाउनुहोस् - सबैभन्दा महत्त्वपूर्ण कार्यहरूको लागि स्रोतहरू बचत गर्नुहोस्।
• स्वतः स्केलिंग गर्दा, साना उदाहरणहरू प्रयोग गर्नुहोस्। 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. निर्भरता नक्सा बनाउनुहोस्

आफ्नो आवेदन बारे सोच्न एक क्षण लिनुहोस्। के त्यहाँ यसको निर्भरताको स्पष्ट नक्सा छ? के तपाईलाई थाहा छ यदि असफल भयो भने तिनीहरूले कस्तो प्रभाव पार्छ?

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

निर्भरता पहिचान र दस्तावेजीकरण भनिन्छ "निर्भरता नक्सा निर्माण» (निर्भरता म्यापिङ)। यो सामान्यतया कोड प्रोफाइलिङ उपकरणहरू प्रयोग गरेर ठूलो कोड आधार भएका अनुप्रयोगहरूको लागि गरिन्छ। (कोड प्रोफाइलिङ) र उपकरण (उपकरण)। तपाईं नेटवर्क ट्राफिक निगरानी गरेर नक्सा पनि निर्माण गर्न सक्नुहुन्छ।

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

महत्वपूर्ण निर्भरता बिना, सेवा काम गर्न सक्दैन। गैर-महत्वपूर्ण निर्भरता"गर्नु हुँदैन» गिरावटको अवस्थामा सेवालाई प्रभाव पार्न। निर्भरताहरू बुझ्नको लागि, तपाइँसँग तपाइँको एप्लिकेसन द्वारा प्रयोग गरिएको API को स्पष्ट समझ हुनु आवश्यक छ। यो देखिन्छ भन्दा धेरै गाह्रो हुन सक्छ - कम्तिमा ठूला अनुप्रयोगहरूको लागि।

सबै API मार्फत जाँदै सुरु गर्नुहोस्। सबैभन्दा बढी हाइलाइट गर्नुहोस् महत्वपूर्ण र आलोचनात्मक। लिनुहोस् निर्भरताहरु कोड भण्डारबाट, यसलाई जाँच गर्नुहोस् जडान लगहरू, त्यसपछि हेर्नुहोस् कागजात (निस्सन्देह, यदि यो अवस्थित छ - अन्यथा तपाईसँग अझै छоठूला समस्याहरू)। उपकरणहरू प्रयोग गर्नुहोस् प्रोफाइलिङ र ट्रेसिङ, बाह्य कलहरू फिल्टर गर्नुहोस्।

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

❯ netstat -a | more 

AWS मा तपाइँ प्रयोग गर्न सक्नुहुन्छ प्रवाह लगहरू (प्रवाह लगहरू) VPC एक विधि हो जसले तपाईंलाई VPC मा नेटवर्क इन्टरफेसहरूमा जाने वा बाट IP ट्राफिकको बारेमा जानकारी सङ्कलन गर्न अनुमति दिन्छ। त्यस्ता लगहरूले अन्य कार्यहरूमा पनि मद्दत गर्न सक्छ - उदाहरणका लागि, किन निश्चित ट्राफिक उदाहरणमा पुग्दैन भन्ने प्रश्नको जवाफ खोज्ने।

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

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

नेटवर्क निर्भरता नक्शा मात्र आंशिक समाधान हो। हो, यसले कुन अनुप्रयोगले कुनसँग सञ्चार गर्छ देखाउँछ, तर त्यहाँ अन्य निर्भरताहरू छन्।

धेरै अनुप्रयोगहरूले निर्भरताहरूमा जडान गर्न DNS प्रयोग गर्छन्, जबकि अरूले कन्फिगरेसन फाइलहरूमा सेवा खोज वा हार्ड-कोड गरिएको IP ठेगानाहरू प्रयोग गर्न सक्छन् (जस्तै। /etc/hosts).

उदाहरणका लागि, तपाईं सिर्जना गर्न सक्नुहुन्छ DNS ब्ल्याकहोल सहयोगको साथ iptables र हेर्नुहोस् के ब्रेक हुन्छ। यो गर्नको लागि, निम्न आदेश प्रविष्ट गर्नुहोस्:

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

DNS ब्ल्याक होल

यदि मा /etc/hosts वा अन्य कन्फिगरेसन फाइलहरू, तपाईंले IP ठेगानाहरू फेला पार्नुहुनेछ जुन तपाईंलाई थाहा छैन (हो, दुर्भाग्यवश, यो पनि हुन्छ), तपाईं पुन: उद्धार गर्न आउन सक्नुहुन्छ। 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"

पहुँच बन्द गर्दै

पहिलो नियमले गुगलको सार्वजनिक DNS बाट सबै प्याकेटहरू छोड्छ: ping काम गर्छ, तर प्याकेटहरू फिर्ता हुँदैनन्। दोस्रो नियमले तपाईंको प्रणालीबाट उत्पत्ति हुने सबै प्याकेटहरूलाई Google को सार्वजनिक DNS तर्फ छोड्छ - प्रतिक्रियामा ping हामी पाउँछौं सञ्चालन अनुमति छैन.

नोट: यो विशेष अवस्थामा यो प्रयोग गर्न राम्रो हुनेछ whois 8.8.8.8तर यो एउटा उदाहरण मात्र हो।

हामी खरायो प्वालबाट अझ गहिरो जान सक्छौं, किनभने TCP र UDP प्रयोग गर्ने सबै कुरा वास्तवमा IP मा पनि निर्भर गर्दछ। अधिकतर अवस्थामा, आईपी एआरपीसँग जोडिएको छ। फायरवालहरूको बारेमा नबिर्सनुहोस् ...

यदि तपाईंले रातो चक्की लिनुभयो भने, तपाईं वन्डरल्याण्डमा बस्नुहुन्छ, र म तपाईंलाई खरायोको प्वाल कति गहिरो हुन्छ देखाउनेछु।"

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

निर्भरता नक्सा निर्माण गर्नु प्रायः धेरै लामो कार्य हो। मैले भर्खरै एक ग्राहकसँग कुरा गरें जसले लगभग 2 वर्ष एक उपकरण विकास गर्न बिताए जसले अर्ध-स्वचालित रूपमा सयौं माइक्रो सेवाहरू र आदेशहरूको लागि निर्भरता नक्सा उत्पन्न गर्दछ।

परिणाम, तथापि, धेरै रोचक र उपयोगी छ। तपाइँ तपाइँको प्रणाली, यसको निर्भरता र अपरेशन बारे धेरै सिक्नुहुनेछ। फेरि, धैर्य हुनुहोस्: यो यात्रा नै सबैभन्दा महत्त्वपूर्ण छ।

3. अति आत्मविश्वास देखि सावधान रहनुहोस्

"जसले के सपना देख्छ, त्यसमा विश्वास गर्छ।" - डेमोस्थेनिस

के तपाईंले कहिल्यै सुन्नु भएको छ अत्यधिक आत्मविश्वास प्रभाव?

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

वृत्ति र अनुभवको आधारमा...

मेरो अनुभवमा, यो विकृति अराजकता ईन्जिनियरिङ् संग कहाँ सुरु गर्ने को एक महान संकेत हो।

अति आत्मविश्वासी अपरेटरबाट सावधान रहनुहोस्:

चार्ली: "यो चीज पाँच वर्षमा खसेको छैन, सबै ठीक छ!"
क्र्यास: "पर्खनुहोस् ... म त्यहाँ छिट्टै आउनेछु!"

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

संक्षेप गर्दै

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

यो दोस्रो भाग समाप्त हुन्छ। कृपया समीक्षा लेख्नुहोस्, विचार साझा गर्नुहोस् वा केवल आफ्नो हात ताली बजाउनुहोस् मध्यम। अर्को भागमा म वास्तवमा म प्रणालीहरूमा असफलताहरू परिचय गर्नका लागि उपकरणहरू र विधिहरू विचार गर्नेछु। सम्म!

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «अराजकता ईन्जिनियरिङ्: जानाजानी विनाश को कला। भाग 1»;
• «Kubernetes मा उच्च उपलब्धता कसरी प्राप्त गर्ने»;
• «निगरानी र Kubernetes (समीक्षा र भिडियो रिपोर्ट)»;
• «Kubernetes मा kube-proxy र नोड अनुपलब्धता संग प्रयोग"।

स्रोत: www.habr.com