अराजकता अभियांत्रिकी: जाणूनबुजून नाश करण्याची कला. भाग 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 मध्ये तुम्ही वापरू शकता प्रवाह नोंदी (फ्लो लॉग) व्हीपीसी ही एक पद्धत आहे जी तुम्हाला व्हीपीसीमधील नेटवर्क इंटरफेसवर जाणाऱ्या किंवा तेथून जाणाऱ्या 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"

प्रवेश बंद करत आहे

पहिला नियम Google च्या सार्वजनिक DNS वरून सर्व पॅकेट सोडतो: ping कार्य करते, परंतु पॅकेट परत केले जात नाहीत. दुसरा नियम तुमच्या सिस्टीममधून उगम पावणारी सर्व पॅकेट Google च्या सार्वजनिक DNS कडे टाकतो - प्रतिसादात ping आम्हाला मिळते ऑपरेशनला परवानगी नाही.

टीप: या विशिष्ट प्रकरणात ते वापरणे चांगले होईल whois 8.8.8.8, पण हे फक्त एक उदाहरण आहे.

आम्ही सशाच्या छिद्राच्या आणखी खोलवर जाऊ शकतो, कारण TCP आणि UDP वापरणारी प्रत्येक गोष्ट प्रत्यक्षात IP वर देखील अवलंबून असते. बहुतेक प्रकरणांमध्ये, आयपी एआरपीशी जोडलेला असतो. फायरवॉल बद्दल विसरू नका...

जर तुम्ही लाल गोळी घेतली तर तुम्ही वंडरलँडमध्ये राहाल आणि मी तुम्हाला दाखवतो की सशाचे छिद्र किती खोल जाते."

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

अवलंबित्व नकाशा तयार करणे हे बऱ्याचदा लांबचे काम असते. मी अलीकडेच एका क्लायंटशी बोललो ज्याने शेकडो मायक्रोसर्व्हिसेस आणि कमांड्ससाठी अर्ध-स्वयंचलितपणे अवलंबित्व नकाशे तयार करणारे साधन विकसित करण्यासाठी जवळजवळ 2 वर्षे घालवली.

परिणाम, तथापि, अत्यंत मनोरंजक आणि उपयुक्त आहे. तुम्ही तुमची प्रणाली, तिची अवलंबित्व आणि ऑपरेशन्स बद्दल बरेच काही शिकाल. पुन्हा, धीर धरा: हा प्रवासच सर्वात महत्त्वाचा आहे.

3. अतिआत्मविश्वासापासून सावध रहा

"जो कोणी कशाचे स्वप्न पाहतो, त्यावर विश्वास ठेवतो." - डेमोस्थेनिस

तुम्ही कधी ऐकले आहे अतिआत्मविश्वास प्रभाव?

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

प्रवृत्ती आणि अनुभवावर आधारित...

माझ्या अनुभवावरून, मी असे म्हणू शकतो की ही विकृती अनागोंदी अभियांत्रिकी कोठून सुरू करायची याचा एक उत्तम संकेत आहे.

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

चार्ली: "ही गोष्ट पाच वर्षांत कमी झाली नाही, सर्व काही ठीक आहे!"
क्रॅश: "थांबा... मी लवकरच तिथे येईन!"

अतिआत्मविश्वासाचा परिणाम म्हणून पूर्वाग्रह ही एक कपटी आणि अगदी धोकादायक गोष्ट आहे कारण त्यावर प्रभाव टाकणाऱ्या विविध घटकांमुळे. हे विशेषतः खरे आहे जेव्हा कार्यसंघ सदस्यांनी त्यांचे हृदय एखाद्या तंत्रज्ञानामध्ये ओतले आहे किंवा ते "फिक्स" करण्यात बराच वेळ घालवला आहे.

सारांश

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

यातून दुसरा भाग संपतो. कृपया पुनरावलोकने लिहा, मते सामायिक करा किंवा फक्त टाळ्या वाजवा मध्यम. पुढच्या भागात मी खरोखर मी सिस्टीममध्ये अयशस्वी होण्यासाठी साधने आणि पद्धतींचा विचार करेन. पर्यंत!

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «अराजकता अभियांत्रिकी: जाणूनबुजून नाश करण्याची कला. भाग 1";
• «Kubernetes मध्ये उच्च उपलब्धता कशी मिळवायची";
• «देखरेख आणि कुबर्नेट्स (पुनरावलोकन आणि व्हिडिओ अहवाल)";
• «Kubernetes मध्ये kube-proxy आणि नोड अनुपलब्धतेसह प्रयोग करत आहे».

स्त्रोत: www.habr.com