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

स्रोत

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

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


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

"समस्या का बयान"

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

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

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

कार्य को दो घटकों में विभाजित किया गया है:

• परीक्षण चरण में विधानसभाओं की गुणवत्ता नियंत्रण (घटिया विधानसभाओं को पकड़ने की प्रक्रिया को स्वचालित करने के लिए);
• उत्पादन वातावरण में सॉफ्टवेयर गुणवत्ता नियंत्रण (स्व-उपचार के लिए स्वचालित समस्या का पता लगाने वाले तंत्र और संभावित परिदृश्य)।

मैट्रिक्स की निगरानी और संग्रह के लिए उपकरण

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

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

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

स्रोत । सिस्टम घटकों के बीच सभी निर्भरता का स्वचालित निर्माण

स्रोत । सेवा के संचालन के लिए एक पथ का स्वचालित पता लगाना और निर्माण

यह भी याद रखें कि हमें विभिन्न स्वचालन उपकरणों के साथ एकीकृत करने की आवश्यकता है। यहां समाधान में एक सुविधाजनक एपीआई है जो आपको विभिन्न मैट्रिक्स और घटनाओं को भेजने और प्राप्त करने की अनुमति देता है।

अगला, हम डायनाट्रेस प्रणाली का उपयोग करके कार्यों को हल करने के तरीके के बारे में अधिक विस्तृत चर्चा करेंगे।

कार्य 1. परीक्षण चरण में विधानसभाओं की गुणवत्ता नियंत्रण का स्वचालन

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



आइए चरणों को देखें कि इसे कैसे लागू करें और इस प्रक्रिया को स्वचालित करें:

स्रोत

आंकड़ा स्वचालित सॉफ्टवेयर गुणवत्ता नियंत्रण चरणों के प्रवाह को दर्शाता है:

1. एक निगरानी प्रणाली (एजेंटों की स्थापना) की तैनाती;
2. आपके सॉफ़्टवेयर की गुणवत्ता के आकलन की घटनाओं की परिभाषा (मीट्रिक और सीमा मूल्य) और निगरानी प्रणाली में उनका स्थानांतरण;
3. लोड पीढ़ी और प्रदर्शन परीक्षण;
4. एक निगरानी प्रणाली में प्रदर्शन और उपलब्धता डेटा एकत्र करना;
5. मॉनिटरिंग सिस्टम से CI / CD सिस्टम में सॉफ़्टवेयर गुणवत्ता मूल्यांकन घटनाओं के आधार पर परीक्षण डेटा स्थानांतरित करना। स्वचालित विधानसभा विश्लेषण।

चरण 1. एक निगरानी प्रणाली तैनात करें

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

चरण 2. अपने सॉफ़्टवेयर गुणवत्ता मूल्यांकन घटनाओं को पहचानें

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

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

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

आइए ऐसी JSON फ़ाइल के एक उदाहरण को देखें। डायनाट्रेस एपीआई से वस्तुओं को एक कुंजी / मूल्य जोड़ी के रूप में उपयोग किया जाता है ( एपीआई के वर्णन के लिए डायनाट्रेस एपीआई देखें)।

{    "timeseries": [    {      "timeseriesId": "service.ResponseTime",      "aggregation": "avg",      "tags": "Frontend",      "severe": 250000,      "warning": 1000000    },    {      "timeseriesId": "service.ResponseTime ",      "aggregation": "avg",      "tags": "Backend",      "severe": 4000000,      "warning": 8000000    },    {      "timeseriesId": "docker.Container.Cpu",      "aggregation": "avg",      "severe": 50,      "warning": 70    }  ] } 

फ़ाइल समय सारणी परिभाषा की एक सरणी है:

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

निम्नलिखित आंकड़ा ऐसे ट्रैशहोल्ड का उपयोग करने का एक उदाहरण दिखाता है।

स्रोत

चरण 3. लोड जनरेशन

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

डायनाट्रेस मॉनिटरिंग सिस्टम आपको अपने परीक्षणों से विभिन्न मेटाडेटा को पकड़ने और यह पहचानने की अनुमति देता है कि कौन सा परीक्षण चक्र और सेवा से संबंधित है। यह अनुशंसा की जाती है कि आप HTTP अनुरोधों के परीक्षण में अतिरिक्त हेडर जोड़ें।

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

स्रोत

जब आप प्रत्येक लोड परीक्षण चलाते हैं, तो आप CI / CD सर्वर से इवेंट API का उपयोग करके डायनाट्रेस को अतिरिक्त प्रासंगिक जानकारी भेजते हैं। इस प्रकार, सिस्टम आपस में विभिन्न परीक्षणों के बीच अंतर कर सकता है।

स्रोत । लोडिंग परीक्षण के शुभारंभ के बारे में निगरानी प्रणाली में घटना

स्टेप 4-5। प्रदर्शन डेटा एकत्र करें और डेटा को CI / CD सिस्टम में स्थानांतरित करें

जनरेट किए गए परीक्षण के साथ, एक घटना निगरानी प्रणाली को प्रेषित की जाती है जो सेवा गुणवत्ता संकेतकों की जांच करने पर डेटा एकत्र करने की आवश्यकता के बारे में बताती है। हमारी JSON फ़ाइल भी इंगित की जाती है, जिसमें प्रमुख मीट्रिक परिभाषित किए गए हैं।

मॉनिटरिंग सिस्टम को भेजने के लिए CI / CD सर्वर पर उत्पन्न सॉफ्टवेयर की गुणवत्ता को सत्यापित करने की आवश्यकता के बारे में एक घटना

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

असेंबली गुणवत्ता नियंत्रण की शुरुआत के बारे में निगरानी प्रणाली में घटना। स्रोत

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

सीआई / सीडी सर्वर पर विधानसभा के आंकड़ों का परिणाम। स्रोत

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

CI / CD सर्वर पर विस्तृत विधानसभा आँकड़े देखें। स्रोत

दो विधानसभाओं की विस्तृत तुलना

यदि आवश्यक हो, तो आप डायनाट्रेस इंटरफ़ेस पर जा सकते हैं और अपनी प्रत्येक असेंबलियों के आंकड़ों पर अधिक विस्तार से देख सकते हैं और उनकी एक-दूसरे से तुलना कर सकते हैं।

डायनाट्रेस में विधानसभा के आंकड़ों की तुलना। स्रोत

निष्कर्ष

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

कार्य 2. उत्पादन वातावरण में सॉफ्टवेयर गुणवत्ता नियंत्रण का स्वचालन

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

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

ऐसा करने के लिए, हम, पिछले अनुभाग के साथ समानता से, उत्पादन वातावरण में स्वचालित सॉफ्टवेयर गुणवत्ता जांच प्रदान करते हैं और उनके तहत सिस्टम के आत्म-चिकित्सा के लिए स्क्रिप्ट देते हैं।


कोड के रूप में ऑटो फिक्स

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

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

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

आपकी निगरानी प्रणाली से कोई भी मीट्रिक स्क्रिप्ट चलाने के लिए एक ट्रिगर के रूप में कार्य कर सकता है, मुख्य बात यह है कि ये मीट्रिक सटीक रूप से निर्धारित करते हैं कि सब कुछ खराब है, क्योंकि मैं एक उत्पादक वातावरण में झूठी सकारात्मकता नहीं प्राप्त करना चाहूंगा।

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

सबसे पहले, वहाँ सब कुछ है कि आवेदन के मामले में operability से संबंधित है। समाधान विभिन्न स्तरों पर सैकड़ों मैट्रिक्स प्रदान करता है जिन्हें आप ट्रिगर के रूप में उपयोग कर सकते हैं:

• उपयोगकर्ता स्तर (ब्राउज़र, मोबाइल एप्लिकेशन, IoT डिवाइस, उपयोगकर्ता व्यवहार, रूपांतरण, आदि);
• सेवा और संचालन का स्तर (प्रदर्शन, उपलब्धता, त्रुटियां, आदि);
• अनुप्रयोग अवसंरचना स्तर (होस्ट OS मेट्रिक्स, JMX, MQ, वेब-सर्वर, आदि);
• मंच स्तर (वर्चुअलाइजेशन, क्लाउड, कंटेनर, आदि)।

डायनाट्रेस में निगरानी के स्तर। स्रोत

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

नीचे Ansible के साथ बातचीत करने के लिए एक उदाहरण है।

स्रोत

नीचे मैं बिल्कुल कुछ उदाहरण दूंगा कि कौन सा स्वचालन किया जा सकता है। यह केवल मामलों का हिस्सा है, उन्हें आपके वातावरण में सूचीबद्ध करना केवल आपकी कल्पना और आपके निगरानी उपकरणों की क्षमताओं तक सीमित हो सकता है।

1. खराब तैनाती - संस्करण रोलबैक

यहां तक ​​कि अगर हम सभी एक परीक्षण वातावरण में बहुत अच्छी तरह से परीक्षण करते हैं, तो अभी भी एक मौका है कि एक नई रिलीज आपके आवेदन को पर्यावरण के वातावरण में मार सकती है। वही मानव कारक को रद्द नहीं किया गया है।

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

तैनाती के बाद प्रदर्शन में गिरावट। स्रोत

2. संसाधन 100% पर लोड हो रहा है - रूटिंग में एक नोड जोड़ें

निम्नलिखित उदाहरण में, निगरानी प्रणाली निर्धारित करती है कि घटकों में से एक में 100% सीपीयू उपयोग है।

CPU उपयोग 100%

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

एक घटना के बाद स्केलिंग नोड्स

3. हार्ड ड्राइव स्पेस की कमी - डिस्क क्लीनअप

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


डिस्क लोडिंग 100%

4. कम उपयोगकर्ता गतिविधि या कम रूपांतरण - नीले और हरे रंग की शाखाओं के बीच स्विच करें

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

सॉफ्टवेयर शाखाओं के बीच स्विच करने के बाद रूपांतरण ड्रॉप। स्रोत

स्वचालित समस्या निर्धारण तंत्र

अंत में मैं एक और उदाहरण दूंगा, जिसके लिए मुझे डायनाट्रेस सबसे ज्यादा पसंद है।

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

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

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

विफलता का मूल कारण निर्धारित करने का एक उदाहरण। स्रोत

निम्न आंकड़ा आपके आवेदन के साथ समस्याओं की निगरानी की प्रक्रिया को घटना की शुरुआत से दिखाता है।

सभी घटकों और उन पर घटनाओं के प्रदर्शन के साथ एक उभरती हुई समस्या का दृश्य

निगरानी प्रणाली ने समस्या पर घटनाओं का एक पूरा कालक्रम तैयार किया है। समयरेखा के तहत विंडो में, हम प्रत्येक घटक पर सभी प्रमुख घटनाओं को देखते हैं। इन घटनाओं के आधार पर, आप कोड स्क्रिप्ट के रूप में स्वचालित सुधार के लिए प्रक्रियाओं को निर्दिष्ट कर सकते हैं।

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

निष्कर्ष

नतीजतन, हम पाइपलाइन में एकीकृत स्वचालित सॉफ्टवेयर गुणवत्ता जांच के साथ एक CI / CD पाइपलाइन के साथ समाप्त हो गए। हम खराब गुणवत्ता वाली असेंबली की संख्या को कम करते हैं, सिस्टम की विश्वसनीयता को संपूर्ण रूप से बढ़ाते हैं, और अगर हम अभी भी सिस्टम के प्रदर्शन को बाधित करते हैं, तो हम इसे पुनर्स्थापित करने के लिए तंत्र लॉन्च करते हैं।


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

मुझे आशा है कि मेरे उदाहरण आपके प्रयासों में आपकी सहायता करेंगे। स्व-उपचार प्रणाली के कार्यान्वयन के लिए प्रयुक्त मेट्रिक्स के आपके उदाहरणों को देखना मेरे लिए भी दिलचस्प होगा।

स्रोत