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

DevOps क्या है?

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

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

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

DevOps को समझने का सबसे अच्छा तरीका है इसकी तुलना क्रमिक एजाइल सॉफ़्टवेयर डेवलपमेंट और प्रक्रिया सुधार के फ़्रेमवर्क से करना। इनमें Scrum, लीन, ITIL, IDEAL (Initiate, Define, Establish, Act and Learn) और Six Sigma DMAIC (Define, Measure, Analyze, Improve and Control) शामिल हैं।

एजाइल Scrum, लीन, ITIL, IDEAL और Six Sigma DMAIC DevOps में प्रभावी मदद कर सकते हैं, लेकिन DevOps को इन तरीकों का मिला-जुला और उन्नत रूप नहीं समझना चाहिए। कारण सरल है। एजाइल Scrum के अलावा इनमें से कोई तरीका खास तौर पर सॉफ़्टवेयर उद्योग की समस्याएँ हल करने के लिए नहीं बना था।

DevOps की कई प्रथाएँ और सिद्धांत लीन आंदोलन से आए हैं। उन्हें सॉफ़्टवेयर डेवलपमेंट, डिलीवरी और ऑपरेशंस के लिए ढाला, आज़माया, जाँचा और बेहतर बनाया गया। DevOps ने निरंतर डिलीवरी आंदोलन, Toyota Improvement Kata, Theory of Constraints, एजाइल घोषणापत्र और एजाइल इन्फ़्रास्ट्रक्चर से भी कई तकनीकें और विचार अपनाए।

लीन आंदोलन:

लीन आंदोलन के सात मुख्य सिद्धांत हैं:

1. पूरी प्रणाली देखें और उसके आपसी संबंध समझकर ग्राहक के लिए मूल्य बनाएँ।
2. शुरुआत से गुणवत्ता शामिल करें, काम का प्रवाह बनाएँ और काम थोपने के बजाय माँग के अनुसार आगे बढ़ाएँ।
3. जितना जल्दी हो सके डिलीवरी करें। कच्चे माल से तैयार उत्पाद या सॉफ़्टवेयर में विचार से प्रोडक्शन में चल रहे उपयोगी फ़ीचर तक का लीड टाइम घटाएँ।
4. सीखने के अवसर बढ़ाएँ और वैज्ञानिक सोच अपनाएँ।
5. टीम को निर्णय की ताकत दें, विनम्रता से नेतृत्व करें और हर व्यक्ति का सम्मान करें।
6. बर्बादी दूर करें, चाहे वह टूल और सिस्टम की हो या सबसे महत्वपूर्ण, उन कामों में लगने वाले समय की जिनसे कोई लाभ नहीं मिलता।
7. जितना देर संभव हो निर्णय लें, यानी ज़रूरत पड़ने पर ही फ़ैसला करें।

निरंतर डिलीवरी आंदोलन:

डिप्लॉयमेंट पाइपलाइन से निरंतर डिलीवरी संभव करें। पाइपलाइन के तीन अहम उद्देश्य हैं: दृश्यता, फ़ीडबैक और निरंतर डिप्लॉयमेंट।

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

Toyota Improvement Kata:

Toyota Improvement Kata एक नियमित अभ्यास है, जिससे आप रचनात्मक और लक्ष्य-केंद्रित तरीके से मौजूदा स्थिति से नई स्थिति की ओर बढ़ते हैं। इसके चार हिस्से हैं:

1. एक बड़े विज़न या बेहतर दिशा पर विचार करते हुए …
2. मौजूदा स्थिति समझें।
3. फिर अगली लक्ष्य स्थिति तय करें।
4. लगातार छोटे चरणों में लक्ष्य स्थिति की ओर बढ़ने की कोशिश करें। रास्ते में जिन बाधाओं का पता चले, उन्हें समझकर दूर करें।

सुधार के दूसरे तरीके पहले रास्ते का अनुमान लगाते हैं और कार्यान्वयन पर ध्यान देते हैं। Toyota Improvement Kata में आप रास्ते में मिली नई जानकारी से सीखते हैं और उसी पर आगे बढ़ते हैं। आप और आपकी टीम लक्ष्य स्थिति पाने की कोशिश में सीखते हैं और सीख के अनुसार तरीका बदलते हैं।

Theory of Constraints (बाधाओं का सिद्धांत):

सॉफ़्टवेयर डिलीवरी करने वाले हर संगठन में IT और व्यवसाय के बीच लगातार टकराव रहता है। व्यावसायिक माँग का तेज़ जवाब देने और साथ ही प्रोडक्शन को स्थिर और अनुमानित रखने के बीच IT को संतुलन बैठाना पड़ता है। कोई प्रोडक्शन रिलीज़ जोखिम से पूरी तरह मुक्त नहीं होती। जटिल सिस्टम में कम जोखिम रखना हो, तो ज़रूरत के मुताबिक तेज़ी से रिलीज़ करना कठिन है। और जल्दी कोड रिलीज़ करना हो, तो कम जोखिम सुनिश्चित करना कठिन है।

इस टकराव को सँभालने के लिए:

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

एजाइल घोषणापत्र:

DevOps में आप एजाइल घोषणापत्र के मूल सिद्धांत अपनाते हैं:

• प्रक्रियाओं और टूल से ज़्यादा लोगों और उनके संवाद को महत्व दें।
• विस्तृत दस्तावेज़ों से ज़्यादा काम करने वाले सॉफ़्टवेयर को महत्व दें।
• अनुबंध की शर्तों और बातचीत से ज़्यादा ग्राहक के साथ सहयोग को महत्व दें।
• योजना का पालन करने से ज़्यादा बदलाव के अनुरूप ढलने को महत्व दें।

एजाइल इन्फ़्रास्ट्रक्चर:

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

एजाइल इन्फ़्रास्ट्रक्चर के DevOps के लिए उपयोगी होने की कुछ मुख्य वजहें:

• कीमतें सरल और पारदर्शी हैं और आप अपने इस्तेमाल का ही भुगतान करते हैं।
• कोडबेस से टेस्ट और प्रोडक्शन परिवेश जल्दी बना और हटा सकते हैं (IaC – Infrastructure as Code)।
• आर्किटेक्चर में लचीलापन रहता है।
• दूसरे भौगोलिक क्षेत्रों में आसानी से विस्तार कर सकते हैं।
• संभवतः बेहतर सुरक्षा मिलती है।
• ऑडिट और अतिरिक्त लागत के बिना अनुपालन बना रहता है।

निष्कर्ष

इस भाग में हमने DevOps का मतलब और उसकी सीमाएँ समझाईं। हमने उन मुख्य आंदोलनों और सिद्धांतों के बारे में भी बताया जिनसे DevOps बना है।

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

याद रखें कि केंद्र में सीखना, प्रयोग करना और अपने तरीके बदलना है। DevOps हमारे लिए बहुत उपयोगी काम करता है। हमारी सबसे बड़ी ज़िम्मेदारी है उसकी सही शैली और रूप पहचानना। Google, Amazon, Facebook, Netflix और Apple समेत हर सफल DevOps संगठन यही करता रहा है।