उत्पादन में सुरक्षित परीक्षण का संगठन। भाग २

लेख के इस भाग में, हम उत्पादन में विभिन्न प्रकार के परीक्षण पर विचार करना जारी रखेंगे। जिन लोगों ने पहले भाग को छोड़ दिया, वे इसे यहां पढ़ सकते हैं। बाकी के लिए - बिल्ली में आपका स्वागत है।

उत्पादन परीक्षण: रिलीज़

तैनाती के बाद सेवा का परीक्षण करने के बाद, इसे रिलीज के लिए तैयार किया जाना चाहिए।
यह ध्यान रखना महत्वपूर्ण है कि इस स्तर पर परिवर्तनों का रोलबैक केवल स्थायी विफलता की स्थितियों में संभव है, उदाहरण के लिए:

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

परिनियोजन चरण में पूरी तरह से परीक्षण मुझे रिलीज़ चरण में आदर्श रूप से कम से कम या अप्रिय आश्चर्य से बचने की अनुमति देता है। हालांकि, नए कोड को सुरक्षित रूप से जारी करने के लिए कई सिफारिशें हैं।

कैनरी की तैनाती

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

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

कैनरी परीक्षण में कुछ समस्याएं हैं, और यह लेख उनमें से काफी संपूर्ण अवलोकन प्रदान करता है।

निगरानी

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

• त्रुटि दर में वृद्धि;
• सेवा के दौरान प्रसंस्करण अनुरोधों की समग्र गति में कमी, एक विशिष्ट समापन बिंदु पर, या इससे भी बदतर, काम का एक पूर्ण समाप्ति;
• देरी बढ़ गई।

स्थायी विफलता के इन तरीकों में से किसी का अवलोकन पिछले राज्य में तत्काल रोलबैक या सॉफ़्टवेयर के नए रिलीज़ किए गए संस्करणों के रोलबैक का आधार है। यह याद रखना महत्वपूर्ण है कि इस स्तर पर निगरानी पूर्ण और सांकेतिक होने की संभावना नहीं है। कई लोगों का मानना ​​है कि निगरानी के दौरान संकेतों की आदर्श संख्या 3 से 5 तक है, लेकिन निश्चित रूप से 7-10 से अधिक नहीं है। क्रैकन फेसबुक श्वेत पत्र निम्नलिखित समाधान प्रस्तुत करता है:

"समस्या को आसानी से कॉन्फ़िगर करने योग्य निगरानी घटक की मदद से हल किया जाता है, जो दो बुनियादी संकेतकों (वेब ​​सर्वर के प्रतिक्रिया समय का 99 वां प्रतिशत और घातक HTTP त्रुटियों की घटना की आवृत्ति) की रिपोर्ट करता है, जो उपयोगकर्ता इंटरैक्शन की गुणवत्ता का वर्णन करता है।"

सिस्टम और एप्लिकेशन इंडिकेटर्स का सेट, जिसे रिलीज़ चरण के दौरान मॉनिटर किया जाता है, सिस्टम डिज़ाइन के दौरान सबसे अच्छा निर्धारित होता है।

अपवाद ट्रैकिंग

हम रिलीज़ स्टेज पर अपवादों पर नज़र रखने की बात कर रहे हैं, हालाँकि ऐसा लग सकता है कि तैनाती के चरणों में और रिलीज़ के बाद यह कम उपयोगी नहीं होगा। अपवाद ट्रैकिंग टूल अक्सर कुछ अन्य सिस्टम मॉनिटरिंग टूल के रूप में एक ही संपूर्णता, सटीकता और बड़े पैमाने पर कवरेज की गारंटी नहीं देते हैं, लेकिन वे अभी भी बहुत उपयोगी हो सकते हैं।

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

यातायात को आकार देने

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

यह विधि नए सॉफ्टवेयर की चरणबद्ध तैनाती (नियमित तैनाती से अलग) के लिए भी उपयोगी है। एक उदाहरण पर विचार करें। Imgix को जून 2016 में एक बुनियादी रूप से नए बुनियादी ढाँचे की वास्तुकला को तैनात करने की आवश्यकता थी। एक निश्चित मात्रा में अंधेरे यातायात के साथ नए बुनियादी ढांचे के पहले परीक्षण के बाद, उन्होंने उत्पादन में तैनात करना शुरू कर दिया, शुरू में उत्पादन पर्यावरण यातायात के लगभग 1% को एक नए स्टैक पर पुनर्निर्देशित किया। फिर, कई हफ्तों के दौरान, नए स्टैक पर पहुंचने वाले डेटा की मात्रा में वृद्धि हुई (रास्ते में समस्याओं को हल करना), जब तक कि यह 100% यातायात की प्रक्रिया शुरू नहीं करता।

सेवा जाल वास्तुकला की लोकप्रियता ने प्रॉक्सी सर्वरों में रुचि में एक नया उछाल ला दिया है। नतीजतन, दोनों पुराने (nginx, HAProxy) और नए (Envoy, Conduit) परदे के पीछे प्रतियोगियों से आगे निकलने की कोशिश में नए कार्यों के लिए समर्थन जोड़ा। यह मुझे लगता है कि भविष्य, जिसमें उत्पाद रिलीज के चरण में 0 से 100% तक ट्रैफिक पुनर्वितरण स्वचालित रूप से किया जाता है, बस कोने के आसपास है।

प्रोडक्शन टेस्टिंग: रिलीज़ के बाद

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

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

फ़ीचर फ़्लैगिंग, या डार्क लॉन्च

फीचर झंडे के सफल उपयोग के बारे में सबसे पुराना प्रकाशन जो मुझे मिला था वह लगभग दस साल पहले प्रकाशित हुआ था। Featureflags.io इस के लिए सबसे व्यापक गाइड प्रदान करता है।

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

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

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

ए / बी परीक्षण

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

लॉग, ईवेंट, संकेतक और ट्रेसिंग

आप तथाकथित "वेधशाला के तीन व्हेल" के बारे में पढ़ सकते हैं - लॉग, संकेतक और वितरित अनुरेखण।

रूपरेखा

कुछ मामलों में, प्रदर्शन समस्याओं का निदान करने के लिए, उत्पादन में आवेदन प्रोफाइलिंग का उपयोग करना आवश्यक है। समर्थित भाषाओं और रनटाइम्स के आधार पर, प्रोफाइलिंग एक काफी सरल प्रक्रिया हो सकती है, जिसमें कोड की केवल एक पंक्ति को शामिल करना शामिल है ( import _ "net/http/pprof" गो के मामले में)। दूसरी ओर, इसे कई उपकरणों के उपयोग की आवश्यकता हो सकती है या ब्लैक बॉक्स विधि द्वारा प्रक्रिया का परीक्षण करने और लौ जैसे उपकरण का उपयोग करके परिणामों की जांच करने की आवश्यकता हो सकती है।

टी परीक्षण

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

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

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

पहले, इस तरह के डिबगिंग imgix में अपेक्षाकृत दुर्लभ थे, लेकिन फिर भी उनका उपयोग किया जाता था, खासकर जब यह डीबगिंग अनुप्रयोगों के साथ समस्याओं के बारे में आया जो देरी के लिए संवेदनशील हैं।

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

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

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

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

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

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

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

मैं 400 त्रुटियों पर लौट आया: त्रुटि के साथ अभी भी एक समस्या थी, जिसे पता लगाने में लगभग दो घंटे लग गए। पुस्तकालय को बदलना, जाहिर है, समस्या का समाधान नहीं हुआ, लेकिन मुझे यकीन था कि चयनित पुस्तकालय पर्याप्त विश्वसनीय था। पसंद की गिरावट का एहसास नहीं, मैंने कुछ भी नहीं बदला। स्थिति का अधिक विस्तार से अध्ययन करने के बाद, मैंने महसूस किया कि सही मान एकल-वर्ण शीर्षलेख में संग्रहीत किया गया था (उदाहरण के लिए, "h: 12345")। यह आखिरकार मुझ पर चढ़ा कि एच कंटेंट-लेंडिंग हेडर का अनुगामी चरित्र था। डेटा को फिर से देखने पर, मुझे महसूस हुआ कि कंटेंट-लेंथ हेडर खाली था।

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


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

अराजकता इंजीनियरिंग दृष्टिकोण

कैओस इंजीनियरिंग एक वितरित प्रणाली पर प्रयोगों के आधार पर एक दृष्टिकोण है ताकि उत्पादन पर्यावरण की अराजक स्थितियों का सामना करने की क्षमता की पुष्टि की जा सके।

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

"अराजक परीक्षण" शब्द निम्नलिखित तकनीकों को संदर्भित करता है:

• यह निर्धारित करने के लिए मनमाना नोड्स को अक्षम करें कि सिस्टम विफलता के लिए कितना प्रतिरोधी है;
• त्रुटियों की शुरुआत करना (उदाहरण के लिए, देरी बढ़ाना) यह पुष्टि करने के लिए कि सिस्टम उन्हें सही ढंग से संसाधित करता है;
• सेवा की प्रतिक्रिया का निर्धारण करने के लिए नेटवर्क का मजबूर उल्लंघन।

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

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

निष्कर्ष

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

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