8.5 टेस्ट और प्रक्रिया स्वचालन

अवलोकन और प्रेरणा

टेस्ट और प्रक्रिया स्वचालन दोहराव वाले, मैनुअल इंजीनियरिंग और परिचालन कार्य को विश्वसनीय, मशीन-निष्पादित वर्कफ़्लो से बदलने का अभ्यास है। टेस्टिंग पक्ष पर, इसका अर्थ है टेस्ट स्वचालन: स्वचालित टेस्ट सूट जो सत्यता (correctness), प्रदर्शन, और सुरक्षा को सत्यापित करने के लिए लगातार चलते हैं। प्रक्रिया पक्ष पर, यह सॉफ़्टवेयर डिलीवरी और ऑपरेशंस की आसपास की मशीनरी तक फैलता है: अनुपालन प्रमाण जुटाना, परिचालन रनबुक निष्पादित करना, ज्ञात समस्याओं का निवारण करना, और गवर्नेंस, सुरक्षा, और लागत नियंत्रणों को लागू करना। एकीकृत विचार सरल है। जो भी काम बार-बार और पूर्वानुमेय रूप से किया जाता है उसे संहिताबद्ध (codify) किया जाना चाहिए, ताकि यह लगातार, तेज़ी से, और बिना मानवीय थकाऊ मेहनत (toil) के चले।

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

एंटरप्राइज़ और सरकारी संदर्भों में, स्वचालन अनुपालन को टिकाऊ बनाने की कुंजी भी है। विनियमित संगठनों को लगातार यह प्रदर्शित करना होता है कि नियंत्रण मौजूद हैं और प्रमाण एकत्र किया जा रहा है। इसे हाथ से करना महँगा, धीमा, और अंतरालों (gaps) के प्रति प्रवण होता है। प्रमाण संग्रह और नियंत्रण प्रवर्तन को स्वचालित करना अनुपालन को एक आवधिक फ़ायर ड्रिल से प्रणाली के एक सतत, सत्यापन-योग्य गुण में बदल देता है। यह “कंप्लायंस-ऐज़-कोड” दृष्टिकोण लागत को कम करता है और साथ ही वह आश्वासन भी मज़बूत करता है जिसकी लेखा परीक्षकों और नियामकों को आवश्यकता होती है।

प्रमुख सिद्धांत

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

अनुशंसाएँ

तेज़, विश्वसनीय, समानांतर टेस्ट इन्फ्रास्ट्रक्चर बनाएँ

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

रिलीज़, अनुपालन, और प्रमाण संग्रह को स्वचालित करें

स्वचालन को टेस्टिंग से आगे रिलीज़ और अनुपालन वर्कफ़्लो तक विस्तारित करें। पाइपलाइन से स्वचालित रूप से वे आर्टिफ़ैक्ट तैयार करवाएँ जिनकी लेखा परीक्षकों को ज़रूरत है: किसने परिवर्तन को स्वीकृत किया इसका रिकॉर्ड, कौन-से टेस्ट चले और पास हुए, सुरक्षा स्कैन में क्या मिला, और वास्तव में कौन-सा आर्टिफ़ैक्ट परिनियोजित किया गया। नियंत्रणों को कोड के रूप में मानें, ताकि आवश्यक जाँचें समान रूप से लागू हों और उनके परिणाम लॉग किए जाएँ। यह “कंप्लायंस-ऐज़-कोड” प्रमाण जुटाने को ऑडिट से पहले की मैनुअल हड़बड़ी से एक सतत, हमेशा-वर्तमान रिकॉर्ड में बदल देता है। यह प्रणाली की अनुपालन स्थिति को किसी भी क्षण अवलोकन-योग्य भी बनाता है।

ChatOps और रनबुक-ऐज़-कोड अपनाएँ

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

स्वचालित निवारण को सावधानी से लागू करें

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

रोबोटिक प्रोसेस ऑटोमेशन (RPA) को सही ढंग से रखें

रोबोटिक प्रोसेस ऑटोमेशन कार्यों को स्वचालित करने के लिए मौजूदा यूज़र इंटरफ़ेस और एप्लिकेशन को संचालित करता है, उन क्लिक और कीस्ट्रोक की नकल करते हुए जो एक इंसान करता। RPA का एक वैध स्थान है , विरासती (legacy) या तीसरे पक्ष की प्रणालियों के लिए एक सेतु (bridge) के रूप में, जो कोई API नहीं दिखातीं और किसी और तरीके से एकीकृत नहीं की जा सकतीं। ऐसे मामलों के लिए इसका व्यावहारिक रूप से उपयोग करें, लेकिन इसकी सीमाओं को जानें। UI-संचालित स्वचालन स्वाभाविक रूप से भंगुर (brittle) है: जब भी इंटरफ़ेस बदलता है यह टूट जाता है, और यह एकीकरण की अंतर्निहित कमी को हल नहीं करता। जहाँ एक उचित API या एकीकरण उपलब्ध हो, उसे प्राथमिकता दें। RPA को एक रणनीतिक आधार नहीं, बल्कि एक सामरिक (tactical) अस्थायी उपाय मानें, और प्रणालियों के आधुनिकीकरण के साथ इसे बदलने की योजना बनाएँ।

गवर्नेंस, सुरक्षा, और लागत नियंत्रणों को स्वचालित करें

संगठनात्मक नियंत्रणों को ऐसी स्वचालित जाँचों के रूप में एनकोड करें जो लगातार चलती हैं: इन्फ्रास्ट्रक्चर गार्डरेल के लिए पॉलिसी-ऐज़-कोड, पाइपलाइनों में स्वचालित सुरक्षा स्कैनिंग, और लागत विसंगतियों (anomalies) और निष्क्रिय संसाधनों की स्वचालित पहचान। गवर्नेंस को स्वचालित करना नियंत्रणों को समान और अपरिहार्य (unbypassable) बनाता है, और यह उस मात्रा में परिवर्तन तक स्केल करता है जिसे मैनुअल समीक्षा कभी कवर नहीं कर पाती। वही दृष्टिकोण जो सुरक्षा नीति लागू करता है, एक बेतहाशा बढ़ते क्लाउड बिल या किसी छूटे हुए आवश्यक टैग को भी चिह्नित कर सकता है। गवर्नेंस एक आवधिक मैनुअल ऑडिट से एक सतत स्वचालित गार्डरेल में बदल जाता है।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

विकल्प	फ़ायदे	नुकसान	सर्वोत्तम फ़िट
व्यापक स्वचालित टेस्टिंग	तेज़, सुसंगत फ़ीडबैक; परिवर्तन को सक्षम करता है	निर्माण और रखरखाव लागत; फ़्लेकीनेस का जोखिम	स्केल पर सभी टीमें
कंप्लायंस-ऐज़-कोड	सतत, ऑडिट-तैयार प्रमाण	नियंत्रणों को संहिताबद्ध करने का अग्रिम इंजीनियरिंग कार्य	विनियमित संगठन
रनबुक-ऐज़-कोड + ChatOps	दोहराने योग्य, दृश्यमान, लॉग किए गए ऑपरेशंस	संहिताबद्ध और बनाए रखने का प्रयास	वास्तविक ऑप्स लोड वाली टीमें
स्वचालित निवारण	तेज़ रिकवरी; कम थकाऊ मेहनत	पहचान गलत होने पर जोखिम	अच्छी तरह समझी गई बार-बार होने वाली समस्याएँ
RPA (UI स्वचालन)	बिना API वाली प्रणालियों के बीच सेतु बनाता है	भंगुर; एकीकरण अंतरालों को छुपाता है	विरासती प्रणालियों के लिए एक अस्थायी उपाय
स्वचालित गवर्नेंस	समान, अपरिहार्य नियंत्रण	पॉलिसी लेखन और ट्यूनिंग प्रयास	बड़ी, गवर्न की गई संपत्तियाँ (estates)

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. क्या आपके इंटीग्रेशन और एंड-टू-एंड टेस्ट यथार्थवादी, अस्थायी वातावरणों के विरुद्ध चलते हैं, या एक साझा स्टेजिंग बॉक्स के विरुद्ध जिसके लिए सब लड़ते हैं? प्रति पुल रिक्वेस्ट ऑन-डिमांड पृथक वातावरण इंटीग्रेशन और एंड-टू-एंड टेस्ट को यथार्थवादी इन्फ्रास्ट्रक्चर पर बिना टीमों को एक-दूसरे को रोके या साझा स्थिति को दूषित किए चलने देते हैं। एक अकेला साझा स्टेजिंग वातावरण जैसे-जैसे अधिक टीमें उस पर बोझ डालती हैं, एक बॉटलनेक और फ़्लेकी, क्रम-निर्भर विफलताओं का स्रोत बन जाता है। तय करें कि क्या आप अस्थायी वातावरण खड़े कर सकते हैं, उनकी लागत क्या है, और किन टेस्टों को वास्तव में उनकी ज़रूरत है बनाम एक तेज़ इन-मेमोरी विकल्प की। डेटा लाएँ: स्टेजिंग पर कितनी बार विवाद होता है, कितनी विफलताएँ साझा-वातावरण हस्तक्षेप से जुड़ी हैं, और इंटीग्रेशन स्तर के लिए वर्तमान वॉल-क्लॉक समय। उत्तर आपकी टेस्ट विश्वसनीयता और पिरामिड की ऊपरी परतें कितनी तेज़ी से फ़ीडबैक लौटाती हैं, दोनों को आकार देता है।

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

3. आपकी पाइपलाइन में, कौन-से सुरक्षा स्कैन और पॉलिसी जाँच किसी मर्ज को रोकते हैं, और कौन-से केवल चेतावनी देते हैं? स्वचालित गवर्नेंस बनाना तभी सार्थक है जब नियंत्रण अपरिहार्य (unbypassable) हों, क्योंकि एक जाँच जो केवल चेतावनी देती है, समय-सीमा के दबाव में ठीक वैसे ही नज़रअंदाज़ कर दी जाती है जैसे एक विकी पॉलिसी। जाँच-दर-जाँच तय करें कि क्या रोकता है और क्या चेतावनी देता है: एक गंभीर भेद्यता या एक छूटा हुआ एन्क्रिप्शन टैग शायद रोकना चाहिए, जबकि कम-गंभीरता वाला स्टाइल निष्कर्ष चेतावनी दे सकता है। स्केल पर यही वह तरीका है जिससे आप उस मात्रा में परिवर्तन पर सुरक्षा और लागत गार्डरेल को समान रूप से लागू करते हैं जिसे कोई मैनुअल समीक्षा कवर नहीं कर सकती। अपनी वर्तमान जाँच सूची लाएँ और हर एक को रोकने वाली या सलाहकारी के रूप में चिह्नित करें, फिर झूठे-सकारात्मक (false-positive) दर पर चर्चा करें, क्योंकि एक शोरगुल भरी रोकने वाली जाँच लोगों को अपवाद माँगना सिखाती है। रोकने और चेतावनी देने के बीच की रेखा ही यह तय करती है कि आपकी गवर्नेंस में दम है या नहीं।

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

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

6. हम RPA से जिस भी विरासती प्रणाली को स्वचालित करते हैं, उसके लिए एक वास्तविक एकीकरण के पक्ष में उस RPA को रिटायर करने की ठोस योजना और ट्रिगर क्या है? RPA उन प्रणालियों के लिए एक वैध सेतु है जो कोई API नहीं दिखातीं, लेकिन बिना किसी निकास योजना वाला एक सेतु चुपचाप स्थायी, भंगुर इन्फ्रास्ट्रक्चर में कठोर हो जाता है जो हर UI परिवर्तन पर टूटता है और उसी एकीकरण अंतराल को मज़बूत करता है जिसे पाटने के लिए यह बनाया गया था। ट्रेड-ऑफ़ वास्तविक है: RPA अभी तेज़ी से और सस्ते में मूल्य देता है, जबकि एक उचित API एकीकरण की अग्रिम लागत अधिक है लेकिन यह टिकाऊ है, इसलिए अनुशासन यह है कि RPA को एक खरीद नहीं बल्कि एक समयबद्ध ऋण (dated loan) माना जाए। उत्पादन में RPA बॉट की सूची, हरेक जिस प्रणाली पर निर्भर है, हरेक कितनी बार टूटता है, और क्या अंतर्निहित प्रणाली के लिए आधुनिकीकरण या एकीकरण प्रयास वास्तव में वित्तपोषित और निर्धारित है, लाएँ। दशकों पुराने मूल एप्लिकेशन ले जाने वाली एंटरप्राइज़ और सरकारी संपत्तियों के लिए, हर RPA बॉट को एक नामित आधुनिकीकरण माइलस्टोन से जोड़ें, क्योंकि ऐसा RPA जो बिना किसी रिटायरमेंट तारीख के चुपचाप महत्वपूर्ण बन गया है, वह तकनीकी ऋण है जो हर साल बढ़ता है जब तक वह इंटरफ़ेस जिसे यह स्क्रेप करता है बदलता रहता है।

क्षेत्र लेंस

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

छोटा व्यवसाय। कोई समर्पित टेस्ट या प्लेटफ़ॉर्म विशेषज्ञ न होने पर, उन टूल में पके हुए स्वचालन पर निर्भर रहें जिनके लिए आप पहले से भुगतान करते हैं: CI सेवा के अंतर्निहित टेस्ट रनर, इसके स्कैनिंग ऐड-ऑन, और अनुकूलित टेस्ट-इन्फ्रास्ट्रक्चर बनाने के बजाय प्रबंधित (managed) वातावरण। खरीदें-बनाम-बनाएँ विकल्प को उस रखरखाव के इर्द-गिर्द तय करें जिसे आप वास्तव में टिकाए रख सकें, क्योंकि एक चतुर कस्टम पाइपलाइन जिसे कोई बनाए नहीं रख सकता, एक सादे होस्टेड पाइपलाइन से बदतर परिणाम है। RPA का कम उपयोग करें और केवल तभी जब कोई विक्रेता टूल उस प्रणाली को पाटता हो जिसे आप किसी और तरीके से एकीकृत नहीं कर सकते।

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

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

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

टेस्ट और प्रक्रिया स्वचालन का ROI पुनः प्राप्त इंजीनियर समय, तेज़ और सुरक्षित डिलीवरी, तेज़ घटना रिकवरी, और नाटकीय रूप से कम अनुपालन लागत के रूप में दिखाई देता है। स्वचालित टेस्टिंग उस तेज़, आत्मविश्वासी परिवर्तन को सक्षम बनाती है जो डिलीवरी प्रदर्शन का आधार है। स्वचालित ऑपरेशंस और निवारण उस थकाऊ मेहनत और डाउनटाइम को कम करते हैं जो टीमों और बजटों को खाली करते हैं। कंप्लायंस-ऐज़-कोड एक ऑडिट को हफ़्तों की मैनुअल तैयारी से एक नियमित क्वेरी में बदल सकता है, एक ऐसी बचत जो वित्तीय और प्रतिष्ठा दोनों की दृष्टि से है।

TCO तुलना स्वचालन बनाने और बनाए रखने की वास्तविक, चल रही लागत को न-स्वचालित करने की लागत के विरुद्ध तौलती है। मैनुअल टेस्टिंग और ऑपरेशंस केवल खर्च किए गए घंटों की लागत नहीं रखते। इनकी लागत उन दोषों की भी है जो बच निकलते हैं, उन घटनाओं की जो लंबी चलती हैं, उन ऑडिट की जो विशेषज्ञ स्टाफ़ को खा जाते हैं, और उन इंजीनियरों की थकावट (burnout) की जो दोहराव वाली थकाऊ मेहनत करते हैं। नेतृत्व के लिए, तर्क सीधा है: स्वचालन बार-बार होने वाले परिचालन खर्च और जोखिम को एक ऐसे एकमुश्त-प्लस-रखरखाव निवेश में बदल देता है जो स्केल करता है, और यह गुणवत्ता व अनुपालन को आवधिक के बजाय सतत बनाता है। एक चेतावनी स्पष्ट रूप से कहने लायक है। स्वचालन को बनाए रखा और भरोसेमंद बनाया जाना चाहिए; अवित्तपोषित, उपेक्षित स्वचालन एक देनदारी में सड़ जाता है।

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

स्तर 1, आरंभ (Initiate)। टेस्टिंग और ऑपरेशंस ज़्यादातर मैनुअल और प्रतिक्रियात्मक हैं। कवरेज तदर्थ है, प्रक्रियाएँ लोगों के दिमाग़ या पुराने दस्तावेज़ों में रहती हैं, निवारण घटनाओं के दौरान हाथ से होता है, और अनुपालन प्रमाण हर ऑडिट से पहले हड़बड़ी में इकट्ठा किया जाता है।

स्तर 2, विकास (Develop)। स्वचालित टेस्ट मौजूद हैं लेकिन धीमे, फ़्लेकी हैं, या असंगत रूप से चलते हैं, और प्रथाएँ टीमों के बीच व्यापक रूप से भिन्न होती हैं। कुछ परिचालन स्क्रिप्ट और रनबुक जेबों (pockets) में मौजूद हैं, लेकिन निवारण अभी भी मैनुअल है और गवर्नेंस सतत जाँचों के बजाय आवधिक समीक्षा द्वारा लागू किया जाता है।

स्तर 3, मानकीकरण (Standardize)। तेज़, समानांतर, विश्वसनीय टेस्ट इन्फ्रास्ट्रक्चर दस्तावेज़ीकृत संगठन-व्यापी मानक है। रनबुक-ऐज़-कोड और ChatOps सामान्य उपयोग में हैं, अनुपालन प्रमाण पाइपलाइन रन से स्वचालित रूप से उत्पन्न होता है, और गवर्नेंस नियंत्रण टीमों में लगातार लागू किए गए स्वचालित जाँच के रूप में चलते हैं।

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

स्तर 5, ऑर्केस्ट्रेशन (Orchestrate)। स्वचालन को पूरे संगठन में लगातार बेहतर और एकीकृत किया जाता है। स्वचालित निवारण सिद्ध सुरक्षा उपायों के साथ नियमित घटनाओं को संभालता है, अनुपालन सतत और हमेशा ऑडिट-तैयार है, और टेस्ट, ऑप्स, और गवर्नेंस टूलचेन प्रणालियों के बदलने पर अनुकूलित होते हैं, साथ ही एकीकरण परिपक्व होने पर RPA सेतुओं को सक्रिय रूप से रिटायर किया जाता है। मनुष्य निर्णय-क्षमता पर ध्यान केंद्रित करते हैं जबकि मशीनें दोहराने योग्य काम संभालती हैं, और पूरी प्रणाली साक्ष्य पर फिर से संतुलित होती है।

चर्चा के लिए विचार

• कौन-सी परिचालन प्रक्रियाओं को पूरी तरह स्वचालित करना सुरक्षित है, और किनमें मनुष्य को लूप में रखना ज़रूरी है?
• आप एक बड़े टेस्ट सूट को बढ़ने के साथ तेज़ और फ़्लेक-मुक्त कैसे रखते हैं?
• आपकी विरासती प्रणालियों के लिए RPA कहाँ एक न्यायसंगत सेतु है, और इसे रिटायर करने की योजना क्या है?
• आप पहले किन नियंत्रणों को मैनुअल ऑडिट से सतत कंप्लायंस-ऐज़-कोड में बदल सकते हैं?
• आप बिना बढ़ी हुई घटनाओं का जोखिम उठाए स्वचालित निवारण में भरोसा कैसे बनाते हैं?
• आप स्वचालन के लिए आवश्यक चल रहे रखरखाव को कैसे वित्तपोषित करते हैं ताकि यह एक देनदारी में न सड़ जाए?

मुख्य निष्कर्ष

• दोहराए जाने वाले, पूर्वानुमेय, और नियम-आधारित काम को स्वचालित करें; मानवीय प्रयास को निर्णय-क्षमता और उच्च-जोखिम निर्णयों के लिए सुरक्षित रखें।
• स्वचालित टेस्ट को तेज़, समानांतर, और विश्वसनीय बनाएँ, और फ़्लेकीनेस को निर्दयता से समाप्त करें।
• ऑपरेशंस को रनबुक-ऐज़-कोड के रूप में संहिताबद्ध करें और दृश्यता व रिकॉर्ड के लिए उन्हें ChatOps के माध्यम से सामने लाएँ।
• अनुपालन प्रमाण स्वचालित रूप से उत्पन्न करें ताकि ऑडिट एक सतत, वर्तमान रिकॉर्ड पर आधारित हों।
• RPA का उपयोग केवल बिना API वाली प्रणालियों के लिए एक जानबूझकर, अस्थायी सेतु के रूप में करें, और इसके रिटायरमेंट की योजना बनाएँ।
• गवर्नेंस, सुरक्षा, और लागत नियंत्रणों को सतत स्वचालित जाँच के रूप में लागू करें, जोखिम भरी कार्रवाइयों की निगरानी मनुष्यों द्वारा करते हुए।

संदर्भ और आगे पठन

• Lisa Crispin and Janet Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams.
• Jez Humble and David Farley, Continuous Delivery.
• Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering (see the chapter on eliminating toil).
• Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
• Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate.
• NIST Special Publication 800-53 and 800-137 (continuous monitoring).
• Open Policy Agent documentation (policy as code).