8 हर दिन DevOps में चुनौतियां अपनाएं और उन्हें कैसे हल करें (चुनौतियां) - भाग 1

आईटी उद्योग में अब DevOps एक नया शब्द नहीं है; यह 2020 है और लगभग हर संगठन या तो चाहता है या काम करने के इन तरीकों के लिए अपनी संस्कृति और तरीकों को विकसित करने की कोशिश कर रहा है। हालांकि, इस तरह के क्रांतिकारी परिवर्तन को अपनाना आसान नहीं है और दोनों नेताओं और 'कर्ता' द्वारा कई चुनौतियों का सामना किया जाता है; DevOps बहुत नीचे-ऊपर और ऊपर-नीचे होने वाली हलचल है। यहाँ कुछ सामान्य चुनौतियाँ हैं जिन्हें मैंने अपने फील्डवर्क में देखा है:

  1. दुविधापूर्ण संस्कृति

ऐसी संस्कृतियाँ जो भारी आज्ञा और नियंत्रण और नौकरशाही के काम करने के लिए बहुत ही आसुरी स्थान हैं। जहां लोगों को समस्याओं या ज्ञान और जानकारी को छिपाने के लिए दंडित किया जाता है, लोगों को साझा करने और सहयोग करने से रोक देगा। जहाँ असफलता से बचने के लिए कुछ किया जाना देखा जाता है, लोग उनसे सीखने की बजाय गलतियों को ढँकने का प्रयास करेंगे।

संस्कृति को परिभाषित करना बहुत कठिन है और बदलने के लिए बहुत कठिन लगता है। यह एक संगठन में लोगों के मूल्य और व्यवहार हैं और इस मानव स्तर पर संबोधित करने की आवश्यकता है; यह आवश्यक है कि हम भावनाओं और भावनाओं के बारे में बात करें, न कि केवल बिट्स और बाइट्स।

2. परिवर्तन का विरोध

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

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

3. दृष्टि की स्पष्टता का अभाव

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

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

कभी-कभी DevOps परिवर्तन एजेंटों के पास DevOps गोद लेने के लिए एक उचित योजना और रणनीति होती है जिसे उन्होंने हमारे प्रबंधन या C-Suite को प्रस्तावित किया है, लेकिन अगर ये नेता खुलेआम समर्थन नहीं कर रहे हैं और DevOps के कार्यान्वयन के लिए निष्पादन योजना का प्रचार कर रहे हैं, तो यह DevOps गोद लेने की प्रक्रियाओं को प्रभावित कर सकता है।

4. टीमें सहयोग नहीं करतीं

DevOps में मुख्य लक्ष्य देव, ऑप्स और अन्य टीमों को प्रोत्साहित करने और उन्हें एक साथ काम करने के लिए सक्षम करना है, जिससे सिलोस के बीच बाधाओं को कम किया जा सके। टीमों के अपने लक्ष्य होंगे; विकास टीम परिवर्तन पर केंद्रित है और स्थिरता पर आईटी संचालन टीम। उन प्रमुख DevOps को अपनाने के लिए टीमों को साझा लक्ष्य सुनिश्चित करना एक बुनियादी चुनौती है।

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

5. वातावरण मानकीकृत नहीं हैं

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

6. टूल कंटेंट में हैं

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

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

7. रिलीज मैनेजमेंट कारण देरी

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

8. मैनुअल टेस्टिंग ऑनरियस और टाइम-कंज्यूमिंग है

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

निष्कर्ष

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