रक्षा QA की अंतिम सीमा: स्वचालित त्रुटि का पता लगाना

नमस्ते! मेरा नाम असखत नुरेव है, मैं डीआईएनएस में एक प्रमुख ऑटोमेशन इंजीनियर हूं।

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

इस लेख में मैं बताऊंगा:

• क्या होगा अगर कीड़े पहले से ही उत्पादन में लीक हो गए हैं?
• सिस्टम की गुणवत्ता के लिए प्रतिस्पर्धा कैसे करें, यदि आप अपने हाथों से त्रुटियों की गणना नहीं कर सकते हैं और अपनी आँखों को संशोधित नहीं करते हैं?
• स्वचालित त्रुटि से निपटने में क्या नुकसान हैं?
• क्वेरी आंकड़ों के विश्लेषण से मुझे क्या बोनस मिल सकता है?

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

प्रणाली, जिसके विकास में हम भाग लेते हैं, 2 मिलियन सक्रिय उपयोगकर्ताओं की सेवा करता है और प्रति दिन 275 मिलियन से अधिक अनुरोध करता है। मैं जिस टीम में काम कर रहा हूं वह एपीआई विकसित कर रही है।
सिस्टम में एक जटिल एपीआई है। इसके साथ, आप एसएमएस भेज सकते हैं, कॉल कर सकते हैं, वीडियो कॉन्फ्रेंस कर सकते हैं, अकाउंट सेट कर सकते हैं और यहां तक ​​कि फैक्स भी भेज सकते हैं (हैलो, 2019)। एक सरलीकृत रूप में, सेवाओं की परस्पर क्रिया की योजना कुछ इस तरह दिखती है। मैं मजाक नहीं कर रहा हूं।



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

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

स्वचालन

निश्चित रूप से, हमने समझना शुरू किया और देखा कि उस त्रुटि को ठीक करने में लगने वाले 90% समय को उस पर जानकारी एकत्र करने में खर्च किया जाता है। यहाँ वास्तव में क्या है:

• अन्य विभागों से गायब जानकारी प्राप्त करें।
• सर्वर लॉग की जाँच करें।
• हमारे सिस्टम के व्यवहार की जांच करें।
• समझें कि क्या यह या वह प्रणाली व्यवहार त्रुटिपूर्ण है।

और केवल शेष 10% हमने सीधे विकास पर खर्च किया।

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

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

तैयार समाधान

सबसे पहले, हमने यह देखने का फैसला किया कि बाजार में पहले से ही समान प्रणालियों में से कौन सा है। यह पता चला कि उनमें से बहुत सारे हैं। आप रेगन, संतरी, एयरब्रेक को उजागर कर सकते हैं, अन्य सेवाएं हैं।
लेकिन उनमें से एक भी हमारे अनुकूल नहीं है, और यहाँ क्यों है:

• कुछ सेवाओं के लिए हमें मौजूदा अवसंरचना में बहुत बड़े परिवर्तन करने की आवश्यकता है, जिसमें सर्वर पर परिवर्तन भी शामिल हैं। Airbrake.io को दर्जनों, सैकड़ों सिस्टम घटकों को परिष्कृत करना होगा।
• दूसरों ने हमारी अपनी गलतियों के बारे में डेटा एकत्र किया और उन्हें कहीं ओर भेज दिया। हमारी सुरक्षा नीति इसकी अनुमति नहीं देती है - उपयोगकर्ता और त्रुटि डेटा हमारे साथ रहना चाहिए।
• वैसे ये काफी महंगे भी होते हैं।

हम अपना करते हैं

यह स्पष्ट हो गया कि हमें अपनी सेवा करनी चाहिए, खासकर जब से हमने पहले ही इसके लिए एक बहुत अच्छा बुनियादी ढांचा बना लिया था:

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

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

सिस्टम के पहले संस्करण ने क्वेरी निष्पादन लॉग एकत्र किए, जो सभी स्टैक निशान पैदा हुए, उपयोगकर्ता डेटा और बग को ट्रैकर में डाल दिया, हमारे मामले में यह JIRA था।

टेस्ट रन के ठीक बाद, हमने देखा कि सिस्टम एक महत्वपूर्ण संख्या में डुप्लिकेट त्रुटियां बनाता है। हालांकि, इन डुप्लिकेट के बीच, कई में लगभग समान स्टैक निशान थे।

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

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

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

और उसके बाद व्यावहारिक रूप से कोई डुप्लिकेट नहीं थे। हालाँकि, कई अद्वितीय त्रुटियाँ पाई गईं।

अगला चरण यह समझना है कि त्रुटियों को कैसे प्राथमिकता दी जाए, उनमें से कौन सा पहले तय किया जाना चाहिए। हमने प्राथमिकता दी:

• त्रुटि की आवृत्ति।
• उपयोगकर्ताओं की संख्या वह चिंतित है।

एकत्रित आंकड़ों के आधार पर, हमने साप्ताहिक रिपोर्ट प्रकाशित करना शुरू किया। वे इस तरह दिखते हैं:



या, उदाहरण के लिए, प्रति सप्ताह शीर्ष 10 गलतियाँ। दिलचस्प है, जीरा में इन 10 बगों में 90% सेवा त्रुटियों का कारण था:



हमने डेवलपर्स और टीम लीडर्स को ऐसी रिपोर्ट भेजी।
सिस्टम शुरू करने के कुछ महीने बाद, समस्याओं की संख्या काफी कम हो गई। यहां तक ​​कि हमारे छोटे MVP (न्यूनतम व्यवहार्य उत्पाद) ने त्रुटियों को बेहतर ढंग से सुलझाने में मदद की।

समस्या

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

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

और हमने एक और विकास यात्रा करने का फैसला किया।

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



और इसलिए - व्यक्तिगत सेवाओं में त्रुटियां।



हम जिम्मेदार इंजीनियरिंग टीमों के लिए एस्केलेशन के साथ ट्रिगर भी खराब कर देते हैं - मामले में बहुत सारी त्रुटियां हैं। हम हर 30 मिनट में एक बार डेटा संग्रह भी सेट करते हैं (दिन में एक बार के बजाय, पहले की तरह)।
हमारे सिस्टम की प्रक्रिया इस तरह दिखाई देने लगी:

ग्राहक गलतियाँ

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

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

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

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

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



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

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

ऐसे प्रत्येक आवेदन के लिए, हम:

• हम JIRA में एक कार्य बनाते हैं।
• हम इन्फ्लक्स में आंकड़े दर्ज करते हैं।
• हम त्रुटियों की संख्या में तेज वृद्धि की स्थिति में सर्जिकल हस्तक्षेप के लिए ट्रिगर तैयार कर रहे हैं।

क्लाइंट त्रुटियों के साथ काम करने की प्रणाली इस तरह दिखती है:



सप्ताह में एक बार हम त्रुटियों की संख्या से शीर्ष 10 सबसे खराब अनुप्रयोगों से रिपोर्ट एकत्र करते हैं।

पकड़ना नहीं है, लेकिन चेतावनी देना

इसलिए, हमने सीखा कि उत्पादन प्रणाली में त्रुटियों को कैसे सीखा जाए, सर्वर त्रुटियों और क्लाइंट त्रुटियों दोनों के साथ कैसे काम किया जाए। सब कुछ ठीक लगता है, लेकिन ...

लेकिन वास्तव में, हम बहुत देर से जवाब देते हैं - कीड़े पहले से ही उपयोगकर्ताओं को प्रभावित करते हैं!

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

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

लेकिन एक और बाधा है - Hadoop इन वातावरणों से डेटा एकत्र नहीं करता है! हम त्रुटियों का पता लगाने के लिए एक ही विधि का उपयोग नहीं कर सकते हैं; हमें एक अलग डेटा स्रोत की तलाश करने की आवश्यकता है।

एक छोटी खोज के बाद, हमने आंकड़ों की स्ट्रीमिंग को संसाधित करने का निर्णय लिया, उस कतार से डेटा को पढ़ना जिसमें हमारी सेवाएं Hadoop में स्थानांतरण के लिए लिखती हैं। यह अद्वितीय त्रुटियों को जमा करने और बैचों में संसाधित करने के लिए पर्याप्त था, उदाहरण के लिए, हर 30 मिनट में एक बार। डेटा को वितरित करने वाली एक कतार प्रणाली को स्थापित करना आसान है - जो कुछ बचा था वह रसीद और प्रसंस्करण को परिष्कृत करने के लिए था।

हमने यह देखना शुरू किया कि त्रुटियों का पता लगाने के बाद कैसा व्यवहार होता है। यह पता चला कि अधिकांश त्रुटियां मिलीं और ठीक नहीं हुईं, बाद में उत्पादन में दिखाई दीं। इसलिए, हम उन्हें सही तरीके से ढूंढते हैं।

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

आगे क्या है

बेशक, हम वहाँ नहीं रुकेंगे और त्रुटियों को खोजने और ट्रैक करने की प्रणाली में सुधार करना जारी रखेंगे। हमारे पास योजनाएं हैं:

• अधिक एपीआई त्रुटियों का विश्लेषण।
• कार्यात्मक परीक्षणों के साथ एकीकरण।
• हमारे सिस्टम में घटनाओं की जांच के लिए अतिरिक्त सुविधाएँ।

लेकिन अगली बार उससे ज्यादा।