🥇 DRP तयार करत आहे - उल्कापात विचारात घेण्यास विसरू नका

आपत्तीच्या काळातही एक कप चहाची वेळ नेहमीच येते.

डीआरपी (डिझास्टर रिकव्हरी प्लॅन) ही एक अशी गोष्ट आहे ज्याची कधीही गरज भासणार नाही. पण जर अचानक वीण हंगामात स्थलांतरित होणारे बीवर मुख्य ऑप्टिकल फायबरमधून कुरतडतात किंवा एखाद्या कनिष्ठ प्रशासकाने उत्पादनक्षम आधार सोडला, तर या सर्व अपमानाचे काय करायचे याची पूर्व-निर्मित योजना तुमच्याकडे निश्चितपणे असेल.

घाबरलेले ग्राहक टेक सपोर्टला कॉल करू लागले असताना, एक कनिष्ठ सायनाइड शोधत आहे, तुम्ही हुशारीने लाल लिफाफा उघडा आणि सर्वकाही व्यवस्थित ठेवण्यास सुरुवात करा.

या पोस्टमध्ये, मला DRP कसे लिहावे आणि त्यात काय असावे यावरील शिफारसी सामायिक करायच्या आहेत. आम्ही पुढील गोष्टी देखील पाहू:

खलनायकासारखा विचार करायला शिका.
सर्वनाश दरम्यान एक कप चहाच्या फायद्यांचे विश्लेषण करूया.
सोयीस्कर DRP रचनेचा विचार करा
त्याची चाचणी कशी करायची ते पाहू

याचा फायदा कोणत्या कंपन्यांना होऊ शकतो?

जेव्हा आयटी विभागाला या गोष्टींची गरज भासू लागते तेव्हा रेषा काढणे फार कठीण असते. मी म्हणेन की तुम्हाला डीआरपीची आवश्यकता असेल जर:

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

आयटी विभाग काही महिन्यांपासून बॅकअपसाठी जुन्या सर्व्हरसाठी किमान दोन एचडीडीची भीक मागत आहे, तेव्हा तुम्हांला अतिरिक्त क्षमतेसाठी खाली पडलेल्या सेवेचे पूर्ण पुनर्स्थापना आयोजित करण्याची शक्यता नाही. जरी येथे कागदपत्रे अनावश्यक नसतील.

दस्तऐवजीकरण महत्वाचे आहे

कागदपत्रांसह प्रारंभ करा. समजा तुमची सेवा पर्ल स्क्रिप्टवर चालते जी प्रशासकांच्या तीन पिढ्यांपूर्वी लिहिलेली होती आणि ती कशी कार्य करते हे कोणालाही माहिती नाही. जमा झालेले तांत्रिक कर्ज आणि कागदपत्रांचा अभाव यामुळे तुम्हाला केवळ गुडघ्यातच नव्हे तर इतर अंगातही मारले जाईल, ही काळाची बाब आहे.

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

एक तोडफोड करणारा विचार

सर्वात कठीण भाग म्हणजे त्या अपघातांचा अंदाज लावणे जे यापूर्वी कधीही घडले नाहीत, परंतु ज्यामुळे तुमची सेवा पूर्णपणे खराब होऊ शकते. इथे आम्ही सहसा सहकाऱ्यांसोबत खलनायकाची भूमिका करतो. भरपूर कॉफी आणि काहीतरी चवदार घ्या आणि स्वतःला मीटिंग रूममध्ये बंद करा. फक्त खात्री करा की त्याच मीटिंगमध्ये तुम्ही त्या अभियंत्यांना लॉक केले आहे ज्यांनी स्वतः लक्ष्य सेवा वाढवली आहे किंवा त्यासोबत नियमितपणे काम केले आहे. मग, एकतर फलकावर किंवा कागदावर, तुम्ही तुमच्या सेवेत घडू शकणार्‍या सर्व संभाव्य भीषणता काढण्यास सुरुवात करता. एखाद्या विशिष्ट साफसफाईच्या महिलेकडे तपशील देणे आणि केबल्स काढणे आवश्यक नाही, "स्थानिक नेटवर्कच्या अखंडतेचे उल्लंघन" या परिस्थितीचा विचार करणे पुरेसे आहे.

सहसा, सर्वात सामान्य आपत्कालीन परिस्थिती खालील प्रकारांमध्ये बसते:

नेटवर्क अपयश
OS सेवा अयशस्वी
अर्ज अयशस्वी
लोह अपयश
आभासीकरण अयशस्वी

फक्त प्रत्येक दृश्यातून जा आणि आपल्या सेवेला काय लागू होते ते पहा. उदाहरणार्थ, Nginx डिमन पडू शकतो आणि उठू शकत नाही - हे OS च्या भागावर अपयश आहे. एक दुर्मिळ परिस्थिती जी तुमच्या वेब ऍप्लिकेशनला कार्यरत नसलेल्या स्थितीत आणते ती सॉफ्टवेअर अयशस्वी आहे. या टप्प्याच्या विकासादरम्यान, समस्येचे निदान करणे आवश्यक आहे. व्हर्च्युअलायझेशनवर हँग इंटरफेसला पडलेल्या सिस्को आणि नेटवर्क क्रॅशपासून वेगळे कसे करायचे, उदाहरणार्थ. जबाबदार व्यक्तींना त्वरीत शोधणे आणि अपघात निश्चित होईपर्यंत त्यांची शेपूट खेचणे सुरू करणे महत्वाचे आहे.

ठराविक समस्या लिहून ठेवल्यानंतर, आम्ही अधिक कॉफी ओततो आणि विचित्र परिस्थितींचा विचार करू लागतो, जेव्हा काही पॅरामीटर्स सर्वसामान्य प्रमाणापेक्षा पुढे जाऊ लागतात. उदाहरणार्थ:

सक्रिय नोडवरील वेळ क्लस्टरमधील इतरांच्या तुलनेत एक मिनिट मागे गेल्यास काय होईल?
आणि जर वेळ पुढे सरकली, आणि जर 10 वर्षांनी?
सिंक्रोनाइझेशन दरम्यान क्लस्टर नोड अचानक नेटवर्क गमावल्यास काय होईल?
आणि नेटवर्कवर एकमेकांच्या तात्पुरत्या अलगावमुळे दोन नोड्स नेतृत्व सामायिक करत नसल्यास काय होईल?

या टप्प्यावर, उलट दृष्टीकोन खूप मदत करते. आजारी कल्पनेने संघातील सर्वात हट्टी सदस्य घ्या आणि त्याला कमीत कमी वेळेत वळवण्याची व्यवस्था करा, ज्यामुळे सेवा खाली येईल. निदान करणे कठीण असल्यास, आणखी चांगले. अभियंत्यांना काहीतरी तोडण्याची कल्पना दिल्यावर ज्या विचित्र आणि छान कल्पना येतात त्यावर तुमचा विश्वास बसणार नाही. आणि जर तुम्ही त्यांना यासाठी चाचणी स्टँडचे वचन दिले तर ते खूप चांगले आहे.

तुमचा हा DRP काय आहे?!

तर तुम्ही धमकीचे मॉडेल परिभाषित केले आहे. त्यांनी तांब्याच्या शोधात फायबर ऑप्टिक केबल्स कापणारे स्थानिक रहिवासी आणि शुक्रवारी 16:46 वाजता रेडिओ रिले लाइन काटेकोरपणे सोडणारे लष्करी रडार यांचाही विचार केला. आता या सगळ्याचे काय करायचे ते शोधून काढायचे आहे.

आपत्कालीन परिस्थितीत उघडले जाणारे समान लाल लिफाफे लिहिणे तुमचे कार्य आहे. ताबडतोब अपेक्षा करा की जेव्हा (नाही तर!) सर्व काही बिघडलेले असेल, तेव्हा फक्त सर्वात अननुभवी प्रशिक्षणार्थी जवळ असेल, ज्याचे हात काय घडत आहे या भीतीने हिंसकपणे थरथर कापतील. वैद्यकीय कार्यालयांमध्ये आपत्कालीन चिन्हे कशी लागू केली जातात ते पहा. उदाहरणार्थ, अॅनाफिलेक्टिक शॉकसह काय करावे. वैद्यकीय कर्मचार्‍यांना सर्व प्रोटोकॉल मनापासून माहित असतात, परंतु जेव्हा जवळची एखादी व्यक्ती मरण्यास सुरवात करते, तेव्हा बरेचदा प्रत्येकजण असहाय्यपणे सर्व गोष्टींकडे लक्ष देतो. हे करण्यासाठी, भिंतीवर "अशा आणि अशांचे पॅकेज उघडा" आणि "औषधांच्या अनेक युनिट्स इंट्राव्हेनस इंजेक्ट करा" यासारख्या आयटमसह एक स्पष्ट सूचना लटकलेली आहे.

आपत्कालीन परिस्थितीत विचार करणे कठीण आहे! स्पाइनल पार्सिंगसाठी सोप्या सूचना असाव्यात.

चांगल्या डीआरपीमध्ये काही साधे ब्लॉक्स असतात:

अपघाताच्या सुरुवातीबद्दल कोणाला सूचित करावे. निर्मूलन प्रक्रिया शक्य तितक्या समांतर करण्यासाठी हे महत्वाचे आहे.
योग्य निदान कसे करावे - आम्ही ट्रेस करतो, systemctl स्टेटस सर्व्हिसनाव मध्ये पाहतो आणि असेच.
प्रत्येक टप्प्यावर किती वेळ घालवता येईल. SLA वेळेत तुमच्या हातांनी ते दुरुस्त करण्यासाठी तुमच्याकडे वेळ नसल्यास, कालच्या बॅकअपमधून व्हर्च्युअल मशीन मारले जाते आणि रोल केले जाते.
क्रॅश संपल्याची खात्री कशी करावी.

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

डीआरपी आणि सिस्टम पासपोर्टमध्ये गोंधळ करू नका! अनावश्यक डेटासह ते ओव्हरलोड करू नका. हायपरलिंक्सद्वारे दस्तऐवजाच्या आवश्यक विभागात जलद आणि सोयीस्करपणे जाण्याची आणि सेवा आर्किटेक्चरच्या आवश्यक विभागांबद्दल विस्तारित स्वरूपात वाचण्याची संधी द्या. आणि डीआरपीमध्येच, कॉपी-पेस्टसाठी विशिष्ट कमांड कोठे आणि कसे जोडायचे याबद्दल थेट सूचना आहेत.

योग्यरित्या चाचणी कशी करावी

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

चुकीचे - "व्हर्च्युअलायझेशनवर जा आणि मृत नोड रीबूट करा"
बरोबर - "वेब इंटरफेसद्वारे virt.example.com शी कनेक्ट करा, नोड विभागात, त्रुटी निर्माण करणारा नोड रीलोड करा."

संदिग्धता टाळा. घाबरलेला इंटर्न लक्षात ठेवा.

DRP चाचणी नक्की करा. ही केवळ शोची योजना नाही - ही अशी गोष्ट आहे जी तुम्हाला आणि तुमच्या क्लायंटना गंभीर परिस्थितीतून लवकर बाहेर पडू देते. हे अनेक वेळा करणे चांगले आहे:

एक तज्ञ आणि अनेक इंटर्न चाचणी बेंचवर काम करतात जे शक्य तितक्या वास्तविक सेवेचे अनुकरण करतात. तज्ञ विविध मार्गांनी सेवा खंडित करतो आणि प्रशिक्षणार्थींना डीआरपीनुसार ती पुनर्संचयित करण्यास सक्षम करतो. सर्व समस्या, दस्तऐवजीकरणातील अस्पष्टता आणि त्रुटी रेकॉर्ड केल्या आहेत. प्रशिक्षणार्थींना प्रशिक्षण दिल्यानंतर, अस्पष्ट ठिकाणी डीआरपी पूरक आणि सरलीकृत केले जाते.
वास्तविक सेवेवर चाचणी. खरं तर, तुम्ही कधीही खऱ्या सेवेची परिपूर्ण प्रत तयार करू शकत नाही. म्हणून, पुनर्प्राप्ती ऑर्डरचे मूल्यांकन करण्यासाठी वर्षातून दोन वेळा सर्व्हरचा काही भाग नियोजित आधारावर बंद करणे, कनेक्शन खंडित करणे आणि धोक्यांच्या सूचीमधून इतर अपघातांची व्यवस्था करणे आवश्यक आहे. डेटा हानीसह पीक लोडवर अनेक तास अचानक अपयशी होण्यापेक्षा मध्यरात्री 10-मिनिटांचा नियोजित आउटेज असणे चांगले आहे.
अपघाताचे वास्तविक निर्मूलन. होय, हा देखील चाचणीचा एक भाग आहे. धोक्यांच्या यादीत नसलेली दुर्घटना घडल्यास, त्याच्या तपासणीच्या परिणामांवर आधारित डीआरपीला पूरक आणि अंतिम रूप देणे आवश्यक आहे.

मुख्य मुद्दे

जर बल्शिट घडू शकते, तर ते केवळ घडणार नाही, तर ते सर्वात आपत्तीजनक परिस्थितीत करेल.
तुमच्याकडे फेलओव्हरसाठी संसाधने असल्याची खात्री करा.
तुमच्याकडे बॅकअप असल्याची खात्री करा, ते आपोआप तयार केले जातात आणि नियमितपणे सातत्य तपासले जातात.
विशिष्ट धोक्याच्या परिस्थितींचा विचार करा.
अभियंत्यांना सेवा देण्यासाठी अ-मानक पर्यायांसह येण्याची संधी द्या.
डीआरपी साध्या आणि मूक सूचना असाव्यात. ग्राहकांनी सेवा पुनर्संचयित केल्यानंतरच सर्व जटिल निदान. जरी ते स्टँडबाय वर असले तरीही.
DRP मध्ये मुख्य फोन नंबर आणि संपर्कांची यादी करा.
डीआरपी समजून घेण्यासाठी कर्मचाऱ्यांची नियमित चाचणी घ्या.
उत्पादनावर नियोजित अपघातांची व्यवस्था करा. स्टँड सर्वकाही बदलू शकत नाही.

स्त्रोत: www.habr.com

डीआरपी तयार करत आहे - उल्का लक्षात घेण्यास विसरू नका