हामी Sportmaster को निगरानी गर्छौं - कसरी र के संग

हामीले उत्पादन टोलीहरू गठन गर्ने चरणमा अनुगमन प्रणाली सिर्जना गर्ने बारे सोच्यौं। यो स्पष्ट भयो कि हाम्रो व्यापार - शोषण - यी टोलीहरूमा पर्दैन। त्यो किन हो?

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

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

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

प्लेटफर्म जसमा हाम्रो अनलाइन स्टोरहरू सञ्चालन हुन्छन् यस्तो देखिन्छ:

• अगाडि
• मध्य कार्यालय
• ब्याक कार्यालय

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

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

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

अन्ततः, त्यस्ता भिन्न कथाहरूले सम्पूर्ण फ्रन्टएन्ड, प्रयोगकर्ताहरू र हाम्रो मुख्य व्यापार कार्यलाई असर गर्छ - अनलाइन बिक्री। हामी कुनै टोलीको हिस्सा होइनौं, तर अनलाइन स्टोरको भागको रूपमा सबै इकमर्स अनुप्रयोगहरूको सञ्चालनमा संलग्न भएकाले, हामीले इकमर्स प्लेटफर्मको लागि एक व्यापक अनुगमन प्रणाली सिर्जना गर्ने कार्यमा लाग्यौं।

प्रणाली संरचना र स्ट्याक

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

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

त्यसैले, तिनीहरूले हात्तीलाई टुक्रा टुक्रा खाने निर्णय गरे।

हाम्रो प्रणाली समावेश छ:

• हार्डवेयर;
• अपरेटिङ सिस्टम;
• सफ्टवेयर;
• अनुगमन अनुप्रयोगमा UI भागहरू;
• व्यापार मेट्रिक्स;
• एकीकरण आवेदन;
• सूचना सुरक्षा;
• नेटवर्कहरू;
• ट्राफिक ब्यालेन्सर।

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

त्यसोभए, स्ट्याकको बारेमा।

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

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

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

अन्य तहहरूका लागि डाटा स्रोतहरू, उदाहरणका लागि, व्यापार मेट्रिक्स, तीन घटकहरूमा विभाजित छन्।

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

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

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

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

अन्तमा, तेस्रो, डाटा स्रोत एक केन्द्रीकृत लगिङ प्रणाली हो। हामी लगहरूका लागि इलास्टिक स्ट्याक प्रयोग गर्छौं, र त्यसपछि हामी यो डाटालाई व्यापार मेट्रिक्सको लागि हाम्रो निगरानी प्रणालीमा तान्न सक्छौं। यी सबैका अतिरिक्त, हामीसँग पाइथनमा लेखिएको हाम्रो आफ्नै निगरानी API सेवा छ, जसले API मार्फत कुनै पनि सेवाहरू सोध्छ र तिनीहरूबाट Zabbix मा डाटा सङ्कलन गर्दछ।

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

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

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

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

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

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

सम्भावनाहरू

अब हामीसँग प्रणालीको कोर पूर्ण रूपमा तयार छ, तर त्यहाँ अझै धेरै चीजहरू छन् जसमा अझै काम गर्न आवश्यक छ। कम्तिमा, यो एक सूचना सुरक्षा तह हो, तर यो नेटवर्कमा पुग्न, सतर्कता विकास गर्न र सहसम्बन्धको समस्या समाधान गर्न पनि महत्त्वपूर्ण छ। हामीसँग धेरै तह र प्रणालीहरू छन्, र प्रत्येक तहमा त्यहाँ धेरै मेट्रिकहरू छन्। यो matryoshka को डिग्री मा matryoshka हुन जान्छ।

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

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

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

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

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

हामीले सञ्चालन गर्ने प्रणालीहरूको अनुगमन र हाम्रो पक्षमा महत्त्वपूर्ण मानिने मेट्रिकहरू सङ्कलन गर्नुको अतिरिक्त, अनुगमन प्रणालीले हामीलाई उत्पादन टोलीहरूको लागि डेटा सङ्कलन गर्न अनुमति दिन्छ। तिनीहरूले हामीले निगरानी गर्ने सूचना प्रणाली भित्र मेट्रिक्सको संरचनालाई प्रभाव पार्न सक्छ।

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

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

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

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

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

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

स्रोत: www.habr.com