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

DevOps संगठन कैसे बनाएँ और सॉफ़्टवेयर आर्किटेक्चर कैसे डिज़ाइन करें?

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

संगठन की बनावट तय करती है कि आपका सॉफ़्टवेयर कैसा होगा

ज़्यादातर कंपनियाँ, शायद आपकी भी, सॉफ़्टवेयर डिलीवरी को अलग-अलग टीमों में बाँटती हैं। सॉफ़्टवेयर आर्किटेक्चर में उतनी ही परतें बनती हैं। नियंत्रित प्रयोग में 6 टीमों वाले संगठन को सॉफ़्टवेयर बनाने दिया गया, तो उसने 6 परतों वाला आर्किटेक्चर बनाया। वही काम 3 टीमों के संगठन ने 3 परतों में किया। ऐसे कई उदाहरण हैं।

दुनिया भर में 86,000 कर्मचारियों वाली एक प्रसिद्ध बीमा कंपनी ने अपने एक IT संगठन को 2 मुख्य कार्यात्मक टीमों में बाँटा था। वे ग्राहकों, अनुबंधों, बिलों और सेवाओं के लिए बैकएंड देती थीं। एक टीम Java और दूसरी PL/SQL स्टोर्ड प्रोसीजर पर काम करती थी। दोनों केंद्रीय IT ऑपरेशंस, डेटाबेस प्रशासन, इन्फ़्रास्ट्रक्चर, नेटवर्किंग, सुरक्षा और गुणवत्ता आश्वासन के सर्विस डेस्क पर निर्भर थीं। इससे सुरक्षित डिलीवरी कठिन होती थी।

टीमें अलग थीं, फिर भी Java का व्यावसायिक ऑर्केस्ट्रेशन लॉजिक और PL/SQL का डेटा एक्सेस लॉजिक अलग नहीं कर सकीं। सैकड़ों फ़ीचर Java और PL/SQL के उलझे कोड से बने। हर बदलाव और नए फ़ीचर पर टीमों के बीच दर्जनों हैंडऑफ़ होते, जिससे छोटे काम भी लंबी कतारों और लीड टाइम में फँस जाते। छोटे बदलाव का पूरा असर भी अनुमान लगाना कठिन था। टीमों के बदलाव मौजूदा प्रोडक्शन फ़ीचर बार-बार बिगाड़ देते, जिससे डाउनटाइम होता। उसे ठीक करने में काफ़ी समय, दोबारा काम, ऊपरी स्तर पर मदद और तनाव लगता था।

काम का तरीका बदलने के लिए दोनों कार्यात्मक टीमें एक प्रोडक्ट टीम बनीं। उन्होंने सॉफ़्टवेयर धीरे-धीरे फिर डिज़ाइन करके डेटा एक्सेस लेयर को API फ़ंक्शन में बदला। नया व्यावसायिक सिस्टम डेटा एक्सेस API के अंदरूनी काम से पूरी तरह अलग बनाया। शुरुआत में ही मनोबल बढ़ा, क्योंकि Java और PL/SQL के विशेषज्ञ अपने अलग विभागों की जगह साझा उत्पाद की सफलता के लिए काम करने लगे। कम आपसी निर्भरता वाले आर्किटेक्चर में बदलाव का असर ढूँढना, बदलाव लागू करना और दोष पहचानकर ठीक करना आसान और तेज़ हुआ। नए फ़ीचर का औसत लीड टाइम 4 महीने से घटकर 3 हफ़्ते हुआ। घटनाओं की कतार लगभग खाली है, इसलिए टीम अतिरिक्त समय कोड की समीक्षा, रीफ़ैक्टरिंग और सुधार में लगाती है।

मैट्रिक्स संगठन, कार्यात्मक टीमें और लागत घटाने का भ्रम

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

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

इन टीमों के पास अक्सर टिकटों की लंबी कतार होती है। आपकी परियोजना को मदद मिलने में समय लगता है। संसाधनों के लिए परियोजनाओं की होड़ में ऊपरी स्तर पर बात उठाना जल्दी ध्यान पाने का एकमात्र तरीका बन जाता है। बार-बार ऐसा करने से काम का माहौल और टीमों का आपसी भरोसा बिगड़ता है।

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

DevOps इस बड़ी समस्या को कैसे हल करता है? उत्पाद और सेवा-केंद्रित टीमों से

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

DevOps उत्पाद और सेवा-केंद्रित टीमों की सलाह देता है। ये स्वतंत्र, अलग-अलग कौशल वाली, स्वायत्त, आत्मनिर्भर और आम तौर पर छोटी होती हैं। वे किसी अस्थायी परियोजना की बजाय किसी उत्पाद या सेवा के जीवनचक्र के सभी चरण सँभालती हैं: आर्किटेक्चर, डिज़ाइन, कोडिंग, टेस्टिंग, प्रयोग, डिप्लॉयमेंट, ऑपरेशंस और रखरखाव। आपने सही पढ़ा। सॉफ़्टवेयर बनाने वालों से बेहतर कौन उसे चला और सँभाल सकता है? कोई नहीं। Amazon और Netflix की सबसे सफल DevOps टीमें रिलीज़ के बाद उत्पाद और सेवाएँ नहीं छोड़तीं। वे अपने प्रोडक्शन सिस्टम में सॉफ़्टवेयर चलाती और सँभालती भी हैं।

आपका संगठन अस्थायी परियोजनाओं की जगह उत्पादों और सेवाओं को धन देता है

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

अपनी DevOps टीमें और सॉफ़्टवेयर आर्किटेक्चर कैसे बनाएँ?

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

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

एक और तरीका जिस पर विचार कर सकते हैं

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

आपकी DevOps टीम कितनी बड़ी होनी चाहिए?

5 से 10 लोगों की टीम आदर्श है। इससे संवाद और तालमेल कम जटिल होते हैं। टीम लीड और सदस्य गैरज़रूरी कामों में कम समय गँवाते हैं। इससे उत्पाद और सेवाओं का दायरा भी सीमित रहता है और ऐप्लिकेशन का रखरखाव और संचालन आसान होता है। हर सदस्य बड़ी तस्वीर समझता है और संगठन के अहम उद्देश्य में भाग लेकर कुछ नेतृत्व अनुभव पाता है। टीम लीड वरिष्ठ प्रबंधन से लक्ष्य समझकर टीम को बताता है।

यदि 10 लोगों तक की टीम आपका उत्पाद और सेवा नहीं सँभाल पा रही, तो क्या करें?

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

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

10 लोगों तक की छोटी टीमें आर्किटेक्चर से ऑपरेशंस तक पूरे जीवनचक्र को खुद कैसे सँभालें?

सभी को कई कामों की समझ रखने वाला जनरलिस्ट बनने के लिए प्रोत्साहित करें। उन्हें लगातार नए कौशल सीखने का मौका दें।

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

माँग आज नहीं तो कल बदलेगी।

निष्कर्ष

इस अध्याय में हमने मैट्रिक्स संगठन और उनके अलग-थलग कार्यात्मक विभागों के खराब नतीजे और DevOps का समाधान समझाया।

DevOps उत्पाद, सेवा या माइक्रोसर्विस API पर केंद्रित 10 लोगों तक की छोटी टीमें बनाने का सुझाव देता है।

टीम में कई कामों की समझ वाले फ़ुल-स्टैक इंजीनियर हों, जो डिज़ाइन से रखरखाव तक जीवनचक्र के सभी चरण खुद सँभालें।

DevOps कम आपसी निर्भरता वाले सर्विस-ओरिएंटेड आर्किटेक्चर (SOA) पर निर्भर है, जिसमें हर टीम अपने हिस्से की मालिक होती है और उसे चलाती है।