DevOps कोण आहेत?

याक्षणी, ही बाजारातील सर्वात महाग स्थिती आहे. "DevOps" अभियंत्यांचा गोंधळ सर्व कल्पना करण्यायोग्य मर्यादेच्या पलीकडे आहे आणि वरिष्ठ DevOps अभियंत्यांसह आणखी वाईट आहे.
मी इंटिग्रेशन आणि ऑटोमेशन विभागाचा प्रमुख म्हणून काम करतो, इंग्रजी डीकोडिंगचा अंदाज लावा - DevOps व्यवस्थापक. इंग्रजी उतारा आपल्या दैनंदिन क्रियाकलापांना प्रतिबिंबित करते हे संभव नाही, परंतु या प्रकरणात रशियन आवृत्ती अधिक अचूक आहे. माझ्या क्रियाकलापाच्या स्वरूपामुळे, मला माझ्या कार्यसंघाच्या भविष्यातील सदस्यांची मुलाखत घेण्याची आवश्यकता असणे स्वाभाविक आहे, आणि गेल्या वर्षभरात, सुमारे 50 लोक माझ्यामधून गेले आहेत आणि माझ्या कर्मचार्‍यांसह प्रीस्क्रीनवर समान संख्या कापली गेली आहे.

आम्ही अजूनही सहकाऱ्यांना शोधत आहोत, कारण DevOps लेबलच्या मागे विविध प्रकारच्या अभियंत्यांचा खूप मोठा थर लपलेला आहे.

खाली लिहिलेले सर्व काही माझे वैयक्तिक मत आहे, आपण त्याच्याशी सहमत असणे आवश्यक नाही, परंतु मी कबूल करतो की या विषयावरील आपल्या वृत्तीमध्ये काही रंग भरेल. पक्षातून बाहेर पडण्याचा धोका असूनही, मी माझे मत प्रकाशित करतो कारण मला विश्वास आहे की त्याला एक स्थान आहे.

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

तर DevOps अभियंते कोण आहेत?

चला त्याच्या देखाव्याच्या इतिहासासह प्रारंभ करूया - अपेक्षित परिणाम म्हणून, उत्पादनाच्या उत्पादनाची गती वाढविण्यासाठी लहान संघांमधील परस्परसंवादाला अनुकूल करण्याच्या दिशेने विकास ऑपरेशन्स आणखी एक पाऊल म्हणून दिसू लागले. उत्पादन वातावरण व्यवस्थापित करण्यासाठी कार्यपद्धती आणि दृष्टीकोनांच्या ज्ञानासह विकास कार्यसंघ मजबूत करणे ही कल्पना होती. दुसऱ्या शब्दांत, विकसकाला त्याचे उत्पादन विशिष्ट परिस्थितीत कसे कार्य करते हे समजून घेणे आणि माहित असणे आवश्यक आहे, त्याचे उत्पादन कसे उपयोजित करायचे हे समजून घेतले पाहिजे, कार्यप्रदर्शन सुधारण्यासाठी पर्यावरणाची कोणती वैशिष्ट्ये समायोजित केली जाऊ शकतात. तर, काही काळासाठी, DevOps दृष्टिकोन असलेले विकसक दिसू लागले. DevOps विकसकांनी त्यांचे क्रियाकलाप आणि उत्पादन वातावरणाचे कार्यप्रदर्शन सुलभ करण्यासाठी बिल्ड आणि पॅकेजिंग स्क्रिप्ट लिहिल्या. तथापि, सोल्यूशन आर्किटेक्चरची जटिलता आणि कालांतराने पायाभूत घटकांच्या परस्पर प्रभावामुळे वातावरणाचे कार्यप्रदर्शन बिघडू लागले; प्रत्येक पुनरावृत्तीसह, विशिष्ट घटकांची अधिकाधिक सखोल समज आवश्यक होती, ज्यामुळे अतिरिक्त घटकांमुळे विकसकाची उत्पादकता कमी होते. विशिष्ट कार्यासाठी घटक आणि ट्यूनिंग सिस्टम समजून घेण्याचा खर्च. . विकसकाची स्वतःची किंमत वाढली, त्यासोबत उत्पादनाची किंमत, टीममधील नवीन विकसकांच्या गरजा झपाट्याने वाढल्या, कारण त्यांना “स्टार” विकासाच्या जबाबदाऱ्याही पूर्ण कराव्या लागल्या आणि स्वाभाविकच “तारे” कमी झाले. आणि कमी उपलब्ध. हे देखील लक्षात घेण्यासारखे आहे की, माझ्या अनुभवानुसार, काही विकासकांना ऑपरेटिंग सिस्टम कर्नल, पॅकेट राउटिंग नियम आणि होस्ट सुरक्षा पैलूंद्वारे पॅकेट प्रक्रियेच्या तपशीलांमध्ये स्वारस्य आहे. तार्किक पायरी म्हणजे एखाद्या प्रशासकाला आकर्षित करणे ज्याला याची माहिती आहे आणि त्याला समान जबाबदाऱ्या सोपविणे, ज्याने त्याच्या अनुभवामुळे, “स्टार” विकासाच्या खर्चाच्या तुलनेत कमी खर्चात समान निर्देशक प्राप्त करणे शक्य झाले. अशा प्रशासकांना एका संघात ठेवण्यात आले होते आणि त्याचे मुख्य कार्य विशिष्ट संघाच्या नियमांनुसार चाचणी आणि उत्पादन वातावरण व्यवस्थापित करणे हे या विशिष्ट संघाला वाटप केलेल्या संसाधनांसह होते. अशाप्रकारे, खरं तर, बहुसंख्यांच्या मनात DevOps प्रकट झाले.

अंशतः किंवा पूर्णपणे, कालांतराने, या प्रणाली प्रशासकांनी विकासाच्या क्षेत्रातील या विशिष्ट संघाच्या गरजा समजून घेण्यास सुरुवात केली, विकासक आणि परीक्षकांचे जीवन कसे सोपे बनवायचे, अपडेट कसे आणायचे आणि शुक्रवारी रात्रभर राहण्याची गरज नाही. कार्यालय, उपयोजन त्रुटी सुधारणे. वेळ निघून गेला, आणि आता "तारे" सिस्टम प्रशासक होते ज्यांना विकासकांना काय हवे आहे हे समजले. प्रभाव कमी करण्यासाठी, व्यवस्थापन उपयुक्तता येऊ लागल्या; प्रत्येकाला ओएस स्तर वेगळे करण्याच्या जुन्या आणि विश्वासार्ह पद्धती आठवल्या, ज्यामुळे सुरक्षा, नेटवर्क भागाचे व्यवस्थापन आणि होस्ट कॉन्फिगरेशनसाठी आवश्यकता कमी करणे शक्य झाले. संपूर्ण आणि परिणामी, नवीन "तारे" साठी आवश्यकता कमी करा.

एक "अद्भुत" गोष्ट दिसली - डॉकर. का अद्भुत? होय, केवळ क्रोट किंवा जेलमध्ये अलगाव निर्माण करण्यासाठी, तसेच ओपनव्हीझेड, ओएसचे क्षुल्लक ज्ञान आवश्यक असल्याने, याउलट, युटिलिटी तुम्हाला एका विशिष्ट होस्टवर आत आणि हाताने आवश्यक असलेल्या सर्व गोष्टींसह एक वेगळे ऍप्लिकेशन वातावरण तयार करण्याची परवानगी देते. पुन्हा विकासाच्या बळावर, आणि सिस्टम प्रशासक फक्त एका होस्टसह व्यवस्थापित करू शकतो, त्याची सुरक्षा आणि उच्च उपलब्धता सुनिश्चित करतो - एक तार्किक सरलीकरण. परंतु प्रगती थांबत नाही आणि सिस्टम पुन्हा अधिकाधिक जटिल होत आहेत, अधिकाधिक घटक आहेत, एक होस्ट यापुढे सिस्टमच्या गरजा पूर्ण करत नाही आणि क्लस्टर तयार करणे आवश्यक आहे, आम्ही पुन्हा सिस्टम प्रशासकांकडे परत जात आहोत जे या प्रणाली तयार करण्यास सक्षम.

सायकल नंतर सायकल, विकास आणि/किंवा प्रशासन सुलभ करणार्‍या विविध प्रणाली दिसतात, ऑर्केस्ट्रेशन सिस्टम्स दिसतात, ज्या, जोपर्यंत तुम्हाला मानक प्रक्रियेपासून विचलित होण्याची आवश्यकता नाही, तो वापरण्यास सोपा आहे. मायक्रोसर्व्हिस आर्किटेक्चर देखील वर वर्णन केलेल्या सर्व गोष्टी सुलभ करण्याच्या उद्देशाने दिसू लागले - कमी संबंध, व्यवस्थापित करणे सोपे. माझ्या अनुभवात, मला पूर्णपणे मायक्रोसर्व्हिस आर्किटेक्चर सापडले नाही, मी म्हणेन 50 ते 50 - 50 टक्के मायक्रोसर्व्हिसेस, ब्लॅक बॉक्स, आले, प्रक्रिया करून बाहेर आले, इतर 50 फाटलेल्या मोनोलिथ आहेत, सेवा इतरांपेक्षा वेगळे काम करू शकत नाहीत. घटक या सर्वांमुळे विकासक आणि प्रशासक दोघांच्या ज्ञानाच्या पातळीवर पुन्हा निर्बंध लादले गेले.

एखाद्या विशिष्ट संसाधनाच्या तज्ञांच्या ज्ञानाच्या पातळीवर असेच “स्विंग” आजही चालू आहेत. परंतु आपण थोडेसे विषयांतर करतो, हायलाइट करण्यासारखे बरेच मुद्दे आहेत.

बिल्ड इंजिनीअर/रिलीझ इंजिनीअर

अत्यंत विशेष अभियंते जे सॉफ्टवेअर बिल्ड प्रक्रिया आणि प्रकाशनांचे मानकीकरण करण्याचे साधन म्हणून उदयास आले. व्यापक चपळ परिचयाच्या प्रक्रियेत, असे दिसते की त्यांनी मागणी करणे थांबवले आहे, परंतु हे प्रकरण फार दूर आहे. हे स्पेशलायझेशन औद्योगिक स्तरावर असेंब्ली आणि सॉफ्टवेअरचे वितरण प्रमाणित करण्याचे साधन म्हणून दिसून आले, उदा. कंपनीच्या सर्व उत्पादनांसाठी मानक तंत्र वापरणे. DevOps च्या आगमनाने, विकासकांनी त्यांची कार्ये अंशतः गमावली, कारण तेच विकसक होते ज्यांनी डिलिव्हरीसाठी उत्पादन तयार करण्यास सुरुवात केली आणि बदलत्या पायाभूत सुविधा आणि गुणवत्तेचा विचार न करता शक्य तितक्या लवकर वितरित करण्याचा दृष्टीकोन पाहता, कालांतराने त्यांचे रूपांतर झाले. बदलांचा थांबा, कारण गुणवत्ता मानकांचे पालन करणे अपरिहार्यपणे वितरण कमी करते. त्यामुळे, हळूहळू, बिल्ड/रिलीज अभियंत्यांच्या कार्यक्षमतेचा काही भाग सिस्टम प्रशासकांच्या खांद्यावर स्थलांतरित झाला.

Ops खूप भिन्न आहेत

आम्ही पुढे जातो आणि पुन्हा मोठ्या प्रमाणात जबाबदार्‍यांची उपस्थिती आणि पात्र कर्मचार्‍यांची कमतरता आम्हाला कठोर स्पेशलायझेशनकडे ढकलते, जसे की पावसानंतर मशरूम, विविध ऑपरेशन्स दिसतात:

• TechOps - enikey सिस्टम प्रशासक उर्फ ​​​​हेल्पडेस्क अभियंता
• LiveOps - सिस्टम प्रशासक प्रामुख्याने उत्पादन वातावरणासाठी जबाबदार आहेत
• क्लाउडऑप्स - सार्वजनिक क्लाउड्स Azure, AWS, GCP, इ. मध्ये विशेष प्रणाली प्रशासक.
• PlatOps/InfraOps/SysOps - इन्फ्रास्ट्रक्चर सिस्टम प्रशासक.
• NetOps - नेटवर्क प्रशासक
• SecOps - माहिती सुरक्षिततेमध्ये तज्ञ असलेले सिस्टम प्रशासक - PCI अनुपालन, CIS अनुपालन, पॅचिंग इ.

DevOps ही (सैद्धांतिकदृष्ट्या) अशी व्यक्ती आहे जी विकास चक्राच्या सर्व प्रक्रिया प्रथम हाताने समजून घेते - विकास, चाचणी, उत्पादन आर्किटेक्चर समजते, सुरक्षा जोखमींचे मूल्यांकन करण्यास सक्षम आहे, दृष्टीकोन आणि ऑटोमेशन साधनांशी परिचित आहे, किमान उच्च पातळीवर स्तर, या व्यतिरिक्त, प्री- आणि पोस्ट-प्रोसेसिंग देखील समजते. उत्पादन प्रकाशन समर्थन. ऑपरेशन्स आणि डेव्हलपमेंट या दोन्हीसाठी वकील म्हणून काम करण्यास सक्षम असलेली व्यक्ती, जी या दोन स्तंभांमधील अनुकूल सहकार्यासाठी परवानगी देते. कार्यसंघांद्वारे कामाचे नियोजन आणि ग्राहकांच्या अपेक्षा व्यवस्थापित करण्याच्या प्रक्रियेस समजते.

या प्रकारचे कार्य आणि जबाबदाऱ्या पार पाडण्यासाठी, या व्यक्तीकडे केवळ विकास आणि चाचणी प्रक्रियाच नव्हे तर उत्पादनाच्या पायाभूत सुविधांचे व्यवस्थापन तसेच संसाधन नियोजन देखील व्यवस्थापित करण्याचे साधन असणे आवश्यक आहे. या समजुतीतील DevOps एकतर IT मध्ये, R&D मध्ये किंवा PMO मध्ये देखील असू शकत नाहीत; या सर्व क्षेत्रांमध्ये त्याचा प्रभाव असणे आवश्यक आहे - कंपनीचे तांत्रिक संचालक, मुख्य तांत्रिक अधिकारी.

तुमच्या कंपनीत हे खरे आहे का? - मला शंका आहे. बहुतेक प्रकरणांमध्ये, हे एकतर IT किंवा R&D आहे.

निधीची कमतरता आणि क्रियाकलापांच्या या तीन क्षेत्रांपैकी किमान एकावर प्रभाव टाकण्याची क्षमता समस्यांचे वजन त्याकडे वळवेल जेथे हे बदल लागू करणे सोपे आहे, जसे की स्थिरतेनुसार "डर्टी" कोडच्या संबंधात रिलीझवर तांत्रिक निर्बंध लागू करणे. विश्लेषक प्रणाली. म्हणजेच, जेव्हा PMO कार्यक्षमतेच्या प्रकाशनासाठी कठोर अंतिम मुदत सेट करते, तेव्हा R&D या मुदतीमध्ये उच्च-गुणवत्तेचा निकाल देऊ शकत नाही आणि ते शक्य तितके चांगले तयार करू शकत नाही, नंतरसाठी रिफॅक्टरिंग सोडून, ​​IT शी संबंधित DevOps तांत्रिक मार्गाने प्रकाशन अवरोधित करते. . परिस्थिती बदलण्याच्या अधिकाराचा अभाव, जबाबदार कर्मचार्‍यांच्या बाबतीत, ते ज्यावर प्रभाव टाकू शकत नाहीत त्याबद्दल अति-जबाबदारी प्रकट होते, विशेषत: जर या कर्मचार्‍यांना चुका समजतात आणि दिसतात आणि त्या कशा दुरुस्त करायच्या - "आनंद म्हणजे अज्ञान", आणि परिणामी या कर्मचार्‍यांचे नुकसान आणि नुकसान.

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

चला विविध कंपन्यांमधील DevOps पदांसाठी अनेक रिक्त जागा पाहू.

आम्ही तुम्हाला भेटायला तयार आहोत जर तुम्ही:

1. तुम्ही Zabbix चे मालक आहात आणि Prometheus काय आहे हे तुम्हाला माहीत आहे;
2. इप्टेबल्स;
3. BASH पीएचडी विद्यार्थी;
4. प्राध्यापक उत्तरदायी;
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 - व्हर्च्युअलायझेशन - मिडल सिस्टम अॅडमिनिस्ट्रेटर, किंवा तथाकथित क्लाउडऑप्स, विशिष्ट होस्टिंग साइटच्या सेवांचे प्रगत ज्ञान, निधीच्या कार्यक्षम वापरासाठी आणि देखभालवरील भार कमी करण्यासाठी

या रिक्त पदाचा सारांश, आम्ही असे म्हणू शकतो की मुलांसाठी मध्यम/वरिष्ठ सिस्टम प्रशासक पुरेसा आहे.

तसे, आपण 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 - कनिष्ठ प्रणाली प्रशासक - होय, एक प्रशासक ज्याला मूलभूत ऑटोमेशन स्क्रिप्ट कसे लिहायचे हे माहित नाही, भाषा कोणतीही असो, प्रशासक नाही - enikey.
• 5 - मध्य प्रणाली प्रशासक
• 6 - वरिष्ठ सिस्टम प्रशासक

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

आणखी एक:

1. Devops अनुभव;
2. CI/CD प्रक्रिया तयार करण्यासाठी एक किंवा अधिक उत्पादने वापरण्याचा अनुभव. Gitlab CI एक फायदा होईल;
3. कंटेनर आणि वर्च्युअलायझेशनसह कार्य करणे; जर तुम्ही डॉकर वापरला असेल, तर चांगले, पण तुम्ही k8 वापरल्यास, उत्तम!
4. चपळ संघात काम करण्याचा अनुभव;
5. कोणत्याही प्रोग्रामिंग भाषेचे ज्ञान;

बघूया:

• 1 - हम्म... अगं म्हणजे काय? =) बहुधा त्यामागे काय दडलेले आहे हे त्यांनाच माहीत नसावे
• 2 - अभियंता तयार करा
• 3 - मध्य प्रणाली प्रशासक
• 4 - सॉफ्ट स्किल, आम्ही सध्या त्याचा विचार करणार नाही, जरी चपळ ही दुसरी गोष्ट आहे ज्याचा अर्थ सोयीस्कर पद्धतीने केला जातो.
• 5 - खूप शब्दशः - ती स्क्रिप्टिंग भाषा किंवा संकलित भाषा असू शकते. मला आश्चर्य वाटते की शाळेत पास्कल आणि बेसिक लिहिणे त्यांना शोभेल का? =)

सिस्टम प्रशासकाद्वारे हा मुद्दा का व्यापला जातो हे समजून घेण्यासाठी मला पॉइंट 3 बद्दल एक टीप देखील ठेवायची आहे. Kubernetes हे फक्त एक ऑर्केस्ट्रेशन आहे, एक साधन जे नेटवर्क ड्रायव्हर्स आणि व्हर्च्युअलायझेशन/आयसोलेशन होस्ट्सना थेट आदेश काही कमांड्समध्ये गुंडाळते आणि तुम्हाला त्यांच्याशी संवाद साधण्याची परवानगी देते, इतकेच. उदाहरणार्थ, ‘बिल्ड फ्रेमवर्क’ बनवू या, ज्याला मी फ्रेमवर्क मानत नाही. होय, मला कुठेही मेक ढकलण्याची फॅशन माहित आहे, जिथे ते आवश्यक आहे आणि आवश्यक नाही - मेवेन इन मेक लपेटणे, उदाहरणार्थ, गंभीरपणे?
मूलत:, मेक हे शेलवर फक्त एक आवरण आहे, जे k8s प्रमाणे संकलन, लिंकिंग आणि संकलन पर्यावरण आदेश सुलभ करते.

एकदा, मी एका व्यक्तीची मुलाखत घेतली ज्याने ओपनस्टॅकच्या शीर्षस्थानी त्याच्या कामात k8s वापरला आणि त्याने त्यावर सेवा कशा तैनात केल्या याबद्दल बोललो, तथापि, जेव्हा मी ओपनस्टॅकबद्दल विचारले तेव्हा असे दिसून आले की ते प्रशासित होते, तसेच सिस्टमद्वारे वाढवले ​​गेले होते. प्रशासक तुम्हाला खरोखर असे वाटते का की ज्या व्यक्तीने ओपनस्टॅक स्थापित केले आहे, तो त्याच्या मागे कोणता प्लॅटफॉर्म वापरतो याची पर्वा न करता, k8s वापरण्यास सक्षम नाही? =)
हा अर्जदार प्रत्यक्षात DevOps नाही, परंतु एक सिस्टम प्रशासक आहे आणि अधिक अचूकपणे सांगायचे तर, Kubernetes प्रशासक आहे.

चला पुन्हा एकदा सारांश देऊ - मध्यम/वरिष्ठ सिस्टीम प्रशासक त्यांच्यासाठी पुरेसा असेल.

ग्रॅममध्ये किती वजन करावे

सूचित रिक्त पदांसाठी प्रस्तावित वेतन श्रेणी 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" च्या अनुभवानुसार, अनुभवाचा वापर केला गेला की किमान कसा तरी SDLC वर परिणाम झाला.

वरीलवरून असे दिसून येते की प्रत्यक्षात कंपन्यांना DevOps ची गरज नसते आणि ते प्रशासक नियुक्त करून सुरुवातीच्या नियोजित खर्चाच्या किमान 50 टक्के बचत करू शकतात; शिवाय, ते शोधत असलेल्या व्यक्तीच्या जबाबदाऱ्या अधिक स्पष्टपणे परिभाषित करू शकतात. आणि गरज जलद भरा. आपण हे देखील विसरू नये की जबाबदाऱ्यांचे स्पष्ट विभाजन आपल्याला कर्मचार्‍यांच्या आवश्यकता कमी करण्यास तसेच ओव्हरलॅप्सच्या अनुपस्थितीमुळे संघात अधिक अनुकूल वातावरण निर्माण करण्यास अनुमती देते. बहुसंख्य रिक्त पदे युटिलिटीज आणि DevOps लेबलांनी भरलेली आहेत, परंतु ती DevOps अभियंत्याच्या वास्तविक आवश्यकतांवर आधारित नाहीत, फक्त टूल प्रशासकासाठी विनंती करतात.

DevOps अभियंत्यांना प्रशिक्षण देण्याची प्रक्रिया देखील केवळ विशिष्ट कार्ये, उपयुक्तता यांच्या संचापुरती मर्यादित आहे आणि प्रक्रिया आणि त्यांचे अवलंबन याबद्दल सामान्य समज प्रदान करत नाही. जेव्हा एखादी व्यक्ती या क्लस्टरमधील Fluentd साइडकार आणि लॉगिंग सिस्टमसाठी AWS ELK स्टॅकच्या संयोगाने, कन्सोलमध्ये फक्त एक कमांड वापरून टेराफॉर्म वापरून AWS EKS तैनात करू शकते तेव्हा हे नक्कीच चांगले आहे, परंतु जर त्याला समजत नसेल तर लॉग स्वतः प्रक्रिया करण्याचे तत्व आणि ते कशासाठी आवश्यक आहेत, जर तुम्हाला त्यावरील मेट्रिक्स कसे संकलित करायचे आणि सेवेच्या ऱ्हासाचा मागोवा कसा घ्यायचा हे माहित नसेल, तरीही तेच एनकी असेल ज्याला काही उपयुक्तता कशी वापरायची हे माहित असेल.

मागणी, तथापि, पुरवठा तयार करते आणि आम्ही DevOps स्थितीसाठी अत्यंत गरम झालेले बाजार पाहतो, जेथे आवश्यकता वास्तविक भूमिकेशी जुळत नाही, परंतु केवळ सिस्टम प्रशासकांना अधिक कमाई करण्याची परवानगी देते.

मग ते कोण आहेत? DevOps की लोभी सिस्टीम प्रशासक? =)

कसे जगायचे?

नियोक्त्यांनी आवश्यकता अधिक तंतोतंत तयार केल्या पाहिजेत आणि ज्यांना आवश्यक आहे ते शोधले पाहिजेत आणि लेबले फेकू नयेत. DevOps काय करतात हे तुम्हाला माहीत नाही - तुम्हाला त्या बाबतीत त्यांची गरज नाही.

कामगार - शिका. तुमचे ज्ञान सतत सुधारा, प्रक्रियांचे एकूण चित्र पहा आणि तुमच्या ध्येयाचा मार्ग मागोवा घ्या. तुम्हाला पाहिजे ते तुम्ही बनू शकता, तुम्हाला फक्त प्रयत्न करावे लागतील.

स्त्रोत: www.habr.com