डेवऑप्स कौन हैं?

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

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

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

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

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

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

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

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

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

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

बिल्ड इंजीनियर/रिलीज़ इंजीनियर

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

ऑप्स बहुत अलग हैं

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

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

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

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

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

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

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

आइए विभिन्न कंपनियों से DevOps पदों के लिए कई रिक्तियों पर नजर डालें।

हम आपसे मिलने के लिए तैयार हैं यदि आप:

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

तो:

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

इस रिक्ति को सारांशित करते हुए, हम कह सकते हैं कि मिडिल/सीनियर सिस्टम एडमिनिस्ट्रेटर लोगों के लिए पर्याप्त है।

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

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

1. उच्च-लोड सिस्टम बनाने का अनुभव;
2. Linux OS, सामान्य सिस्टम सॉफ़्टवेयर और वेब स्टैक (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. सीआई/सीडी प्रक्रियाएं बनाने के लिए एक या अधिक उत्पादों का उपयोग करने का अनुभव। गिटलैब सीआई से होगा फायदा;
3. कंटेनर और वर्चुअलाइजेशन के साथ काम करना; यदि आपने डॉकर का उपयोग किया है, तो अच्छा है, लेकिन यदि आपने k8s का उपयोग किया है, तो बहुत अच्छा है!
4. चुस्त टीम में काम करने का अनुभव;
5. किसी भी प्रोग्रामिंग भाषा का ज्ञान;

हम देख लेंगे:

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

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

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

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

ग्राम में कितना वजन करना है

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

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

अनुभव:

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

कर्मचारी खोज साइट ऑफ़र करती है:
सिस्टम प्रशासक:

1. जूनियर - 2 वर्ष - 50 हजार रूबल।
2. मध्य - 5 वर्ष - 70 हजार रूबल।
3. वरिष्ठ - 11 वर्ष - 100 हजार रूबल।

DevOps इंजीनियर:

1. जूनियर - 2 वर्ष - 100 हजार रूबल।
2. मध्य - 3 वर्ष - 160 हजार रूबल।
3. वरिष्ठ - 6 वर्ष - 220 हजार रूबल।

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

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

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

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

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

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

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

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

स्रोत: www.habr.com