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

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



एलेक्सी कुद्रेवत्सेव: सभी को नमस्कार! आज, हमारे अतिथि Mail.ru Cloud से Pavel Osipov हैं, जिनके साथ हम अराजकता इंजीनियरिंग के बारे में बात करेंगे।

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

व्यक्तिगत रूप से, प्रजनन मैनुअल अराजकता मुझे विश्वास की एक अतिरिक्त खुराक प्राप्त करने की अनुमति देती है कि सब कुछ ठीक हो जाएगा, भले ही आवेदन के बाहर सब कुछ खराब हो।

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

अराजकता की जड़ देखकर

अलेक्सेई कुद्र्यावत्सेव: इस तरह की प्रथा की जड़ें कहां से आईं?

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

उदाहरण के लिए, 2016 में, कैस्केडिंग डेटाबेस शटडाउन के कारण, 2.5 घंटे का फेसबुक बंद हो गया। फिर कॉन्फ़िगरेशन फ़ाइलों की वैधता की जांच करने वाली प्रणाली न केवल कैशिंग सबसिस्टम में, बल्कि प्राथमिक स्रोत के डेटाबेस में भी गलती से उन्हें हटाना शुरू कर दिया।

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

मोबाइल विकास में अराजकता के लाभ

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

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

हमें कई परिस्थितियां मिलीं जहां आवेदन के विभिन्न स्थानों पर लॉग इन करने से मेमोरी लीक जैसे परिणाम होते हैं। पूरा होने वाले ब्लॉक के साथ एक ही दर्शक एक महत्वपूर्ण सेवा ले सकता है, जो अंततः लीक हो गया था।

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

इसके लिए धन्यवाद, हमने iOS में UIKit के एक दिलचस्प व्यवहार की खोज की: यदि, जब एक रूटेड व्यू कॉन्ट्रोलर को हाइलाइट किया जाता है, तो विंडो से दूसरी विंडो को सामान्य रूप से ब्लॉक किया जाता है, फिर रूट व्यूक्रॉन्टोलर लीक होता है और सिस्टम में हमेशा के लिए रहता है। यदि एक ही समय में ViewController की सेवाओं के लिए एक लिंक था, जो वास्तुकला के तर्क के अनुसार, एक उदाहरण में सिस्टम में मौजूद होना चाहिए, तो समस्याओं से बचा नहीं जा सकता है। उदाहरण के लिए, क्लाउड में एक फोटो ऑटोलॉड सेवा है, और यदि ऐसी दो सेवाएं सिस्टम में रहती हैं, तो वे बहुत सारे अनावश्यक काम करेंगे और डिवाइस की बैटरी को दो बार जितनी जल्दी हो सके उतना अधिक डालें।

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

अराजकता का प्रकार

डेनियल पोपोव: अराजकता को ब्याज या एक विन्यास के आधार पर स्वचालित रूप से सिस्टम में पेश किया जाता है, लेकिन क्या किसी व्यक्ति को यह समझने के लिए एक नज़र की आवश्यकता है कि क्या गलत हुआ?

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

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

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

अराजकता का समय कब है?

अलेक्सई कुद्र्यावत्सेव: अभ्यास के कार्यान्वयन के लिए एक ट्रिगर के रूप में क्या किया गया?

पावेल ओसिपोव: हम परीक्षण की लागत को कम करने की आवश्यकता के माध्यम से इस पर आए थे। रैज़्लोज़िन की समान समस्याओं से कोई कैसे निपट सकता है? आप लीक के लिए इकाई परीक्षण लिख सकते हैं, आप भ्रमित हो सकते हैं और यूआई परीक्षण लिख सकते हैं।

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

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

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

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

अलेक्सई कुद्रियावत्सेव: क्या कारण को स्थानीय बनाना और अराजकता इंजीनियरिंग के बिना इसे ठीक करना संभव हो सकता है?

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

अलेक्सेई कुद्र्यावत्सेव: आप कब से इस प्रथा का उपयोग कर रहे हैं?

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

डेनियल पोपोव: यदि मेरे आवेदन में कुछ दुर्घटनाग्रस्त हो गया है और मुझे जेआईआरए में एक कार्य शुरू करने की आवश्यकता है, तो मैं भविष्य में क्या तय कर सकता हूं, मैं इस स्थिति को कैसे पुन: पेश कर सकता हूं?

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

अलेक्सेई कुद्रेवत्सेव: क्या आप प्रजनन योग्य व्यवहार बनाने की कोशिश कर रहे हैं ताकि आपकी अराजकता प्रणाली आपको समस्या की स्थिति के बारे में सूचित करे और इस अवस्था को दोहराने के लिए इसे शुरू में ही प्रवेश करने का सुझाव दे?

पावेल ओसिपोव: कॉस्मिक लगता है और संभवतः Redux जैसे आर्किटेक्चर में। यदि वास्तुकला आपको उन सभी कार्यों को रिकॉर्ड करने की अनुमति देता है जो महत्वपूर्ण घटनाओं से पहले थे, तो यह संभव है। हमारे साथ ऐसा नहीं है। जब मैं टेलीकॉम में सर्वराइड-प्रोग्रामर के रूप में काम कर रहा था तब यह अभ्यास किया गया था। ऐसे परीक्षण थे जिन्होंने सबसिस्टम के प्रवेश द्वार को यादृच्छिक किया और पर्याप्त आउटपुट के लिए जाँच की। हमने यह हासिल किया कि जब यादृच्छिक इनपुट के साथ परीक्षण ने सिस्टम को क्रैश कर दिया था, और उस कार्यक्रम में जो स्वचालन के परीक्षण के लिए जिम्मेदार था, तो इनपुट अनुरोध के सभी आवश्यक मापदंडों को स्थगित कर दिया गया था ताकि इसे पुन: प्रस्तुत किया जा सके।

आवेदन में अराजकता लागू करें

डेनियल पोपोव: क्या यह सही है कि इस तरह की अराजकता को हाथ से कोड में पेश किया जाता है?

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

हम केवल सब कुछ यादृच्छिक नहीं करते हैं, सही कोड खेलते हैं, लेकिन सार्थक रूप से यादृच्छिक करते हैं कि उपयोगकर्ता वास्तविक जीवन में क्या पुन: उत्पन्न कर सकता है।

अलेक्सेई कुद्रेवत्सेव: आप नेटवर्क और फ़ाइलों के अलावा यादृच्छिक क्या करते हैं?

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

अलेक्सेई कुद्रेवत्सेव: क्या यह सब आप करते हैं?

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

अराजकता का स्थान कहां है? आप हमेशा एक जगह पा सकते हैं जहां आप आवेदन के लिए एक और अशांति पैदा कर सकते हैं। समस्याओं पर निर्माण करना महत्वपूर्ण है। हमने लॉगिंग के लिए अव्यवस्था की क्योंकि हमने बड़ी संख्या में इसी तरह की समस्याओं का अवलोकन किया।

यदि निगरानी से पता चलता है कि अन्य उप-प्रणालियों में कोई विशेष समस्याएं नहीं हैं, तो यह अप्रत्याशित परिस्थितियों के लिए समय बिताने का कोई मतलब नहीं है।

यह बिलिंग पर लागू नहीं होता है, जहां सही संचालन महत्वपूर्ण है।

अलेक्सेई कुद्रेवत्सेव: दूसरी ओर, हम नहीं जानते कि उपयोगकर्ताओं के साथ क्या हो रहा है - यह अपने आप में अराजकता है, क्योंकि आप नहीं जानते कि इसे कहां रखा जाए या नहीं, और आपको इसे अनुकरण करना है।

पावेल ओसिपोव: आपको हमेशा ROI देखने की आवश्यकता है। बेशक, आप सबसे अधिक विदेशी मामलों को पुन: पेश कर सकते हैं, लेकिन अगर वे एकल हैं, तो शायद वे महत्वपूर्ण नहीं हैं, और उन्हें मॉडलिंग करने का कोई मतलब नहीं है।

अराजकता का परिचय देने की चुनौतियाँ

अलेक्सेई कुद्रियावत्सेव: जो पहले से ही किया गया है, वह आपके लिए आसान था, और किन कठिनाइयों के कारण?

पावेल ओसिपोव: अव्यवस्था के लिए इस्तेमाल किया जाना एक शुरुआत के लिए असामान्य है, क्योंकि यह आमतौर पर इस्तेमाल नहीं किया जाने वाला अभ्यास है। इस तथ्य के अनुकूल होना कठिन है कि आपके पास गलतियों का एक समूह है। लगभग हर स्क्रीन पर, आपको "पांच सौ" या असंगत "404" का पैक मिल सकता है, सर्वर एक बार जवाब देता है। केवल समय के साथ आपको इस तथ्य की आदत हो जाती है कि यह सब उबाऊ है, और सर्वर से प्रतिक्रियाएं सिस्टम द्वारा ही मॉडलिंग की जाती हैं।

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

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

डेनियल पोपोव: तो, क्या डेवलपर्स हमेशा अव्यवस्था को डिफ़ॉल्ट रूप से चालू करते हैं?

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

अराजकता का अर्थ बड़ी संख्या में घटकों की बातचीत में अप्रत्याशित परिणामों की पहचान करना है।

यदि आप अव्यवस्थित और सटीक तरीके से अराजकता को शामिल करते हैं, तो ये दुर्लभ लेकिन अच्छी तरह से लक्षित शॉट्स अदृश्य होंगे।

डेनियल पोपोव: क्या अराजकता कोड की पठनीयता को रोकती है?

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

अलेक्सेई कुद्रेवत्सेव: आप बहुत सारे दुर्लभ मामलों को पकड़ते हैं, उन्हें ठीक करते हैं और कोड बैसाखी से घिरा होता है। क्या यह एप्लिकेशन लॉजिक को जटिल करता है?

पावेल ओसिपोव: यह हमेशा हमारे कोड का एक बड़ा हिस्सा होता है, लेकिन अन्यथा बड़े उत्पादन अनुप्रयोग नहीं लिखे जाते हैं। बेशक, यह सब डेवलपर के कौशल पर निर्भर करता है, जो जानता है कि कोड को कैसे ठीक किया जाए, ताकि वह आंखों को न छेड़े।

अराजकता की शुरुआत करने के पेशेवरों

डेनियल पोपोव: क्या कोई मात्रात्मक संकेतक हैं जो अराजकता इंजीनियरिंग की शुरुआत के बाद सुधार हुए हैं?

पावेल ओसिपोव: मेरे लिए, सबसे महत्वपूर्ण मीट्रिक है मन की आंतरिक शांति जब मैं रिलीज करने के लिए एक फीचर भेजता हूं।

एलेक्सी कुद्र्यावत्सेव: शांति को व्यापार में नहीं बेचा जा सकता है। कंपनी में अराजकता इंजीनियरिंग की शुरूआत का तर्क कैसे दिया जाए?

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

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

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

किससे सीखें और कहाँ से शुरू करें?

अलेक्सेई कुद्र्यावत्सेव: आपने इसके लिए कौन से उपकरण का उपयोग किया? खुले पुस्तकालयों को लिया या ओपन सोर्स में लिखा और पोस्ट किया गया?

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

डेनियल पोपोव: मैं अराजकता इंजीनियरिंग के बारे में और अधिक कहां पढ़ सकता हूं?

पावेल ओसिपोव: सबसे पहले, अराजकता वेबसाइट के सिद्धांत , जो इस विषय पर सभी संसाधनों को लिंक करते हैं। दूसरी बात, सीखने की अराजकता इंजीनियरिंग और अराजकता इंजीनियरिंग अवलोकन ।

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

अलेक्सई कुद्रियावत्सेव: यदि आप अभी भी अराजकता लाने का फैसला करते हैं तो कहां से शुरू करें?

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

अलेक्सेई कुद्र्यावत्सेव: कई चीजें आवेदन में चोट कर सकती हैं, लेकिन प्राथमिकता कैसे करें? बेहतर नहीं है कि कहां ध्यान लगाएं?

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

अराजकता एक यादृच्छिक प्रहार नहीं है, लेकिन नकली स्थितियों की स्पष्ट समझ है।

अलेक्सई कुद्र्यावत्सेव: आप इस अभ्यास को लागू करने की कितनी सलाह देते हैं?

पावेल ओसिपोव: मैं आमतौर पर इकाई परीक्षणों के बजाय अराजकता इंजीनियरिंग की शुरुआत के साथ शुरू करने की सलाह देता हूं, क्योंकि यह सबसे सस्ता अभ्यास है।

अराजकता इंजीनियरिंग में रुचि रखते हैं? 21-21 अक्टूबर को सेंट पीटर्सबर्ग में शरद ऋतु एप्सकॉफ में पावेल ओसिपोव को पकड़ो, जहां वह की-वैल्यू डेटाबेस पर अपनी नई रिपोर्ट पेश करेंगे।