🥇डीआरपी तैयार करना - उल्कापिंड को ध्यान में रखना न भूलें

आपदा के दौरान भी, एक कप चाय के लिए हमेशा समय होता है।

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

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

इस पोस्ट में, मैं डीआरपी कैसे लिखें और इसमें क्या शामिल होना चाहिए, इस पर सिफारिशें साझा करना चाहता हूं। हम निम्नलिखित पर भी गौर करेंगे:

खलनायक की तरह सोचना सीखें.
आइए सर्वनाश के दौरान एक कप चाय के लाभों का विश्लेषण करें।
एक सुविधाजनक डीआरपी संरचना पर विचार करें
आइए देखें कि इसका परीक्षण कैसे करें

इससे किन कंपनियों को फायदा हो सकता है?

जब आईटी विभाग को इन चीजों की जरूरत पड़ने लगे तो एक रेखा खींचना बहुत मुश्किल हो जाता है। मैं कहूंगा कि आपको डीआरपी की आवश्यकता की गारंटी है यदि:

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

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

दस्तावेज़ीकरण महत्वपूर्ण है

दस्तावेज़ीकरण से प्रारंभ करें. मान लीजिए कि आपकी सेवा एक पर्ल स्क्रिप्ट पर चलती है जो तीन पीढ़ियों पहले व्यवस्थापकों द्वारा लिखी गई थी, और कोई नहीं जानता कि यह कैसे काम करती है। संचित तकनीकी ऋण और दस्तावेज़ीकरण की कमी अनिवार्य रूप से आपको न केवल घुटने में, बल्कि अन्य अंगों में भी गोली मार देगी, बल्कि यह समय की बात है।

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

तोड़फोड़ करने वाले की तरह विचार

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

आमतौर पर, अधिकांश विशिष्ट आपातस्थितियाँ निम्नलिखित प्रकारों में फिट होती हैं:

नेटवर्क विफलता
ओएस सेवा विफलता
अनुप्रयोग विफलता
लोहे की विफलता
वर्चुअलाइजेशन विफलता

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

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

यदि सक्रिय नोड पर समय क्लस्टर में अन्य के सापेक्ष एक मिनट पीछे चला जाए तो क्या होगा?
और यदि समय आगे बढ़ता है, और यदि 10 वर्ष तक?
यदि कोई क्लस्टर नोड सिंक्रोनाइज़ेशन के दौरान अचानक नेटवर्क खो देता है तो क्या होगा?
और क्या होगा यदि दो नोड नेटवर्क पर एक-दूसरे के अस्थायी अलगाव के कारण नेतृत्व साझा नहीं करते हैं?

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

आपकी यह डीआरपी क्या है?!

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

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

आपात्कालीन स्थिति में सोचना कठिन है! स्पाइनल पार्सिंग के लिए सरल निर्देश होने चाहिए।

एक अच्छे डीआरपी में कुछ सरल ब्लॉक होते हैं:

दुर्घटना की शुरुआत के बारे में किसे सूचित करें। उन्मूलन प्रक्रिया को यथासंभव समानांतर बनाने के लिए यह महत्वपूर्ण है।
सही तरीके से निदान कैसे करें - हम ट्रेस करते हैं, systemctl स्टेटस सर्विसनेम में देखते हैं और इसी तरह।
प्रत्येक चरण पर कितना समय व्यतीत किया जा सकता है. यदि आपके पास SLA समय के दौरान इसे अपने हाथों से ठीक करने का समय नहीं है, तो वर्चुअल मशीन बंद हो जाती है और कल के बैकअप से रोल हो जाती है।
कैसे सुनिश्चित करें कि दुर्घटना ख़त्म हो गई है.

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

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

सही तरीके से परीक्षण कैसे करें

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

ग़लत - "वर्चुअलाइजेशन पर जाएं और मृत नोड को रीबूट करें"
सही ढंग से - "वेब इंटरफ़ेस के माध्यम से virt.example.com से कनेक्ट करें, नोड अनुभाग में, उस नोड को पुनः लोड करें जो त्रुटि उत्पन्न कर रहा है।"

अस्पष्टता से बचें. भयभीत इंटर्न को याद करें.

डीआरपी का परीक्षण अवश्य करें। यह केवल दिखावे की योजना नहीं है - यह कुछ ऐसा है जो आपको और आपके ग्राहकों को एक गंभीर स्थिति से जल्दी बाहर निकलने की अनुमति देगा। ऐसा कई बार करना सर्वोत्तम है:

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

प्रमुख बिंदु

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

स्रोत: www.habr.com

डीआरपी तैयार करना - उल्कापिंड को ध्यान में रखना न भूलें