कंपनी के भीतर व्यवस्थापकों, डेवॉप्स, अंतहीन भ्रम और डेवऑप्स परिवर्तन के बारे में

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

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

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

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

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

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

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

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

क्या पकड़ है?

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

लेकिन व्यवसाय के लिए इसका क्या मतलब है?

नियुक्ति, यह सब इसके बारे में है।

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

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

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

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

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

एक और DevOps समस्या

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

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

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

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

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

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

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

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

स्रोत: www.habr.com