किन इन्जिनियरहरूले अनुप्रयोग अनुगमनको बारेमा वास्ता गर्दैनन्?

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

अनुगमन छ बस। यो ज्ञात तथ्य हो। Nagios ल्याउनुहोस्, रिमोट प्रणालीमा NRPE चलाउनुहोस्, NRPE TCP पोर्ट 5666 मा Nagios कन्फिगर गर्नुहोस् र तपाईंसँग निगरानी छ।

यो धेरै सजिलो छ यो रोचक छैन। अब तपाईंसँग CPU समय, डिस्क सबसिस्टम, RAM, Nagios र NRPE लाई पूर्वनिर्धारित रूपमा आपूर्ति गरिएको आधारभूत मेट्रिक्स छ। तर यो वास्तवमा "निगरानी" होइन। यो त सुरुवात मात्र हो।

(सामान्यतया तिनीहरू PNP4Nagios, RRDtool र Thruk स्थापना गर्छन्, Slack मा अधिसूचनाहरू सेट अप गर्छन् र सिधै nagiosexchange मा जान्छन्, तर यसलाई अहिलेको लागि छोडौं)।

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

निगरानी गर्न गाह्रो छ?

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

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

(म चाहन्छु कि मेरो ड्यासबोर्डहरू नियोन नीलो भएको होस् - सपनामा सुस्केरा हाल्दै -... हम्म...)

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

के विकासकर्ताहरूले मात्र यो गर्छन्?

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

फोटोका लेखक टिम Gouw मा Unsplash

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

मेट्रिक्स को आवश्यकता को बारे मा सोच मा परिवर्तन विकासकर्ताहरु मा मात्र होइन, तर प्रणाली ईन्जिनियरहरु मा पनि हुनुपर्दछ।

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

यद्यपि, प्रणाली इन्जिनियरहरूले सामान्यतया आफ्नो कम्पनीको लागि पैसा कमाउन कोडको साथ टिंकर गर्दैनन्। उनीहरूलाई नेतृत्व विकासकर्ताहरू चाहिन्छ जसले समस्याहरू पहिचान गर्न, कार्यसम्पादन मुद्दाहरूको जागरूकता बढाउने, र यस्तै कुराहरूमा प्रणाली इन्जिनियरको जिम्मेवारीको महत्त्व बुझ्छन्।

यो कुरा भत्काउँछ

डेभप मानसिकताले विकास (देव) र अपरेशन (अप्स) सोच बीचको तालमेललाई वर्णन गर्दछ। कुनै पनि कम्पनी जसले "डेभोप्स गर्न" दाबी गर्नुपर्छ:

1. उनीहरूले सायद गर्दैनन् भन्ने कुराहरू (राजकुमारी दुलही मेमलाई सन्दर्भ गर्दै - "मलाई लाग्दैन कि यसको मतलब तपाईले के सोच्नुहुन्छ त्यसको अर्थ!")
2. निरन्तर उत्पादन सुधारको मनोवृत्तिलाई प्रोत्साहन दिनुहोस्।

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

बायाँ, बायाँ सर्नुहोस्, मैले लिइई भनें-

मेरो लागि, Devops को मुख्य सिद्धान्तहरू मध्ये एक "बायाँ परिवर्तन" हो। यस सन्दर्भमा बायाँ सिफ्ट गर्नुको अर्थ सम्भाव्यता सार्नु हो (कुनै जिम्मेवारी छैन, तर केवल क्षमताहरू) सफ्टवेयर डेलिभरी लाइफ साइकलमा बायाँ तिर कार्यसम्पादन मेट्रिक्स सिर्जना गर्ने, लगहरू अझ प्रभावकारी रूपमा प्रयोग गर्ने, आदि जस्ता प्रणाली इन्जिनियरहरूले सामान्यतया ख्याल गर्ने कुराहरू गर्न।

फोटोका लेखक NESA Makers द्वारा मा Unsplash

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

छोटो कुरा गर्दै

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

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

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

स्रोत: www.habr.com