DevOps को हुन्?

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

हामी अझै सहकर्मीहरू खोजिरहेका छौं, किनभने DevOps लेबलको पछाडि विभिन्न प्रकारका इन्जिनियरहरूको धेरै ठूलो तह लुकेको छ।

तल लेखिएका सबै मेरो व्यक्तिगत विचार हो, तपाईं यसमा सहमत हुनु आवश्यक छैन, तर म स्वीकार गर्दछु कि यसले विषयप्रति तपाईंको मनोवृत्तिमा केही रंग थप्नेछ। पक्षबाट बाहिर खस्ने जोखिमको बाबजुद, म मेरो विचार प्रकाशित गर्छु किनभने मलाई विश्वास छ कि यो हुनको लागि ठाउँ छ।

कम्पनीहरूसँग DevOps ईन्जिनियरहरू को हुन् भन्ने बारे फरक-फरक बुझाइहरू छन् र, द्रुत रूपमा संसाधन भाडामा लिनको लागि, तिनीहरूले यो लेबल सबैमा झुण्ड्याउँछन्। अवस्था एकदमै अनौठो छ, किनकि कम्पनीहरूले यी व्यक्तिहरूलाई अवास्तविक पारिश्रमिक तिर्न तयार छन्, धेरै अवस्थामा, तिनीहरूका लागि एक उपकरण प्रशासक प्राप्त गर्दै।

त्यसोभए DevOps ईन्जिनियरहरू को हुन्?

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

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

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

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

एक विशेष स्रोत को विशेषज्ञ ज्ञान को स्तर मा समान "स्विंग" आज पनि जारी छ। तर हामी अलिकति बिग्रन्छौं, हाइलाइट गर्न लायक धेरै बिन्दुहरू छन्।

निर्माण इन्जिनियर/रिलीज इन्जिनियर

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

Ops धेरै फरक छन्

हामी अगाडि बढ्छौं र जिम्मेवारीहरूको ठूलो दायराको उपस्थिति र योग्य कर्मचारीहरूको अभावले हामीलाई कडा विशेषज्ञतातर्फ धकेल्छ, जस्तै वर्षा पछि च्याउ, विभिन्न सञ्चालनहरू देखा पर्दछ:

• TechOps - enikey प्रणाली प्रशासक उर्फ ​​​​हेल्पडेस्क इन्जिनियर
• LiveOps - उत्पादन वातावरणको लागि मुख्य रूपमा जिम्मेवार प्रणाली प्रशासकहरू
• CloudOps - सार्वजनिक क्लाउड 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 को मालिक हुनुहुन्छ र प्रोमेथियस के हो थाहा छ;
2. Iptables;
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 - मध्य प्रणाली प्रशासक
• १२ — तोकिएका कार्यहरूमा निर्भर गर्दै, मध्य प्रणाली प्रशासक वा निर्माण इन्जिनियर
• 13 - भर्चुअलाइजेशन - मध्य प्रणाली प्रशासक, वा तथाकथित CloudOps, एक विशेष होस्टिङ साइटको सेवाहरूको उन्नत ज्ञान, कोषको कुशल प्रयोग र मर्मतसम्भारमा भार कम गर्नको लागि।

यो रिक्तता संक्षेपमा, हामी भन्न सक्छौं कि मध्य / वरिष्ठ प्रणाली प्रशासक केटाहरूको लागि पर्याप्त छ।

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

अर्को रिक्तता विचार गरौं:

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

हेरौं:

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

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

अर्को:

1. विकास अनुभव;
2. CI/CD प्रक्रियाहरू सिर्जना गर्न एक वा बढी उत्पादनहरू प्रयोग गर्ने अनुभव। Gitlab CI एक फाइदा हुनेछ;
3. कन्टेनर र भर्चुअलाइजेसनको साथ काम गर्दै; यदि तपाईंले डकर प्रयोग गर्नुभयो भने, राम्रो, तर यदि तपाईंले k8s प्रयोग गर्नुभयो भने, राम्रो!
4. फुर्तिलो टोलीमा काम गर्ने अनुभव;
5. कुनै पनि प्रोग्रामिङ भाषाको ज्ञान;

हेरौं:

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

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

एक पटक, मैले ओपनस्ट्याकको शीर्षमा आफ्नो काममा k8s प्रयोग गर्ने एक केटासँग अन्तर्वार्ता लिएँ, र उसले यसमा सेवाहरू कसरी प्रयोग गर्यो भन्ने बारे कुरा गरे, यद्यपि, जब मैले ओपनस्ट्याकको बारेमा सोधे, यो पत्ता लाग्यो कि यो प्रशासित थियो, साथै प्रणालीद्वारा उठाइयो। प्रशासकहरू। के तपाई वास्तवमै सोच्नुहुन्छ कि एक व्यक्ति जसले OpenStack स्थापना गरेको छ, उसले आफ्नो पछाडि कुन प्लेटफर्म प्रयोग गर्दछ, 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 ईन्जिनियरहरूलाई प्रशिक्षण दिने प्रक्रिया पनि विशेष कार्यहरू, उपयोगिताहरूको सेटमा मात्र सीमित छ, र प्रक्रियाहरू र तिनीहरूको निर्भरताहरूको सामान्य बुझाइ प्रदान गर्दैन। यो निश्चित रूपमा राम्रो छ जब एक व्यक्तिले टेराफर्म प्रयोग गरेर AWS EKS प्रयोग गर्न सक्छ, यस क्लस्टरमा Fluentd sidecar र AWS ELK स्ट्याक 10 मिनेटमा लगिङ प्रणालीको लागि, कन्सोलमा एउटा मात्र आदेश प्रयोग गरेर, तर यदि उसले बुझ्दैन भने। आफैं लगहरू प्रशोधन गर्ने सिद्धान्त र तिनीहरूको लागि के आवश्यक छ, यदि तपाईलाई थाहा छैन कि कसरी मेट्रिक्स सङ्कलन गर्ने र सेवाको गिरावट ट्र्याक गर्ने, तब यो अझै पनि उही enikey हुनेछ जसले केही उपयोगिताहरू कसरी प्रयोग गर्ने भनेर जान्दछन्।

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

त्यसोभए तिनीहरू को हुन्? DevOps वा लोभी प्रणाली प्रशासकहरू? =)

कसरी बाँच्न जारी राख्न?

नियोक्ताहरूले आवश्यकताहरू अझ सटीक रूपमा तयार गर्नुपर्छ र आवश्यक पर्नेहरूलाई खोज्नुपर्छ, र लेबलहरू वरिपरि फाल्नुहुन्न। तपाईलाई थाहा छैन कि DevOps ले के गर्छ - तपाईलाई त्यस अवस्थामा तिनीहरूको आवश्यकता पर्दैन।

कामदार - सिक्नुहोस्। निरन्तर आफ्नो ज्ञान सुधार, प्रक्रिया को समग्र तस्वीर हेर्नुहोस् र आफ्नो लक्ष्य को मार्ग ट्रयाक। तपाईं जो चाहानुहुन्छ बन्न सक्नुहुन्छ, तपाईंले प्रयास मात्र गर्नुपर्छ।

स्रोत: www.habr.com