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

स्रोत

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

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

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

"समस्याको ढाँचा"

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

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

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

कार्य दुई भागमा विभाजित छ:

• परीक्षण चरणमा सम्मेलनहरूको गुणस्तर नियन्त्रण (कम-गुणस्तरको सम्मेलनहरू समात्ने प्रक्रियालाई स्वचालित गर्न);
• उत्पादन वातावरणमा सफ्टवेयर गुणस्तर नियन्त्रण (समस्याहरूको स्वचालित पत्ता लगाउने संयन्त्र र तिनीहरूको आत्म-उपचारको लागि सम्भावित परिदृश्यहरू)।

निगरानी र मेट्रिक्स सङ्कलन लागि उपकरण

निर्धारित लक्ष्यहरू प्राप्त गर्नको लागि, CI/CD पाइपलाइनको विभिन्न चरणहरूमा समस्याहरू पत्ता लगाउन र तिनीहरूलाई स्वचालन प्रणालीहरूमा स्थानान्तरण गर्न सक्ने निगरानी प्रणाली आवश्यक छ। यो पनि सकारात्मक कुरा हुनेछ यदि यस प्रणालीले विभिन्न टोलीहरूको लागि उपयोगी मेट्रिक्स प्रदान गर्दछ: विकास, परीक्षण, सञ्चालन। र यो एकदम राम्रो छ यदि यो व्यवसायको लागि पनि हो।

मेट्रिक्स सङ्कलन गर्न, तपाईंले विभिन्न प्रणालीहरूको सेट प्रयोग गर्न सक्नुहुन्छ (प्रोमेथियस, ELK स्ट्याक, Zabbix, आदि), तर, मेरो विचारमा, APM-वर्ग समाधानहरू यी कार्यहरूका लागि उपयुक्त छन् (अनुप्रयोग प्रदर्शन अनुगमन), जसले तपाईको जीवनलाई धेरै सरल बनाउन सक्छ।

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

स्रोत। प्रणाली घटकहरू बीच सबै निर्भरताहरूको स्वचालित निर्माण

स्रोत। स्वचालित पत्ता लगाउने र सेवा सञ्चालन मार्ग निर्माण

हामी यो पनि सम्झन्छौं कि हामीले विभिन्न स्वचालन उपकरणहरूसँग एकीकृत गर्न आवश्यक छ। यहाँ समाधानसँग एक सुविधाजनक API छ जसले तपाईंलाई विभिन्न मेट्रिक्स र घटनाहरू पठाउन र प्राप्त गर्न अनुमति दिन्छ।

अर्को, Dynatrace प्रणाली प्रयोग गरेर यी समस्याहरू कसरी समाधान गर्ने भन्ने बारे थप विस्तृत हेराइमा जाऔं।

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

पहिलो चुनौती भनेको एप्लिकेसन डेलिभरी पाइपलाइनमा सकेसम्म चाँडो समस्याहरू फेला पार्नु हो। केवल "राम्रो" कोड निर्माण उत्पादनमा पुग्नु पर्छ। यो गर्नको लागि, परीक्षण चरणमा तपाईंको पाइपलाइनमा तपाईंको सेवाहरूको गुणस्तर जाँच गर्न अतिरिक्त मोनिटरहरू समावेश गर्नुपर्छ।

यसलाई कसरी कार्यान्वयन गर्ने र यस प्रक्रियालाई स्वचालित बनाउने भनेर चरण-दर-चरण हेरौं:

स्रोत

चित्रले स्वचालित सफ्टवेयर गुणस्तर परीक्षण चरणहरूको प्रवाह देखाउँछ:

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

चरण 1. अनुगमन प्रणाली को तैनाती

पहिले, तपाईंले आफ्नो परीक्षण वातावरणमा एजेन्टहरू स्थापना गर्न आवश्यक छ। Dynatrace मा एउटा राम्रो सुविधा छ: यसले एक विश्वव्यापी एजेन्ट, OneAgent प्रयोग गर्दछ, जुन OS उदाहरणमा स्थापना गरिएको छ (Windows, Linux, AIX), स्वचालित रूपमा तपाईंका सेवाहरू पत्ता लगाउँछ र तिनीहरूमा अनुगमन डेटा सङ्कलन गर्न थाल्छ। तपाईंले प्रत्येक प्रक्रियाको लागि छुट्टै एजेन्ट कन्फिगर गर्नुपर्दैन। क्लाउड र कन्टेनर प्लेटफर्महरूमा पनि यही कुरा लागू हुन्छ। तपाईं एजेन्ट स्थापना प्रक्रियालाई स्वचालित पनि गर्न सक्नुहुन्छ। Dynatrace "कोडको रूपमा पूर्वाधार" अवधारणामा पूर्ण रूपमा फिट हुन्छ (कोड वा IaC को रूपमा पूर्वाधार): त्यहाँ सबै लोकप्रिय प्लेटफर्महरूको लागि तयार स्क्रिप्ट र निर्देशनहरू छन्। तपाईंले एजेन्टलाई आफ्नो सेवाको कन्फिगरेसनमा इम्बेड गर्नुहुन्छ, र जब तपाईंले यसलाई प्रयोग गर्नुहुन्छ, तपाईंले तुरुन्तै पहिले नै कार्यरत एजेन्टसँग नयाँ सेवा प्राप्त गर्नुहुन्छ।

चरण 2: तपाईंको सफ्टवेयर गुणस्तर घटनाहरू परिभाषित गर्नुहोस्

अब तपाईंले सेवा र व्यापार सञ्चालनहरूको सूचीमा निर्णय गर्न आवश्यक छ। यो खातामा ती प्रयोगकर्ता अपरेसनहरू लिनु महत्त्वपूर्ण छ जुन तपाईंको सेवाको लागि व्यापार महत्त्वपूर्ण छ। यहाँ म व्यापार र प्रणाली विश्लेषकहरूसँग परामर्श सिफारिस गर्दछु।

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

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

यस्तो JSON फाइलको उदाहरण हेरौं। Dynatrace API बाट वस्तुहरू कुञ्जी/मान जोडीको रूपमा प्रयोग गरिन्छ (एपीआई विवरण यहाँ फेला पार्न सकिन्छ Dynatrace API).

{
    "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: लोड जेनेरेसन

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

Dynatrace को निगरानी प्रणालीले तपाइँलाई तपाइँको परीक्षणहरूबाट विभिन्न मेटाडेटाहरू खिच्न र कुन परीक्षणहरू कुन रिलीज चक्र र कुन सेवा हो भनेर पहिचान गर्न अनुमति दिन्छ। HTTP परीक्षण अनुरोधहरूमा थप हेडरहरू थप्न सिफारिस गरिन्छ।

निम्न चित्रले एउटा उदाहरण देखाउँछ जहाँ, अतिरिक्त हेडर X-Dynatrace-Test प्रयोग गरेर, हामी संकेत गर्छौं कि यो परीक्षण कार्टमा वस्तु थप्ने कार्यको परीक्षणसँग सम्बन्धित छ।

स्रोत

जब तपाइँ प्रत्येक लोड परीक्षण चलाउनुहुन्छ, तपाइँ CI/CD सर्भरबाट घटना API प्रयोग गरेर Dynatrace मा अतिरिक्त प्रासंगिक जानकारी पठाउनुहुन्छ। यस तरिकाले, प्रणालीले विभिन्न परीक्षणहरू बीच फरक गर्न सक्छ।

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

चरण 4-5। प्रदर्शन डाटा सङ्कलन र CI/CD प्रणालीमा डाटा स्थानान्तरण

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

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

हाम्रो उदाहरणमा, गुणस्तर जाँच घटना भनिन्छ perfSigDynatraceReport (कार्यसम्पादन_हस्ताक्षर) - यो तयार छ प्लगइन जेन्किन्ससँग एकीकरणको लागि, जुन T-Systems Multimedia Solutions बाट केटाहरू द्वारा विकसित गरिएको थियो। प्रत्येक परीक्षण प्रक्षेपण घटनाले सेवा, निर्माण नम्बर, र परीक्षण समय बारे जानकारी समावेश गर्दछ। प्लगइनले निर्माण समयमा प्रदर्शन मानहरू सङ्कलन गर्दछ, तिनीहरूलाई मूल्याङ्कन गर्दछ, र अघिल्लो निर्माणहरू र गैर-कार्यात्मक आवश्यकताहरूसँग परिणाम तुलना गर्दछ।

निर्माण गुणस्तर जाँच सुरु गर्ने बारे अनुगमन प्रणालीमा घटना। स्रोत

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

CI/CD सर्भरमा विधानसभाहरूमा तथ्याङ्कको नतिजा। स्रोत

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

CI/CD सर्भरमा विधानसभाहरूमा विस्तृत तथ्याङ्कहरू हेर्नुहोस्। स्रोत

दुई विधानसभाहरूको विस्तृत तुलना

यदि आवश्यक छ भने, तपाइँ Dynatrace इन्टरफेसमा जान सक्नुहुन्छ र त्यहाँ तपाइँ तपाइँको प्रत्येक निर्माण को लागी तथ्याङ्कहरू थप विवरणमा हेर्न सक्नुहुन्छ र तिनीहरूलाई एक अर्कासँग तुलना गर्न सक्नुहुन्छ।

Dynatrace मा निर्माण तथ्याङ्क को तुलना। स्रोत
 
निष्कर्ष

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

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

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

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

यसो गर्नको लागि, हामीले अघिल्लो खण्डसँग समानता गरेर, उत्पादन वातावरणमा स्वचालित सफ्टवेयर गुणस्तर जाँचहरू प्रदान गर्न र प्रणाली आत्म-उपचारको लागि परिदृश्यहरूमा आधारित गर्न आवश्यक छ।

कोडको रूपमा स्वतः सच्याउनुहोस्

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

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

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

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

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

पहिलो, त्यहाँ अनुप्रयोग सञ्चालनको सर्तमा प्रदर्शनसँग सम्बन्धित सबै कुरा छ। समाधानले विभिन्न स्तरहरूमा सयौं मेट्रिक्स प्रदान गर्दछ जुन तपाईंले ट्रिगरहरूको रूपमा प्रयोग गर्न सक्नुहुन्छ:

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

Dynatrace मा निगरानी स्तर। स्रोत

दोस्रो, मैले पहिले भनेझैं, Dynatrace सँग खुला API छ, जसले विभिन्न तेस्रो-पक्ष प्रणालीहरूसँग एकीकृत गर्न धेरै सजिलो बनाउँछ। उदाहरणका लागि, नियन्त्रण प्यारामिटरहरू नाघिँदा स्वचालन प्रणालीमा सूचना पठाउँदै।

तल Ansible संग अन्तरक्रिया को लागी एक उदाहरण छ।

स्रोत

तल म कस्तो प्रकारको स्वचालन गर्न सकिन्छ भन्ने केही उदाहरणहरू दिनेछु। यो केसहरूको मात्र एक अंश हो; तपाईंको वातावरणमा तिनीहरूको सूची तपाईंको कल्पना र तपाईंको निगरानी उपकरणहरूको क्षमताले मात्र सीमित हुन सक्छ।

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

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

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

परिनियोजन पछि सञ्चालन कार्यसम्पादनको ह्रास। स्रोत

2. 100% मा संसाधन लोड गर्दै - रूटिङमा नोड थप्नुहोस्

निम्न उदाहरणमा, अनुगमन प्रणालीले निर्धारण गर्छ कि कम्पोनेन्टहरू मध्ये एकले १००% CPU लोड अनुभव गरिरहेको छ।

CPU लोड 100%
 
यस घटनाको लागि धेरै फरक परिदृश्यहरू सम्भव छन्। उदाहरणका लागि, अनुगमन प्रणालीले थप रूपमा जाँच गर्दछ कि स्रोतहरूको अभाव सेवामा लोडमा वृद्धिसँग सम्बन्धित छ कि छैन। यदि त्यसो हो भने, त्यसपछि स्क्रिप्ट निष्पादित हुन्छ जसले स्वचालित रूपमा रूटिङमा नोड थप्छ, जसले गर्दा प्रणालीको समग्र रूपमा कार्यक्षमता पुनर्स्थापित हुन्छ।

घटना पछि मापन

3. हार्ड ड्राइभमा ठाउँको अभाव - डिस्क सफाई

मलाई लाग्छ कि धेरै व्यक्तिहरूले पहिले नै यी प्रक्रियाहरू स्वचालित गरिसकेका छन्। APM प्रयोग गरेर, तपाइँ डिस्क सबसिस्टममा खाली ठाउँको पनि निगरानी गर्न सक्नुहुन्छ। यदि त्यहाँ कुनै ठाउँ छैन वा डिस्क बिस्तारै चलिरहेको छ भने, हामी यसलाई सफा गर्न वा स्पेस थप्नको लागि स्क्रिप्ट कल गर्छौं।

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

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

सफ्टवेयर शाखाहरू बीच स्विच गरेपछि रूपान्तरण दर घट्छ। स्रोत

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

अन्तमा, म तपाईंलाई किन Dynatrace सबैभन्दा धेरै मन पराउँछु भन्ने अर्को उदाहरण दिनेछु।

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

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

कम्पोनेन्टहरू बीचको निर्भरताहरू स्वचालित रूपमा विश्लेषण गरेर, Dynatrace समस्याग्रस्त सेवा मूल कारण हो कि होइन, तर अन्य सेवाहरूमा यसको निर्भरता पनि निर्धारण गर्दछ। तलको उदाहरणमा, Dynatrace ले लेनदेन कार्यान्वयन भित्र प्रत्येक सेवाको स्वास्थ्यको स्वतः अनुगमन र मूल्याङ्कन गर्दछ, Golang सेवालाई मूल कारणको रूपमा पहिचान गर्दछ।

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

तलको आंकडाले घटनाको सुरुदेखि नै तपाइँको आवेदनको साथ समस्याहरूको अनुगमन गर्ने प्रक्रिया देखाउँछ।

तिनीहरूमा सबै घटक र घटनाहरूको प्रदर्शनको साथ एक उभरिरहेको समस्याको दृश्य

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

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

निष्कर्षमा

नतिजाको रूपमा, हामीले पाइपलाइनमा निर्मित स्वचालित सफ्टवेयर गुणस्तर जाँचको साथ CI/CD पाइपलाइनको साथ समाप्त गर्यौं। हामी कम-गुणस्तरको एसेम्बलीहरूको संख्या कम गर्छौं, समग्र रूपमा प्रणालीको विश्वसनीयता बढाउँछौं, र यदि हाम्रो प्रणाली अझै असफल भयो भने, हामी यसलाई पुनर्स्थापना गर्न संयन्त्रहरू सुरू गर्छौं।

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

मलाई आशा छ कि मेरा उदाहरणहरूले तपाईंको प्रयासहरूमा मद्दत गर्नेछ। म पनि आत्म-उपचार प्रणाली लागू गर्न प्रयोग गरिने मेट्रिक्स को उदाहरणहरू हेर्न इच्छुक हुनेछु।

स्रोत

स्रोत: www.habr.com