लिखित DevOps प्रशिक्षण

DevOps में काम का प्रवाह कैसे बेहतर बनाएँ?

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

अपने DevOps बदलाव का उद्देश्य तय करें

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

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

DevOps बदलाव की शुरुआत के लिए उद्देश्य के कुछ उदाहरण हैं:

• 3 महीनों में कोड चेक-इन से लाइव प्रोडक्शन तक का औसत लीड टाइम 75% कम करना।
• 6 महीनों में अनुरोध से लाइव प्रोडक्शन तक का औसत लीड टाइम 33% कम करना।
• 12 महीनों में प्रोडक्शन घटनाओं की संख्या 50% कम करना।

वैल्यू स्ट्रीम क्या है और इसमें कौन शामिल है?

काम सुधारने के लिए अपनी वैल्यू स्ट्रीम समझें। IT में यह किसी सॉफ़्टवेयर उत्पाद और सेवा को डिज़ाइन, बिल्ड और संचालित करने की गतिविधियों का क्रम है। इसमें वे लोग, जानकारी, सुविधाएँ और सामग्री भी तय होती हैं जो काम का प्रवाह संभव बनाती हैं।

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

सुधार के अवसर खोजने के लिए वैल्यू स्ट्रीम मैप बनाएँ

मैप आपको और टीम को दिखाता है कि सॉफ़्टवेयर डेवलपमेंट और डिलीवरी में सामान्य काम कैसे होता है। लक्ष्य हर कदम का विस्तृत दस्तावेज़ बनाना नहीं है। इतना समझना है कि बड़ी अक्षमताएँ, बाधाएँ, समस्याएँ और समय या संसाधनों की बर्बादी कहाँ है।

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

हैंडऑफ़, बाधाएँ और बर्बादी जितना हो सके हटाएँ

हैंडऑफ़, बर्बादी और बाधाएँ कुशलता के अहम, अक्सर अनदेखे पहलू हैं। एक टीम से दूसरी को काम सौंपने के लिए सूचना, अनुरोध, समय तय करने, प्राथमिकताएँ बदलने और टकराव सुलझाने की ज़रूरत होती है।

हर हैंडऑफ़ में कुछ जानकारी खोती है और वैल्यू स्ट्रीम का कुल लीड टाइम बढ़ता है।

इन समस्याओं को दूर करने के लिए:

• हर हैंडऑफ़ में लगने वाले समय पर सवाल उठाएँ। ऊपर के उदाहरण में टेस्ट पास कर चुका कोड डिप्लॉयमेंट टीम तक पहुँचने में 80 घंटे लेता है। ऐसा क्यों? क्या इसे ऑटोमेट नहीं कर सकते? ज़रूर कर सकते हैं।
• बार-बार हैंडऑफ़ से होने वाली बर्बादी दूर करें। ऊपर के उदाहरण में टेस्ट टीम 65% फ़ीचर वापस डेवलपमेंट को भेजती है। कुछ दोषों के सुधार टेस्टर की स्वीकृति से पहले 3 बार तक देने पड़ते हैं। क्या डेवलपमेंट और टेस्टिंग के बेहतर तालमेल से यह तेज़ नहीं हो सकता? दोषों की बड़ी संख्या बताती है कि डेवलपमेंट टीम में कुछ ठीक नहीं चल रहा। इन समस्याओं के कारण पहचानकर सुधारें।
• हैंडऑफ़ पर सवाल उठाएँ और जहाँ हो सके उन्हें हटाएँ। उदाहरण में किसी अनुरोध को स्पष्ट करने के बाद अनुमोदन के लिए 320 घंटे लगते हैं। यह प्राधिकरण क्यों चाहिए? इससे वैल्यू स्ट्रीम को क्या लाभ है? क्या इसके पास सही फ़ैसले के लिए पर्याप्त जानकारी और समझ है? इसे अनुरोध स्पष्ट करने वाली टीम में क्यों न शामिल करें? तब यह बेहतर जानेगा कि किस बात को मंज़ूरी दे रहा है और 320 घंटे का एक हैंडऑफ़ कम होगा। जब तक प्रवाह धीमा करने वाली बाधाएँ नहीं हटाएँगे, DevOps से ज़्यादा उम्मीद नहीं कर सकते।

DevOps में ऐसे सवालों से पुराने तरीकों को चुनौती दें। संगठन में हर किसी को ये सवाल पसंद नहीं आएँगे। आप इसके लिए तैयार हैं।

काम का प्रवाह सबको दिखाएँ

वैल्यू स्ट्रीम में बाएँ से दाएँ काम बढ़ाने और संगठन के लक्ष्य पूरे करने के लिए ऐसे टूल और तरीके रखें जो प्रवाह दिखाएँ। IT में किसी काम को दूसरी टीम को सौंपना एक क्लिक की बात है। फिर भी अधूरे काम, असंगत निर्भरताओं और ग़लतफ़हमियों से काम टीमों के बीच आगे-पीछे जाता है, जैसे एक कदम आगे, दो पीछे। आगे बढ़े भी तो बहुत धीरे।

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

बैच का आकार और चल रहा काम सीमित करें

यह शोध किया गया था Stanford University में। इसमें पता चला कि एक समय में एक काम करना कई काम साथ करने से ज़्यादा उत्पादक है। कई इलेक्ट्रॉनिक स्रोतों से लगातार जानकारी पाने वाले लोग उतना ध्यान नहीं दे पाते, जानकारी उतनी अच्छी तरह याद नहीं कर पाते या काम बदल नहीं पाते, जितना एक समय में एक काम करने वाले।

अपनी टीम में एक साथ चल रहा काम और कोड डिलीवरी के बैच का आकार घटाएँ। उदाहरण के लिए बार-बार काम बदलने से बचने और ध्यान बनाए रखने के लिए एक समय में डेवलपमेंट के अधिकतम 6 काम रखें। या फ़िबोनाची संख्याओं (0, 1, 2, 3, 5, 8, 13, 21, 34, …) के स्टोरी पॉइंट से हर काम का अनुमान लगाएँ। टीम तय समय (स्प्रिंट) में एक कुल संख्या (वेलोसिटी) तक काम करे।

बैच छोटे करने से गुणवत्ता और उत्पादकता बढ़ती है और समस्याओं के मूल कारण जल्दी ढूँढ और सुलझा सकते हैं। काम पूरा होने पर साझा रिपॉज़िटरी में चेक इन करें, निरंतर इंटीग्रेशन प्लैटफ़ॉर्म से जाँचें और प्रोडक्शन में डिप्लॉय करें। छोटे बैच में डिलीवरी से आई समस्याएँ पहचानना और ज़रूरत पर रोलबैक करना आसान है। निरंतर डिलीवरी से टीम को संगठन के उद्देश्य में योगदान का गर्व भी होता है। इसकी तुलना उन टीमों के मनोबल, प्रेरणा और तकनीकी चुनौतियों से करें, जो 8 महीने कोड लिखती हैं और प्रोडक्शन में एक भी पंक्ति नहीं डालतीं।

तकनीकी ऋण घटाने के लिए 20% समय रखें

तकनीकी ऋण घटाने का समय न रखें और एक के ऊपर एक अस्थायी उपाय जोड़ते रहें, तो एक दिन सभी इंजीनियर पूरा समय समस्याएँ सुधारने में बिताएँगे। वित्तीय ऋण की तरह, आपका संगठन सिर्फ़ ब्याज भर रहा होगा।

निष्कर्ष

इस अध्याय में हमने समझाया कि DevOps में वैल्यू स्ट्रीम और काम का प्रवाह क्या है, क्यों अहम है और काम को उसके ज़रिए आगे कैसे बढ़ाएँ।