DRP तयारी गर्दै - उल्कापिण्डलाई ध्यानमा राख्न नबिर्सनुहोस्

विपद्को बेला पनि एक कप चियाको समय हुन्छ

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

आतंकमा परेका ग्राहकहरूले प्राविधिक समर्थन फोनहरू काट्न थालेपछि, जुनियर साइनाइड खोज्दैछ, तपाईंले बुद्धिमानीपूर्वक रातो खाम खोल्नुहोस् र सबै कुरा व्यवस्थित गर्न थाल्नुभयो।

यस पोष्टमा म कसरी DRP लेख्ने र यसमा के समावेश हुनुपर्छ भन्ने बारे सिफारिसहरू साझा गर्न चाहन्छु। हामी निम्न कुराहरू पनि हेर्नेछौं:

1. खलनायक जस्तै सोच्न सिकौं।
2. सर्वनाशको समयमा एक कप चियाका फाइदाहरू हेरौं।
3. एक सुविधाजनक DRP संरचना विचार गरौं
4. यसलाई कसरी परीक्षण गर्ने हेरौं

यो कुन कम्पनीहरूको लागि उपयोगी हुन सक्छ?

IT विभागलाई त्यस्ता चीजहरूको आवश्यकता पर्न थालेपछि रेखा कोर्न धेरै गाह्रो छ। म भन्छु कि तपाईलाई निश्चित रूपमा DRP चाहिन्छ यदि:

• सर्भर, एप्लिकेसन रोक्न वा केही डाटाबेस गुमाउनुले समग्र रूपमा व्यापारको लागि महत्त्वपूर्ण घाटा निम्त्याउँछ।
• तपाईंसँग पूर्ण विकसित IT विभाग छ। विभागको अर्थमा कम्पनीको पूर्ण इकाईको रूपमा, आफ्नै बजेटको साथ, र नेटवर्क बिछ्याउने, भाइरसहरू सफा गर्ने र प्रिन्टरहरू रिफिल गर्ने केही थकित कर्मचारीहरू मात्र होइन।
• तपाईंसँग आपतकालीन अवस्थामा कम्तिमा आंशिक रिडन्डन्सीको लागि यथार्थपरक बजेट छ।

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

कागजात महत्त्वपूर्ण छ

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

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

एक तोडफोड जस्तै विचार

सबैभन्दा गाह्रो भाग ती दुर्घटनाहरू भविष्यवाणी गर्नु हो जुन पहिले कहिल्यै भएको थिएन, तर जसले सम्भावित रूपमा तपाईंको सेवालाई पूर्ण रूपमा क्र्यास गर्न सक्छ। यहाँ मेरा सहकर्मीहरू र म प्राय: खलनायकको भूमिका खेल्छौं। धेरै कफी र स्वादिलो ​​चीज लिनुहोस् र आफैलाई बैठक कोठामा बन्द गर्नुहोस्। केवल निश्चित गर्नुहोस् कि उही वार्तालापहरूमा तपाईंले ती इन्जिनियरहरूलाई लक गर्नुहुन्छ जसले आफैंले लक्षित सेवा विकास गरेका छन् वा नियमित रूपमा यसको साथ काम गर्छन्। त्यसपछि, या त बोर्डमा वा कागजमा, तपाइँ तपाइँको सेवामा हुन सक्ने सबै सम्भावित भयावहहरू कोर्न सुरु गर्नुहुन्छ। यो एक विशेष सफाई महिला र केबुलहरू तान्न तल विस्तारमा जान आवश्यक छैन; यो "स्थानीय नेटवर्कको अखण्डताको उल्लङ्घन" को परिदृश्यलाई विचार गर्न पर्याप्त छ।

सामान्यतया, प्रायजसो सामान्य आपतकालीन अवस्थाहरू निम्न प्रकारहरूमा पर्छन्:

• नेटवर्क विफलता
• OS सेवा विफलता
• आवेदन विफलता
• फलामको विफलता
• भर्चुअलाइजेशन विफलता

केवल प्रत्येक प्रकार मार्फत जानुहोस् र हेर्नुहोस् तपाईंको सेवामा के लागू हुन्छ। उदाहरण को लागी, Nginx डेमन खस्न सक्छ र उठ्न सक्दैन - यसको मतलब OS को भाग मा विफलता। एक दुर्लभ अवस्था जसले तपाइँको वेब अनुप्रयोगलाई असफल बनाउँछ एक सफ्टवेयर विफलता हो। यस चरण मार्फत काम गर्दा, यो समस्या को निदान बाहिर काम गर्न महत्त्वपूर्ण छ। उदाहरणका लागि, पतित cis ड्राइभ र नेटवर्क विफलताबाट भर्चुअलाइजेशनमा फ्रिज गरिएको इन्टरफेस कसरी छुट्याउन सकिन्छ। यो चाँडै जिम्मेवार व्यक्तिहरू फेला पार्न र दुर्घटना समाधान नभएसम्म तिनीहरूको पुच्छर तान्न सुरु गर्न महत्त्वपूर्ण छ।

सामान्य समस्याहरू लेखिसकेपछि, हामी थप कफी खन्याउछौं र अनौठो परिदृश्यहरू विचार गर्न थाल्छौं, जब केही प्यारामिटरहरू सामान्यभन्दा धेरै टाढा जान थाल्छन्। उदाहरणका लागि:

• के हुन्छ यदि सक्रिय नोडमा रहेको समय क्लस्टरमा अन्यको तुलनामा एक मिनेट पछाडि सर्छ?
• के हुन्छ यदि समय अगाडि बढ्यो भने, के हुन्छ भने 10 वर्षमा?
• के हुन्छ यदि क्लस्टर नोडले सिङ्क्रोनाइजेसनको बेला अचानक आफ्नो नेटवर्क गुमाउँछ?
• नेटवर्कमा एक अर्काको अस्थायी अलगावको कारण दुई नोडहरूले नेतृत्व साझेदारी गर्दैन भने के हुन्छ?

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

तपाईको यो DRP के हो?!

त्यसैले तपाईंले आफ्नो खतरा मोडेल परिभाषित गर्नुभयो। तिनीहरूले तामाको खोजीमा फाइबर अप्टिक केबलहरू काट्ने स्थानीय बासिन्दाहरू र शुक्रबार 16:46 मा कडा रूपमा रेडियो रिले लाइन खसाउने सैन्य रडारलाई पनि ध्यानमा राखे। अब यी सबैलाई के गर्ने भन्ने बुझ्नुपर्छ ।

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

यो आपतकालीन मा सोच्न गाह्रो छ! मेरुदण्ड पार्सिङको लागि सरल निर्देशनहरू हुनुपर्छ।

राम्रो DRP मा धेरै साधारण ब्लकहरू हुन्छन्:

1. दुर्घटना सुरु भएको बारे कसलाई सूचित गर्ने। उन्मूलन प्रक्रियालाई सकेसम्म समानान्तर बनाउन यो महत्त्वपूर्ण छ।
2. कसरी सही निदान गर्ने - ट्रेस प्रदर्शन गर्नुहोस्, systemctl स्थिति सेवानाम हेर्नुहोस् र यस्तै अन्य।
3. तपाइँ प्रत्येक चरणमा कति समय खर्च गर्न सक्नुहुन्छ? यदि तपाईंसँग SLA समय भित्र म्यानुअल रूपमा यसलाई ठीक गर्न समय छैन भने, भर्चुअल मेसिन मारिन्छ र हिजोको ब्याकअपबाट फिर्ता हुन्छ।
4. कसरी सुनिश्चित गर्ने कि दुर्घटना समाप्त भयो।

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

DRP र प्रणाली पासपोर्ट भ्रमित नगर्नुहोस्! यसलाई अनावश्यक डाटाको साथ ओभरलोड नगर्नुहोस्। कागजातको वांछित खण्डमा जान र सेवा वास्तुकलाको आवश्यक खण्डहरू बारे विस्तारित ढाँचामा पढ्नको लागि द्रुत र सहज रूपमा हाइपरलिङ्कहरू प्रयोग गर्न सम्भव बनाउनुहोस्। र DRP मा मात्र प्रतिलिपि टाँस्नका लागि विशेष आदेशहरू कहाँ र कसरी जडान गर्ने भन्ने बारे प्रत्यक्ष निर्देशनहरू छन्।

कसरी सही परीक्षण गर्ने

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

गलत - "भर्चुअलाइजेशनमा जानुहोस् र मृत नोड रिबुट गर्नुहोस्"
दाँया - "वेब इन्टरफेस मार्फत virt.example.com मा जडान गर्नुहोस्, नोड्स खण्डमा, त्रुटि निम्त्याउने नोडलाई रिबुट गर्नुहोस्।"

अस्पष्टताबाट बच्नुहोस्। डराएको इन्टर्नलाई सम्झनुहोस्।

DRP परीक्षण गर्न निश्चित हुनुहोस्। यो केवल शो को लागी एक योजना होइन - यो केहि चीज हो जसले तपाई र तपाईका ग्राहकहरुलाई एक महत्वपूर्ण अवस्थाबाट छिटो बाहिर निस्कन अनुमति दिनेछ। यो धेरै पटक गर्न सबै भन्दा राम्रो छ:

• एक विशेषज्ञ र धेरै प्रशिक्षार्थीहरूले परीक्षण बेन्चमा काम गर्छन् जसले यथासम्भव वास्तविक सेवालाई अनुकरण गर्दछ। विशेषज्ञले विभिन्न तरिकाले सेवा तोड्छन् र प्रशिक्षार्थीहरूलाई DRP अनुसार पुनर्स्थापित गर्न सक्षम बनाउँछन्। सबै समस्या, कागजात अस्पष्टता र त्रुटिहरू रेकर्ड छन्। प्रशिक्षार्थीहरूलाई तालिम दिएपछि, अस्पष्ट क्षेत्रहरूमा DRP विस्तार र सरलीकृत गरिन्छ।
• एक वास्तविक सेवा मा परीक्षण। वास्तवमा, तपाईले कहिल्यै वास्तविक सेवाको पूर्ण प्रतिलिपि बनाउन सक्नुहुन्न। तसर्थ, रिकभरी अर्डरको मूल्याङ्कन गर्न वर्षमा दुई पटक नियमित रूपमा केही सर्भरहरू बन्द गर्न, जडानहरू तोड्न र खतराहरूको सूचीबाट अन्य प्रकोपहरू निम्त्याउन आवश्यक छ। मध्यरातमा 10 मिनेटको लागि योजनाबद्ध विफलता डेटा हानिको साथ पीक लोडको समयमा धेरै घण्टाको लागि अचानक विफलता भन्दा राम्रो छ।
• वास्तविक समस्या निवारण। हो, यो पनि परीक्षणको भाग हो। यदि कुनै दुर्घटना धम्कीको सूचीमा थिएन भने, यसको अनुसन्धानको नतिजाको आधारमा DRP लाई पूरक र अन्तिम रूप दिन आवश्यक छ।

मुख्य बुँदाहरू

1. यदि बकवास हुन सक्छ, यो मात्र हुनेछैन, तर यो सम्भव सबै भन्दा विनाशकारी परिदृश्यमा गर्नेछ।
2. सुनिश्चित गर्नुहोस् कि तपाईंसँग आपतकालीन लोड स्थानान्तरणको लागि स्रोतहरू छन्।
3. निश्चित गर्नुहोस् कि तपाइँसँग ब्याकअपहरू छन्, तिनीहरू स्वचालित रूपमा सिर्जना हुन्छन् र स्थिरताको लागि नियमित रूपमा जाँच गरिन्छ।
4. सामान्य खतरा परिदृश्यहरू मार्फत सोच्नुहोस्।
5. इन्जिनियरहरूलाई सेवा प्रदान गर्नका लागि गैर-मानक विकल्पहरू ल्याउने मौका दिनुहोस्।
6. DRP सरल र स्पष्ट निर्देशन हुनुपर्छ। सबै जटिल निदानहरू ग्राहकहरूको सेवा पुनर्स्थापित भएपछि मात्र गरिन्छ। रिजर्भ क्षमतामा भए पनि।
7. DRP मा मुख्य फोन नम्बर र सम्पर्कहरू प्रदान गर्नुहोस्।
8. नियमित रूपमा DRP को कर्मचारीहरूको बुझाइ परीक्षण गर्नुहोस्।
9. उत्पादन साइटहरूमा योजनाबद्ध दुर्घटनाहरू व्यवस्थित गर्नुहोस्। स्ट्यान्डले सबै कुरा प्रतिस्थापन गर्न सक्दैन।

स्रोत: www.habr.com