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

स्रोत

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

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

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

"समस्या का निरूपण"

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

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

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

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

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

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

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

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

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

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

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

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

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

कार्य 1. परीक्षण चरण में असेंबलियों के गुणवत्ता नियंत्रण का स्वचालन

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

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

स्रोत

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

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

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

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

चरण 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 परीक्षण अनुरोधों में अतिरिक्त हेडर जोड़ने की अनुशंसा की जाती है।

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

स्रोत

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

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

चरण 4-5. प्रदर्शन डेटा एकत्र करें और डेटा को सीआई/सीडी सिस्टम में स्थानांतरित करें

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

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

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

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

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

सीआई/सीडी सर्वर पर असेंबली पर आंकड़ों का परिणाम। स्रोत

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

सीआई/सीडी सर्वर पर असेंबली पर विस्तृत आँकड़े देखें। स्रोत

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

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

डायनाट्रेस में बिल्ड आँकड़ों की तुलना। स्रोत
 
निष्कर्ष

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

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

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

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

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

कोड के रूप में स्वत: सुधार

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

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

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

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

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

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

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

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

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

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

स्रोत

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

1. ख़राब परिनियोजन - संस्करण रोलबैक

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

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

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

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

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

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

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

3. हार्ड ड्राइव पर जगह की कमी - डिस्क की सफाई

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

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

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

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

स्वचालित समस्या का पता लगाने के लिए तंत्र

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

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

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

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

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

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

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

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

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

निष्कर्ष

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

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

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

स्रोत

स्रोत: www.habr.com