🍳 🎵 🎨 व्यक्तिगत अनुभव: कैसे DevOps विभाग में एक कैरियर बनाने के लिए 👩🏿‍⚖️ 🆖 🦕

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

अस्वीकरण

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

हमने अपने विभाग और कंपनी में DevOps के विचारों को कैसे विकसित किया, इसके बारे में आप हैबे पर पढ़ सकते हैं:

और अब, चलो चलते हैं!

हमें DevOps की आवश्यकता क्यों है

प्रत्येक कंपनी के पास स्वचालन विभाग की अपनी विशिष्टता है। एक नियम के रूप में, उन कार्यों को जो कई अलग-अलग विभागों के स्तर पर करना मुश्किल या बहुत महंगा है, उन्हें एक केंद्रीकृत समूह या स्वचालन विभाग में स्थानांतरित किया जाता है। हमारी कंपनी में, DevOps के विचारों को लागू करने का वैश्विक लक्ष्य मात्रात्मक शब्दों (मानव-घंटे या मशीन-घंटे, CPU, RAM) में उत्पादन और उत्पाद समर्थन की लागत में लगातार कमी सुनिश्चित करना है।

इस लक्ष्य के आधार पर, पूरी कंपनी के स्तर पर स्वचालन विभाग की भूमिका पर प्रकाश डाला गया है - यह उत्पादन के सभी चरणों में विशिष्ट धारावाहिक कार्यों को करने की लागत को कम करना है।

यह काम किस प्रकार करता है

स्वचालन विभागों की कार्यात्मक जिम्मेदारियां भी किसी विशेष कंपनी की बारीकियों पर अत्यधिक निर्भर हैं। हमारी कंपनी एक डेवलपर और सूचना सुरक्षा समाधानों की विक्रेता है, और स्वचालन विभाग उत्पादन वाहक के लिए जिम्मेदार है - उत्पादों के व्यक्तिगत घटकों को इकट्ठा करने से लेकर उन्हें परीक्षण करने और ग्राहक के बुनियादी ढांचे तक अद्यतन पहुंचाने के लिए। हम टीमों में मुख्य विकास प्रक्रियाओं को स्वचालित करने में मदद करते हैं और हमारे सिस्टम (निरंतर एकीकरण और निरंतर वितरण (CI / CD)) के प्रदर्शन को सुनिश्चित करते हैं।

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

वर्कफ़्लो दिशा विकास और परीक्षण प्रक्रियाओं के प्रबंधन, कोड की स्थिति का विश्लेषण करने और प्रोजेक्ट एनालिटिक्स प्राप्त करने के लिए उपकरण प्रदान करती है। और अंत में, वेबदेव कॉर्पोरेट अपडेट सर्वर (GUS और FLUS) पर प्रकाशन रिलीज़ प्रदान करता है, साथ ही साथ लाइसेंस लैब सेवा का उपयोग करके उत्पादों को लाइसेंस देता है।

उत्पादन पाइपलाइन का समर्थन करने के लिए, हम डेवलपर्स के लिए कई अलग-अलग समर्थन सेवाओं की स्थापना और रखरखाव करते हैं। उनमें से कुछ के बारे में कहानियां हमारे पुराने mitaps पर सुनी जा सकती हैं: Op! DevOps! 2016 और ऑप! DevOps! 2017 । हम DevOpsHQ सहित आंतरिक स्वचालन उपकरण भी विकसित करते हैं ।

हमारे इंजीनियरों का अनुभव

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

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

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

हमारे DevOps विभाग में एक कैरियर के बारे में

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

हालांकि, समय के साथ, प्रक्रियाओं में सुधार हुआ, विभाग में वृद्धि हुई। उसके साथ, हमारे इंजीनियरों ने जानना चाहा कि इस बात की बढ़ती समझ थी: विशेषज्ञ के रूप में उनकी विकास की संभावनाएं क्या हैं, विभाग नए इंजीनियरों के लिए क्या पेशकश कर सकता है? इससे पहली बात जो तार्किक रूप से होती है, वह यह है कि हमें इंजीनियरों के पदों और श्रेणियों के लिए विकास तालिका की आवश्यकता होगी। जैसा कि कहावत है: जब समाज में पैंट का कोई रंग भेद नहीं है, तो कोई उद्देश्य नहीं है! और जब कोई लक्ष्य नहीं है ...

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

प्रत्येक श्रेणी के लिए, हमने नौकरी विवरणों के साथ दस्तावेज विकसित किए, जहां कर्मचारियों के कार्यों और भूमिकाएं निर्धारित की गईं, और सेवाओं और काम के क्षेत्रों के लिए कर्मचारियों की जिम्मेदारी के क्षेत्रों को भी इंगित किया गया।

लेकिन चूंकि हम, इंजीनियरिंग के अलावा, प्रोग्राम करना भी पसंद करते हैं, और हम में से कोई भी उबाऊ दस्तावेज़ पढ़ना पसंद नहीं करता है, यहाँ भी हमने अपने जीवन को थोड़ा सरल किया है। हमने प्रत्येक निर्देश को Word में नहीं लिखा, लेकिन सादे पाठ के रूप में एक विशेष मार्कडाउन मार्कअप भाषा के साथ स्वरूपित किया । उसी समय, किसी भी संपादक में एक व्यक्ति द्वारा इसकी पठनीयता खो नहीं जाती है। उसके बाद, हमने इन ग्रंथों को अपने गीतालाब भंडार में सहेजा। गीतालाब स्वयं बहुत ही खूबसूरती से विभिन्न दस्तावेज़ स्वरूपों को प्रदर्शित कर सकता है, जिसमें मार्कडाउन ड्रॉ भी शामिल है ताकि इसे वर्ड से अलग न किया जा सके। और मानक गिट क्लाइंट में कई अतिरिक्त विशेषताएं हैं, उदाहरण के लिए, यह दो दस्तावेजों के बीच अंतर (अंतर) दिखा सकता है।

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

git --no-pager diff --no-index 
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md

कंसोल में, जो सभी सॉफ़्टवेयर इंजीनियरों के लिए उपयोग किया जाता है, माइनस साइन और लाल रंग उन आवश्यकताओं के लिए बाहर खड़े होते हैं जो बदल गए हैं या हटा दिए गए हैं, और जोड़ा लाइनें एक प्लस चिह्न और हरे रंग के साथ बाहर खड़ी हैं: प्रत्येक पंक्ति प्लस एक नई आवश्यकता है।

हां, हम थोड़ा तकनीकी विशेषज्ञ हैं, लेकिन फिर यह हमारे लिए एक अच्छा समाधान है:

DevOps इंजीनियर प्रतियोगिता मानचित्र

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

तो हमारे विभाग में काम करने वाले एक DevOps इंजीनियर को क्या करना चाहिए? ऐसा करने के लिए, आपको पहले यह निर्धारित करने की आवश्यकता है कि सामान्य ज्ञान क्या ज्ञान, कौशल और क्षमता (संक्षिप्त ZUN ) हैं।

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

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

इस प्रकार, हम एक सारणीबद्ध रूप में एक इंजीनियर के लिए हमारी सभी आवश्यकताओं का वर्णन करने और वर्गीकृत करने की आवश्यकता पर आए थे, और हमारे पास " DevOps Engineers 1.0 कॉम्पीटिशन मैप " है। यह इस तरह दिखता है: तालिका को चार बड़े वर्गों में विभाजित किया गया है:

हमारे DevOps- विभाग के कर्मचारियों की सामान्य दक्षताओं का विवरण, रोजमर्रा के कार्यों के सफल समाधान के लिए आवश्यक है।
ज्ञान DevOps इंजीनियरों का विशिष्ट, उत्पाद-उन्मुख ज्ञान है।
— ; .
— ; , .

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

2018 में, मेरे सहयोगियों और मैंने उत्पादन प्रक्रिया के तथाकथित तकनीकी मानचित्र को विकसित किया और बनाया (हेबर " अराजकता प्रबंधन पर लेख पढ़ें : हमने तकनीकी नक्शे की मदद से चीजों को रखा ")। उसके लिए धन्यवाद, हम उत्पाद, उत्पाद में इस्तेमाल की जाने वाली तकनीकों और उत्पाद वाहक के चरणों के आधार पर DevOps इंजीनियरों की दक्षताओं के विकास और विकास का वेक्टर बनाने के करीब आए हैं।

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

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

पुनश्च लेख जनवरी की बैठक के लिए कहानी पर आधारित है, जिसमें हेस के सहयोगियों ने हमें अनुभवों के आदान-प्रदान के लिए आमंत्रित किया है (आप प्रस्तुति और पाठ देख सकते हैं )।

लेखक : तैमूर गिल्मुलिन- डिप्टी। प्रौद्योगिकी और विकास प्रक्रियाओं के प्रमुख (DevOps), सकारात्मक प्रौद्योगिकी।