कंपनी के भीतर प्रवेश, devops, अंतहीन भ्रम और DevOps परिवर्तन के बारे में

2019 में एक आईटी कंपनी की सफलता के लिए क्या आवश्यक है? कोनोफ़्स और माइटैप्स के व्याख्याता बहुत ज़ोर से बोलते हैं और सामान्य लोगों को हमेशा स्पष्ट शब्द नहीं देते हैं। परिनियोजन, माइक्रोसर्विस, मोनोलिथ की अस्वीकृति, देवओप्स परिवर्तन और बहुत कुछ, के लिए संघर्ष। यदि हम मौखिक सौंदर्य को त्यागते हैं और सीधे और रूसी में बोलते हैं, तो यह सब एक साधारण थीसिस के लिए नीचे आता है: एक गुणवत्ता वाला उत्पाद बनाते हैं, और टीम के लिए आराम से करते हैं।

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

"मोडुलो" से पूरी कहानी सुंदर है, लेकिन ... ऐसा हुआ कि कुछ प्रशासकों ने अचानक DevOps को डब किया, और DevOps इंजीनियरों को न्यूनतम, टेलीपैथी और क्लैरवॉयंस कौशल की आवश्यकता होने लगी।

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

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

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

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

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

कैच क्या है?

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

लेकिन यह व्यवसाय में क्या अनुवाद करता है?

किराए पर लेना, यह सब उसके बारे में है।

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

हालाँकि, ऐसी रिक्ति को पढ़ते समय क्या धारणा बनती है? कि कंपनी एक मल्टी-टूल ऑपरेटर की तलाश में है, जो एक संस्करण नियंत्रण और निगरानी प्रणाली दोनों को तैनात करेगा और अपने दांतों से अपने दांतों को हिलाएगा ...

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

नहीं, नहीं, और फिर नहीं। इन्फ्रास्ट्रक्चर एडमिनिस्ट्रेटर जो कंपनी के आंतरिक सर्वरों को संचालित करेंगे, या एल 2 / एल 3 के पदों पर कब्जा करेंगे और अन्य कर्मचारियों की मदद करेंगे, कहीं भी नहीं गए हैं और नहीं जा रहे हैं।

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

एक और DevOps की समस्या

वास्तव में, सब कुछ काम पर रखने और प्रशासकों और देवों के बीच निरंतर भ्रम तक सीमित नहीं है। कुछ बिंदु पर, व्यापार को अपडेट देने और अंतिम बुनियादी ढांचे के साथ विकास टीम की बातचीत की समस्या का सामना करना पड़ा।

शायद यह तब था जब जलती हुई आंखों वाला एक चाचा एक सम्मेलन के दृश्य में आया और कहा, “और हम ऐसा कर रहे हैं और इसे देवोप्स कहते हैं। ये लोग आपकी सभी समस्याओं का समाधान करेंगे - और देवोप्स प्रथाओं के लागू होने के बाद कंपनी में कितनी अच्छी तरह से रहते हैं, यह बताना शुरू कर दिया।

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

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

पागल, निश्चित रूप से, देवों के पास जाते हैं, जिन्होंने "सही रोलबैक सिस्टम नहीं बनाया था," और इस तथ्य से कि इस कहानी में मूस डेवलपर्स हैं किसी को परेशान नहीं करते हैं।

निष्कर्ष सरल है: जैसे कि DevOps के लिए एक सामान्य दृष्टिकोण के बिना, इसमें बहुत कुछ नहीं है।
याद रखने वाली मुख्य बात: DevOps इंजीनियर एक जादूगर नहीं है, और उच्च गुणवत्ता वाले संचार और विकास के साथ दो-तरफ़ा बातचीत के बिना, वह अपने कार्यों का सामना करने में सक्षम नहीं होगा। देवों को उनकी "समस्याओं" के साथ अकेले नहीं छोड़ा जा सकता है या उन्हें "डेवलपर्स के पास न जाएं, उनके व्यवसाय को कोड करें", और फिर यह उम्मीद है कि एक महत्वपूर्ण क्षण में सब कुछ उसी तरह काम करेगा जैसे यह होना चाहिए। तो यह काम नहीं करता है।

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

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