देवऑप्स इंजीनियर्स को एक अकेला भेड़िया की तरह कम महसूस करने में मदद कैसे करें?

Question

मैं सिर्फ एक DevOps आदमी से बात कर रहा हूं जिसने DevOps Engineer होने के संघर्षों के बारे में कुछ अच्छे बिंदु उठाए हैं और कभी-कभी एक-एक सेना की तरह महसूस करता है, भले ही वह 16 इंजीनियर्स की टीम में हो।

वह कई अलग-अलग टोपी पहनते हैं, लेकिन बुनियादी ढांचे के काम करने वाली विकास टीम में बैठते हैं। वह शांत तकनीक से प्यार करता है जो उसे काम करने के लिए मिलता है- स्वचालन, क्लाउड, कंटेनराइजेशन आदि का भार। लेकिन वह संघर्ष करता है कि वह opsएक devटीम में एकमात्र व्यक्ति है । वह विकास प्रबंधक को रिपोर्ट करता है, लेकिन इन्फ्रास्ट्रक्चर मैनेजर के साथ मिलकर काम करता है।

ऐसा लगता है कि मैं बहुत से DevOps पेशेवरों के साथ बात करता हूं। DevOps इंजीनियर्स को अकेला भेड़िया जैसा महसूस करने में मदद करने के लिए क्या किया जा सकता है?

Comments

संभव डुप्लिकेट Sysadmin और DevOps इंजीनियर के बीच क्या अंतर है?

— ०३०

मैं हमेशा एक व्यावसायिक संगठन मॉडल के रूप में DevOps के बारे में सोचता हूं, न कि ऐसी भूमिका जो कोई ले सकता है।

— टी। सर

Answer 1

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

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

परामर्श, संचार, और जिम्मेदारियों का सम्मिश्रण सभी एक devops टीम की सफलता के लिए महत्वपूर्ण हैं।

Comments

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

— TafT

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

— स्टुअर्ट आइन्सवर्थ

Answer 2

मुझे लगता है कि पहला दोष इस वाक्य में है:

वह विकास प्रबंधक को रिपोर्ट करता है, लेकिन इन्फ्रास्ट्रक्चर मैनेजर के साथ मिलकर काम करता है।

DevOps एक सांस्कृतिक पारी है जिसका उद्देश्य साइलो को हटाना है। यदि सिलोस रहता है, तो यह इंजीनियर जो कुछ भी आप उसे नाम देना चाहते हैं; एक इंजीनियर जो ऑपरेशनल डेवलपमेंट कर रहा है, एक ऑटोमेशन एक्सपर्ट, एक डेवलपर जो इन्फ्रास्ट्रक्चर को ऑटोमेट करता है - लेकिन यह इंजीनियर एक DevOps इंजीनियर नहीं है।
वास्तव में, "DevOps Engineer" एक वास्तविक भूमिका नहीं है , यह एक 'चाप्यू' अधिक है क्योंकि यह डेवलपर्स, सिस्टम प्रशासक, क्यूए परीक्षक और एक आम टीम में काम करने वाले वास्तुकारों को शामिल कर सकता है।

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

जैसा कि आप इसका वर्णन करते हैं कि यह इंजीनियर देव टीम में केवल एक ओपीएस कर रहा है। वह उसे "DevOps इंजीनियर" नहीं बनाता है। (उनके संगठन में जो भी मतलब है) वह अलगाव में काम कर रहा है क्योंकि नौकरी को "DevOps Engineer" के रूप में प्रस्तुत किया गया है, लेकिन ऐसा लगता है कि उसकी टीम के अन्य लोग ऑपरेशन पर काम करना नहीं चाहते हैं।

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

मेरी राय में पहली बात यह होगी कि आप ऑपरेशनल टूल्स को टीम के सामने पेश करें और सभी को टूल्स पर बेसिक नॉलेज दें, फिर ऑपरेशनल टूल्स को कॉन्फ़िगर / कोड करने की जिम्मेदारी पूरी टीम को ट्रांसफर करें। इसके पीछे मुख्य विचार "सभी ऑप्स चीजें कर रहा है" से "जो समर्थन करता है और टीम को संदर्भ कार्यान्वयन देता है" से बढ़ रहा है।

यह एक प्रबंधन पुनर्गठन की तुलना में पहले कदम के रूप में सरल तरीके से कुछ कार्रवाई करने योग्य प्रदान करके अन्य उत्तरों को पूरक करता है।

Comments

एक devops कार्यान्वयन के बारे में सामंजस्य स्थापित करने के लिए कठिन चीजों में से एक ऑर्ग चार्ट है। सिलोस आमतौर पर प्रबंधन के इर्द-गिर्द बनता है, और यदि आपके पास देव एमआरजी और इन्फ्रास्ट्रक्चर एमआरजी है, तो उन टीमों को संवाद करना अच्छा लगता है, लेकिन समेकन के लिए अनिच्छा है। संस्कृति को बदलना कठिन है, और ऑर्ग चार्ट संस्कृति को विशद रूप से प्रदर्शित करते हैं।

— स्टुअर्ट आइन्सवर्थ

@StuartAinsworth वास्तव में, यही कारण है कि मैंने संगठन को संशोधित करने के बारे में बात नहीं की, लेकिन टीम के बाकी हिस्सों में बोर्ड पर अधिक।

— तेनसीबाई

Answer 3

इस तरह की स्थितियों में DevOps इंजीनियर्स के लिए सबसे महत्वपूर्ण बात, (ए) प्रबंधन प्रतिबद्धता और (बी) आवश्यक बजट प्राप्त करना है । दोनों पर कुछ और विवरणों के लिए पढ़ें ...

प्रबंधन प्रतिबद्धता प्राप्त करें

एक बार ऐसा होने पर, ऐसे DevOps इंजीनियरों के लिए चीजें आसान हो जाती हैं। विशेष रूप से जब भी प्रतिरोध (सभी प्रकार की पार्टियों से) खेल में आता है। मेरा विश्वास करो, ऐसा प्रतिरोध होगा, जो इस तरह की चुनौतियां हैं:

• हमें क्यों बदलना होगा? मैं वही करना चाहता हूं जो मैंने एक्स सालों से किया था!
• मैं अपने पास होने वाली तकनीकी (तकनीकी) शक्ति को ढीला नहीं करना चाहता, और सभी प्रकार की वर्कफ़्लो प्रक्रियाओं को पूरा करना चाहता हूं, ताकि उत्पादन में एक मूर्खतापूर्ण समाधान मिल सके जो मुझे 5 घंटे (या दिन ...) के बजाय 5 मिनट की तरह लेना चाहिए।
• ... (मैं यहां एक और दर्जन गोलियां जोड़ सकता था ...)।

जब भी वे चुनौतियां सामने आती हैं, तो सभी DevOps इंजीनियर को कहना चाहिए:

मुझे क्षमा करें, मैं सिर्फ अपना काम कर रहा हूं ... ऊपरी प्रबंधन के निर्देशों के आधार पर।

आवश्यक बजट प्राप्त करें

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

नीचे कुछ वास्तविक दुनिया के मामले हैं जिन्हें मैंने खुद अनुभव किया था, एक SCM सलाहकार के रूप में कुछ कंपनियों द्वारा काम पर रखा गया था जहाँ ये चीजें हुई थीं। मुझे पता है, SCM केवल DevOps का हिस्सा है, लेकिन यह वह क्षेत्र है जहाँ मुझे कुछ विशेषज्ञता हासिल है ...

1. स्वचालन के लाभ

केवल 2 (!!!) से कुछ हड़ताल के कारण कंप्यूटर ऑपरेटर (जो कंसोल को टाइप नहीं करते हैं, जहां उन्हें टाइप करने की उम्मीद है), ट्रेनों को 2 कारखानों के बीच आधे रास्ते में बंद करना पड़ा (क्योंकि सिस्टम में सिस्टम के बाद से) जहां ट्रेन नीचे जा रही थी, ट्रेन को संभालने के बारे में महत्वपूर्ण डेटा उपलब्ध नहीं था)।

SCM प्रणाली लागू करने से, कई ऑपरेटर कमांड स्वचालित हो गए थे।

2. सॉफ्टवेयर लाइसेंस की लागत कम करें

कुछ सॉफ्टवेयर विक्रेता ने (पुरानी) SCM सॉफ्टवेयर के लिए कुछ वार्षिक शुल्क बढ़ाने का फैसला किया था, जिसके लिए प्रबंधन सहमत नहीं था। इसके लिए उन्होंने कुछ वैकल्पिक SCM सॉफ्टवेयर द्वारा प्रतिस्थापित करने के लिए एक विशेष परियोजना बनाई।

परियोजना का बजट वार्षिक शुल्क के बराबर था जिसे वे भुगतान नहीं करना चाहते थे। इसमें परियोजना को सफल बनाने के लिए अन्य महाद्वीपों (जैसे मेरे) के इंजीनियरों में उड़ान शामिल थी।

3. परिचालन लागत कम करें

कुछ प्रमुख बीमा कंपनी देश भर में लगभग 13.000 मिडरेंज कंप्यूटर (AS / 400s) के लिए सॉफ़्टवेयर फ़िक्स को स्थानांतरित करने के लिए कुछ FTP सॉफ़्टवेयर का उपयोग कर रही थी, और जब भी "एक" फिक्स उपलब्ध हुआ। 1 ऐसे हस्तांतरण की लागत लगभग 4 USD थी (एक हस्तांतरण के लिए 13.000 x 4 = 52.000 USD ...)। सॉफ्टवेयर में लगभग 150 डेवलपर्स द्वारा विकसित / अनुरक्षित 120.000 घटक शामिल थे। इस संभावना के बारे में गणित करें कि 1 डेवलपर ने इन 120.000 घटकों में से किसी में 1 (छोटी) गलती की, जिसने इसे उत्पादन के लिए बनाया, और एक तत्काल फिक्स की आवश्यकता थी, जिसकी लागत एक और 52.000 USD होगी (बस हस्तांतरण के लिए!)।

एक पर्याप्त SCM प्रणाली (प्रबंधित परीक्षण वातावरण, अनुमोदन आदि के साथ) को लागू करके, इस कंपनी ने एक बड़ी लागत में कमी हासिल की। इसके बारे में सोचें, यदि SCM सिस्टम केवल 20 स्थानान्तरणों की तत्काल आवश्यकता की रोकथाम कर सकता है, तो इसके परिणामस्वरूप 52.000 x 20 = 1.040.000 USD की लागत में कमी आई है (SCM प्रणाली को लागू करने के लिए काफी बजट, उन्हें केवल एक अंश की आवश्यकता थी उस राशि का काम पूरा करने के लिए)।

4. अनुपलब्धता की लागत को कम करना

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

शायद यही कारण है कि, बहुत लंबे समय के लिए, ऐसी कंपनियों के पास पहले से ही कई दशकों से परिष्कृत DevOps उपकरण हैं। क्योंकि प्रत्येक दूसरे वे व्यवसाय में नहीं हैं, उन्हें एक भाग्य खर्च होता है।

Comments

मुझे लगता है कि आप कुछ चरणों को याद कर रहे हैं। यदि देव टीम पहले से ही आवेदन की कई प्रतियाँ (कम से कम एक परीक्षण वातावरण से पहले नहीं) तैनात कर रही है, तो यह अनिवार्य होना चाहिए। तब वे शायद अपने दम पर कुछ समय के लिए संघर्ष कर सकते हैं यदि वे वास्तव में समय बिताना चाहते हैं। यह देव ऑप्स विशेषज्ञ को इन लोगों के लिए सहायक बनाता है ; "प्रबंधन ऐसा कहता है" के बजाय वे एक दर्दनाक प्रक्रिया को एक चिकनी एक में बदल सकते हैं। यही कारण है कि देव ऑप्स का पूरा विचार, आखिरकार: कई वातावरणों को तैनात करने और प्रबंधित करने के दर्द को समाप्त करता है।

— jpmc26

Answer 4

टीएल; डीआर: चूंकि ऊपरी प्रबंधन आमतौर पर चंचल होता है और गुस्से से ग्रस्त होता है, इसलिए मैं धीरे-धीरे चीजों को बेहतर तरीके से बदलते हुए एक अलग दृष्टिकोण प्राप्त करने के लिए अपने दिमाग को थोड़ा मोड़ने की कोशिश करूंगा।

(मैं मान रहा हूं कि उनकी परेशानी मुख्य रूप से अनिच्छुक देवों के साथ है , न कि उनके अन्य ऑप्स सहयोगियों की जो मुख्य रूप से शास्त्रीय काम करते हैं।)

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

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

दूसरा, निश्चित रूप से हर किसी को यह पता होना चाहिए कि स्वचालन क्या कर रहा है, और कम से कम सिद्धांत में, कुछ आसपास खुदाई के साथ, स्वचालन मशीनरी को शुरू करने में सक्षम हो (यानी, अगर सब कुछ एक प्रतिबद्ध / धक्का से चलता है, तो देवता इस तथ्य से अवगत होने और बहुत अधिक अद्यतित होने की आवश्यकता है कि जब वे प्रतिबद्ध होते हैं तो पृष्ठभूमि में सामान हो रहा होगा)। CI (/ CD) पाइपलाइन को काफी दिखाई देने की आवश्यकता है और यह एक ऐसी चीज होनी चाहिए जिसके बारे में हर कोई लगातार जानता हो (यानी जब कोई देवता इसे तोड़ता है)।

तीसरा, "एक आदमी" को यह देखना होगा कि वह अपने साथियों के लिए रोज़मर्रा के काम नहीं करता है (जैसे, उनकी कलाकृतियों के लिए डॉकरीफाइल के बाद डॉकरफाइल बनाना ...)।

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

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

और अंत में, यदि वर्षों के बाद और मेहनत करने के बाद भी उनके सहयोगियों के साथ कोई भी सुधार नहीं हुआ है, तो हमेशा अन्य राशियों (कंपनी के अंदर या बाहर होना) की तलाश करना संभव है। अपनी बेल्ट के नीचे देवओप्स का अनुभव होने के कारण, इन दिनों नौकरी की तलाश के लिए उत्कृष्ट आधार है ...

Answer 5

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

यह उत्तर अनुभव से सिर्फ मेरा अनूठा दृष्टिकोण है, और यह मानदंडों या सर्वोत्तम अभ्यास का संकेत नहीं हो सकता है ...

लेकिन जो आपके DevOps सहयोगी के बारे में शिकायत कर रहा था , वह बहुत ही स्वभाव है जो DevOps को चुनौतीपूर्ण और कठिन बनाता है , खासकर जब DevOps इंजीनियर की भूमिका नियुक्त की जाती है, और केवल एक सांस्कृतिक मानसिकता नहीं होती है।

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

कुछ साइलो बरकरार हैं , और यह ठीक है, यह DevOps मिशन है कि इसके चारों ओर काम करें और जितना संभव हो उतना उस साइलो को महत्वहीन या अदृश्य बनाने की कोशिश करें।

यह संभव है कि आपका सहकर्मी साकार हो रहा हो, या उसे अभी तक यह एहसास नहीं हुआ है, कि वह देवो इंजीनियर बनना पसंद नहीं करता है ।

Answer 6

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

Answer 7

मेरे लिए, DevOps का अर्थ है कि एक सॉफ्टवेयर सिस्टम का विकास और संचालन अलग-अलग देव और ops टीमों के बजाय, एक टीम की जिम्मेदारी बन जाता है। यह दो तरफा सड़क है। सर्वश्रेष्ठ टीमें " टी-शेप्ड " लोगों से बनती हैं जो एक क्षेत्र में विशेषज्ञ हैं और कई संबंधित क्षेत्रों से परिचित हैं।

• ऑप्स के अनुभव वाले टीम के सदस्यों से अपेक्षा की जाती है कि वे जो कुछ भी करते हैं, उसे करने के लिए (यानी ऑप्स) सबसे अच्छा करते हैं, जो वे दूसरों के लिए सबसे अच्छा (यानी ऑप्स) करते हैं, और संबंधित क्षेत्रों (यानी देव कार्यों) में काम करने और सीखने के लिए करते हैं।
• देव अनुभव के साथ टीम के सदस्यों से अपेक्षा की जाती है कि वे जो करते हैं (यानी देव) सबसे अच्छा करते हैं, वे जो करते हैं उसकी बुनियादी बातों को सिखाने के लिए (यानी देव) दूसरों के लिए, और संबंधित क्षेत्रों (यानी ऑप्स कार्यों) में काम करने और सीखने के लिए।

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

उसे शुरू से ही उच्च-स्तरीय वास्तुकला में अनपेक्षित करें, ताकि वह अपनी विशेषता की चिंताओं का परिचय दे सके। (इससे पहले कि हम DevOps होते, हमारी आर्किटेक्चर ड्रॉइंग हमेशा "छोटी चीज़ों" पर चमकती थी जैसे लोड बैलेंसर्स और निरर्थक सर्वर। अब ऐसी चीज़ें बहुत पहले स्केच का हिस्सा हैं।)

दैनिक दिनचर्या के कुछ कार्यों को लेने के लिए देवताओं से अपेक्षा करें कि दोनों टीम में अतिरेक का निर्माण करें और "ड्रग" कार्यों को निष्पक्ष रूप से फैलाएं।

यदि कोई ऑप्स जैसे कार्य नहीं करने हैं तो देव प्रयास में योगदान देने की अपेक्षा करें। कुछ DevOps मुझे पता है कि डेटाबेस को उनके विशेषज्ञता के क्षेत्र का एक स्वाभाविक विस्तार काम लगता है, निश्चित नहीं कि अगर इसे सामान्यीकृत किया जा सकता है।

Answer 8

DevOps इंजीनियर्स को अकेला भेड़िया जैसा महसूस करने में मदद करने के लिए क्या किया जा सकता है?

व्याख्या करने के लिए - एक DevOps अभियंता क्या कर सकते हैं खुद / खुद को कम एक अकेला भेड़िया की तरह महसूस करने?

संस्कृति और प्रबंधन समर्थन का अभाव समीकरण का केवल एक हिस्सा है। अन्य भाग मेरी राय में है कि विस्तार DevOps ज्ञान अक्सर जटिल संदर्भों को संदर्भित करता है और काम करने वाले उदाहरणों के लिए सलाह और संदर्भ होना महत्वपूर्ण है।

इसलिए - एक अकेला भेड़िया की तरह महसूस मत करो; DevOps समुदायों में यहां एक या उपकरण-विशिष्ट समूहों और GitHub की तरह भाग लें - भावना कम से कम है तो आप केवल अकेले भेड़िया नहीं हैं; ;-)

Comments

DevOps, स्वभाव से यह एक टीम अभ्यास है। केवल एक चीज जो देवोप्स इंजीनियर अपने आप को या अकेला भेड़िया की तरह कम महसूस करने के लिए कर सकता है, वह है एक अधिक कार्यात्मक संगठन में शामिल होना और छोड़ना।

— जेम्स शेवेई