DevOps कौन है और कब इसकी आवश्यकता नहीं है?

पिछले कुछ वर्षों में DevOps एक बहुत लोकप्रिय विषय बन गया है। बहुत से लोग इसमें शामिल होने का सपना देखते हैं, लेकिन, जैसा कि अभ्यास से पता चलता है, अक्सर केवल वेतन के स्तर के कारण।

कुछ लोग अपने बायोडाटा में DevOps को सूचीबद्ध करते हैं, हालाँकि वे हमेशा इस शब्द का सार नहीं जानते या समझते हैं। कुछ लोग सोचते हैं कि एन्सिबल, गिटलैब, जेनकिंस, टेराफॉर्म और इस तरह का अध्ययन करने के बाद (सूची आपके स्वाद के अनुसार जारी रखी जा सकती है), आप तुरंत "डेवोप्सिस्ट" बन जाएंगे। निःसंदेह, यह सच नहीं है।

पिछले कुछ वर्षों से, मैं मुख्य रूप से विभिन्न कंपनियों में DevOps के कार्यान्वयन में शामिल रहा हूँ। इससे पहले, उन्होंने सिस्टम प्रशासक से लेकर आईटी निदेशक तक के पदों पर 20 से अधिक वर्षों तक काम किया। वर्तमान में Playgendary में DevOps लीड इंजीनियर।

डेवऑप्स कौन है?

एक लेख लिखने का विचार एक अन्य प्रश्न के बाद उत्पन्न हुआ: "DevOps कौन है?" यह क्या है या कौन है इसके लिए अभी भी कोई स्थापित शब्द नहीं है। इसमें कुछ उत्तर पहले से ही मौजूद हैं वीडियो. सबसे पहले, मैं इसके मुख्य बिंदुओं पर प्रकाश डालूँगा, और फिर मैं अपने अवलोकन और विचार साझा करूँगा।

DevOps कोई विशेषज्ञ नहीं है जिसे काम पर रखा जा सके, उपयोगिताओं का एक सेट नहीं है, और इंजीनियरों के साथ डेवलपर्स का एक विभाग नहीं है।

DevOps एक दर्शन और कार्यप्रणाली है।

दूसरे शब्दों में, यह प्रथाओं का एक सेट है जो डेवलपर्स को सिस्टम प्रशासकों के साथ सक्रिय रूप से बातचीत करने में मदद करता है। अर्थात् कार्य प्रक्रियाओं को एक-दूसरे से जोड़ना और एकीकृत करना।

DevOps के आगमन के साथ, विशेषज्ञों की संरचना और भूमिकाएँ वही रहीं (डेवलपर्स हैं, इंजीनियर हैं), लेकिन बातचीत के नियम बदल गए हैं। विभागों के बीच की सीमाएँ धुंधली हो गई हैं।

DevOps के लक्ष्यों को तीन बिंदुओं में वर्णित किया जा सकता है:

• सॉफ़्टवेयर को नियमित रूप से अद्यतन किया जाना चाहिए।
• सॉफ्टवेयर शीघ्रता से किया जाना चाहिए।
• सॉफ़्टवेयर को सुविधाजनक रूप से और कम समय में तैनात किया जाना चाहिए।

DevOps के लिए कोई एकल उपकरण नहीं है। कई उत्पादों को कॉन्फ़िगर करना, वितरित करना और अध्ययन करना इसका मतलब यह नहीं है कि DevOps कंपनी में दिखाई दिया है। बहुत सारे उपकरण हैं और वे सभी विभिन्न चरणों में उपयोग किए जाते हैं, लेकिन एक ही उद्देश्य पूरा करते हैं।

और यह DevOps टूल का केवल एक हिस्सा है

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

साक्षात्कार के अनुभव से, मुझे निम्नलिखित चित्र दिखाई देता है: जो विशेषज्ञ DevOps को एक नौकरी का शीर्षक मानते हैं, उन्हें आमतौर पर सहकर्मियों के साथ गलतफहमी होती है.

एक अद्भुत उदाहरण था. एक युवक अपने बायोडाटा में बहुत सारे स्मार्ट शब्दों के साथ साक्षात्कार में आया। अपनी पिछली तीन नौकरियों में, उनके पास 5-6 महीने का अनुभव था। मैंने दो स्टार्टअप छोड़ दिए क्योंकि वे "चल नहीं पाए।" लेकिन तीसरी कंपनी के बारे में उन्होंने कहा कि वहां उन्हें कोई नहीं समझता: डेवलपर्स विंडोज़ पर कोड लिखते हैं, और निदेशक इस कोड को नियमित डॉकर में "लिपटे" और सीआई/सीडी पाइपलाइन में बनाने के लिए बाध्य करते हैं। उस व्यक्ति ने अपने वर्तमान कार्यस्थल और अपने सहकर्मियों के बारे में बहुत सारी नकारात्मक बातें कहीं - मैं बस उत्तर देना चाहता था: "तो आप एक हाथी नहीं बेचेंगे।"

फिर मैंने उनसे एक ऐसा प्रश्न पूछा जो हर उम्मीदवार के लिए मेरी सूची में सबसे ऊपर है।

— आपके लिए व्यक्तिगत रूप से DevOps का क्या अर्थ है?
- सामान्य तौर पर या मैं इसे कैसे समझता हूँ?

मुझे उनकी निजी राय में दिलचस्पी थी. वह इस शब्द के सिद्धांत और उत्पत्ति को जानते थे, लेकिन वे उनसे पूरी तरह असहमत थे। उनका मानना ​​था कि DevOps एक नौकरी का शीर्षक था। यहीं उसकी समस्याओं की जड़ है. साथ ही अन्य विशेषज्ञ भी यही राय रखते हैं।

नियोक्ता, "डेवऑप्स के जादू" के बारे में बहुत कुछ सुन चुके हैं, एक ऐसे व्यक्ति को ढूंढना चाहते हैं जो आकर यह "जादू" बनाए। और "डेवऑप्स एक नौकरी है" श्रेणी के आवेदक यह नहीं समझते हैं कि इस दृष्टिकोण से वे अपेक्षाओं को पूरा नहीं कर पाएंगे। और, सामान्य तौर पर, उन्होंने अपने बायोडाटा पर DevOps लिखा क्योंकि यह एक चलन है और वे इसके लिए बहुत अधिक भुगतान करते हैं।

DevOps कार्यप्रणाली और दर्शन

कार्यप्रणाली सैद्धांतिक और व्यावहारिक हो सकती है। हमारे मामले में, यह दूसरा है। जैसा कि मैंने ऊपर उल्लेख किया है, DevOps निर्धारित लक्ष्यों को प्राप्त करने के लिए उपयोग की जाने वाली प्रथाओं और रणनीतियों का एक समूह है। और प्रत्येक मामले में, कंपनी की व्यावसायिक प्रक्रियाओं के आधार पर, यह काफी भिन्न हो सकता है। जो इसे बेहतर या बदतर नहीं बनाता है।

DevOps कार्यप्रणाली केवल लक्ष्य प्राप्त करने का एक साधन है।

अब DevOps दर्शन क्या है इसके बारे में। और यह शायद सबसे कठिन प्रश्न है.

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

मेरे विश्वविद्यालय में ऐसा कोई विषय नहीं था, मुझे 90 के दशक में मिलने वाली सामग्रियों का उपयोग करके स्वयं ही सब कुछ अध्ययन करना पड़ता था। यह विषय इंजीनियरिंग शिक्षा के लिए वैकल्पिक है, इसलिए उत्तर की औपचारिकता का अभाव है। लेकिन जो लोग गंभीरता से DevOps में डूबे हुए हैं, उन्हें कंपनी की सभी प्रक्रियाओं की एक निश्चित "भावना" या "अचेतन व्यापकता" महसूस होने लगती है।

अपने स्वयं के अनुभव का उपयोग करते हुए, मैंने इस दर्शन के कुछ "अभिधारणाओं" को औपचारिक रूप देने का प्रयास किया। परिणाम निम्नलिखित है:

• DevOps कोई स्वतंत्र चीज़ नहीं है जिसे ज्ञान या गतिविधि के एक अलग क्षेत्र में विभाजित किया जा सके।
• कंपनी के सभी कर्मचारियों को अपनी गतिविधियों की योजना बनाते समय DevOps पद्धति द्वारा निर्देशित किया जाना चाहिए।
• DevOps किसी कंपनी के भीतर सभी प्रक्रियाओं को प्रभावित करता है।
• अपनी सेवाओं के विकास और अधिकतम ग्राहक सुविधा सुनिश्चित करने के लिए किसी कंपनी के भीतर किसी भी प्रक्रिया के लिए समय की लागत को कम करने के लिए DevOps मौजूद है।
• DevOps, आधुनिक भाषा में, कंपनी के प्रत्येक कर्मचारी की सक्रिय स्थिति है, जिसका उद्देश्य समय की लागत को कम करना और हमारे आसपास के आईटी उत्पादों की गुणवत्ता में सुधार करना है।

मुझे लगता है कि मेरे "अभिधारणाएं" चर्चा के लिए एक अलग विषय हैं। लेकिन अब निर्माण करने के लिए कुछ है।

DevOps क्या करता है

यहां मुख्य शब्द संचार है। बहुत सारे संचार हैं, जिनका आरंभकर्ता बिल्कुल वही DevOps इंजीनियर होना चाहिए। ऐसा क्यों? क्योंकि यह दर्शन और पद्धति है, और उसके बाद ही इंजीनियरिंग ज्ञान है।

मैं पश्चिमी श्रम बाज़ार के बारे में 100% विश्वास के साथ नहीं बोल सकता। लेकिन मैं रूस में DevOps बाज़ार के बारे में काफ़ी कुछ जानता हूँ। सैकड़ों साक्षात्कारों के अलावा, पिछले डेढ़ साल में मैंने बड़ी रूसी कंपनियों और बैंकों के लिए "डेवऑप्स के कार्यान्वयन" सेवा के लिए सैकड़ों तकनीकी प्रीसेल्स में भाग लिया है।

रूस में, DevOps अभी भी एक बहुत ही युवा, लेकिन पहले से ही ट्रेंडिंग विषय है। जहाँ तक मुझे पता है, अकेले मॉस्को में 2019 में ऐसे विशेषज्ञों की कमी 1000 से अधिक लोगों की थी। और नियोक्ताओं के लिए कुबेरनेट्स शब्द लगभग बैल के लिए लाल चिथड़े जैसा है। इस उपकरण के अनुयायी इसका उपयोग वहां भी करने के लिए तैयार हैं जहां यह आवश्यक नहीं है और आर्थिक रूप से लाभदायक है। नियोक्ता हमेशा यह नहीं समझता है कि किन मामलों में क्या उपयोग करना अधिक उपयुक्त है, और उचित तैनाती के साथ, कुबेरनेट्स क्लस्टर को बनाए रखने में पारंपरिक क्लस्टर योजना का उपयोग करके एप्लिकेशन को तैनात करने की तुलना में 2-3 गुना अधिक लागत आती है। इसका उपयोग वहीं करें जहां आपको वास्तव में इसकी आवश्यकता हो।

DevOps को लागू करना पैसे के मामले में महंगा है। और यह केवल वहीं उचित है जहां यह अन्य क्षेत्रों में आर्थिक लाभ पहुंचाता है, अपने आप में नहीं।

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

साथ ही, एक DevOps इंजीनियर को समय-समय पर एक प्रशासनिक संसाधन का उपयोग करने की आवश्यकता होती है। उदाहरण के लिए, "पर्यावरणीय प्रतिरोध" पर काबू पाने के लिए - जब टीम DevOps टूल और कार्यप्रणाली को स्वीकार करने के लिए तैयार नहीं है।

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

लेकिन ऐसी टीमें हैं, जो इसके विपरीत, नए उपकरण और तरीके पेश करने में प्रसन्न हैं, और इस प्रक्रिया में सक्रिय रूप से भाग लेती हैं। हालाँकि इस मामले में भी, DevOps इंजीनियर और टीम के बीच संचार रद्द नहीं किया गया था।

जब DevOps की आवश्यकता नहीं है

ऐसी स्थितियाँ होती हैं जब DevOps की आवश्यकता नहीं होती है। यह एक तथ्य है - इसे समझने और स्वीकार करने की जरूरत है।

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

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

इसका ज्वलंत उदाहरण एक प्रसिद्ध बैंक है। कंपनी के पास पारंपरिक ग्राहक कार्यालय नहीं हैं, दस्तावेज़ प्रवाह मेल या कोरियर के माध्यम से किया जाता है, और कई कर्मचारी घर से काम करते हैं। कंपनी सिर्फ एक बैंक बनकर रह गई है और, मेरी राय में, विकसित DevOps प्रौद्योगिकियों के साथ एक आईटी कंपनी में बदल गई है।

कई अन्य उदाहरण और व्याख्यान विषयगत बैठकों और सम्मेलनों की रिकॉर्डिंग में पाए जा सकते हैं। मैंने उनमें से कुछ का व्यक्तिगत रूप से दौरा किया - यह उन लोगों के लिए एक बहुत ही उपयोगी अनुभव है जो इस दिशा में विकास करना चाहते हैं। DevOps पर अच्छे व्याख्यानों और सामग्रियों वाले YouTube चैनलों के लिंक यहां दिए गए हैं:

• देवउफ़
• DevOpsConf
• HighLoad ++
• फ़्लैंट
• मेलरू क्लाउड सॉल्यूशन

अब अपने व्यवसाय को देखें और इस बारे में सोचें: आपकी कंपनी और उसका मुनाफा ग्राहक संपर्क को सक्षम करने के लिए आईटी उत्पादों पर कितना निर्भर करता है?

यदि आपकी कंपनी एक छोटे से स्टोर में मछली बेचती है और एकमात्र आईटी उत्पाद दो 1C: एंटरप्राइज़ कॉन्फ़िगरेशन (अकाउंटिंग और यूएनएफ) है, तो DevOps के बारे में बात करना शायद ही समझ में आता है।

यदि आप एक बड़े व्यापारिक और विनिर्माण उद्यम में काम करते हैं (उदाहरण के लिए, आप शिकार राइफलें बनाते हैं), तो आपको इसके बारे में सोचना चाहिए। आप पहल कर सकते हैं और अपने प्रबंधन को DevOps को लागू करने की संभावनाओं से अवगत करा सकते हैं। ठीक है, और साथ ही, इस प्रक्रिया का नेतृत्व करें। एक सक्रिय स्थिति DevOps दर्शन के महत्वपूर्ण सिद्धांतों में से एक है।

वार्षिक वित्तीय कारोबार का आकार और मात्रा यह निर्धारित करने के लिए मुख्य मानदंड नहीं है कि आपकी कंपनी को DevOps की आवश्यकता है या नहीं।

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

उनके ग्राहक कार डीलरों की एक सीमित सूची हैं। और प्रत्येक को निर्माता की ओर से एक विशेषज्ञ सौंपा गया है। सभी आंतरिक दस्तावेज़ प्रवाह SAP ERP के माध्यम से होता है। आंतरिक कर्मचारी अनिवार्य रूप से सूचना प्रणाली के ग्राहक हैं। लेकिन इस आईएस को क्लस्टर सिस्टम के प्रबंधन के शास्त्रीय तरीकों से नियंत्रित किया जाता है। जो DevOps प्रथाओं का उपयोग करने की संभावना को बाहर करता है।

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

दूसरी ओर, कई छोटी कंपनियाँ हैं जो DevOps पद्धति, दर्शन, प्रथाओं और उपकरणों का उपयोग करके सॉफ़्टवेयर विकसित करती हैं। और उनका मानना ​​है कि DevOps को लागू करने की लागत ही वह लागत है जो उन्हें सॉफ़्टवेयर बाज़ार में प्रभावी ढंग से प्रतिस्पर्धा करने की अनुमति देती है। ऐसी कंपनियों के उदाहरण देखे जा सकते हैं यहां.

यह समझने का मुख्य मानदंड कि क्या DevOps की आवश्यकता है: आपके आईटी उत्पादों का कंपनी और ग्राहकों के लिए क्या मूल्य है।

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

कोई भी खेल फंडिंग की बदौलत अस्तित्व में आता है: खिलाड़ियों से प्रत्यक्ष या अप्रत्यक्ष रूप से। प्लेजेंडरी में, हम 200 से अधिक लोगों के साथ मुफ्त मोबाइल गेम विकसित करते हैं, जो सीधे तौर पर उनके निर्माण में शामिल होते हैं। हम DevOps का उपयोग कैसे करते हैं?

हाँ, बिल्कुल वैसा ही जैसा ऊपर बताया गया है। मैं डेवलपर्स और परीक्षकों के साथ लगातार संवाद करता हूं, और DevOps कार्यप्रणाली और टूल पर कर्मचारियों के लिए आंतरिक प्रशिक्षण आयोजित करता हूं।

अब हम यूनिटी के साथ सभी असेंबली पाइपलाइनों को निष्पादित करने और बाद में ऐप स्टोर और प्ले मार्केट में तैनाती के लिए सीआई/सीडी पाइपलाइन टूल के रूप में जेनकींस का सक्रिय रूप से उपयोग कर रहे हैं। क्लासिक टूलकिट से अधिक:

• आसन - परियोजना प्रबंधन के लिए। जेनकींस के साथ एकीकरण कॉन्फ़िगर किया गया है।
• Google मीट - वीडियो मीटिंग के लिए।
• स्लैक - संचार और विभिन्न अलर्ट के लिए, जिसमें जेनकींस की सूचनाएं भी शामिल हैं।
• एटलसियन संगम - दस्तावेज़ीकरण और समूह कार्य के लिए।

हमारी तात्कालिक योजनाओं में सोनारक्यूब का उपयोग करके स्थैतिक कोड विश्लेषण शुरू करना और सतत एकीकरण चरण में सेलेनियम का उपयोग करके स्वचालित यूआई परीक्षण करना शामिल है।

इसके बजाय एक निष्कर्ष की

मैं निम्नलिखित विचार के साथ अपनी बात समाप्त करना चाहूंगा: एक उच्च योग्य DevOps इंजीनियर बनने के लिए, यह सीखना महत्वपूर्ण है कि लोगों के साथ लाइव संवाद कैसे किया जाए।

एक DevOps इंजीनियर एक टीम प्लेयर होता है। और कुछ न था। सहकर्मियों के साथ संवाद करने की पहल उसकी ओर से होनी चाहिए, न कि कुछ परिस्थितियों के प्रभाव में। एक DevOps विशेषज्ञ को टीम के लिए सर्वोत्तम समाधान देखना और प्रस्तावित करना होगा।

और हाँ, किसी भी समाधान के कार्यान्वयन के लिए बहुत अधिक चर्चा की आवश्यकता होगी, और अंत तक यह पूरी तरह से बदल सकता है। स्वतंत्र रूप से विकास करना, अपने विचारों को प्रस्तावित करना और कार्यान्वित करना, ऐसा व्यक्ति टीम और नियोक्ता दोनों के लिए मूल्य बढ़ाता है। जो, अंततः, उसके मासिक पारिश्रमिक की राशि या अतिरिक्त बोनस के रूप में परिलक्षित होता है।

स्रोत: www.habr.com