लिखित DevOps प्रशिक्षण
DevOps में निरंतर सीखने को कैसे बढ़ावा दें?
अपनी परियोजनाओं से जानते हैं कि चेकलिस्ट, सहकर्मी समीक्षा, नियंत्रण, ऑडिट और अनुपालन के बाद भी समस्याएँ होती हैं। यह टाला नहीं जा सकता। ऐसी संस्कृति बनाएँ जिसमें टीम और संगठन खुद समस्याएँ पहचानें, सीखें और सुधार करें। समस्याएँ स्वीकार करें और उनके आने पर तैयार रहें। समस्या हल करना रोज़ के काम और निरंतर सुधार का हिस्सा है। समाधान पूरे संगठन में खुले और आसानी से उपलब्ध रखने से उनका असर बढ़ता है।
प्रमुख DevOps संगठनों में से एक Netflix ने क्लाउड डेटा सेंटर में गंभीर घटनाओं का अनुकरण करने के लिए अपना Chaos Monkey सॉफ़्टवेयर बनाया। यह प्रोडक्शन में यादृच्छिक रूप से सर्वर बंद करता है, ताकि टीम अपने ऑपरेशंस की मज़बूती, स्थिरता और ग्राहकों को बिना रुकावट अच्छी सेवा देने की क्षमता पर ज़्यादा भरोसा कर सके। हर विफलता से सीखकर वे सिस्टम और मज़बूत करते हैं।
सीखने की संस्कृति क्यों महत्वपूर्ण है
घटनाओं के बाद दोषारोपण से इंजीनियरों में डर पैदा होता है। संगठन धीमा, नौकरशाही और अंदरूनी राजनीति से भरा हो जाता है। ग़लतियों से सीखने, उनके असर से उबरने और सावधानी से उन्हें रोकने की जगह लोग अपना बचाव करते हैं। काम, समस्याएँ और समाधान भी पूरी तरह खुले नहीं रहते।
Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so
- कम ग़लतियाँ करने के लिए कम काम करेंगे।
- काम, समस्याओं और समाधानों के बारे में खुलकर नहीं बताएँगे।
- समाधान को पूरे संगठन की सीख में बदलने के लिए प्रेरित नहीं होंगे।
- वही या बहुत मिलती-जुलती समस्या ज़रूर दोहराएगी, क्योंकि कोई सीखने, समस्याएँ व समाधान साझा करने और दूसरों को सिखाने में समय और ऊर्जा नहीं लगाएगा।
घटना के तुरंत बाद पोस्टमॉर्टम करें, जब कारण याद हों
पोस्टमॉर्टम समीक्षा के लक्ष्य सरल हैं:
- पहचानें कि क्या सही किया ताकि मिलती-जुलती स्थिति में दोहरा सकें।
- दर्ज करें कि क्या अलग करना चाहिए था, ताकि भविष्य में अपने तरीके सुधार सकें।
- दर्ज करें कि क्या ग़लत किया और वैसी समस्या फिर हो तो दूसरे तरीके या सुरक्षा उपाय सुझाएँ।
- समझें कि जिस कदम से घटना हुई, उस समय उसे उठाना या न उठाना उचित क्यों लगा।
अपनी ग़लती की जाँच डरावनी और कुछ संगठनों में खतरनाक हो सकती है। ग़लती मानने पर आलोचना या अनुशासनात्मक कार्रवाई हो सकती है, तो लोग उसे नहीं मानेंगे। इससे अंत में नुकसान होता है। पुरानी ग़लती समझे बिना आगे उसके दोहरने की संभावना है। सुधार को गंभीरता से लेने वाले संगठन ऐसी प्रक्रिया और संस्कृति बनाते हैं जिसमें ग़लतियों की जाँच सुरक्षित हो।
पोस्टमॉर्टम शुरू करते समय कुछ बुनियादी बातें मानें:
- सभी अपनी समझ के अनुसार सबसे अच्छा करने की कोशिश करते हैं।
- तनाव में आप अधूरी जानकारी पर फ़ैसले लेते हैं।
- अक्सर आपको बिना प्रशिक्षण के काम करने पड़ते हैं, जो भी टूल और संसाधन हाथ में हों उनसे।
- ऐसी परिस्थितियों में ग़लतियाँ होना तय है।
- मकसद किसी व्यक्ति या उसके काम में दोष ढूँढना नहीं है। देखें क्या हुआ और उससे क्या सीख सकते हैं।
- नतीजा किसी व्यक्ति या समूह का आकलन नहीं होगा। प्रक्रियाओं और उन्हें सुधारने के तरीकों का आकलन होगा।
ज़रूरी है कि सभी इस सिद्धांत को पूरी तरह स्वीकार करें: «दोषारोपण नहीं, हम यहाँ सीखने के लिए हैं»। ऐसे सुरक्षित परिवेश बनाने के लिए कई संगठन बहुत मेहनत करते हैं। उदाहरण के लिए FAA की Aviation Safety Reporting System में «ग़लती» करने वाले पायलट घटना की रिपोर्ट करके नियामक अनुशासन से छूट पा सकते हैं।
पोस्टमॉर्टम में घटना दोहरने से रोकने के लिए करने योग्य कदम तय हों। उदाहरण हैं नए टेलीमेट्री मेट्रिक्स, नए ऑटोमेटेड टेस्ट, बदलाव के ऐसे प्रकार पहचानना जिनमें अतिरिक्त कोड समीक्षा चाहिए, रीफ़ैक्टरिंग या बार-बार समस्या देने वाले जटिल कंपोनेंट की निर्भरता कम करना।
पूरे संगठन में पोस्टमॉर्टम का रिकॉर्ड और सीख प्रकाशित करें। इससे एक कार्यकेंद्र की स्थानीय सीख पूरे संगठन के काम आती है। यह पारदर्शिता, खुलेपन और सीखने को बढ़ावा देने का साफ़ संदेश है।
सिस्टम बेहतर बनाने के लिए गेम डे आयोजित करें
गेम डे कोई उबाऊ टीम कार्यक्रम नहीं है जहाँ बाहरमुखी लोग मज़े करें और अंतर्मुखी फ़ोन पर समय बिताएँ।
गेम डे में टेस्ट सिस्टम में गंभीर विफलताओं की नकल की जाती है। DevOps टीमें उन्हें ठीक करती और उनसे सीखती हैं।
मिसाल के लिए महत्वपूर्ण सर्वर बंद करके देखें कि फ़ेलओवर बिना सेवा रुकावट के सफल होता है या नहीं। फिर टीम जाँचती है कि बैकअप या Infrastructure as Code (IaC) से बहाली कैसे और क्या हो पाती है। इन परिस्थितियों की समस्याएँ पहचानकर टीम मज़बूत, दोष-सहिष्णु सिस्टम बनाती और सीखती है।
समस्या हल करते समय टीम दूसरे विभागों से संबंध बनाती है, क्योंकि वे बिना असली तनाव के विफलता का पूर्वाभ्यास करते हैं। पूरे बड़े संगठन में संवाद और समस्या निवारण को परखने और सुधारने का मौका मिलता है।
भविष्य की बड़ी समस्याओं के हल्के संकेत भी दिखते हैं। अभ्यास में बार-बार कम प्राथमिकता वाली घटनाएँ या छोटा दुष्प्रभाव जिससे दूसरा महत्वपूर्ण कंपोनेंट लगभग क्रैश हो गया, ऐसे संकेत हैं। उन्हें ध्यान में रखकर सिस्टम बेहतर करें।
निष्कर्ष
टीम को सोचे-समझे जोखिम लेने दें। उच्च प्रदर्शन वाले DevOps संगठन ज़्यादा बार ग़लतियाँ करते हैं। इससे सीखने और बेहतर प्रदर्शन करने में मदद मिलती है।
सामान्य संगठनों के मुकाबले उच्च प्रदर्शन वाले संगठनों में प्रोडक्शन की गंभीर विफलताएँ 80% कम होती हैं। यानी ग्राहकों को प्रभावित करने वाली घटनाएँ 5 गुना कम हैं। इसलिए इंजीनियरों को ग़लती करने और उससे सीखने की आज़ादी महसूस होनी चाहिए।
