कौन हैं देवो?

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

हम अभी भी सहकर्मियों की तलाश कर रहे हैं, क्योंकि DevOps लेबल के पीछे विभिन्न प्रकार के इंजीनियरों की एक बहुत बड़ी परत है।

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

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

तो DevOps इंजीनियर कौन हैं?

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

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

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

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

किसी विशेष संसाधन के विशेषज्ञ ज्ञान के स्तर के समान "झूलों" आज भी जारी हैं। लेकिन हम थोड़ा विचलित थे, कई बिंदु हैं जो हाइलाइटिंग के लायक हैं।

इंजीनियर / रिलीज इंजीनियर बनाएँ

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

ऑप्स इतना अलग है

हम आगे बढ़ते हैं और फिर से जिम्मेदारियों की एक विस्तृत श्रृंखला की उपस्थिति और योग्य कर्मियों की कमी हमें कठिन विशेषज्ञता की ओर धकेलती है, जैसे बारिश के बाद मशरूम, विभिन्न ऑपरेशन दिखाई देते हैं:

• TechOps - एक जैसे सिस्टम प्रशासक उर्फ ​​हेल्पडेस्क इंजीनियर
• LiveOps - सिस्टम प्रशासक मुख्य रूप से उत्पादक वातावरण के लिए जिम्मेदार हैं
• CloudOps - सिस्टम प्रशासक, जो अज़ुरे, AWS, GCP, आदि के सार्वजनिक "बादलों" में विशेषज्ञता रखते हैं।
• प्लैटिप्स / इन्फ्राओप्स / एसआईएसओपीएस - बुनियादी ढांचा प्रणाली प्रशासक।
• नेटऑप्स - नेटवर्क प्रशासक
• SecOps - सूचना सुरक्षा में विशेषज्ञता प्रणाली प्रशासक - PCI अनुपालन, CIS अनुपालन, पैचिंग, आदि।

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

इस तरह के काम और जिम्मेदारियों को निभाने के लिए, इस व्यक्ति के पास न केवल विकास, परीक्षण, बल्कि उत्पाद बुनियादी ढांचे के प्रबंधन के साथ-साथ संसाधन नियोजन को नियंत्रित करने का साधन होना चाहिए। इस अर्थ में DevOps IT, R & D, या PMO में भी स्थित नहीं हो सकता है, इन सभी क्षेत्रों में इसका प्रभाव होना चाहिए - कंपनी के तकनीकी निदेशक, मुख्य तकनीकी अधिकारी।

क्या आपकी कंपनी में ऐसा है? - मुझे शक है। ज्यादातर मामलों में, यह या तो आईटी या आरएंडडी है।

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

बाजार DevOps संसाधन

आइए विभिन्न कंपनियों से कुछ DevOps नौकरी के उद्घाटन को देखें।

अगर आप:

1. खुद ज़बिक्स और जानिए कि प्रोमेथियस क्या है;
2. iptables;
3. स्नातक छात्र BASH;
4. प्रोफेसर Ansible;
5. लिनक्स गुरु
6. डिबग का उपयोग करने और डेवलपर्स के साथ मिलकर एप्लिकेशन की समस्याओं को जानने का तरीका जानें (php / java / python);
7. रूटिंग से आपको नखरे नहीं होते हैं;
8. सिस्टम सुरक्षा पर महत्वपूर्ण ध्यान दें;
9. बैकअप "सब कुछ और सब कुछ", और यह भी सफलतापूर्वक "सब कुछ और सब कुछ" बहाल;
10. आप जानते हैं कि न्यूनतम से अधिकतम निचोड़ने के लिए सिस्टम को कैसे कॉन्फ़िगर किया जाए;
11. Postgres और MySQL पर सोने की प्रतिकृति कॉन्फ़िगर करें;
12. आपके लिए CI / CD की स्थापना और समायोजन नाश्ता / दोपहर / रात के भोजन की तरह एक आवश्यकता है।
13. AWS के साथ अनुभव है;
14. कंपनी के साथ विकसित करने के लिए तैयार;

तो:

• 1 से 6 - सिस्टम प्रशासक
• 7 - नेटवर्क प्रशासन का एक सा, जो सिस्टम प्रशासक, मध्य स्तर में भी फिट बैठता है
• 8 - थोड़ी सी सुरक्षा, जो कि एक मध्य-स्तरीय सिस्टम प्रशासक के लिए अनिवार्य है
• 9-11 - मध्य प्रणाली प्रशासक
• 12 - सेट किए गए कार्यों के आधार पर, मध्य सिस्टम एडमिनिस्ट्रेटर या बिल्ड इंजीनियर
• 13 - वर्चुअलाइजेशन - मध्य सिस्टम प्रशासक, या तथाकथित CloudOps, धन के कुशल उपयोग के लिए और एक विशेष होस्टिंग प्लेटफ़ॉर्म की सेवाओं का उन्नत ज्ञान, सेवा पर भार को कम करने के लिए

इस रिक्ति को संक्षेप में, हम कह सकते हैं कि मध्य / वरिष्ठ प्रणाली प्रशासक लोगों के लिए पर्याप्त है।

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

एक और रिक्ति पर विचार करें:

1. अत्यधिक भरी हुई व्यवस्था के निर्माण में अनुभव;
2. लिनक्स ओएस, सिस्टम-वाइड सॉफ़्टवेयर और वेब स्टैक (Nginx, PHP / Python, HAProxy, MySQL / PostgreSQL, Memcached, Redis, RabbitMQ, ELK) का उत्कृष्ट ज्ञान;
3. वर्चुअलाइजेशन सिस्टम (KVM, VMWare, LXC / Docker) के साथ अनुभव;
4. स्क्रिप्टिंग भाषाओं का ज्ञान;
5. नेटवर्क प्रोटोकॉल के नेटवर्क के संचालन के सिद्धांतों को समझना;
6. दोष-सहिष्णु प्रणालियों के निर्माण के सिद्धांतों को समझना;
7. स्वतंत्रता और पहल;

पार्स:

• 1 - वरिष्ठ प्रणाली प्रशासक
• 2 - इस स्टैक में निवेश किए गए अर्थ के आधार पर - मध्य / वरिष्ठ सिस्टम प्रशासक
• 3 - अनुभव, सहित, इसका मतलब हो सकता है - "क्लस्टर नहीं बढ़ा, लेकिन वर्चुअल मशीन बनाई और प्रबंधित की गई, एक डॉकर होस्ट था, कंटेनरों तक पहुंच बाधित थी" - मध्य सिस्टम प्रशासक
• 4 - जूनियर सिस्टम प्रशासक - हाँ, व्यवस्थापक प्राथमिक स्वचालन स्क्रिप्ट लिखने में सक्षम नहीं है, भाषा की परवाह किए बिना, व्यवस्थापक नहीं - एक जैसे।
• 5 - मध्य प्रणाली प्रशासक
• 6 - वरिष्ठ सिस्टम प्रशासक

सारांश - मध्य / वरिष्ठ प्रणाली प्रशासक

एक और एक:

1. अनुभव देवों;
2. CI / CD प्रक्रियाएँ बनाने के लिए एक या एक से अधिक उत्पादों का उपयोग करने का अनुभव। Gitlab CI एक फायदा होगा;
3. कंटेनरों और वर्चुअलाइजेशन के साथ काम करें; यदि आप डॉकटर का उपयोग करते हैं - ठीक है, लेकिन यदि k8s - महान!
4. एक फुर्तीली टीम में अनुभव;
5. किसी भी प्रोग्रामिंग भाषा का ज्ञान;

आइए देखें:

• 1 - हम्म ... दोस्तों का क्या मतलब है? =) सबसे अधिक संभावना है कि वे खुद नहीं जानते कि इसके पीछे क्या है
• 2 - इंजीनियर का निर्माण
• 3 - मध्य प्रणाली प्रशासक
• 4 - सॉफ्ट-स्किल, हम अभी तक इस पर विचार नहीं करेंगे, हालांकि एजाइल एक और चीज है जिसे आसानी से समझा जाता है।
• ५ - बहुत बड़ा - यह एक स्क्रिप्टिंग भाषा हो सकती है, या संकलित हो सकती है। दिलचस्प है, क्या उसने पास्कल और बेसिक पर स्कूल में लिखा था? =)

मैं इस बिंदु को समझने के लिए 3 बिंदुओं के बारे में एक टिप्पणी छोड़ना चाहूंगा कि यह बिंदु सिस्टम व्यवस्थापक द्वारा क्यों कवर किया गया है। Kubernetes सिर्फ एक ऑर्केस्ट्रेशन है, एक उपकरण जो नेटवर्क कमांडरों को प्रत्यक्ष कमांड लपेटता है और वर्चुअलाइजेशन / आइसोलेशन कुछ कमांड में होस्ट करता है और आपको उनके साथ संचार करने की अनुमति देता है, बस। उदाहरण के लिए, 'बिल्ड फ्रेमवर्क' को लें, जो, वैसे, मुझे फ्रेमवर्क के रूप में नहीं मानता है। हां, मुझे लगता है कि मेव को लपेटने के फैशन के बारे में कहीं भी, जहां यह आवश्यक है और आवश्यक नहीं है - मेवेन को लपेटने के लिए, उदाहरण के लिए, गंभीरता से?
संक्षेप में, मेक शेल के ऊपर केवल एक आवरण है, जो संकलन, लिंकिंग, संकलन वातावरण, साथ ही 8s को सरल करता है।

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

हम फिर से संक्षेप में कहते हैं - मध्य / वरिष्ठ प्रणाली प्रशासक उनके लिए पर्याप्त होगा।

ग्राम में कितना लटकना है

संकेतित रिक्तियों के लिए प्रस्तावित वेतन का प्रसार 90k-200k है
अब मैं सिस्टम एडमिनिस्ट्रेटर और DevOps इंजीनियर्स के मौद्रिक पुरस्कारों के बीच एक समानता बनाना चाहूंगा।

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

अनुभव:

1. 3 साल से कम उम्र - जूनियर
2. 6 साल से कम उम्र के - मध्य
3. 6 से अधिक - वरिष्ठ

कर्मचारी खोज साइट प्रदान करता है:
सिस्टम प्रवेशक:

1. जूनियर - 2 साल - 50k रगड़।
2. मध्य - 5 साल - 70k रूबल।
3. वरिष्ठ - 11 साल की उम्र - 100k रूबल।

DevOps इंजीनियर्स:

1. जूनियर - 2 साल - 100k रगड़।
2. मध्य - 3 साल - 160k रगड़।
3. वरिष्ठ - 6 साल - 220k रगड़।

"DevOps" के अनुभव के अनुसार, हमने अनुभव का उपयोग किया, कम से कम किसी तरह एसडीएलसी को प्रभावित किया।

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

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

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

तो वे कौन हैं? DevOps या लालची सिस्टम प्रशासक? =)

आगे कैसे जीना है?

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

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