🚈 👨‍👩‍👧‍👦 🐣 कौन DevOps है और कब इसकी जरूरत नहीं है 👃🏽 😬 📜

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

कुछ अपने सीवी में DevOps का संकेत देते हैं, हालांकि वे हमेशा शब्द के सार को नहीं जानते और समझते हैं। किसी का मानना है कि Ansible, GitLab, Jenkins, Terraform और जैसे अध्ययन (सूची को आपकी पसंद के अनुसार जारी रखा जा सकता है) का अध्ययन करने के बाद, यह तुरंत "devoop" बन जाएगा। यह, ज़ाहिर है, ऐसा नहीं है।

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

कौन है देवो

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

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

DevOps एक दर्शन और पद्धति है।

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

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

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

सॉफ़्टवेयर को नियमित रूप से अपडेट किया जाना चाहिए।
सॉफ्टवेयर जल्दी से किया जाना चाहिए।
सॉफ्टवेयर को आसानी से और थोड़े समय में तैनात किया जाना चाहिए।

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

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

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

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

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

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

- व्यक्तिगत रूप से DevOps का क्या मतलब है?
- आम तौर पर या मुझे यह कैसे पता चलता है?

मुझे उनकी निजी राय में दिलचस्पी थी। वह इस शब्द के सिद्धांत और उत्पत्ति को जानता था, लेकिन उनसे दृढ़ता से असहमत था। उन्होंने सोचा कि DevOps एक पोस्ट था। यहीं उसकी समस्याओं की जड़ है। एक ही राय वाले अन्य पेशेवरों की तरह।

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

कार्यप्रणाली और दर्शन देवो

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

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

अब देवो के दर्शन के बारे में क्या है। और यह शायद सबसे कठिन सवाल है।

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

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

मैंने इस दर्शन के कुछ "डाकुओं" को औपचारिक रूप देने की कोशिश की। यह निम्नलिखित निकला:

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

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

DevOps क्या करता है

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

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

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

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

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

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

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

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

जब DevOps की जरूरत नहीं है

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आसन - परियोजना प्रबंधन के लिए। जेनकींस के साथ एकीकृत एकीकरण।
Google मीटिंग - वीडियो कॉल के लिए।
सुस्त - संचार और विभिन्न अलर्ट के लिए, जेनकिंस से सूचनाओं सहित।
Atlassian Confluence - प्रलेखन और समूह कार्य के लिए।

निकट भविष्य में, हम सोनारक्यूब का उपयोग करके स्थिर कोड विश्लेषण पेश करेंगे और कॉन्टिनेंटल इंटीग्रेशन स्टेज पर सेलेनियम टूल्स के साथ स्वचालित यूआई परीक्षण का संचालन करेंगे।

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

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

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

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

कौन DevOps है और कब इसकी जरूरत नहीं है

कौन है देवो

कार्यप्रणाली और दर्शन देवो

DevOps क्या करता है

जब DevOps की जरूरत नहीं है

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

More articles: