अभियंते अनुप्रयोग निरीक्षणाची काळजी का घेत नाहीत?

सर्वांना शुक्रवारच्या शुभेच्छा! मित्रांनो, आज आपण अभ्यासक्रमाला समर्पित प्रकाशनांची मालिका सुरू ठेवतो "DevOps सराव आणि साधने", कारण अभ्यासक्रमासाठी नवीन गटातील वर्ग पुढील आठवड्याच्या शेवटी सुरू होतील. तर, चला सुरुवात करूया!

देखरेख आहे फक्त. हे ज्ञात तथ्य आहे. Nagios आणा, रिमोट सिस्टमवर NRPE चालवा, NRPE TCP पोर्ट 5666 वर Nagios कॉन्फिगर करा आणि तुमच्याकडे मॉनिटरिंग आहे.

हे इतके सोपे आहे की ते मनोरंजक नाही. आता तुमच्याकडे CPU वेळ, डिस्क सबसिस्टम, RAM साठी मूलभूत मेट्रिक्स आहेत, जे नागिओस आणि NRPE ला डिफॉल्टनुसार पुरवले जातात. परंतु हे प्रत्यक्षात "निरीक्षण" नाही. हे फक्त सुरूवात आहे.

(सामान्यत: ते PNP4Nagios, RRDtool आणि Thruk स्थापित करतात, स्लॅकमध्ये सूचना सेट करतात आणि थेट नागीओसेक्चेंजवर जातात, परंतु आता ते सोडून द्या).

चांगले निरीक्षण खरं तर खूप क्लिष्ट आहे, तुम्ही देखरेख करत असलेल्या ऍप्लिकेशनचे इंटर्नल्स तुम्हाला खरोखर माहित असणे आवश्यक आहे.

निरीक्षण करणे कठीण आहे का?

कोणताही सर्व्हर, मग तो लिनक्स असो किंवा विंडोज, व्याख्येनुसार काही उद्देश पूर्ण करेल. Apache, Samba, Tomcat, फाइल स्टोरेज, LDAP - या सर्व सेवा एक किंवा अधिक बाबतीत कमी-अधिक अद्वितीय आहेत. प्रत्येकाचे स्वतःचे कार्य, स्वतःची वैशिष्ट्ये आहेत. मेट्रिक्स, KPIs (मुख्य कार्यप्रदर्शन निर्देशक) मिळविण्याचे वेगवेगळे मार्ग आहेत, जे सर्व्हर लोडखाली असताना तुमच्यासाठी मनोरंजक असतात.

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

(माझी इच्छा आहे की माझे डॅशबोर्ड निऑन निळे असावेत - स्वप्नाळूपणे उसासा टाकत -... हम्म...)

सेवा प्रदान करणारे कोणतेही सॉफ्टवेअर मेट्रिक्स गोळा करण्यासाठी एक यंत्रणा असणे आवश्यक आहे. Apache मध्ये एक मॉड्यूल आहे mod-status, सर्व्हर स्थिती पृष्ठ प्रदर्शित करणे. Nginx आहे - stub_status. Tomcat मध्ये JMX किंवा सानुकूल वेब अनुप्रयोग आहेत जे की मेट्रिक्स दर्शवतात. MySQL ला "शो ग्लोबल स्टेटस" इत्यादी कमांड आहे.
मग डेव्हलपर त्यांनी तयार केलेल्या ऍप्लिकेशन्समध्ये समान यंत्रणा का तयार करत नाहीत?

हे फक्त विकासकच करतात का?

मेट्रिक्स एम्बेडिंगबद्दल उदासीनता एक विशिष्ट स्तर विकासकांसाठी मर्यादित नाही. मी अशा कंपन्यांमध्ये काम केले जेथे त्यांनी Tomcat वापरून ऍप्लिकेशन विकसित केले आणि सामान्य टॉमकॅट त्रुटी लॉग वगळता त्यांचे स्वतःचे कोणतेही मेट्रिक्स, सेवा क्रियाकलापांचे कोणतेही लॉग प्रदान केले नाहीत. काही डेव्हलपर बरेच लॉग व्युत्पन्न करतात ज्याचा अर्थ सिस्टम प्रशासकासाठी काहीही नसतो जो पहाटे 3:15 वाजता वाचण्यास पुरेसा दुर्दैवी असतो.

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

सिस्टीम अभियंते जे अशी उत्पादने सोडण्यास सक्षम करतात त्यांनी परिस्थितीसाठी काही जबाबदारी देखील उचलली पाहिजे. काही सिस्टीम अभियंत्यांना लॉगमधून अर्थपूर्ण मेट्रिक्स काढण्याचा प्रयत्न करण्यासाठी वेळ किंवा काळजी असते, त्या मेट्रिक्सच्या संदर्भाशिवाय आणि अनुप्रयोग क्रियाकलापांच्या प्रकाशात त्यांचा अर्थ लावण्याची क्षमता. "काहीतरी सध्या (किंवा लवकरच होईल) चुकीचे आहे" निर्देशकांव्यतिरिक्त, काहींना त्याचा फायदा कसा होऊ शकतो हे समजत नाही.

मेट्रिक्सच्या गरजेबद्दल विचारात बदल केवळ विकासकांमध्येच नाही तर सिस्टम अभियंत्यांमध्ये देखील झाला पाहिजे.

कोणत्याही सिस्टीम अभियंत्यासाठी ज्यांना केवळ गंभीर घटनांना प्रतिसाद देणे आवश्यक नाही, परंतु ते घडू नयेत याची देखील खात्री करणे आवश्यक आहे, मेट्रिक्सचा अभाव सहसा असे करण्यात अडथळा असतो.

तथापि, सिस्टम अभियंते सहसा त्यांच्या कंपनीसाठी पैसे कमविण्यासाठी कोडसह टिंकर करत नाहीत. त्यांना समस्या ओळखणे, कार्यप्रदर्शन समस्यांबद्दल जागरूकता वाढवणे आणि यासारख्या गोष्टींमध्ये सिस्टम अभियंत्याच्या जबाबदारीचे महत्त्व समजणारे प्रमुख विकासक आवश्यक आहेत.

ही गोष्ट devops

डेव्हप्स मानसिकता विकास (देव) आणि ऑपरेशन्स (ऑप्स) विचार यांच्यातील समन्वयाचे वर्णन करते. "डेव्हॉप्स" करण्याचा दावा करणाऱ्या कोणत्याही कंपनीने हे करणे आवश्यक आहे:

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

तुम्ही एखादे उत्पादन सुधारू शकत नाही आणि ते सध्या कसे कार्य करते हे तुम्हाला माहिती नसल्यास ते सुधारले आहे हे जाणून घ्या. एखादे उत्पादन कसे कार्य करते हे तुम्हाला कळू शकत नाही जर तुम्हाला त्याचे घटक कसे कार्य करतात, ते कोणत्या सेवांवर अवलंबून आहेत, त्याचे मुख्य वेदना बिंदू आणि अडथळे समजत नाहीत.
तुम्ही संभाव्य अडथळ्यांकडे लक्ष न दिल्यास, पोस्टमॉर्टम लिहिताना तुम्ही फाइव्ह व्हाईज तंत्राचा अवलंब करू शकणार नाही. एखादे उत्पादन कसे कार्य करते हे पाहण्यासाठी किंवा ते "सामान्य आणि आनंदी" कसे दिसते हे जाणून घेण्यासाठी तुम्ही सर्व काही एका स्क्रीनवर ठेवू शकणार नाही.

डावीकडे शिफ्ट, डावीकडे, मी म्हणालो ली-

माझ्यासाठी, Devops च्या मुख्य तत्त्वांपैकी एक म्हणजे “डावीकडे शिफ्ट”. या संदर्भात डावीकडे शिफ्ट म्हणजे शक्यता बदलणे (जबाबदारी नाही, परंतु केवळ क्षमता) सॉफ्टवेअर डिलिव्हरी लाइफ सायकलमध्ये डावीकडे, कार्यप्रदर्शन मेट्रिक्स तयार करणे, लॉग अधिक कार्यक्षमतेने वापरणे इत्यादीसारख्या गोष्टी करणे ज्याची सिस्टम अभियंता सामान्यत: काळजी घेतात.

फोटोचा लेखक मेकर्स नेसा वर Unsplash

सॉफ्टवेअर डेव्हलपर वापरण्यास सक्षम असणे आवश्यक आहे आणि कंपनी त्याच्या सर्व प्रकारांमध्ये, मेट्रिक्स, लॉगिंग, मॉनिटरिंग इंटरफेस आणि सर्वात महत्त्वाचे म्हणजे, निरीक्षण करण्यासाठी वापरते. त्यांचे उत्पादन उत्पादनात कसे कार्य करते ते पहा. डेव्हलपर जोपर्यंत ते मेट्रिक्स पाहू शकत नाहीत आणि ते कसे दिसतात, उत्पादन मालक त्यांना पुढील ब्रीफिंगमध्ये CTO कडे कसे सादर करतात, इत्यादींवर प्रभाव पाडत नाही तोपर्यंत तुम्ही मॉनिटरिंगमध्ये मेहनत आणि वेळ गुंतवू शकत नाही.

थोडक्यात

1. आपल्या घोड्याला पाण्यात घेऊन जा. विकासकांना दाखवा की ते स्वतःसाठी किती त्रास टाळू शकतात, त्यांना त्यांच्या ऍप्लिकेशनसाठी योग्य KPI आणि मेट्रिक्स ओळखण्यात मदत करा जेणेकरून CTO द्वारे ओरडत असलेल्या उत्पादन मालकाकडून कमी ओरडता येईल. हळूवारपणे आणि शांतपणे त्यांना प्रकाशात आणा. जर ते कार्य करत नसेल, तर लाच द्या, धमकावा आणि त्यांना किंवा उत्पादन मालकास शक्य तितक्या लवकर ऍप्लिकेशन्समधून हे मेट्रिक्स मिळवून देण्याची अंमलबजावणी करा आणि नंतर आकृत्या काढा. हे कठीण होईल कारण याकडे प्राधान्य म्हणून पाहिले जाणार नाही आणि उत्पादन रोडमॅपमध्ये अनेक महसूल उत्पन्न करणारे प्रकल्प प्रलंबित असतील. म्हणून, उत्पादनामध्ये देखरेख करण्यासाठी खर्च केलेला वेळ आणि खर्चाचे समर्थन करण्यासाठी तुम्हाला व्यावसायिक प्रकरणाची आवश्यकता असेल.
2. सिस्टम अभियंत्यांना रात्री चांगली झोप घेण्यास मदत करा. त्यांना दाखवा की रिलीज होत असलेल्या कोणत्याही उत्पादनासाठी "चला सोडा" चेकलिस्ट वापरणे ही चांगली गोष्ट आहे. आणि उत्पादनातील सर्व ऍप्लिकेशन मेट्रिक्सने कव्हर केले आहेत याची खात्री केल्याने विकासकांना काय आणि कुठे चूक होत आहे हे पाहण्याची परवानगी देऊन तुम्हाला रात्री चांगली झोप घेण्यास मदत होईल. तथापि, कोणत्याही विकसक, उत्पादन मालक किंवा CTO यांना चिडवण्याचा आणि निराश करण्याचा योग्य मार्ग म्हणजे टिकून राहणे आणि प्रतिकार करणे. तुम्ही पुन्हा शेवटच्या मिनिटापर्यंत थांबल्यास या वर्तनाचा कोणत्याही उत्पादनाच्या प्रकाशन तारखेवर परिणाम होईल, त्यामुळे पुन्हा डावीकडे जा आणि या समस्या लवकरात लवकर तुमच्या प्रकल्प योजनेत मिळवा. आवश्यक असल्यास, उत्पादन मीटिंगमध्ये जा. बनावट मिशा घाला आणि वाटले किंवा काहीतरी, ते कधीही अपयशी होणार नाही. तुमच्या समस्यांशी संवाद साधा, स्पष्ट फायदे दाखवा आणि सुवार्ता सांगा.
3. डेव्हलपमेंट (डेव्हलपमेंट) आणि ऑपरेशन्स (ऑपर्स) दोन्ही रेड झोनमध्ये जाणाऱ्या उत्पादन मेट्रिक्सचा अर्थ आणि परिणाम समजत असल्याची खात्री करा. उत्पादनांच्या आरोग्याचे एकमेव संरक्षक म्हणून Ops सोडू नका, विकासक देखील सहभागी आहेत याची खात्री करा (#productsquads).
4. लॉग ही एक चांगली गोष्ट आहे, परंतु मेट्रिक्स देखील आहेत. त्यांना एकत्र करा आणि निरुपयोगीतेच्या प्रचंड ज्वलंत बॉलमध्ये तुमचे लॉग कचरा बनू देऊ नका. विकासकांना त्यांचे लॉग का समजणार नाहीत ते समजावून सांगा आणि त्यांना दाखवा, पहाटे 3:15 वाजता निरुपयोगी लॉग पाहणे कसे आहे ते त्यांना दाखवा.

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

इतकंच. नवीन साहित्य पुढील आठवड्यात प्रसिद्ध होईल. जर तुम्हाला कोर्सबद्दल अधिक जाणून घ्यायचे असेल तर आम्ही तुम्हाला आमंत्रित करतो खुला दिवस, जे सोमवारी होणार आहे. आणि आता आम्ही पारंपारिकपणे आपल्या टिप्पण्यांची वाट पाहत आहोत.

स्त्रोत: www.habr.com