मौजूदा प्लेटफॉर्म उपकरणों के साथ आपदा पुनर्प्राप्ति योजना

आपदा पुनर्प्राप्ति (Disaster Recovery) योजना हमेशा कठिन होती है — इसमें इतने सारे कारक और “क्या होगा अगर” होते हैं जिन पर विचार करना पड़ता है, और पुनर्प्राप्ति समाधान में बहुत अधिक निवेश करना स्वयं एक छोटी-सी आपदा बन सकता है। DR योजना में अक्सर एक पहलू को नज़रअंदाज़ किया जाता है: किसी आपदा की स्थिति में आप आम तौर पर समझौते करने में सक्षम और पूरी तरह तैयार होते हैं, क्योंकि आपदा पहले ही आ चुकी होती है। यह ट्रायज का समय होता है, न कि सामान्य व्यवसाय का।

बहुत से लोग तुरंत यह सोच लेते हैं कि यदि लाइव, उत्पादन प्रणालियों के लिए X क्षमता और performance की आवश्यकता है, तो आपदा पुनर्प्राप्ति प्रणालियों के लिए भी X की आवश्यकता होगी। लेकिन वास्तविक दुनिया में, यह शायद ही कभी सच होता है। किसी आपदा की स्थिति में आप, कुछ दुर्लभ अपवादों को छोड़कर, कम performance के साथ काम कर सकते हैं और system की उपलब्धता को केवल अधिक महत्वपूर्ण प्रणालियों तक सीमित कर सकते हैं — और कई रखरखाव कार्य, जिनमें अक्सर archiving systems शामिल हैं, पूर्ण उत्पादन बहाल होने तक निलंबित रहते हैं। इसका मतलब है कि आपकी आपदा पुनर्प्राप्ति प्रणाली अक्सर आपकी प्राथमिक उत्पादन प्रणालियों से बहुत छोटी हो सकती है।

आपदा पुनर्प्राप्ति प्रणालियाँ उत्पादकता में निवेश नहीं हैं, ये विफलता के विरुद्ध सुरक्षा हैं और इन्हें उसी दृष्टिकोण से देखा जाना चाहिए। इसीलिए DR प्रणाली की ज़रूरतों को “पर्याप्त” के नज़रिए से देखना एक सामान्य और प्रभावी रणनीति है — यानी व्यावसायिक गतिविधियाँ चलाने के लिए पर्याप्त, लेकिन जरूरी नहीं कि आरामदायक या पारदर्शी तरीके से। यदि पूरी तरह की आपदा आती है और कर्मचारियों को धीमी file retrieval, सामान्य से धीमे database या high-performance उत्पादन प्रणालियों के बहाल होने तक BI analysis रोकने से जूझना पड़े, तो बहुत कम लोग शिकायत करेंगे। अधिकांश कर्मचारी और निश्चित रूप से व्यावसायिक निर्णय लेने वाले यह समझ सकते हैं कि system विफल अवस्था में है और उन्हें पूरी क्षमता बहाल होने तक जितना हो सके काम करना होगा।

इस दृष्टिकोण को ध्यान में रखते हुए, यह एक प्रभावी रणनीति हो सकती है कि नए platforms के लिए प्राथमिक उत्पादन उपयोग के लिए खरीदारी और कार्यान्वयन के समय पुराने platforms को Disaster Recovery sites पर पुनः उपयोग किया जाए। इससे एक कम लागत वाली और आसानी से नियोजित “DR pipeline” बन सकती है जहाँ DR site में हमेशा आपके “अंतिम refresh” की क्षमता होती है जो अधिकांश DR परिदृश्यों में पर्याप्त से अधिक होती है। यह उस उपकरण का उपयोग करने का एक शानदार तरीका हो सकता है जिसे अन्यथा या तो सीधे रद्द कर दिया जाता या “sunk cost” की भावनात्मक प्रतिक्रिया के कारण उत्पादन में फिर से तैनात करने का प्रलोभन देता — जिससे आम तौर पर बचना चाहिए।

Sunk cost की भूल से बचना कठिन है। उपकरण पहले से ही होने पर उसे फिर से तैनात करना बहुत आसान लगता है, भले ही एक नई प्रणाली लागू की जा रही हो — सिस्टम डिज़ाइन और विशिष्टताओं के बाहर। और ऐसे मामले हैं जहाँ यह सच हो सकता है, लेकिन अधिकांशतः नहीं। लेकिन जिस तरह हम नहीं चाहते कि उपकरण के लिए हम अत्यधिक भावनात्मक रूप से जुड़ जाएं केवल इसलिए क्योंकि हम पहले ही उसके लिए भुगतान कर चुके हैं, उसी तरह हम मौजूदा उपकरण के मूल्य को भी नज़रअंदाज़ नहीं करना चाहते। यहीं पर एक नियोजित Disaster Planning pipeline जो हमारे पास पहले से मौजूद है उसका बेहतरीन उपयोग कर सकती है। हमें याद रखना होगा कि यह संभवतः बहुत उपयोगी उपकरण है जिसमें अभी बहुत मूल्य बाकी है, यदि हम जानते हैं कि इसे अपनी मौजूदा ज़रूरतों को पूरा करने के लिए कैसे सही तरीके से उपयोग करना है।

एक मज़बूत उत्पादन से आपदा पुनर्प्राप्ति platform migration योजना प्रक्रिया बजट खर्च को कम करते हुए उत्कृष्ट आपदा पुनर्प्राप्ति परिणाम प्राप्त करने का एक शानदार तरीका हो सकती है।