इंजीनियरों को आवेदन की निगरानी के बारे में परवाह क्यों नहीं है?

सभी शुक्रवार के साथ! दोस्तों, आज हम DevOps प्रथाओं और उपकरण पाठ्यक्रम के लिए समर्पित प्रकाशनों की एक श्रृंखला जारी रखते हैं, क्योंकि पाठ्यक्रम पर नए समूह में कक्षाएं अगले सप्ताह के अंत में शुरू होंगी। तो चलिए शुरू करते है!



निगरानी आसान है । यह एक ज्ञात तथ्य है। नागेस को उठाएं, रिमोट सिस्टम पर एनआरपीई चलाएं, एनआरपीई टीसीपी पोर्ट 5666 पर नागोस को कॉन्फ़िगर करें और आपके पास निगरानी है।

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

(आमतौर पर वे PNP4Nagios, RRDtool और Thruk स्थापित करते हैं, स्लैक में सूचनाएँ सेट करते हैं और सीधे nagiosexchange पर जाते हैं, लेकिन अब इसे जाने देते हैं)।

अच्छी निगरानी वास्तव में काफी जटिल है, आपको वास्तव में आपके द्वारा देखे जा रहे एप्लिकेशन के इंटर्ल्स को जानना होगा।

निगरानी मुश्किल है?

कोई भी सर्वर, चाहे लिनक्स हो या विंडोज, किसी न किसी उद्देश्य से काम करेगा। Apache, Samba, Tomcat, फ़ाइल स्टोरेज, LDAP - ये सभी सेवाएँ कमोबेश एक या अधिक मामलों में विशिष्ट हैं। प्रत्येक का अपना कार्य है, अपनी विशेषताएं हैं। मैट्रिक्स, केपीआई (प्रमुख प्रदर्शन संकेतक) प्राप्त करने के लिए अलग-अलग तरीके हैं, आपके लिए दिलचस्प है जब सर्वर लोड हो रहा है।


Unsplash पर ल्यूक शतरंज द्वारा फोटो


(मैं चाहूंगा कि मेरे डैशबोर्ड को नीयन-नीले रंगों में चित्रित किया जाए - सपने को देखते हुए - ... हम्म ...)

कोई भी सॉफ़्टवेयर जो सेवाएं प्रदान करता है, उसके पास मैट्रिक्स एकत्रित करने के लिए एक तंत्र होना चाहिए। Apache में एक mod-status मॉड्यूल है जो सर्वर mod-status पेज को प्रदर्शित करता है। Nginx में stub_status । टॉमकैट में जेएमएक्स या विशेष वेब एप्लिकेशन हैं जो प्रमुख मीट्रिक दिखाते हैं। MySQL के पास कमांड "वैश्विक स्थिति दिखाएं", आदि हैं।
इसलिए डेवलपर्स अपने द्वारा बनाए गए अनुप्रयोगों में ऐसे तंत्र को एम्बेड नहीं करते हैं?

क्या डेवलपर्स केवल ऐसा करते हैं?

मैट्रिक्स को एम्बेड करने के प्रति उदासीनता का एक निश्चित स्तर डेवलपर्स तक सीमित नहीं है। मैंने उन कंपनियों में काम किया जहां मैंने टॉमकैट का उपयोग करके एप्लिकेशन विकसित किए और सामान्य टॉमकैट त्रुटि लॉग को छोड़कर मेरे किसी भी मेट्रिक्स, कोई सेवा गतिविधि लॉग का उत्पादन नहीं किया। कुछ डेवलपर्स लॉग की बहुतायत उत्पन्न करते हैं, जिसका अर्थ है कि सिस्टम व्यवस्थापक के लिए कुछ भी नहीं है, जो उन्हें सुबह 3:15 पर पढ़ने के लिए अशुभ था।


टिम Gouw द्वारा Unsplash पर पोस्ट किया गया

सिस्टम इंजीनियर जो ऐसे उत्पादों को जारी करने की अनुमति देते हैं, उनके पास स्थिति के लिए कुछ जिम्मेदारी भी होनी चाहिए। कुछ सिस्टम इंजीनियरों के पास इन मैट्रिक्स के संदर्भ और अनुप्रयोग गतिविधि के प्रकाश में उनकी व्याख्या करने की क्षमता के बिना लॉग से सार्थक मैट्रिक्स प्राप्त करने का प्रयास करने का समय और देखभाल है। कुछ समझ में नहीं आता कि इससे क्या लाभ हो सकता है, जैसे कि संकेतक के अलावा "कुछ वर्तमान में (या जल्द ही होगा) गलत है।"

मैट्रिक्स की आवश्यकता के बारे में सोच में बदलाव न केवल डेवलपर्स के बीच होना चाहिए, बल्कि सिस्टम इंजीनियरों के बीच भी होना चाहिए।

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

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

यह देवोपास बात है

डेवोप्स मानसिकता डेवलपर सोच (देव) और शोषण (ऑप्स) के तालमेल का वर्णन करती है। कोई भी कंपनी जो "देवोप्स" करने का दावा करती है:

1. यह कहने के लिए कि वे क्या करते हैं (फिल्म "राजकुमारी दुल्हन" के मेमे में एक संकेत - "मुझे नहीं लगता कि इसका मतलब यह है कि आपको लगता है कि इसका क्या मतलब है!")
2. निरंतर उत्पाद सुधार की स्थिति को बढ़ावा देना।

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

वाम शिफ्ट, बाएँ, मैं SAID, NOOOOOOOO-

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


NESA द्वारा मेकर्स द्वारा फोटो Unsplash पर

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

संक्षेप में

1. घोड़े को पानी में लाओ। डेवलपर्स को दिखाएं कि वे अपने लिए कितनी समस्याओं से बच सकते हैं, उन्हें अपने अनुप्रयोगों के लिए सही KPI और मैट्रिक्स की पहचान करने में मदद करें ताकि उत्पाद स्वामी से कम चिल्लाओ कि CTO चिल्ला रहा है। उन्हें प्रकाश में लाएं, धीरे और शांति से। यदि यह काम नहीं करता है, तो इन मेट्रिक्स को अनुप्रयोगों से जल्दी से प्राप्त करने के लिए उन्हें या उत्पाद के मालिक को रिश्वत, धमकी और राजी करें, और फिर चित्र बनाएं। यह मुश्किल होगा, क्योंकि इसे प्राथमिकता नहीं माना जाएगा, और उत्पाद रोडमैप में कार्यान्वयन की प्रतीक्षा में कई आय-सृजन परियोजनाएं होंगी। इसलिए, आपको उत्पाद में निगरानी को लागू करने के लिए खर्च किए गए समय और धन को सही ठहराने के लिए एक व्यावसायिक मामले की आवश्यकता होगी।
2. सिस्टम इंजीनियरों को पर्याप्त नींद लेने में मदद करें। उन्हें दिखाएं कि किसी भी उत्पाद के लिए रिलीज़ रिलीज़ चेकलिस्ट का उपयोग करना अच्छा है। और जाँच कर रहा है कि उत्पादन में सभी एप्लिकेशन मेट्रिक्स के साथ कवर किए गए हैं जो आपको एक अच्छी रात की नींद लाने में मदद करेंगे, जिससे डेवलपर्स को यह देखने में मदद मिलती है कि क्या काम करता है और कहाँ काम नहीं करता है। हालांकि, किसी भी डेवलपर, उत्पाद के मालिक और CTO को परेशान करने और परेशान करने का सही तरीका है कि लाठी को पहियों में धकेलें और विरोध करें। यह व्यवहार किसी भी उत्पाद की रिलीज़ की तारीख को प्रभावित करेगा यदि आप अंतिम मिनट तक फिर से इंतजार करते हैं, इसलिए फिर से बाईं ओर मुड़ें और इन मुद्दों को जल्द से जल्द परियोजना योजना में शामिल करें। यदि आवश्यक हो, तो उत्पाद की बैठकों के लिए अपना रास्ता बनाएं। नकली मूंछें पहनें और ऐसा कुछ महसूस करें, यह कभी विफल नहीं होता है। अपनी चिंताओं की रिपोर्ट करें, स्पष्ट लाभ दिखाएं और प्रचार करें।
3. सुनिश्चित करें कि डेवलपर्स (देव) और ऑपरेशन (ऑप्स) दोनों रेड ज़ोन के लिए उत्पाद मैट्रिक्स को आगे बढ़ाने के अर्थ और परिणाम को समझते हैं। उत्पाद के प्रदर्शन पर केवल गार्ड के रूप में ऑपरेशन को न छोड़ें, सुनिश्चित करें कि डेवलपर्स भी इसमें भाग लेते हैं (#productsquads)।
4. लॉग एक बड़ी बात है, लेकिन मैट्रिक्स भी। उन्हें मिलाएं और व्यर्थ की विशाल ज्वलंत गेंद में अपने लॉग को कचरा न बनने दें। डेवलपर्स को समझाएं और दिखाएं कि उनके अलावा कोई भी उनके लॉग को क्यों नहीं समझेगा, उन्हें दिखाओ कि सुबह 3:15 पर बेकार लॉग देखना कैसा लगता है।

मार्क्‍स होर्वाट द्वारा अनस्प्लैश पर फोटो

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