क्या आपको वास्तव में Redundancy की जरूरत है: Downtime की असली कीमत

Downtime – यह एक ऐसा शब्द है जिसे कोई नहीं सुनना चाहता। यह व्यवसायों, अधिकारियों और विशेष रूप से IT कर्मचारियों के दिल में डर पैदा करता है। Downtime से पैसे का नुकसान होता है और निराशा होती है।

क्योंकि Downtime एक भावनात्मक प्रतिक्रिया उत्पन्न करता है, व्यवसाय अक्सर इसे पारंपरिक व्यावसायिक कारकों से अलग तरीके से देखते हैं। यह भावनात्मक दृष्टिकोण व्यवसायों को, विशेष रूप से छोटे व्यवसायों को, जिनके पास अक्सर तर्कसंगत वित्तीय नियंत्रण नहीं होते, Downtime को वास्तविकता से कहीं अधिक बुरा मानने पर मजबूर करता है। यह असामान्य नहीं है कि छोटे व्यवसायों ने संभावित Downtime के डर से प्रतिक्रिया करते हुए खुद को उससे ज्यादा आर्थिक नुकसान पहुंचाया है, जितना कि वास्तविक Downtime होने पर होता। यह एक खतरनाक अतिप्रतिक्रिया है।

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

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

एक बार जब हमें Downtime लागत का अनुमानित आंकड़ा मिल जाता है, तो हम Downtime जोखिम पर विचार कर सकते हैं। यह आकलन करना बहुत कठिन है क्योंकि IT system की विश्वसनीयता पर अच्छे आंकड़े लगभग नहीं मिलते और हर संगठन के systems इतने अनूठे होते हैं कि उद्योग डेटा लगभग बेकार होता है। यहां हम IT कर्मचारियों पर निर्भर हैं कि वे जोखिमों का अवलोकन प्रदान करें और, उम्मीद है, व्यक्तिगत जोखिमों की संभावनाओं का एक विश्वसनीय मूल्यांकन दें। उदाहरण के लिए, मोटे तौर पर, यदि हमारे पास एक line of business application है जो केवल एक hard drive वाले server पर चलती है, तो हम उम्मीद करेंगे कि अगले पांच से दस वर्षों में उस drive की हानि से जुड़ा Downtime होगा। यदि उसी server में hot swap drives एक mirrored array में हैं तो उस storage system से जुड़े Downtime की संभावना, दस वर्षों में भी, काफी कम है। इसका मतलब यह नहीं कि drive विफल नहीं होगी, होगी, लेकिन यह कि system संभवतः प्रभावित नहीं होगा जब तक redundancy बहाल न हो जाए और end users को कुछ पता भी नहीं चलेगा।

हमारा अंतिम अनुमानित उपकरण लागू व्यावसायिक घंटों को लागू करना है। कई व्यवसाय 24×7 नहीं चलते, कुछ चलते हैं, निश्चित रूप से, लेकिन अधिकांश नहीं चलते। क्या शाम छह बजे line of business application का नुकसान सुबह दस बजे उसी application के नुकसान के बराबर है? सप्ताहांत के बारे में क्या? क्या लोग शुक्रवार दोपहर तीन बजे इसका उत्पादक उपयोग कर रहे हैं या इसे खोना शायद ही कोई नुकसान हो और कर्मचारियों को उनके सप्ताहांत में एक-दो घंटे अतिरिक्त मिलें? क्या दोपहर के भोजन के समय के आसपास नुकसान होने पर कार्यक्रमों को स्थानांतरित किया जा सकता है? ये कारक जबकि सामान्य रूप से तुच्छ लगते हैं, महत्वपूर्ण हो सकते हैं। यदि Downtime केवल दो से चार घंटे तक सीमित है, तो कई व्यवसाय कर्मचारियों से अपने कार्यक्रम में थोड़ी लचीलापन दिखाने के लिए कह सकते हैं – जल्दी दोपहर का भोजन करें या एक दिन जल्दी काम छोड़ दें और अगले दिन एक घंटा अतिरिक्त काम करें।

अब जब हमारे पास ये कारक हैं – Downtime की लागत, अवधि के आधार पर Downtime प्रभाव को कम करने की क्षमता और outage events के जोखिम – तो हम यह चित्रण शुरू कर सकते हैं कि Downtime event कैसा दिखेगा। इससे हम यह निर्धारित कर सकते हैं कि ऐसी event के जोखिम को कम करने के लिए कितना खर्च करना उचित होगा। कुछ व्यवसायों के लिए यह संख्या बहुत अधिक होगी और कुछ के लिए आश्चर्यजनक रूप से कम। यह अभ्यास व्यवसाय के काम करने के तरीके के बारे में बहुत कुछ उजागर कर सकता है जो आमतौर पर इतना दृश्यमान नहीं होता।

इस बिंदु पर यह नोट करना महत्वपूर्ण है कि हम यहां systems की उपलब्धता की हानि देख रहे हैं, data की हानि नहीं। हम मान रहे हैं कि अच्छे backups लिए जा रहे हैं और वे backups समझौता नहीं किए गए हैं। Redundancy और Downtime, data loss से नहीं बल्कि availability loss से संबंधित विषय हैं। Data loss परिदृश्यों को समान या अधिक परिश्रम के साथ संभाला जाना चाहिए लेकिन यह एक अलग विषय है। ऐसे व्यवसाय दुर्लभ हैं जो catastrophic data loss से बच सकते हैं, लेकिन यहां तक कि पर्याप्त Downtime का अनुभव करना और उससे आसानी से उबरना सामान्य है।

Downtime को रोकने के कई तरीके हैं, Redundancy अत्यधिक दृश्यमान है और इसे लगभग एक buzzword की तरह माना जाता है और इसलिए इस पर बहुत ध्यान दिया जाता है, लेकिन इसके अन्य साधन भी हैं। अच्छा system design महत्वपूर्ण है, system की जटिलता से बचने से अनावश्यक जोखिम और नाजुकता के बिंदुओं को हटाकर Downtime को काफी कम किया जा सकता है। गुणवत्तापूर्ण hardware और software का उपयोग भी महत्वपूर्ण है – क्योंकि low end hardware जो redundant है, अक्सर उतनी ही बार विफल होगी जितनी non-redundant enterprise class hardware। replacement parts की एक त्वरित supply chain एक महत्वपूर्ण कारक हो सकती है जो अक्सर four hour hardware vendor replacement part response contracts के रूप में देखी जाती है। यह सूची जारी रहती है। हम Redundancy पर ध्यान केंद्रित करेंगे जो वह जगह है जहां Downtime के डर का सामना करने पर हम सबसे अधिक अत्यधिक खर्च करने की संभावना रखते हैं।

अब जब हम पर्याप्त Redundancy न होने की लागत जानते हैं, तो हम इस संभावित लागत की तुलना उस Redundancy प्रदान करने की वास्तविक, अग्रिम लागत से कर सकते हैं। कुछ चीजें, जैसे hard drives, विफल होने की अत्यधिक संभावना है और Redundant बनाना अपेक्षाकृत आसान और किफायती है – महत्वपूर्ण जोखिम लेना और उसे तुच्छ बनाना। ये आम तौर पर पहला फोकस बिंदु होते हैं। लेकिन Redundancy के कई क्षेत्रों पर विचार करना है जैसे power supplies, network hardware, Internet connections और पूरे systems – अक्सर आधुनिक virtualization तकनीकों के माध्यम से Redundant बनाए जाते हैं जो कई छोटे व्यवसायों के लिए पहले accessible नहीं थे।

Redundancy के नए प्रकार, विशेष रूप से वे जो virtualization के माध्यम से उपलब्ध हुए हैं, अक्सर एक ऐसा बिंदु होते हैं जहां व्यवसाय Downtime के जोखिमों की तुलना में नाटकीय रूप से अत्यधिक खर्च करने के लिए प्रलोभित होंगे। इससे भी बुरी बात यह है कि Redundancy में नवीनतम फैशन को अपनाने की कोशिश में कंपनियां अक्सर इन तकनीकों को गलत तरीके से लागू करती हैं और वास्तव में कुछ न करने की तुलना में अधिक जोखिम और Downtime की अधिक संभावना पैदा करती हैं। यह तेजी से सामान्य हो रहा है कि व्यवसाय केवल कुछ हजार डॉलर के Downtime मौद्रिक नुकसान को कम करने के प्रयास में दसियों या सैकड़ों हजारों डॉलर खर्च करते हैं – और फिर उस प्रयास में विफल होते हैं और अपना जोखिम वैसे भी बढ़ा लेते हैं।

Mitigation की लागत का आकलन करते समय यह याद रखना महत्वपूर्ण है कि mitigation एक guaranteed खर्च है जबकि जोखिम केवल एक जोखिम है। बिल्कुल auto insurance की तरह जहां आप एक बड़े, अनियोजित खर्च को दूर रखने के लिए एक guaranteed छोटी मासिक फीस देते हैं। Risk mitigation का सिद्धांत यह है कि बाद में एक बड़े खर्च के जोखिम को कम करने के लिए अभी तुलनात्मक रूप से कम पैसा खर्च करें, लेकिन अगर mitigation की लागत बहुत अधिक हो जाती है तो जोखिम को स्वीकार करना बेहतर हो जाता है।

Systems का मूल्यांकन व्यक्तिगत रूप से किया जा सकता है। web presence और telephone system को हर समय चालू रखना email system की तुलना में कहीं अधिक महत्वपूर्ण है जहां घंटों के Downtime का बाहरी clients को पता भी नहीं चल सकता। केवल उन्हीं systems की सुरक्षा के लिए भुगतान करना जहां Downtime की लागत महत्वपूर्ण है, एक महत्वपूर्ण रणनीति है।

यह जानकर आश्चर्यचकित न हों कि जो आप खोजते हैं वह यह है कि कुछ बहुत ही बुनियादी Redundancy (जैसे mirrored hard drives) से परे, एक सरल network design जिसमें अच्छे backups और restore plans और एक अच्छा hardware support contract हो, आपके अधिकांश, यदि सभी नहीं, systems के लिए पर्याप्त है। अपने systems की जटिलता को कम करके आप उन्हें स्वाभाविक रूप से अधिक स्थिर और प्रबंधन में आसान बनाते हैं – जिससे आपके IT infrastructure की लागत और कम होती है।