DevOps के 12 एंटीपैटर्न

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

तो आप DevOps बनना चाहते हैं? ठीक है, लेकिन शुरू करने से पहले, आइए कुछ बातों पर ध्यान दें जो आपको नहीं करनी चाहिए।

अच्छे पुराने दिनों में, हमने उन्हें "बुरे विचार" कहा, लेकिन कूटनीति और राजनीतिक शुद्धता दिखाई दी, "बुद्धिशीलता" चली गई और "विचार बौछार" दिखाई दिया, और इसके साथ शब्द "विरोधी पैटर्न"।

यदि "पैटर्न" सही तरीका है, तो संक्षेप में "एंटी-पैटर्न" गलत है - और इसलिए, आपको गलत तरीके से जाने से रोकने के लिए, हमने इस सूची (DevOps समुदाय से थोड़ी मदद के साथ) को संकलित किया है।

1. DevOps एक प्रक्रिया है

वास्तव में नहीं। यह एक दर्शन है। यह सोचने का एक तरीका है। DevOps प्रक्रियाओं और उपकरणों द्वारा समर्थित है। DevOps, जीन किम के अनुसार, "तीन तरीकों" के रूप में जाना जाने वाले 3 मूल सिद्धांतों पर आधारित है

पहला रास्ता पूरे सिस्टम के प्रदर्शन पर जोर देता है - मूल्य प्रवाह।

दूसरा तरीका फीडबैक लूप को कम करना और तेज करना है।

तीसरा तरीका एक ऐसी संस्कृति का निर्माण करना है जो सीखने और समझने को बढ़ावा देती है।

( इस लेख के अनुवाद में इसके बारे में और अधिक पढ़ें "11 चीजें जो आपको देवो के बारे में जानना आवश्यक है," भाग 2 और 1 )

2. फुर्तीली देवो के समान है?

यदि आप यह सवाल पूछते हैं, तो आप शायद किसी तरह की चुस्त प्रक्रिया पर काम कर रहे हैं। बुरा नहीं है। आपके पास एक सॉफ़्टवेयर विकास प्रक्रिया है जो DevOps मानों का अनुसरण करती है, लेकिन Agile का अर्थ यह नहीं है कि आपने DevOps को लागू किया है।

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

3. अपनी टीम के नाम / डेवलपर्स / किसी को भी DevOps में बदलें

CIO: "मैं अगले साल में देवो में अपग्रेड करना चाहता हूं।"

एमजीआर: “पहले से ही किया है, हमने आज सुबह विभागों के दरवाजों पर संकेत बदल दिए हैं। हम इतने कूल हैं कि अब हमारे पास 2 DevOps टीमें हैं। ”

सुपर आसान। और मुझे यकीन है कि अब आपके पास बहुत सारे DevOps इंजीनियर हैं। यदि आप भाग्यशाली हैं, तो वे रात के खाने में आपके बगल में बैठ सकते हैं।

4. एक अलग DevOps कमांड चलाएँ

पर चलें। मैं आपसे बहुत विनती करता हूं। पहले से ही? शाबाश! आपने DevOps को कार्यान्वित किया है। वास्तव में, आपने जो किया वह एक और साइलो का निर्माण करता है। अब आपको खुद एक और टीम मिल गई है जिसे आपको वर्तमान प्रक्रिया में एकीकृत करने की कोशिश करने की आवश्यकता है। दीवारों से घिरी एक और टीम जिसे तोड़ने की जरूरत है। हो सकता है कि आप वापस जाएं, रिब्रांड करें और 3 देवओप्स टीम बनाएं और सुपर कूल बनें?

DevOps का मतलब यह नहीं है कि विकास और प्रशासन से कई लोगों को बाहर निकालना और उन्हें एक नई टीम में पैक करना आवश्यक है। आपको स्वीकार करना चाहिए और लागू करना चाहिए। प्रशासन टीम या इसके विपरीत में विकास टीम डालो। आपको टीमों के बीच बाधाओं / दीवारों / गार्ड को पूरी तरह से नष्ट करने की जरूरत है और उन्हें सामान्य लक्ष्यों और जिम्मेदारियों के साथ एक पूरे में बना दें।

अधिक जानकारी यहाँ

4. शत्रुतापूर्ण अधिग्रहण

DevOps। यह एक शब्द है जो "देव" से शुरू होता है। इसका मतलब है कि विकास अधिक महत्वपूर्ण हो रहा है क्योंकि विकास पहले आता है ... समस्याएं?

DevMgr - “उह, हम अभी DevOps कर रहे हैं। मेरे लोगों को सीखना है कि उत्पादन के लिए कैसे काम करना है। ”

ऑप्समार्ग - “उह… ठीक है। तो कोड का विकास कौन करेगा? "

DevOps शब्द स्मार्ट है। यह व्युत्पन्न है। इसका मतलब यह है कि यह दो शब्दों का एक संयोजन है, ताकि एक नया शब्द बन सके जो एक नया अर्थ देता है। यहां तक ​​कि इसकी कुछ प्रभावशीलता भी है। इसका मतलब यह नहीं है कि हमने शब्द संचालन को लिया और इसे शब्द विकास के साथ बदल दिया। तो आप इस तरह से DevOps को स्वीकार करने की कोशिश क्यों नहीं करते?

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

6. DevOps एक और चर्चा है

अगर आपको लगता है कि DevOps सिर्फ एक चर्चा है, तो आप शायद "बादलों" का गलत तरीके से उपयोग कर रहे हैं। DevOps पाने के लिए एक पदक की तरह है।

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

7. DevOps को सिल्वर बुलेट के रूप में बेचना

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

यह जाओ ... DevOps कड़ी मेहनत है! अधिकांश के लिए, यह एक सांस्कृतिक परिवर्तन की आवश्यकता है! यह उन कठिन चीजों में से एक है जिन्हें आपने कभी हासिल करने की कोशिश की है। अनुभवी डेवलपर्स और प्रशासक जिनके साथ आप ऐसा करने की कोशिश कर रहे हैं, यह उल्टा खड़े होने के समान होगा। एक रात में ऐसा करने की कोशिश न करें, अन्यथा असफल रहें।

8. DevOps का मतलब है कि डेवलपर्स युद्ध सर्वर का प्रबंधन करते हैं

नहीं! नर्क और फिर नहीं। यह आपको गुस्से से हिलाता है कि आपको इसे पढ़ना है ...

9. DevOps विकास-संचालित रिलीज प्रबंधन है

2 बातें स्पष्ट करता हूं।

DevOps विकास संचालित नहीं है ।
DevOps का प्रबंधन प्रशासन द्वारा नहीं किया जाता है ।
यदि आप एक विकास का माहौल चाहते हैं, तो ठीक है, जाओ और एक निर्माण करो। इसे DevOps नहीं कहेंगे, इसलिए यह नहीं है।

इस लेख को एक उदाहरण के रूप में देखें ।

"DevOps में, प्रोग्रामर प्रोग्रामर हैं।" - बिल्कुल!

"उसी तरह, DevOps में, व्यवस्थापक प्रवेश हैं।" - हम तैयार हैं!

"परंपरागत रूप से, एक लड़ाकू सर्वर को सॉफ्टवेयर पहुंचाने का कार्य प्रशासकों या विकास टीम की जिम्मेदारी है।"

एक मिनट रुकिए ...

"प्रशासक डाउनटाइम को कम करने और लचीलेपन और जवाबदेही के माध्यम से स्थिरता प्रदान करने के लिए तैनाती रणनीति बनाते हैं।"

हाँ, हम परिचित ट्रैक पर वापस आ गए हैं ... और अब बाम!

विकास के माध्यम से रिलीज प्रबंधन - डब्ल्यूटीएफ? स्थिति बद से बदतर होती जा रही है

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

नहीं। नहीं। गैर। Nej। ना। नी। Nein।

विकास-संचालित एक प्रक्रिया हो सकती है। ये केवल DevOps नहीं हैं। एक स्वचालित परिनियोजन प्रक्रिया के साथ व्यवस्थापकों को बदलना बकवास है। कृपया इसे घर पर दोहराने की कोशिश न करें!

10. हम देवो को नहीं बना सकते - हम अद्वितीय हैं

हाँ तुम हो, हाँ तुम मेरी होशियार लड़की हो! लेकिन आप इतने खास नहीं हैं कि आप DevOps नहीं बन सकते। मुझे यकीन है कि आप वहां सबसे अच्छे डेवलपर हैं, आपके कोड की गति प्रकाश की गति से तेज है, और जब अन्य प्रोग्रामर इसे देखते हैं, तो वे खुशी से रोते हैं। नहीं? तो, आप ग्रह पर सबसे आश्चर्यजनक ऑप्स हैं। अगर चक नोरिस प्रशासक थे, तो वह आप होंगे। हालाँकि, आपके और आपके संगठन के पास एक भी ऐसा कारक नहीं है जो आपको DevOps को कार्यान्वित करने की अनुमति नहीं देगा।

ऑप्सकोड के जेसी रॉबिंस ने शुरू करने के लिए कुछ अच्छे सुझाव दिए हैं :

• छोटा शुरू करो - ट्रस्ट बनाओ
• चैंपियंस बनाएं
• विश्वास पैदा करो
• सफलता का जश्न मनाएं
• परंपराओं का आविष्कार

पढ़ने के लिए भी उपयोगी है।

11. हम DevOps नहीं बना सकते - हमारे पास गरीब कर्मचारी हैं

आप उन्हें क्यों काम पर रख रहे हैं? यही कारण है कि - वे अद्भुत हैं! यदि आप ऐसा नहीं सोचते हैं, तो आपको अपने अंदर एक बारीकी से देखने की जरूरत है, और फिर जाकर अपनी टीम में असली छिपी हुई प्रतिभाओं की खोज करें।

किसी ने मुझे हाल ही में बताया कि वे DevOps नहीं कर सकते, क्योंकि "उनके पास गलत डेवलपर और प्रशासक हैं ..."। क्या उनके पास ऐसे डेवलपर हैं जो कोड नहीं लिख सकते हैं? मैंने खुद से सोचा: "मेरी कंपनी के बुरे डेवलपर हैं - जो लोग प्रोग्राम करना नहीं जानते हैं, वे एचआर और मार्केटिंग का काम करते हैं!"

DevOps विकास और प्रशासन के बीच सहयोग को बढ़ावा देता है; इस सहयोग को पूरी कंपनी के नीतिगत स्तर पर विकसित किया जाना चाहिए।

और यह मत कहो कि "गलत" लोग आपके लिए काम करते हैं। आप उन्हें खाना बनाना नहीं जानते। लड़ो इसे।

12 सहयोग जब मिस्टर *** प्रशंसक के बारे में मारा

ठीक है, प्रतिभा। आपने *** के बारे में बात की। तो क्या? हम सब करते हैं। लेकिन अब आप चाहते हैं कि आपके व्यवस्थापक लोग रात को 2 बजे बिस्तर से बाहर निकलें, ताकि वे इस बारे में कुछ भी न जान सकें। वे माइकल क्लेटन की तरह "क्लीनर" नहीं, बल्कि प्रवेश हैं। डेवलपर्स और प्रशासकों के बीच बातचीत शुरू करने के लिए तैनाती के दौरान एक त्रुटि होने तक प्रतीक्षा करने के लिए एक पूर्ण बकवास है।

इस समस्या के लिए बहुत देर हो चुकी है ... लेकिन शायद अगले एक के लिए नहीं। आपके पास डेवलपर्स और प्रवेशकर्ताओं की एक टीम है जो एक दूसरे के साथ संवाद करते हैं (या 2 बजे शपथ लेते हैं), लेकिन कम से कम वे बात करते हैं। संवाद स्थिर रखें। क्या हुआ और भविष्य में आप इसे कैसे ठीक कर सकते हैं, इसका पूर्वव्यापी अवलोकन प्राप्त करें। यदि आप इस स्थिति का सामना करते हैं, तो टीमों के बीच एक संवाद बनाए रखने का प्रयास करें। डेवलपर्स और प्रशासकों के बीच जल्द से जल्द संचार चैनल खोलें। और फिर आशा नहीं खो जाती है!