एप्लिकेशन स्थिरता: विंडोज ऐप्स को उपलब्ध रखें

परिचय

Windows अनुप्रयोग अक्सर उस सर्वर से कहीं अधिक पर निर्भर करते हैं जो उन्हें होस्ट करता है। डेटाबेस, पहचान सेवाएँ, भंडारण, गेटवे, नेटवर्क और उपयोगकर्ता एंडपॉइंट सभी यह प्रभावित कर सकते हैं कि क्या कोई अनुप्रयोग विघटन के दौरान उपयोगी बना रहता है। यह लेख बताता है कि आईटी टीमें उन निर्भरताओं का आकलन कैसे कर सकती हैं, मौजूदा Windows अनुप्रयोगों के चारों ओर लचीलापन कैसे डिजाइन कर सकती हैं, सही स्तरों की निगरानी कैसे कर सकती हैं और यह परीक्षण कर सकती हैं कि क्या पुनर्प्राप्ति योजनाएँ वास्तव में उन व्यावसायिक कार्यों को बनाए रखती हैं जिन पर उपयोगकर्ता निर्भर करते हैं।

एप्लिकेशन लचीलापन क्या है?

एप्लिकेशन लचीलापन एक एप्लिकेशन और इसके चारों ओर की अवसंरचना की क्षमता है कि वह एक व्यवधान के दौरान महत्वपूर्ण कार्यों को प्रदान करना जारी रखे और एक विफलता के बाद पूर्वानुमानित रूप से पुनर्प्राप्त हो सके।

विघटन छोटा या बड़ा हो सकता है, और इसके कारण हार्डवेयर या ऑपरेटिंग सिस्टम की विफलता, एप्लिकेशन क्रैश, असफल अपडेट, डेटाबेस आउटेज, नेटवर्क बाधाएं, प्रमाणीकरण विफलताएं, संसाधन समाप्ति, अनुपलब्ध निर्भरताएं या सुरक्षा घटनाएं हो सकते हैं।

एक लचीली वास्तुकला यह स्वीकार करती है कि विफलताएँ अनिवार्य हैं, और हर घटना को रोकने के बजाय, आईटी संगठन प्रत्येक के प्रभाव को सीमित करने और सेवा को बनाए रखने या बहाल करने के लिए नियंत्रित पुनर्प्राप्ति प्रक्रियाएँ स्थापित करने का प्रयास करते हैं।

एप्लिकेशन स्थिरता सर्वर अपटाइम से अधिक है

एक सामान्य गलती यह है कि सर्वर की उपलब्धता का उपयोग एप्लिकेशन की उपलब्धता के लिए प्रॉक्सी के रूप में किया जाता है, जो सर्वर पर चलती है।

एक व्यावसायिक अनुप्रयोग को वास्तव में उपलब्ध होने के लिए, कई घटकों को एक ही समय में उपलब्ध होना चाहिए:

इन्फ्रास्ट्रक्चर → ऑपरेटिंग सिस्टम → एप्लिकेशन → निर्भरताएँ → एक्सेस पथ → उपयोगकर्ता सत्र → व्यावसायिक प्रक्रिया

इस श्रृंखला के किसी भी तत्व में समस्या होने से एप्लिकेशन प्रभावी रूप से अनुपलब्ध हो सकता है।

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

ऐप्लिकेशन लचीलापन, इसलिए, उपयोगकर्ता की आवश्यक व्यावसायिक कार्य को करने की क्षमता के आधार पर मापा जाना चाहिए, न कि इस पर कि क्या एक सर्वर उपलब्धता या स्वास्थ्य जांच का उत्तर देने में सक्षम है।

Windows अनुप्रयोगों के लिए एप्लिकेशन लचीलापन अलग क्यों है?

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

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

इन अनुप्रयोगों को माइक्रोसर्विसेज के रूप में पुनःआर्किटेक्ट करना अत्यधिक महंगा, तकनीकी रूप से चुनौतीपूर्ण, या यहां तक कि पूरी तरह से असंभव हो सकता है यदि संगठन स्रोत कोड को नियंत्रित नहीं करता है।

ऐसे मामलों में, एप्लिकेशन के चारों ओर संचालन को अधिक लचीला बनाने में महत्वपूर्ण मूल्य हो सकता है, बजाय इसके कि एप्लिकेशन को स्वयं अधिक लचीला बनाने की कोशिश की जाए। एप्लिकेशन प्रकाशन इस दृष्टिकोण का हिस्सा हो सकता है जिसमें मौजूदा Windows अनुप्रयोगों को केंद्रीकृत बुनियादी ढांचे पर रखा जाता है जबकि उपयोगकर्ताओं के उनके तक पहुंचने के तरीके को बदला जाता है। इसमें अनुप्रयोग की मेज़बानी करने वाले बुनियादी ढांचे में परिवर्तन शामिल हो सकते हैं, जैसे कि बुनियादी ढांचे की बाधाओं को समाप्त करना, अतिरिक्त अनुप्रयोग होस्ट बनाना, वैकल्पिक पहुंच विधियों को सक्षम करना और अनुप्रयोग होस्ट के लिए अधिक प्रतिक्रियाशील पुनर्प्राप्ति प्रक्रियाओं को लागू करना।

किस स्थिति में एक विंडोज़ एप्लिकेशन की उपलब्धता विफल हो सकती है?

ऐप्लिकेशन की स्थिरता का निर्माण उन घटकों की खोज से शुरू होता है जो एक ऐप्लिकेशन को उनके होस्ट से उपयोगकर्ताओं तक सफलतापूर्वक पहुंचाने के लिए आवश्यक हैं। यह प्रक्रिया संभावित विफलता के बिंदुओं को उजागर करती है जो एक पूरे ऐप्लिकेशन को नीचे ला सकती है।

एप्लिकेशन होस्ट्स

एक एप्लिकेशन जो एकल Windows सर्वर पर चल रहा है, उसमें स्पष्ट एकल विफलता का बिंदु है।

हार्डवेयर समस्याएँ, विंडोज अपडेट, ऑपरेटिंग सिस्टम भ्रष्टाचार, संसाधन समाप्ति या एप्लिकेशन विफलता उस मशीन पर निर्भर हर उपयोगकर्ता को बाधित कर सकती हैं। यदि उपलब्धता की आवश्यकताएँ हैं, तो किसी एक मशीन पर निर्भरता को कम करने और जब एक सर्वर अनुपलब्ध हो जाता है, तो क्षमता प्रदान करने के लिए कई एप्लिकेशन होस्ट स्थापित किए जा सकते हैं।

डेटाबेस, संग्रहण और अन्य निर्भरताएँ

कई विंडोज अनुप्रयोगों को अनुप्रयोग होस्ट के बाहरी सेवाओं पर निर्भर रहना पड़ता है। इन सेवाओं में शामिल हो सकते हैं:

• SQL डेटाबेस
• फाइल शेयर
• लाइसेंसिंग सर्वर
• Active Directory
• डोमेन नाम प्रणाली (DNS)
• प्रमाणपत्र
• एपीआई
• मध्यवर्ती सॉफ़्टवेयर
• नेटवर्क स्टोरेज
• प्रिंट बुनियादी ढांचा

दूसरे एप्लिकेशन सर्वर का परिचय देना न्यूनतम लचीलापन प्रदान करता है यदि वे एक सामान्य डेटाबेस या स्टोरेज निर्भरता साझा करते हैं जो अनुपलब्ध है। यह स्पष्ट हो जाता है कि निर्भरता मैपिंग को दृश्य एप्लिकेशन अवसंरचना से परे बढ़ाने की आवश्यकता है।

प्रमाणीकरण और पहचान

उपयोगकर्ता एक स्वस्थ एप्लिकेशन तक पहुंच नहीं सकते यदि आवश्यक प्रमाणीकरण बुनियादी ढांचा उपलब्ध नहीं है।

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

नेटवर्क और रिमोट एक्सेस पथ

केंद्रीकृत विंडोज अनुप्रयोगों के लिए, उपयोगकर्ताओं और अनुप्रयोग वातावरण के बीच कनेक्टिविटी एक और संभावित विफलता डोमेन का प्रतिनिधित्व करती है।

आइए संपूर्ण श्रृंखला की कल्पना करें:

उपयोगकर्ता उपकरण → इंटरनेट या LAN → गेटवे → अनुप्रयोग होस्ट → बैकएंड सेवाएँ

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

समाप्तिबिंदु

एप्लिकेशन लचीलापन के लिए आवश्यक नहीं है कि उपयोगकर्ता का सामान्य कार्यस्थल उपलब्ध हो।

अधिकृत उपयोगकर्ताओं को एक वैकल्पिक डिवाइस या ब्राउज़र के माध्यम से केंद्रीय रूप से होस्ट की गई अनुप्रयोगों तक पहुंचने के साधन प्रदान करना सुनिश्चित कर सकता है, यदि एक लैपटॉप अनुपलब्ध हो जाता है, एक कार्यालय अप्राप्य हो जाता है या कर्मचारियों को एक अलग स्थान से काम करने की आवश्यकता होती है।

एप्लिकेशन डिलीवरी आर्किटेक्चर एक व्यापक व्यवसाय निरंतरता रणनीति का एक घटक हो सकता है।

Windows ऐप्स के लिए एप्लिकेशन स्थिरता बनाने की प्रक्रिया क्या है?

कोई एकल तकनीक अनुप्रयोग को लचीला नहीं बनाती। आईटी टीमें इसके बजाय उन विफलताओं की संख्या को कम करने के लिए काम करती हैं जो एक पूर्ण कार्य को बंद कर सकती हैं और जो बनी रहती हैं उनके लिए नियंत्रित पुनर्प्राप्ति तंत्र के लिए तैयारी करती हैं।

1. महत्वपूर्ण अनुप्रयोगों और व्यावसायिक प्रक्रियाओं की पहचान करें

सभी अनुप्रयोगों को समान सुरक्षा स्तर की आवश्यकता नहीं होती। यह निर्धारित करने से शुरू करें कि कौन से अनुप्रयोग प्राथमिक संचालन का समर्थन करते हैं, कौन से उपयोगकर्ता उन पर निर्भर करते हैं और उनकी डाउनटाइम सहिष्णुता क्या है।

दो पुनर्प्राप्ति उद्देश्यों को व्यावसायिक आवश्यकताओं को तकनीकी विनिर्देशों में अनुवादित करें। NIST की आकस्मिक योजना मार्गदर्शिका रिकवरी टाइम ऑब्जेक्टिव (RTO) और रिकवरी पॉइंट ऑब्जेक्टिव (RPO) को रिकवरी आवश्यकताओं को निर्धारित करने के लिए प्रमुख पैरामीटर के रूप में परिभाषित करता है:

• पुनर्प्राप्ति समय उद्देश्य (RTO): सेवा बहाल होने से पहले स्वीकार्य डाउनटाइम की अवधि।
• रिकवरी पॉइंट ऑब्जेक्टिव (RPO): स्वीकार्य डेटा हानि का एक अंतराल, जो समय में मापा जाता है।

एक एप्लिकेशन जो ऑर्डर प्रोसेस करने के लिए अत्यधिक उपयोग किया जाता है, उसका RTO मिनटों में हो सकता है, जबकि एक वित्तीय रिपोर्टिंग एप्लिकेशन जो सप्ताह में एक बार चलाया जाता है, उसे डाउनटाइम के लिए दिनों की अनुमति हो सकती है।

RTO और RPO एक एप्लिकेशन के लिए आवश्यक सुरक्षा के प्रकार को परिभाषित करते हैं: तात्कालिक फेलओवर, सेवाओं की तेज पुनर्स्थापना या केवल एक प्रलेखित पुनर्प्राप्ति प्रक्रिया।

पूरी एप्लिकेशन निर्भरता श्रृंखला का मानचित्रण करें

ऐसे सभी दस्तावेज़ तैयार करें जो आवेदन को अपना काम करने के लिए आवश्यक हैं।

कार्यकारी या विंडोज सर्वर पर न रुकें। डेटाबेस, संग्रहण, प्रमाणीकरण, DNS, नेटवर्किंग, प्रमाणपत्र, लाइसेंसिंग सिस्टम, गेटवे और बाहरी सेवाओं को न भूलें।

प्रत्येक के लिए, पूछें:

यदि यह चला जाता है तो एप्लिकेशन का क्या होगा?

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

3. महत्वपूर्ण एकल विफलता के बिंदुओं को हटाएं

एक बार निर्भरता वृक्ष स्थापित हो जाने के बाद, यह निर्धारित करें कि कौन से घटकों को व्यापारिक महत्व और पुनर्प्राप्ति उद्देश्यों के आधार पर अधिशेष बनाया जाना है।

Windows एप्लिकेशन डिलीवरी के मामले में, इसमें एकल होस्ट की क्षमताओं पर निर्भर रहने के बजाय कई एप्लिकेशन सर्वरों को तैनात करना शामिल हो सकता है। लोड बैलेंसिंग परत के साथ, सामान्य संचालन के दौरान सत्रों को एप्लिकेशन उदाहरणों के बीच फैलाया जा सकता है। एक होस्ट विफलता के मामले में, आने वाले कनेक्शनों को स्वस्थ एप्लिकेशन सर्वर उदाहरणों की ओर रूट किया जा सकता है।

अतिरिक्तता योजना को निर्भरता विश्लेषण द्वारा सूचित किया जाना चाहिए, हालांकि। एकल महत्वपूर्ण डेटाबेस, नेटवर्क गेटवे या स्टोरेज लेयर को एक्सेस करने वाले कई एप्लिकेशन सर्वर अभी भी एकल विफलता का बिंदु प्रस्तुत करते हैं।

उच्च उपलब्धता डिज़ाइन को इसलिए एप्लिकेशन सेवा को एक एकीकृत इकाई के रूप में विचार करना चाहिए। विंडोज सर्वर वातावरण के लिए जो अवसंरचना स्तर की पुनरावृत्ति की आवश्यकता होती है, Microsoft के फेलओवर क्लस्टरिंग दस्तावेज़ उच्च उपलब्धता और आपदा पुनर्प्राप्ति टोपोलॉजी पर आगे की मार्गदर्शिका प्रदान करता है।

4. व्यक्तिगत एंडपॉइंट्स से एप्लिकेशन को अलग करें

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

प्रबंधित विंडोज होस्ट पर अनुप्रयोगों का केंद्रीकरण और उपयोगकर्ताओं के लिए एप्लिकेशन इंटरफ़ेस प्रस्तुत करने से इस जोखिम को समाप्त कर दिया जाता है। डेटा और एप्लिकेशन की स्थिति प्रबंधित विंडोज होस्ट पर संग्रहीत होती है और अधिकृत एंडपॉइंट्स द्वारा एक्सेस की जाती है।

इससे, हम एप्लिकेशन को उपयोगकर्ताओं के लिए उपलब्ध कराते हैं, भले ही वे उपकरण या स्थान बदलें। जबकि एप्लिकेशनों को केंद्रीकृत करना बुनियादी ढांचे की समस्याओं को समाप्त नहीं करता है, यह इसे एक ऐसे वातावरण में स्थानांतरित करने में मदद करता है जहाँ इसे आईटी द्वारा नियंत्रित किया जा सकता है।

5. एक से अधिक व्यावहारिक पहुँच विधि प्रदान करें

लचीलापन एकल एंडपॉइंट प्रकार या कनेक्शन विधि पर अनावश्यक निर्भरता से बचकर भी प्राप्त किया जा सकता है।

आवेदन वितरण आर्किटेक्चर के आधार पर, उपयोगकर्ता विभिन्न का उपयोग कर सकते हैं। दूरस्थ पहुंच विधियाँ, जिसमें एक RDP-संगत क्लाइंट, समर्पित एप्लिकेशन लॉन्चर, वेब पोर्टल या HTML5 ब्राउज़र सत्र शामिल हैं।

वैकल्पिक कनेक्शन विधियों को अवसंरचना की पुनरावृत्ति के साथ भ्रमित नहीं किया जाना चाहिए। यदि सभी एक ही विफल सर्वर पर निर्भर हैं, तो एप्लिकेशन अभी भी अनुपलब्ध है।

वे उपयोगकर्ता के सामान्य डिवाइस, स्थापित क्लाइंट या स्थान पर व्यवधान प्रभाव डालने पर पहुंच स्थिरता प्रदान करते हैं, न कि एप्लिकेशन सेवा स्वयं पर।

6. निगरानी करें इससे पहले कि गिरावट एक आउटेज में बदल जाए

एप्लिकेशन लचीलापन केवल पुनर्प्राप्ति के बारे में नहीं है, बल्कि जल्दी पहचान करने से आउटेज में गिरावट से बचा जा सकता है।

Windows अनुप्रयोग वातावरण में उपयोगी संकेतक हैं CPU उपयोग, मेमोरी दबाव, डिस्क क्षमता और I/O, नेटवर्क उपयोग, सक्रिय सत्र, अनुप्रयोग प्रक्रिया, प्रतिक्रिया समय, विफल कनेक्शन और निर्भर सेवाओं की उपलब्धता।

प्रवृत्ति निगरानी यह महत्वपूर्ण है, क्योंकि एक सर्वर जो बार-बार अपनी सीमाओं के करीब पहुंचता है, वह अभी भी ऑनलाइन रह सकता है जबकि उपयोगकर्ता का अनुभव धीरे-धीरे बिगड़ता है।

थ्रेशोल्ड अलर्ट प्रशासकों को उपयोगकर्ताओं के पहुंच खोने से पहले एक घटना के पूर्ववर्ती की जांच करने में सक्षम बनाते हैं।

7. क्षमता स्पाइक्स और फेलओवर के लिए योजना बनाएं

एक ऐसा अनुप्रयोग जो हार्डवेयर स्तर की विफलताओं को सहन करता है लेकिन बढ़ती मांगों के तहत पूरी तरह से कार्य करने में असमर्थ हो जाता है, किसी भी प्रकार की विफलताओं के प्रति वास्तव में लचीला नहीं है।

क्षमता की योजना में न केवल रोज़मर्रा के उपयोग के पैटर्न को ध्यान में रखना चाहिए, बल्कि मौसमी मांग, परिवर्तन शिफ्ट, वृद्धि, या अन्य अनुप्रयोगों के लिए होस्टिंग आवश्यकताओं के कारण होने वाले पीक को भी ध्यान में रखना चाहिए।

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

अन्यथा, फेल-ओवर प्रक्रियाएँ एक अलग घटना को एक व्यापक प्रणाली प्रदर्शन समस्या में बदल सकती हैं।

8. डेटा और कॉन्फ़िगरेशन की सुरक्षा करें

एक प्रतिस्थापन विंडोज सर्वर का कोई उपयोग नहीं है यदि आईटी आवश्यक घटकों को पुनर्स्थापित नहीं कर सकता है जो एप्लिकेशन को काम करने के लिए आवश्यक हैं।

यह इसका मतलब हो सकता है कि बैकअप प्रक्रियाओं में एप्लिकेशन डेटा, डेटाबेस, कॉन्फ़िगरेशन फ़ाइलें, प्रमाणपत्र, एप्लिकेशन सेटिंग्स, उपयोगकर्ता प्रोफाइल, बुनियादी ढांचे की कॉन्फ़िगरेशन, स्क्रिप्ट और लाइसेंसिंग जानकारी शामिल होनी चाहिए।

यह रणनीति अनुप्रयोग के रिकवरी टाइम ऑब्जेक्टिव (RTO) और रिकवरी पॉइंट ऑब्जेक्टिव (RPO) के आधार पर भिन्न होगी।

सबसे पहले, यह सुनिश्चित करें कि एक सफल बैकअप का मतलब सफल पुनर्प्राप्ति नहीं है। आईटी टीमों को यह परीक्षण करना चाहिए कि क्या सुरक्षित डेटा और कॉन्फ़िगरेशन से पूरे एप्लिकेशन सेवा को पुनर्स्थापित करना संभव है।

9. परिवर्तनों के विस्फोटक क्षेत्र को कम करें

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

एक मल्टी-सरवर सेटअप में, सुधार परिवर्तनों को चरणों में करना संभव है, जिससे प्रशासक यह सुनिश्चित कर सके कि सब कुछ सही ढंग से काम कर रहा है। किए गए परिवर्तनों को वापस करने की क्षमता भी आवश्यक है।

इसलिए, जब आकस्मिक प्रक्रियाओं को डिजाइन करते हैं, तो रोलबैक विकल्पों पर भी विचार किया जाना चाहिए। प्रक्रिया को सही तरीके से दस्तावेजीकृत किया जाना चाहिए, और कर्मचारियों को यह जानना चाहिए कि यदि कोई परिवर्तन विफल हो जाता है तो क्या करना है, न कि इसे केवल उनकी विवेकाधीनता पर छोड़ देना चाहिए।

10. सुचारू अवनति के लिए डिज़ाइन करें

लचीलापन हमेशा सामान्य कार्यों को 100% चालू और चलाते रहना नहीं है।

कुछ मामलों में, प्रमुख उपयोगकर्ताओं या अनुप्रयोगों के लिए संचालन को बनाए रखना सभी उपयोगकर्ताओं के लिए सभी सेवाओं को उपलब्ध रखने से अधिक महत्वपूर्ण हो सकता है। आईटी टीमों द्वारा एक घटना होने से पहले प्राथमिकताएँ स्थापित की जा सकती हैं।

यदि उपलब्ध क्षमता है जिसका उपयोग किया जा सकता है, तो इसे पहले उत्पादन, ग्राहक सेवा, वित्त या अन्य कार्यों को आवंटित करना समझदारी हो सकती है।

यह सुंदर अपघटन है: सबसे अधिक व्यावसायिक मूल्य उत्पन्न करने वाले कार्यों को चलाने की क्षमता बनाए रखना, बजाय इसके कि कम महत्वपूर्ण तत्वों की विफलता पूरे सिस्टम को क्रैश कर दे।

आईटी टीमों को एप्लिकेशन स्थिरता की निगरानी कैसे करनी चाहिए?

व्यक्तिगत सर्वरों की निगरानी उपयोगी हो सकती है, लेकिन लचीलापन निगरानी को उपयोगकर्ताओं द्वारा अनुभव की गई कुल एप्लिकेशन सेवा को दर्शाना चाहिए।

एक यथार्थवादी मॉडल में कई परतें होती हैं:

परत	क्या मॉनिटर करना है	उदाहरण विफलता
होस्ट	सीपीयू, रैम, डिस्क, ओएस उपलब्धता	सर्वर ओवरलोडेड या ऑफ़लाइन
एप्लिकेशन	प्रक्रिया और सेवा स्थिति	ऐप्लिकेशन क्रैश होता है
निर्भरता	डेटाबेस, DNS, पहचान, भंडारण	एप्लिकेशन लॉन्च होता है लेकिन संचालन नहीं कर सकता
पहुँच	गेटवे, पोर्टल, नेटवर्क पथ	उपयोगकर्ता कनेक्ट नहीं कर सकते
सत्र	सक्रिय उपयोगकर्ता, विफलताएँ, विलंबता	ऐप्लिकेशन ऑनलाइन है लेकिन अनुपयोगी है
व्यवसाय कार्य	सफल कार्यप्रवाह पूर्णता	उपयोगकर्ता आवश्यक कार्य पूरा नहीं कर सकता

व्यवसाय-कार्य परत को नजरअंदाज करना सबसे सरल में से एक है।

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

ऐप्लिकेशन की स्थिरता का परीक्षण कैसे किया जाना चाहिए?

एक लचीलापन आर्किटेक्चर जिसमें कभी भी नियंत्रित विफलता का अनुभव नहीं हुआ है, उसमें अप्रयुक्त धारणाएँ होती हैं।

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

परीक्षण प्रक्रियाएँ पुनर्प्राप्ति के तकनीकी पहलुओं से परे होनी चाहिए। आईटी टीमों को यह समीक्षा करनी चाहिए कि क्या अलर्ट सही प्रशासनिक कर्मचारियों को भेजे जा रहे हैं, पुनर्प्राप्ति के चरण सही क्रम में किए जा रहे हैं, और उपयोगकर्ता सेवाएँ बहाल होने के बाद वास्तविक व्यावसायिक कार्य करने में सक्षम हैं।

संचालन प्रक्रियाएँ एक मजबूत प्रणाली के लिए अनिवार्य हैं। चेतावनी वृद्धि प्रक्रियाएँ: चेतावनी किसे प्राप्त होती है? किसके पास फेलओवर शुरू करने का अधिकार है? पुनर्प्राप्ति दस्तावेज़ और क्रेडेंशियल्स कहाँ संग्रहीत हैं? कौन सी निर्भरता पहले ऑनलाइन आनी चाहिए?

तकनीकी पुनरावृत्ति का कोई विशेष लाभ नहीं होता यदि पुनः पहुँच प्राप्त करने की प्रक्रियाओं का परीक्षण नहीं किया गया है।

क्या हो सकता है एप्लिकेशन रेजिलियंस चेकलिस्ट?

महत्वपूर्ण Windows एप्लिकेशन के लिए तैयार होने से पहले, आईटी टीमों को निम्नलिखित प्रश्नों का उत्तर देने में सक्षम होना चाहिए:

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

सभी उत्तरों के लिए महंगे उच्च उपलब्धता बुनियादी ढांचे की आवश्यकता नहीं होती है। सुरक्षा का सही स्तर लागत और डाउनटाइम के संचालन पर प्रभाव पर निर्भर करता है।

महत्वपूर्ण यह है कि उपलब्धता, पुनरावृत्ति और पुनर्प्राप्ति के निर्णय जानबूझकर किए जाएं, न कि अनुमानित।

TSplus कैसे विंडोज़ एप्लिकेशन उपलब्ध रखने में मदद कर सकता है?

संस्थाओं के लिए जो मौजूदा विंडोज अनुप्रयोगों पर निर्भर करती हैं, हम प्रबंधित विंडोज सर्वरों पर अनुप्रयोगों को केंद्रीकृत करके और उन्हें उपयोगकर्ताओं को RDP-संगत क्लाइंट, RemoteApp-शैली के एक्सेस या एक HTML5 वेब पोर्टल के माध्यम से प्रदान करके उपलब्धता में सुधार करने में मदद कर सकते हैं। यह व्यक्तिगत उपयोगकर्ता एंडपॉइंट्स पर निर्भरता को कम करता है और आईटी टीमों को अधिक लचीलापन देता है जब उपयोगकर्ताओं को किसी अन्य डिवाइस या स्थान से कनेक्ट करने की आवश्यकता होती है।

TSplus Remote Access कई सर्वर तैनाती का समर्थन भी कर सकता है जिसमें लोड संतुलन और गेटवे-आधारित पहुंच शामिल है। जब इसे लचीले डेटाबेस, भंडारण, पहचान सेवाओं और नेटवर्किंग के साथ मिलाया जाता है, तो यह आर्किटेक्चर एकल एप्लिकेशन होस्ट पर निर्भरता को कम कर सकता है और बुनियादी ढांचे में व्यवधान के दौरान महत्वपूर्ण विंडोज एप्लिकेशन तक पहुंच बनाए रखने में मदद कर सकता है।

निष्कर्ष

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

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