विषय 3.9 — व्यावसायिक निरंतरता और आपदा रिकवरी

स्वास्थ्य और देखभाल में, एक प्रमुख सिस्टम आउटेज एक IT समस्या होने से पहले एक रोगी-सुरक्षा घटना है, इसलिए एक सिस्टम बंद रहते हुए देखभाल देते रहने — और इसे पूरी तरह और जल्दी पुनर्स्थापित करने — की आपकी क्षमता एक मुख्य क्लिनिकल और सार्वजनिक-विश्वास क्षमता है, कोई तकनीकी फुटनोट नहीं।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

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

दांव राष्ट्रीय और अच्छी तरह से दस्तावेज़ीकृत हैं। 2017 के WannaCry रैनसमवेयर हमले ने इंग्लैंड में लगभग एक तिहाई NHS ट्रस्टों को बाधित किया, हज़ारों अपॉइंटमेंट और ऑपरेशनों को रद्द करने के लिए मजबूर किया, एम्बुलेंस को मोड़ा, और स्टाफ को उन्हीं उपकरणों से बाहर कर दिया — कुछ इमेजिंग और पैथोलॉजी उपकरण सहित — जिनकी उन्हें लोगों का इलाज करने के लिए आवश्यकता थी। इसने NHS को अनुमानित £92 मिलियन की कीमत चुकाई और, अधिक महत्वपूर्ण रूप से, दिखाया कि स्वास्थ्य बुनियादी ढांचे पर एक साइबर-हमला एक क्लिनिकल संकट के रूप में उतरता है, केवल एक डेटा-सुरक्षा घटना नहीं। तब से, लचीलापन सर्वर कक्ष से बोर्ड टेबल तक चला गया है, और उचित रूप से।

यह विषय, विषय 3.8 — सेवा प्रबंधन और लाइव संचालन के परिचालन अनुशासन का विस्तार करता है, लेकिन ध्यान को रोज़मर्रा के चलाने से प्रमुख व्यवधान की ओर स्थानांतरित करता है: आग, बाढ़, साइबर-हमला, आपूर्तिकर्ता पतन, या क्षेत्रीय आउटेज जो घंटों या दिनों के लिए एक महत्वपूर्ण सेवा को बंद करने की धमकी देता है। यह विषय 1.7 — सूचना प्रशासन, डेटा सुरक्षा और साइबर सुरक्षा से कसकर जुड़ता है (क्योंकि रैनसमवेयर रिकवरी अब एक केंद्रीय निरंतरता परिदृश्य है), विषय 4.0 — तकनीकी आर्किटेक्चर, क्लाउड और विरासत से (क्योंकि लचीलापन डिज़ाइन में शामिल है, जोड़ा नहीं गया), और विषय 6.4 — प्रशासन और आश्वासन से (क्योंकि किसी को योजना का स्वामी, परीक्षक, और जवाबदेह होना चाहिए)। इसे सही करें और व्यवधान एक बुरा दिन बन जाता है; इसे गलत करें और यह एक सार्वजनिक जांच बन जाता है।

मुख्य अवधारणाएं#

व्यावसायिक निरंतरता और आपदा रिकवरी। व्यावसायिक निरंतरता योजना (BCP) एक विघटनकारी घटना के दौरान और बाद में पूर्व-परिभाषित स्वीकार्य स्तरों पर उत्पाद या सेवाएं — आपके मामले में, सुरक्षित देखभाल — देते रहने की क्षमता है। IT आपदा रिकवरी (DR) उन सिस्टमों, डेटा, और बुनियादी ढांचे को पुनर्स्थापित करने से संबंधित संकीर्ण, तकनीकी उपसमूह है जो उन सेवाओं को आधार देते हैं। व्यावसायिक निरंतरता व्यापक वादा है ("रोगियों का इलाज होता रहता है"); आपदा रिकवरी साधनों में से एक है ("परिणाम सिस्टम चार घंटों के भीतर वापस आ जाता है")। आपको दोनों की आवश्यकता है, और आपको एक पुनर्स्थापित सर्वर को एक पुनर्स्थापित सेवा के साथ भ्रमित नहीं करना चाहिए।

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

रिकवरी समय उद्देश्य और रिकवरी बिंदु उद्देश्य। दो संख्याएं हर रिकवरी योजना को आधार देती हैं। रिकवरी समय उद्देश्य (RTO) विफलता के बाद एक सेवा को पुनर्स्थापित करने के लिए अधिकतम स्वीकार्य समय है। रिकवरी बिंदु उद्देश्य (RPO) डेटा हानि की अधिकतम स्वीकार्य मात्रा है, समय के रूप में व्यक्त: पंद्रह मिनट का एक RPO का अर्थ है कि आप अधिकतम अंतिम पंद्रह मिनट की प्रविष्टियां खोना सहन कर सकते हैं। एक महत्वपूर्ण क्लिनिकल सिस्टम के लिए ये मिनट हो सकते हैं; एक रिपोर्टिंग वेयरहाउस के लिए वे दिन हो सकते हैं। उन्हें ईमानदारी से, प्रति सेवा सेट करना आपके द्वारा लिया गया सबसे उपयोगी एकल निरंतरता निर्णय है।

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

उच्च उपलब्धता, अतिरेक, और फेलओवर। उच्च उपलब्धता (HA) एक डिज़ाइन गुण है जो घटक विफलता के माध्यम से एक सिस्टम को चलता रखता है, आमतौर पर अपटाइम के "नौ" में मापा जाता है। यह अतिरेक — महत्वपूर्ण घटकों की सोच-समझकर नकल — और फेलओवर, जब प्राथमिक विफल होता है तो एक स्टैंडबाय घटक या साइट पर स्वचालित स्विच के माध्यम से प्राप्त होता है। उच्च उपलब्धता आउटेज की आवृत्ति कम करती है; आपदा रिकवरी उन लोगों को संभालती है जो पार हो जाते हैं। वे पूरक हैं, विकल्प नहीं, और उन्हें भ्रमित करना खतरनाक अंतराल छोड़ता है।

एकल विफलता बिंदु और महत्वपूर्ण निर्भरताएं। एक एकल विफलता बिंदु (SPOF) कोई भी घटक है जिसकी विफलता पूरी सेवा को रोकती है — एक नेटवर्क लिंक, एक प्रमाणीकरण सेवा, एक आपूर्तिकर्ता, एक डेटाबेस, या एक व्यक्ति जो अकेले जानता है कि कुछ कैसे काम करता है। SPOF और महत्वपूर्ण निर्भरताओं (अपस्ट्रीम सेवाएं और तीसरे पक्ष जिन पर आपकी सेवा चुपचाप निर्भर करती है) को मैप करना लचीलेपन का विश्लेषणात्मक हृदय है। आधुनिक स्वास्थ्य IT में, निर्भरताएं शायद ही कभी स्थानीय होती हैं: एक एकल-साइन-ऑन सेवा, एक राष्ट्रीय स्पाइन कनेक्शन, या एक क्लाउड क्षेत्र एक साथ कई सिस्टम को नीचे ले जा सकता है।

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

रैनसमवेयर और साइबर-रिकवरी। रैनसमवेयर आपके डेटा को एन्क्रिप्ट करता है और भुगतान की मांग करता है, और यह स्वास्थ्य प्रणालियों के लिए परिभाषित निरंतरता खतरा बन गया है। 2017 का WannaCry रैनसमवेयर हमला संदर्भ मामला है: यही कारण है कि साइबर-रिकवरी — अलग करना, साफ़ बैकअप से फिर से बनाना, और फिर से जुड़ने से पहले अखंडता को मान्य करना — अब हर गंभीर योजना में एक प्रथम-श्रेणी परिदृश्य है।

निरंतरता मानक। ISO 22301 व्यावसायिक निरंतरता प्रबंधन प्रणालियों के लिए अंतर्राष्ट्रीय मानक है। यह निरंतरता क्षमता बनाने और ऑडिट करने के लिए एक मान्यता प्राप्त संरचना प्रदान करता है — संदर्भ, नेतृत्व, योजना, समर्थन, संचालन, मूल्यांकन, सुधार — और यह एक उपयोगी रीढ़ है चाहे आप औपचारिक प्रमाणन चाहें या नहीं।

सर्वोत्तम प्रथाएं#

1. क्लिनिशियनों द्वारा स्वामित्व वाले एक व्यावसायिक प्रभाव विश्लेषण से शुरू करें, केवल IT द्वारा नहीं। हर सेवा को उस क्लिनिकल नुकसान से रैंक करें जो इसके विफल होने पर होता है और वह कितनी जल्दी असहनीय हो जाता है, फिर हर एक को एक विशिष्ट RTO और RPO सौंपें। इसे उन क्लिनिशियनों और परिचालन प्रबंधकों के साथ करें जो परिणाम उठाते हैं, क्योंकि "इसके बिना हम कितनी देर सुरक्षित रूप से चल सकते हैं?" एक देखभाल प्रश्न है, कोई बुनियादी ढांचा प्रश्न नहीं। आउटपुट एक प्राथमिकता वाली सूची है जो आपको बताती है कि अपना सीमित लचीलापन बजट पहले कहां खर्च करना है।

2. महत्ता के अनुपात में लचीलापन डिज़ाइन करें। इंजीनियरिंग को प्रभाव से मिलाएं: मिशन-महत्वपूर्ण सिस्टम (आपातकालीन विभाग, रोगी प्रशासन, ई-प्रिस्क्राइबिंग) उच्च उपलब्धता, भौगोलिक अतिरेक, और स्वचालित फेलओवर के हकदार हैं; कम-महत्ता वाले सिस्टम लंबी रिकवरी और सरल बैकअप स्वीकार कर सकते हैं। महत्वपूर्ण सिस्टमों को कम-इंजीनियर करने और तुच्छ लोगों को गोल्ड-प्लेट करने दोनों का विरोध करें। आर्किटेक्चर और निरंतरता को एक साथ डिज़ाइन किया जाना चाहिए (देखें विषय 4.0 — तकनीकी आर्किटेक्चर, क्लाउड और विरासत), क्योंकि आप बाद में एक नाजुक डिज़ाइन पर लचीलापन नहीं जोड़ सकते।

3. एकल विफलता बिंदुओं और छिपी निर्भरताओं का शिकार करें। हर महत्वपूर्ण सेवा की निर्भरताओं को व्यवस्थित रूप से मैप करें — नेटवर्क, प्रमाणीकरण, DNS, राष्ट्रीय कनेक्शन, बिजली, कूलिंग, मुख्य आपूर्तिकर्ता, और मुख्य लोग — और पहचानें कि कहां एक विफलता झरने की तरह गिरती है। एकल साइन-ऑन या एक सामान्य एकीकरण इंजन जैसी साझा सेवाओं पर विशेष ध्यान दें, जिनकी विफलता एक साथ कई सिस्टमों को नीचे ले जाती है। एक निर्भरता जिसे आपने मैप नहीं किया है एक निर्भरता है जिसे आप आउटेज के दौरान खोजेंगे।

4. रैनसमवेयर से बचने के लिए बैकअप लें, और परीक्षण करके पुनर्स्थापन साबित करें। 3-2-1 नियम का पालन करें और कम से कम एक बैकअप प्रति को अपरिवर्तनीय या भौतिक रूप से ऑफ़लाइन रखें, ताकि एक हमलावर जो आपके नेटवर्क तक पहुंचता है आपकी अंतिम रक्षा रेखा को एन्क्रिप्ट न कर सके। फिर अपने RTO के विरुद्ध समय देते हुए और अपने RPO के विरुद्ध डेटा अखंडता को मान्य करते हुए, एक अनुसूची पर पुनर्स्थापन परखें — एक पुनर्स्थापन जो चार घंटे के लक्ष्य के विरुद्ध दो दिन लेता है एक विफल नियंत्रण है जिसे आपने बस अभी तक नोटिस नहीं किया है। "अंतिम सफल पुनर्स्थापन" को एक मीट्रिक मानें जिसे आप रिपोर्ट करते हैं, एक कार्य नहीं जिसे आप मान लेते हैं।

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

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

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

8. अपने आपूर्तिकर्ताओं और क्लाउड तक निरंतरता विस्तारित करें। आपका लचीलापन केवल उतना मज़बूत है जितने वे तीसरे पक्ष जिन पर आपकी महत्वपूर्ण सेवाएं निर्भर करती हैं, इसलिए निरंतरता को एक संविदात्मक और आश्वासन मामला बनाएं: आपूर्तिकर्ताओं से अपने स्वयं के RTO/RPO, DR परीक्षण, और साइबर-रिकवरी को प्रमाणित करने की मांग करें, और अपने क्लाउड प्रदाता के साझा-ज़िम्मेदारी मॉडल को समझें — उपलब्धता क्षेत्र और क्षेत्र कुछ विफलताओं से रक्षा करते हैं लेकिन एक गलत-कॉन्फ़िगरेशन या खाता समझौता से नहीं जिसका आप स्वामित्व रखते हैं। स्वयं आपूर्तिकर्ता विफलता की योजना बनाएं, उस परिदृश्य सहित जहां एक प्रमुख आपूर्तिकर्ता वह है जो रैनसमवेयर से प्रहार किया जाता है (देखें विषय 6.3 — खरीद और वाणिज्यिक)।

9. एक मान्यता प्राप्त मानक अपनाएं और निरंतरता को प्रशासन के तहत रखें। ISO 22301 को एक संरचित रीढ़ के रूप में और NHS और राष्ट्रीय मार्गदर्शन को क्षेत्र ओवरले के रूप में उपयोग करें, और बोर्ड को रिपोर्ट करते हुए व्यावसायिक निरंतरता के लिए एक नामित कार्यकारी जवाबदेही दें। निरंतरता जिसका कोई स्वामी, वित्तपोषण, या समीक्षा नहीं करता वह घटना उजागर करने तक चुपचाप घटती है। इसे अपने आश्वासन ढांचे में वायर करें (देखें विषय 6.4 — प्रशासन और आश्वासन) ताकि योजनाएं नियमित रूप से बनाए रखी, परखी, और सुधारी जाएं, एक संकट में फिर से खोजी न जाएं।

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

1. हमारे हर महत्वपूर्ण क्लिनिकल सिस्टम के लिए, हमने वास्तव में क्लिनिशियनों के साथ कौन सा RTO और RPO सहमत किया है — और क्या हम वर्तमान में उन्हें पूरा कर सकते हैं? यह प्रश्न आकांक्षा और क्षमता के बीच के अंतर को खुले में मजबूर करता है। कई संगठनों ने कभी स्पष्ट रिकवरी उद्देश्य निर्धारित नहीं किए, या उन्हें क्लिनिकल इनपुट के बिना IT में निर्धारित किया, इसलिए "स्वीकार्य" डाउनटाइम वास्तव में बस वही है जो वर्तमान आर्किटेक्चर देता है। बहस करें कि क्लिनिकल आवश्यकता (एक आपातकालीन सिस्टम के लिए मिनट) कहां आपके बैकअप और DR वास्तव में क्या प्राप्त कर सकते हैं (शायद एक दिन) से टकराती है, क्योंकि वह अंतर अप्रबंधित क्लिनिकल जोखिम है जिसे आप उठा रहे हैं चाहे आप इसे नाम दें या नहीं। अपनी आखिरी वास्तविक या परखी गई रिकवरी को ठोस रूप से देखें: इसमें कितना समय लगा, आप कितना डेटा खो देते, और किसने हस्ताक्षर किया कि यह सुरक्षित है? एक अच्छा, ईमानदार उत्तर प्रति सिस्टम विशिष्ट संख्याएं नाम देता है, स्वीकार करता है कि आप अभी उन्हें कहां पूरा नहीं कर सकते, और हर अंतराल को एक आरामदायक चुप्पी के बजाय एक वित्तपोषित कार्रवाई में बदल देता है।

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

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

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

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

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

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

Meadowvale NHS Foundation Trust एक 600-बेड एक्यूट अस्पताल चलाता है। एक मंगलवार सुबह, स्टाफ आता है और अपने इलेक्ट्रॉनिक रोगी रिकॉर्ड (EPR), पैथोलॉजी, और रेडियोलॉजी सिस्टम को एक फिरौती नोट से लॉक किया हुआ पाता है; हमलावरों ने दस दिन पहले एक आपूर्तिकर्ता के रिमोट-अभिगम खाते के माध्यम से प्रवेश किया था। मुख्य सूचना अधिकारी एक घंटे के भीतर एक प्रमुख घटना घोषित करता है, और ट्रस्ट की व्यावसायिक निरंतरता योजना सक्रिय होती है।

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

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

डीब्रीफ में, ट्रस्ट वास्तविक अंतराल पाता है: एकल साइन-ऑन एक एकल विफलता बिंदु था जिसने रिकवरी के दौरान क्लिनिशियन अभिगम में देरी की, और आपूर्तिकर्ता का रिमोट अभिगम ट्रस्ट के अपने निरंतरता आश्वासन द्वारा कवर नहीं किया गया था। दोनों स्वामियों और तारीखों के साथ बोर्ड की जोखिम रजिस्टर पर जाते हैं, और अगला पूर्ण अभ्यास निर्धारित किया जाता है। यह एक बुरा हफ्ता था — लेकिन एक विपत्ति नहीं, क्योंकि योजना मौजूद थी, संसाधित थी, और परखी गई थी।

क्षेत्र दृष्टिकोण#

स्टार्टअप#

एक डिजिटल-स्वास्थ्य स्टार्टअप के पास शायद ही कभी एक अतिरिक्त डेटा सेंटर होता है, इसलिए इसकी निरंतरता रणनीति लगभग पूरी तरह से क्लाउड-नेटिव लचीलेपन और अनुशासित बैकअप पर झुकती है। उपलब्धता क्षेत्रों में निर्मित उच्च उपलब्धता वाली प्रबंधित सेवाओं का उपयोग करें, रैनसमवेयर और एक समझौता किए गए क्लाउड खाते दोनों से बचने के लिए अपरिवर्तनीय, ऑफ़-अकाउंट प्रतियों के साथ बैकअप को स्वचालित करें, और वास्तव में एक साफ़ वातावरण में एक पुनर्स्थापन का अभ्यास करें। आपके ग्राहक — NHS ट्रस्ट और एकीकृत देखभाल प्रणालियां — DTAC और आपूर्तिकर्ता आश्वासन जैसे ढांचों के माध्यम से RTO, RPO, और DR परीक्षण के साक्ष्य की तेज़ी से मांग करेंगे, इसलिए निरंतरता को ओवरहेड नहीं, एक बिक्री संपत्ति मानें। एक छोटे आपूर्तिकर्ता के लिए अस्तित्वगत जोखिम यह है कि एक एकल घटना, या वह संस्थापक जो अकेले तैनाती समझता है, आपका एकल विफलता बिंदु बन जाता है।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, एक घरेलू-देखभाल एजेंसी, या एक एकल-साइट क्लिनिक — एक आउटेज के माध्यम से रोगियों को सुरक्षित रखने का एक बड़े ट्रस्ट के समान कर्तव्य उठाता है, लेकिन वास्तविक रोगियों, तंग नकदी, और अक्सर बिल्कुल कोई समर्पित IT स्टाफ के साथ। यहां निरंतरता जानबूझकर व्यावहारिक है: जानें कि कौन सी एक या दो सिस्टम (क्लिनिकल रिकॉर्ड, डिस्पेंसिंग या eMAR सिस्टम) विफल होने पर सुरक्षित देखभाल रोक देंगी, अपने सिस्टम आपूर्तिकर्ता से अपने स्वयं के बैकअप, RTO, और RPO को प्रमाणित करने पर ज़ोर दें, और एक सरल, मुद्रित डाउनटाइम पैक रखें — कागज़ी दवा चार्ट, मुख्य फोन नंबर, हाल की रोगी सूचियां — जहां स्क्रीन अंधेरे होने पर स्टाफ इसे पहुंच सके। क्योंकि एक अकेला प्रैक्टिस मैनेजर या एक अकेला IT ठेकेदार अक्सर एकमात्र व्यक्ति होता है जो सेटअप समझता है, रिकवरी कदमों को लिख लें और सुनिश्चित करें कि एक दूसरा व्यक्ति उनका पालन कर सके। रैनसमवेयर और एक टूटी हुई ब्रॉडबैंड लाइन रोज़मर्रा के खतरे हैं, इसलिए एक ऑफ़लाइन या अपरिवर्तनीय बैकअप प्रति और काम करने का एक फ़ॉलबैक तरीका किसी भी विस्तृत DR साइट से अधिक मायने रखता है जिसे आप वहन या चला नहीं सकते।

बड़ा संगठन#

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

सरकार#

NHS England, एक विकेंद्रीकृत स्वास्थ्य विभाग, या UKHSA जैसा एक राष्ट्रीय निकाय जनसंख्या और प्रणालीगत पैमाने पर लचीलेपन के बारे में सोचना चाहिए, जहां एक राष्ट्रीय सेवा या व्यापक रूप से उपयोग किए जाने वाले आपूर्तिकर्ता की विफलता स्वयं पूरे क्षेत्र के लिए एक निरंतरता घटना है। मानक और अपेक्षाएं (रिकवरी उद्देश्य, साइबर-रिकवरी, अनिवार्य अभ्यास) निर्धारित करें, साझा सुरक्षात्मक क्षमताओं को वित्तपोषित करें, और एक राष्ट्रीय रैनसमवेयर अभियान जैसी प्रमुख घटनाओं की क्षेत्र-व्यापी प्रतिक्रिया का समन्वय करें। WannaCry प्रतिक्रिया ने राष्ट्रीय नीति को ठीक इसलिए फिर से आकार दिया क्योंकि प्रभाव ने एक साथ सैकड़ों संगठनों को पार किया, सामान्य कमज़ोरियों को उजागर करते हुए। यहां जवाबदेही सार्वजनिक और संसदीय है, इसलिए ज्ञात जोखिमों के बारे में पारदर्शिता, और तैयारी की ईमानदार रिपोर्टिंग, स्वयं तकनीकी नियंत्रणों जितनी ही मायने रखती है।

सामान्य विफलता मोड#

• बैकअप जो कभी पुनर्स्थापित नहीं किए गए। "हम रात में बैकअप करते हैं" को "हम पुनर्स्थापित कर सकते हैं" के साथ भ्रमित करना। अपरीक्षित पुनर्स्थापन नियमित रूप से विफल होते हैं या RTO उड़ा देते हैं; बैकअप पूर्णता नहीं, सफल अंत-से-अंत पुनर्स्थापन मापें और रिपोर्ट करें।
• रैनसमवेयर-पहुंच योग्य बैकअप। हर बैकअप को ऑनलाइन और नेटवर्क-कनेक्टेड रखना, इसलिए एक हमलावर उन्हें प्रोडक्शन के साथ एन्क्रिप्ट करता है। कम से कम एक अपरिवर्तनीय या ऑफ़लाइन प्रति रखें।
• DR जो सर्वरों की रक्षा करता है, सेवाओं की नहीं। एक डेटाबेस को पुनर्स्थापित करना लेकिन उन निर्भरताओं, एकीकरणों, और अभिगम को नहीं जो इसे एक उपयोग योग्य क्लिनिकल सेवा बनाते हैं। निर्भरता क्रम में पूरी सेवाएं रिकवर और परखें।
• डाउनटाइम प्रक्रियाएं जो केवल कागज़ के बारे में कागज़ पर मौजूद हैं। फ़ॉलबैक योजनाएं जो कभी अभ्यास नहीं की जातीं, विफल होने वाले सिस्टम पर संग्रहीत हैं, या फ्रंटलाइन स्टाफ को अज्ञात हैं। उन्हें वहां अभ्यास करें जहां देखभाल वास्तव में होती है।
• अनमैप्ड निर्भरताएं और साझा SPOF। आउटेज के दौरान यह खोजना कि एकल साइन-ऑन, DNS, या एक आपूर्तिकर्ता ने सब कुछ आधार दिया। घटना से पहले, इसके दौरान नहीं, निर्भरताओं को मैप करें।
• ऑडिटर के लिए लिखी गई एक योजना, कभी अभ्यास नहीं की गई। एक अनुपालन दस्तावेज़ के रूप में निरंतरता जो आवश्यकता होने के दिन तक अपरीक्षित घटती है। एक कभी न परखी गई योजना एक विफल होने वाली योजना है।
• आपूर्तिकर्ता और क्लाउड निरंतरता को नज़रअंदाज़ करना। यह मान लेना कि आपके तीसरे पक्ष बिना साक्ष्य के लचीले हैं, और साझा-ज़िम्मेदारी मॉडल को भूल जाना। निरंतरता को संविदात्मक और सुनिश्चित बनाएं।

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

जांच-सूची#

• क्लिनिशियनों के साथ स्वामित्व वाला एक व्यावसायिक प्रभाव विश्लेषण हर सेवा को रैंक करता है और हर महत्वपूर्ण सिस्टम के लिए एक स्पष्ट RTO और RPO सेट करता है।
• महत्वपूर्ण सिस्टमों में उनकी क्लिनिकल महत्ता के अनुपात में उच्च उपलब्धता और अतिरेक है।
• एकल विफलता बिंदु और महत्वपूर्ण निर्भरताएं (साझा सेवाओं और आपूर्तिकर्ताओं सहित) मैप और शमित हैं।
• बैकअप 3-2-1 नियम का पालन करते हैं जिसमें कम से कम एक अपरिवर्तनीय या ऑफ़लाइन प्रति है जिस तक रैनसमवेयर नहीं पहुंच सकता।
• पुनर्स्थापन एक अनुसूची पर परखे जाते हैं और RTO/RPO के विरुद्ध समयबद्ध होते हैं, "अंतिम सफल पुनर्स्थापन" एक मीट्रिक के रूप में रिपोर्ट किया जाता है।
• हर महत्वपूर्ण क्लिनिकल सिस्टम में एक अभ्यास की गई डाउनटाइम प्रक्रिया और एक नियंत्रित डेटा पुनः-प्रवेश प्रक्रिया है।
• एक आपदा रिकवरी योजना रिकवरी कदम, क्रम, निर्णय अधिकार, और वापस-विफलता को परिभाषित करती है, और DR साइट/क्षेत्र परखी गई है।
• एक साइबर-रिकवरी परिदृश्य (अलग करें, साफ़ बैकअप से फिर से बनाएं, मान्य करें, फिर से जुड़ें) दस्तावेज़ीकृत और अभ्यास किया गया है।
• आपूर्तिकर्ता और क्लाउड निरंतरता संविदात्मक रूप से आवश्यक, प्रमाणित, और सुनिश्चित है, साझा-ज़िम्मेदारी मॉडल सहित।
• निरंतरता ISO 22301 के अनुरूप है, एक नामित कार्यकारी द्वारा स्वामित्व में है, एक कैलेंडर पर अभ्यास की जाती है, और बोर्ड को रिपोर्ट की जाती है।

मुख्य स्रोत#

• NHS England — Business Continuity Management Toolkit और Emergency Preparedness, Resilience and Response (EPRR) Framework और Core Standards।
• National Cyber Security Centre (NCSC) — ऑफ़लाइन/अपरिवर्तनीय बैकअप, रैनसमवेयर शमन, और घटना प्रतिक्रिया पर मार्गदर्शन।
• ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements (International Organization for Standardization)।
• ISO/IEC 27031 — Guidelines for information and communication technology readiness for business continuity।
• Business Continuity Institute (BCI) — Good Practice Guidelines।
• National Audit Office — Investigation: WannaCry cyber attack and the NHS (2017) और Department of Health lessons-learned review।
• NHS England / Data Security and Protection Toolkit (DSPT) — व्यावसायिक निरंतरता और घटना प्रतिक्रिया सहित डेटा सुरक्षा मानक।
• GOV.UK Service Manual — लाइव सेवाओं के लिए लचीलापन, निगरानी, और रिकवरी मार्गदर्शन।

संदर्भ#

1. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
2. IT disaster recovery — Wikipedia — https://en.wikipedia.org/wiki/IT_disaster_recovery
3. ISO 22301 — Wikipedia — https://en.wikipedia.org/wiki/ISO_22301
4. Backup — Wikipedia — https://en.wikipedia.org/wiki/Backup
5. High availability — Wikipedia — https://en.wikipedia.org/wiki/High_availability
6. Redundancy (engineering) — Wikipedia — https://en.wikipedia.org/wiki/Redundancy_(engineering)
7. Failover — Wikipedia — https://en.wikipedia.org/wiki/Failover
8. Single point of failure — Wikipedia — https://en.wikipedia.org/wiki/Single_point_of_failure
9. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
10. WannaCry ransomware attack — Wikipedia — https://en.wikipedia.org/wiki/WannaCry_ransomware_attack
11. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — International Organization for Standardization — https://www.iso.org/standard/75106.html
12. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
13. Emergency Preparedness, Resilience and Response (EPRR) — NHS England — https://www.england.nhs.uk/ourwork/eprr/
14. Offline backups in an online world — National Cyber Security Centre — https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/