मुझे 'DevOps Engineer' को नौकरी देने की कोशिश क्यों नहीं करनी चाहिए?

Question

एक DevOps Engineer होने का विचार हाल ही में काफी लोकप्रिय हो गया है , और यह सिर्फ एक व्यक्ति को अपील करने लगता है जो कठपुतली ब्लॉग में वर्णित के रूप में DevOps के कई लाभ प्रदान कर सकता है और प्रदान कर सकता है :

DevOps प्रथाओं का उपयोग करने वाले संगठन अत्यधिक उच्च-कार्य कर रहे हैं: वे हमारे 2015 की DevOps रिपोर्ट के अनुसार, अपने प्रतिद्वंद्वियों की तुलना में 30 गुना अधिक बार कोड तैनात करते हैं, और उनकी तैनाती के 50 प्रतिशत कम विफल होते हैं।

हालाँकि, मैंने इन सुधारों को आजमाने और बनाने के लिए एक DevOps Engineer के विचार का बहुत अधिक मुखर विरोध किया है:

यहां तक ​​कि कोर DevOps विशेषताओं के बारे में व्यापक समझौते के साथ, विवाद "DevOps इंजीनियर" शब्द को घेरता है। कुछ लोग खुद को DevOps मान बताते हैं। कॉन्टीन्यूअस डिलीवरी के सह-लेखक जेज विनम्र बताते हैं कि सिर्फ किसी को DevOps इंजीनियर कहकर देव और ऑप्स के अलावा तीसरा साइलो भी बनाया जा सकता है - "... स्पष्ट रूप से एक गरीब (और विडंबना) तरीका है कि आप इन समस्याओं को हल करने का प्रयास करें। । "

किसी व्यवसाय के लिए इस तरह के एक महान विचार के लिए एक DevOps Engineer को काम पर रखने और 'DevOps को लागू करने' के लिए क्यों नहीं हो सकता है, जैसा कि इस तरह ब्लॉगों द्वारा वकालत किए गए संगठनात्मक परिवर्तन के विपरीत है ? क्या केवल एक पृथक DevOps भूमिका होने से लाभों को नकार दिया जाएगा?

Comments

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

— एड्रियन

Answer 1

TL; DR : आपको कभी भी DevOps टीम किराए पर लेने की कोशिश नहीं करनी चाहिए

---

इसके लिए अनिवार्य रूप से तीन सबसे आम भूमिकाएँ हैं:

1. DevOps वास्तुकार / इंजीलवादी
2. DevOps इंजीनियर
3. सीआई / सीडी इंजीनियर

ये भूमिकाएँ आपके 6 आवश्यक सॉफ़्टवेयर विकास भूमिकाओं से अलग हैं जो पारंपरिक रूप से सॉफ़्टवेयर इंजीनियरिंग संगठन की रचना करती हैं:

1. उत्पाद प्रबंधन
2. सॉफ्टवेयर विकास
3. उपकरण विकास
4. सुरक्षा और अनुपालन
5. गुणवत्ता और परीक्षण
6. सिस्टम ऑपरेशन (SRE)

आइए एक-एक करके तीन भूमिकाओं से गुजरें और देखें कि वे कैसे फिट होते हैं

---

DevOps वास्तुकार या इंजीलवादी

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

कुछ मामलों में और छोटी और मध्यम आकार की कंपनियों के लिए आप DORA की तरह एक परामर्श संगठन को काम पर रखने के बजाय प्रक्रिया शुरू कर सकते हैं।

DevOps इंजीनियर

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

सीआई / सीडी इंजीनियर

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

Comments

मैंने आपके tl को लिंक करने में कठिन समय दिया है; शेष उत्तर के लिए

— ड्राप करें

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

— जिरी क्लौडा

@JiriKlouda उत्कृष्ट उत्तर, मैं लगभग 100% सहमत हूँ, शब्द की कमी "सिस्टम ऑपरेशंस (SRE) - सिस्टम ऑपरेशंस! = साइट विश्वसनीयता अभियंता, उत्तरार्द्ध DevOps के लिए Google का मॉडल है जो अभी भी DevOps के मुख्य सिद्धांतों का प्रतीक है लेकिन कुछ को बरकरार रखता है। विशेषज्ञ ऑपरेटरों की एक टीम होने के फायदे।

— रिचर्ड स्लेटर

मेरा मतलब है कि किसी भी रूप में ऑपरेशन टीम, पारंपरिक या एसआरई या किसी अन्य रूप में बुनियादी ढांचे या प्लेटफ़ॉर्म प्रबंधन। और मुझ पर भरोसा करें, आपके पास पूरी तरह से DevOps को अपनाए बिना साइट विश्वसनीय टीम हो सकती है :)

— जिरी क्लौडा

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

— जिरी क्लौडा

Answer 2

मैं बहस करूँगा Devops Engineer के रूप में आपके प्रश्न लिंक में वर्णित मुख्य रूप से एक sysadmin भूमिका है। इस उत्तर की पृष्ठभूमि के लिए यहां कौशल का हवाला देते हुए:

आपका चढ़ना गियर

• लिनक्स / यूनिक्स प्रशासन में मजबूत पृष्ठभूमि स्वचालन / कॉन्फ़िगरेशन प्रबंधन के साथ कठपुतली, बावर्ची या समकक्ष का उपयोग कर
• खुले स्रोत प्रौद्योगिकियों और क्लाउड सेवाओं की एक विस्तृत विविधता का उपयोग करने की क्षमता (AWS के साथ अनुभव आवश्यक है)
• SQL और MySQL के साथ मजबूत अनुभव (NoSQL अनुभव एक प्लस है, क्योंकि हम भी Redis का उपयोग करते हैं)
• कोड और स्क्रिप्ट (पीएचपी, पायथन, पर्ल और / या रूबी) की एक कार्यशील समझ
• एक सर्वोत्तम, हमेशा उपलब्ध सेवा में सर्वोत्तम प्रथाओं और आईटी कार्यों का ज्ञान

इस सैंपल जॉब विवरण में DevOps Engineer क्लाउड आधारित आधारभूत संरचना, स्वचालन के साथ एक sysadmin आरामदायक के लिए एक चर्चा शब्द है, जो डायग्नोस्टिक में मदद करने के लिए कोड पढ़ने में सक्षम है, और उच्च उपलब्धता प्रथाओं और समाधानों से अवगत है।

यह देवों की प्रथाओं और देव और ऑप्स के बीच साइलो ब्रेकिंग कल्चर से संबंधित है, जैसा कि इस प्रश्न में देखा गया है कि सियासमिन और देवऑप्स इंजीनियर के बीच क्या अंतर है?

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

देवोप्स के लाभ की दिशा में एक सफल पैटर्न के लिए, @ Jiri Klouda का उत्तर स्वीकार्य DevOps इंजीनियर भूमिका पर एक महान अवलोकन देता है और परिवर्तन की दिशा में कदम के साथ यह मूल्य और सफलता की ओर मदद करेगा।

Comments

आप कैसे सुझाएंगे कि कोई एक sysadmin के बीच अंतर करता है जो मुद्दों, क्लाउड इंफ्रास्ट्रक्चर और ऑटोमेशन, और पारंपरिक sysadmins का निदान करने के लिए आरामदायक रीडिंग कोड है, जिनके पास बहुत अनुभव है, लेकिन उनमें से कोई भी कौशल नहीं है?

— avi

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

— Tensibai

@ एवी यदि आप नौकरी के प्रस्ताव में हैं, तो प्रस्ताव के विवरण में, आवश्यक योग्यताएं सवाल में लोगों से अलग हैं और

— जोरी

मैं यह कहना चाह रहा हूं कि ऑटोमेशन के साथ सहज नहीं रहने वाला एक sysadmin सिर्फ एक खराब-कुशल sysadmin है, अलग नौकरी का शीर्षक नहीं। जॉन अल्लस्पॉ का यह निबंध भी देखें ।

— जिओनीज चामिओसोव

Answer 3

मुझे पता है कि यह उत्तर आपके लिए एक सही फिट नहीं हो सकता है, लेकिन यहां मैंने क्या किया है

मैं अविश्वसनीय रूप से उच्च यातायात के साथ एक बहुत व्यस्त ईकॉमर्स स्टार्टअप पर काम करने वाला पहला डेवलपर था। मुझे लगता है कि कंपनी अभी भी युवा थी, और यह कि, कुछ समय के लिए, मैं केवल इन-हाउस संसाधन वाला तकनीकी बनूंगा।

यह जानकर, मैंने अपने बुनियादी ढांचे को इस तरह से बनाने का फैसला किया, कि मुझे ज़ीरो सिस्टम एडमिनिस्ट्रेशन करना होगा।

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

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

यह बहुत अच्छी तरह से काम किया, और आज, 3 साल बाद, मैं अभी भी कोई सिस्टम रखरखाव नहीं करता हूं। हमारे पास एक सिस्टम एडमिन (एक ही एडब्ल्यूएस इंजीनियर) एक महीने में 10 घंटे के लिए है, और मैं उसके स्प्रिंट को इस तरह से संरचना करने की कोशिश करता हूं कि मैं उसके लिए झुंझलाहट नहीं बनूं। इस तरह से मैं उनके समय का सम्मान करता हूं, और सबसे बेहतर तरीके से उनके स्प्रिंट का प्रबंधन कर सकता हूं।

यदि किसी सिस्टम का अपमानजनक प्रदर्शन है, तो मैं इसे समाप्त कर देता हूं, और एक अन्य उसकी जगह पर घूमता है।

मुझे उम्मीद है कि यह उत्तर आपको किसी भी तरह से फायदा पहुंचा सकता है

Comments

बहुत मददगार, धन्यवाद। यह सुनना दिलचस्प है कि आप अनिवार्य रूप से कैसे बन गए हैं, जो अन्य लोग 'DevOps Engineer' को अप्रत्यक्ष रूप से कह सकते हैं, और मुझे लगता है (दूसरे उत्तरों से क्या कहा गया है) कि आपका तरीका DevOps के दर्शन के अनुरूप है जो पूरी तरह से अलग नहीं है - DevOps 'विभाग। ऐसा लगता है कि यह आपके लिए अब तक अच्छा काम कर रहा है!

— अरोरा ००००

तो मूल रूप से आप अपने आप को सब कुछ प्रबंधित करते हैं? कंपनी छोड़ने पर क्या होता है? क्या व्यवसाय बच पाएगा? इस पर आपके प्रबंधन का दृष्टिकोण क्या है?

— 030

आधारभूत संरचना ही प्रबंधन करती है। यह पूरी तरह से प्रलेखित है, और हम टेराफॉर्म और कठपुतली का उपयोग आधारभूत संरचना को ऑर्केस्ट्रेट करने और सर्वर कॉन्फ़िगरेशन का प्रबंधन करने के लिए करते हैं। इसलिए वास्तव में, AWS अनुभव वाला कोई भी कठपुतली / टेराफॉर्म इंजीनियर सही में प्लग कर सकता है। मैं अब व्यवसाय में एक शेयरधारक हूं, और हमारी देव टीम काफी विकसित हो गई है। शुक्र है कि अब हर कोई जानता है कि बुनियादी ढांचा कैसे बहता है

— user2965205

Answer 4

आपको एक DevOps इंजीनियर नहीं रखना चाहिए क्योंकि DevOps में विषयों की इतनी विस्तृत विविधता समाहित है कि एक व्यक्ति संभवतः इन विषयों के सभी पहलुओं का विशेषज्ञ नहीं हो सकता है। सभी ट्रेडों के एक जैक को काम पर रखने से, आप कोई भी नहीं को काम पर रख सकते हैं।

DevOps आवश्यक रूप से एक टीम आधारित प्रयास है और आप पूरी टीम की अपेक्षाओं का समर्थन करने के लिए संभवतः किसी एक व्यक्ति से अपेक्षा नहीं कर सकते। DevOps के दायरे पर विचार करें। एक व्यक्ति संभवतः नहीं कर सकता है:

• एक रॉकस्टार डेवलपर बनें [भाषा]
• सभी आवश्यक RFC को जानते हुए, एक नेटवर्किंग गुरु बनें
• एक एक्सर्ट सिस्टम एडमिनिस्ट्रेटर बनें
• एक विशेषज्ञ क्यूए परीक्षक हो
• एक डेटाबेस प्रशासक बनें
• भंडारण और बैकअप में विशेषज्ञता
• अभियान विश्वसनीयता इंजीनियरिंग को जानें
• संभावित अन्य विषयों के रूप में अच्छी तरह से

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

कोई भी व्यक्ति संभवतः इस सब में एक विशेषज्ञ नहीं हो सकता है, जिसका अर्थ है कि यदि आप एक DevOps इंजीनियर के लिए विज्ञापन कर रहे हैं, जब आपकी DevOps टीम का सबसे कमजोर क्षेत्र नेटवर्किंग है, तो आप एक नेटवर्किंग विशेषज्ञ के लिए अपनी ज़रूरत के विज्ञापन का बहुत अच्छा काम नहीं कर रहे हैं आपकी DevOps टीम के लिए । हालांकि किसी भी व्यक्ति को DevOps टीम में एक विशिष्ट भूमिका के लिए कबूतर-होली नहीं किया जाना चाहिए, आप अपनी टीम को यह दिखावा करके भंग कर देंगे कि DevOps के दायरे में कोई विशेषज्ञ या विषय विशेषज्ञ (SME) नहीं हैं। पेंडुलम को एक चरम से दूसरे तक घुमाते हुए - साइलो-आईएनजी से लेकर अपने देवओप्स टीम पर हर भूमिका की तरह नाटक करना एक समान है - बस कई समस्याओं का कारण बन सकता है।

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

इसका मतलब यह है कि जो कोई भी आपको बताता है कि वे DevOps के सभी पहलुओं को जानते हैं, वह शायद आपसे झूठ बोल रहा है। उस क्षेत्र के एक विशेषज्ञ को किराए पर लें जो आप एक DevOps टीम में काम कर चुके हैं - "DevOps Engineer" नहीं।

Comments

तो उन सभी नौकरी विवरणों को देखने के लिए केवल फुलाना है जो लागू होता है? वे दुनिया की हर चीज चाहते हैं। मैं इसे देखता हूं और सोचता हूं, मैं यह जानता हूं, यह, यह, और वह नहीं, वह नहीं, वह नहीं .... शायद सभी व्यवसाय दुनिया को वर्णन में डालते हैं और देखते हैं कि उन्हें क्या मिलता है।

— जॉनी

@ जॉनी मैंने 5 साल पहले बनाई गई प्रौद्योगिकियों में 7 साल के अनुभव की आवश्यकता वाले व्यवसायों के किस्से सुने हैं ... हां, वे सूचियों की इच्छा रखते हैं। कठोर आवश्यकताएं नहीं।

— जेम्स शेवेय

धन्यवाद। विश लिस्ट वह वाक्यांश है जिसकी मुझे तलाश थी।

— जॉनी

Answer 5

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

हमने जो किया वह था:

• DevOps इंजीनियरों का कार्यकाल खोना, DevOps एक ऐसी चीज है जिसे हम सभी को करना चाहिए, न कि हमारी नौकरी का शीर्षक इसलिए हमने उन्हें कुछ अलग कहा।

• उन्हें टीमों के लिए बाहर ले जाया गया लेकिन केवल 1 प्रति 3, इसका मतलब है कि वे कर्ता नहीं हो सकते थे, लेकिन टीमों को खुद को बेहतर बनाने और अपनी समस्याओं को हल करने के लिए एक योग्यता के रूप में देखा जाना चाहिए (मार्गदर्शन के साथ)

• एक केंद्रीय समारोह बनाए रखने के साथ-साथ योग्यता केंद्र के रूप में कार्य करने और उद्यम के विचारों को संभालने के लिए, कुछ भी जो सभी टीमों को प्रभावित करता है

जैसा कि हम विकसित करते हैं हम इस मॉडल की समीक्षा करते हैं लेकिन हमारे लिए यह अब तक प्रभावी रूप से काम कर रहा है

Answer 6

मुझे नहीं लगता कि आप इसके लिए एक निश्चित उत्तर प्राप्त कर पाएंगे क्योंकि यह बहुत सारी चीजों का कारक है।

• कैसे कंपनी देवओप्स अभ्यास के साथ बोर्ड पर है
• कंपनी किस प्रकार का एप्लिकेशन या सेवा प्रदान करती है
• आपकी कंपनी की संरचना

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

अब जब मैं इस स्थिति में हूं तो मैं कुछ स्वचालन में सींग काटने की कोशिश कर रहा हूं और हमारे पास कुछ लोगों की समस्याएं हैं जिन्हें हमें सुलझाना होगा। लोग आते हैं और चले जाते हैं और कुछ वर्कफ़्लोज़ डिज़ाइन किए गए थे क्योंकि किसी और ने इसे इस तरह डिज़ाइन किया था और इसलिए नहीं कि यह फिट बैठता है कि लोग कैसे काम करते हैं।

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

Answer 7

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

यदि एक सच्चे DevOps व्यवसायी होना आपके लिए महत्वपूर्ण नहीं है, तो आप इसे जो चाहें कह सकते हैं।

Comments

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

— Tensibai

@ तेंसिबाई - मेरा एकमात्र बिंदु यह है कि यह सिर्फ एक शीर्षक है। किसी को DevOps इंजीनियर

— बुलाना