इंजीनियर एप्लिकेशन मॉनिटरिंग की परवाह क्यों नहीं करते?

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

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

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

(आमतौर पर वे PNP4Nagios, RRDtool और Thruk इंस्टॉल करते हैं, स्लैक में नोटिफिकेशन सेट करते हैं और सीधे nagiosexchange पर जाते हैं, लेकिन इसे अभी के लिए छोड़ दें)।

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

क्या निगरानी करना कठिन है?

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

फोटो के लेखक ल्यूक चेसर पर Unsplash

(काश मेरे डैशबोर्ड नीयन नीले रंग के होते - स्वप्न में आह भरते हुए -... हम्म...)

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

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

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

फोटो के लेखक टिम गौव पर Unsplash

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

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

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

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

इससे बात ख़त्म हो जाती है

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

1. ऐसी बातें कहना जो शायद वे नहीं कहते (द प्रिंसेस ब्राइड मीम का संदर्भ देते हुए - "मुझे नहीं लगता कि इसका वह मतलब है जो आप सोचते हैं!")
2. निरंतर उत्पाद सुधार के दृष्टिकोण को प्रोत्साहित करें।

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

बाएँ शिफ्ट, बाएँ, मैंने कहा ली-

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

फोटो के लेखक मेकर्स द्वारा एनईएसए पर Unsplash

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

थोड़े ही बोल रहे हैं

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

फोटो के लेखक मार्को होर्वाट पर Unsplash

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

स्रोत: www.habr.com