ഡിആർപി തയ്യാറാക്കുന്നു - ഉൽക്കാശില കണക്കിലെടുക്കാൻ മറക്കരുത്

ഒരു ദുരന്തസമയത്ത് പോലും ഒരു കപ്പ് ചായയ്ക്ക് എപ്പോഴും സമയമുണ്ട്

ഡി.ആർ.പി. (ഡിസാസ്റ്റർ റിക്കവറി പ്ലാൻ) എന്നത് ഒരിക്കലും ആവശ്യമില്ലാത്ത ഒരു കാര്യമാണ്. എന്നാൽ ഇണചേരൽ സമയത്ത് പെട്ടെന്ന് കുടിയേറുന്ന കൊക്കുകൾ നട്ടെല്ല് ഒപ്റ്റിക്കൽ ഫൈബറിലൂടെ കടിച്ചുകീറുകയോ അല്ലെങ്കിൽ ഒരു ജൂനിയർ അഡ്മിൻ ഉൽപ്പാദനക്ഷമമായ അടിത്തറ കുറയ്ക്കുകയോ ചെയ്താൽ, ഈ നാണക്കേടുമായി എന്തുചെയ്യണമെന്ന് മുൻകൂട്ടി തയ്യാറാക്കിയ പ്ലാൻ നിങ്ങൾക്കുണ്ടാകുമെന്ന് നിങ്ങൾ ഉറപ്പായും ആഗ്രഹിക്കുന്നു.

പരിഭ്രാന്തരായ ഉപഭോക്താക്കൾ സാങ്കേതിക പിന്തുണാ ഫോണുകൾ കട്ട് ചെയ്യാൻ തുടങ്ങുമ്പോൾ, ജൂനിയർ സയനൈഡിനായി തിരയുന്നു, നിങ്ങൾ വിവേകത്തോടെ ചുവന്ന കവർ തുറന്ന് എല്ലാം ക്രമീകരിക്കാൻ തുടങ്ങുന്നു.

ഈ പോസ്റ്റിൽ ഒരു ഡിആർപി എങ്ങനെ എഴുതാമെന്നും അതിൽ എന്തൊക്കെ അടങ്ങിയിരിക്കണം എന്നതിനെക്കുറിച്ചും ശുപാർശകൾ പങ്കിടാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ഇനിപ്പറയുന്ന കാര്യങ്ങളും ഞങ്ങൾ പരിശോധിക്കും:

1. വില്ലനെപ്പോലെ ചിന്തിക്കാൻ പഠിക്കാം.
2. അപ്പോക്കലിപ്സ് സമയത്ത് ഒരു കപ്പ് ചായയുടെ ഗുണങ്ങൾ നോക്കാം.
3. സൗകര്യപ്രദമായ ഒരു ഡിആർപി ഘടനയെക്കുറിച്ച് നമുക്ക് ചിന്തിക്കാം
4. ഇത് എങ്ങനെ പരീക്ഷിക്കാമെന്ന് നോക്കാം

ഏത് കമ്പനികൾക്ക് ഇത് ഉപയോഗപ്രദമാകും?

ഐടി വകുപ്പിന് അത്തരം കാര്യങ്ങൾ ആവശ്യമായി വരുമ്പോൾ വര വരയ്ക്കുക എന്നത് വളരെ ബുദ്ധിമുട്ടാണ്. ഇനിപ്പറയുന്നവയാണെങ്കിൽ നിങ്ങൾക്ക് തീർച്ചയായും DRP ആവശ്യമാണെന്ന് ഞാൻ പറയും:

• ഒരു സെർവറോ ആപ്ലിക്കേഷനോ നിർത്തുകയോ ചില ഡാറ്റാബേസ് നഷ്ടപ്പെടുകയോ ചെയ്യുന്നത് ബിസിനസ്സിന് മൊത്തത്തിൽ കാര്യമായ നഷ്ടത്തിലേക്ക് നയിക്കും.
• നിങ്ങൾക്ക് ഒരു സമ്പൂർണ്ണ ഐടി വകുപ്പുണ്ട്. കമ്പനിയുടെ ഒരു സമ്പൂർണ്ണ യൂണിറ്റിന്റെ രൂപത്തിൽ ഒരു വകുപ്പിന്റെ അർത്ഥത്തിൽ, സ്വന്തം ബജറ്റ്, മാത്രമല്ല ക്ഷീണിതരായ കുറച്ച് ജീവനക്കാർ ഒരു നെറ്റ്‌വർക്ക് സ്ഥാപിക്കുകയും വൈറസുകൾ വൃത്തിയാക്കുകയും പ്രിന്ററുകൾ വീണ്ടും നിറയ്ക്കുകയും ചെയ്യുന്നു.
• അടിയന്തിര സാഹചര്യങ്ങളിൽ ഭാഗികമായെങ്കിലും ഒഴിവാക്കുന്നതിന് നിങ്ങൾക്ക് ഒരു യഥാർത്ഥ ബജറ്റ് ഉണ്ട്.

ബാക്കപ്പുകൾക്കായി ഒരു പഴയ സെർവറിലേക്ക് കുറഞ്ഞത് രണ്ട് HDD-കൾക്കായി ഐടി വകുപ്പ് മാസങ്ങളായി യാചിക്കുമ്പോൾ, റിസർവ് ശേഷിക്കായി ഒരു പരാജയപ്പെട്ട സേവനത്തിന്റെ പൂർണ്ണമായ നീക്കം സംഘടിപ്പിക്കാൻ നിങ്ങൾക്ക് സാധ്യതയില്ല. ഇവിടെ ഡോക്യുമെന്റേഷൻ അതിരുകടന്നതായിരിക്കില്ലെങ്കിലും.

ഡോക്യുമെന്റേഷൻ പ്രധാനമാണ്

ഡോക്യുമെന്റേഷൻ ഉപയോഗിച്ച് ആരംഭിക്കുക. മൂന്ന് തലമുറകൾക്ക് മുമ്പ് അഡ്മിൻമാർ എഴുതിയ ഒരു പേൾ സ്‌ക്രിപ്റ്റിലാണ് നിങ്ങളുടെ സേവനം പ്രവർത്തിക്കുന്നത് എന്ന് പറയട്ടെ, പക്ഷേ അത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ആർക്കും അറിയില്ല. കുമിഞ്ഞുകൂടിയ സാങ്കേതിക കടവും ഡോക്യുമെന്റേഷന്റെ അഭാവവും അനിവാര്യമായും നിങ്ങളെ കാൽമുട്ടിൽ മാത്രമല്ല, മറ്റ് അവയവങ്ങളിലും വെടിവയ്ക്കും, ഇത് സമയത്തിന്റെ കാര്യമാണ്.

സേവന ഘടകങ്ങളെ കുറിച്ച് നിങ്ങൾക്ക് ഒരു നല്ല വിവരണം ലഭിച്ചുകഴിഞ്ഞാൽ, അപകട സ്ഥിതിവിവരക്കണക്കുകൾ നോക്കുക. അവ മിക്കവാറും തികച്ചും സാധാരണമായിരിക്കും. ഉദാഹരണത്തിന്, നിങ്ങളുടെ ഡിസ്ക് കാലാകാലങ്ങളിൽ നിറയുന്നു, ഇത് സ്വമേധയാ വൃത്തിയാക്കുന്നത് വരെ നോഡ് പരാജയപ്പെടുന്നതിന് കാരണമാകുന്നു. അല്ലെങ്കിൽ ആരെങ്കിലും വീണ്ടും സർട്ടിഫിക്കറ്റ് പുതുക്കാൻ മറന്നുപോയതിനാലും Let's Encrypt-ന് കോൺഫിഗർ ചെയ്യാൻ കഴിയാതെ വന്നതിനാലോ ക്ലയന്റ് സേവനം ലഭ്യമല്ലാതാകുന്നു.

ഒരു അട്ടിമറിക്കാരനെപ്പോലെയുള്ള ചിന്തകൾ

മുമ്പൊരിക്കലും സംഭവിച്ചിട്ടില്ലാത്ത, എന്നാൽ നിങ്ങളുടെ സേവനം പൂർണ്ണമായും തകരാറിലായേക്കാവുന്ന അപകടങ്ങൾ പ്രവചിക്കുന്നതാണ് ഏറ്റവും ബുദ്ധിമുട്ടുള്ള ഭാഗം. ഇവിടെ ഞാനും എന്റെ സഹപ്രവർത്തകരും സാധാരണയായി വില്ലൻ വേഷങ്ങളാണ് ചെയ്യുന്നത്. ധാരാളം കാപ്പിയും രുചികരമായ എന്തെങ്കിലും എടുത്ത് ഒരു മീറ്റിംഗ് റൂമിൽ സ്വയം പൂട്ടുക. ടാർഗെറ്റ് സേവനം സ്വയം വികസിപ്പിച്ചെടുത്ത അല്ലെങ്കിൽ പതിവായി പ്രവർത്തിക്കുന്ന എഞ്ചിനീയർമാരെ അതേ ചർച്ചകളിൽ നിങ്ങൾ ലോക്ക് ചെയ്യുന്നുവെന്ന് ഉറപ്പാക്കുക. തുടർന്ന്, ഒന്നുകിൽ ബോർഡിലോ പേപ്പറിലോ, നിങ്ങളുടെ സേവനത്തിന് സംഭവിക്കാവുന്ന എല്ലാ ഭീകരതകളും നിങ്ങൾ വരയ്ക്കാൻ തുടങ്ങുന്നു. ഒരു പ്രത്യേക ക്ലീനിംഗ് ലേഡിയിലേക്ക് വിശദമായി പോയി കേബിളുകൾ പുറത്തെടുക്കേണ്ട ആവശ്യമില്ല; "പ്രാദേശിക നെറ്റ്‌വർക്കിന്റെ സമഗ്രതയുടെ ലംഘനം" എന്ന രംഗം പരിഗണിച്ചാൽ മതി.

സാധാരണഗതിയിൽ, ഏറ്റവും സാധാരണമായ അടിയന്തര സാഹചര്യങ്ങൾ ഇനിപ്പറയുന്ന തരത്തിൽ ഉൾപ്പെടുന്നു:

• നെറ്റ്‌വർക്ക് പരാജയം
• OS സേവനങ്ങളുടെ പരാജയം
• ആപ്ലിക്കേഷൻ പരാജയം
• ഇരുമ്പ് പരാജയം
• വെർച്വലൈസേഷൻ പരാജയം

ഓരോ തരത്തിലും പോയി നിങ്ങളുടെ സേവനത്തിന് എന്താണ് ബാധകമെന്ന് കാണുക. ഉദാഹരണത്തിന്, Nginx ഡെമൺ വീഴുകയും ഉയരാതിരിക്കുകയും ചെയ്യാം - ഇതിനർത്ഥം OS- ന്റെ ഭാഗത്തെ പരാജയങ്ങൾ എന്നാണ്. നിങ്ങളുടെ വെബ് ആപ്ലിക്കേഷൻ പരാജയപ്പെടുന്നതിന് കാരണമാകുന്ന ഒരു അപൂർവ സാഹചര്യം ഒരു സോഫ്റ്റ്വെയർ പരാജയമാണ്. ഈ ഘട്ടത്തിൽ പ്രവർത്തിക്കുമ്പോൾ, പ്രശ്നത്തിന്റെ രോഗനിർണയം നടത്തേണ്ടത് പ്രധാനമാണ്. വീണുപോയ സിസ് ഡ്രൈവിൽ നിന്നും നെറ്റ്‌വർക്ക് പരാജയത്തിൽ നിന്നും വിർച്ച്വലൈസേഷനിൽ ഫ്രീസുചെയ്‌ത ഇന്റർഫേസിനെ എങ്ങനെ വേർതിരിക്കാം, ഉദാഹരണത്തിന്. ഉത്തരവാദികളെ പെട്ടെന്ന് കണ്ടെത്തുന്നതിനും അപകടം പരിഹരിക്കപ്പെടുന്നതുവരെ അവരുടെ വാൽ വലിക്കാൻ തുടങ്ങുന്നതിനും ഇത് പ്രധാനമാണ്.

സാധാരണ പ്രശ്നങ്ങൾ എഴുതിയ ശേഷം, ഞങ്ങൾ കൂടുതൽ കോഫി ഒഴിച്ചു, ചില പാരാമീറ്ററുകൾ മാനദണ്ഡത്തിനപ്പുറത്തേക്ക് പോകാൻ തുടങ്ങുമ്പോൾ, വിചിത്രമായ സാഹചര്യങ്ങൾ പരിഗണിക്കാൻ തുടങ്ങുന്നു. ഉദാഹരണത്തിന്:

• സജീവ നോഡിലെ സമയം ക്ലസ്റ്ററിലെ മറ്റുള്ളവരുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഒരു മിനിറ്റ് പിന്നോട്ട് നീങ്ങിയാൽ എന്ത് സംഭവിക്കും?
• കാലം മുന്നോട്ട് പോയാലോ, 10 വർഷം കൊണ്ടാലോ?
• സിൻക്രൊണൈസേഷൻ സമയത്ത് ഒരു ക്ലസ്റ്റർ നോഡിന് പെട്ടെന്ന് നെറ്റ്‌വർക്ക് നഷ്ടപ്പെട്ടാൽ എന്ത് സംഭവിക്കും?
• നെറ്റ്‌വർക്കിൽ പരസ്പരം താൽക്കാലികമായി ഒറ്റപ്പെടൽ കാരണം രണ്ട് നോഡുകൾ നേതൃത്വം പങ്കിടുന്നില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

ഈ ഘട്ടത്തിൽ, വിപരീത സമീപനം വളരെ സഹായകരമാണ്. നിങ്ങൾ ടീമിലെ ഏറ്റവും ധാർഷ്ട്യമുള്ള അംഗത്തെ രോഗബാധിതനായ ഭാവനയോടെ എടുത്ത്, ചുരുങ്ങിയ സമയത്തിനുള്ളിൽ ഒരു അട്ടിമറി സംഘടിപ്പിക്കാനുള്ള ചുമതല അവനു നൽകുക, അത് സേവനത്തെ തകർക്കും. രോഗനിർണയം ബുദ്ധിമുട്ടാണെങ്കിൽ, ഇതിലും മികച്ചതാണ്. എന്തെങ്കിലും തകർക്കാൻ നിങ്ങൾ അവർക്ക് ഒരു ആശയം നൽകിയാൽ എഞ്ചിനീയർമാർ കൊണ്ടുവരുന്ന വിചിത്രവും രസകരവുമായ ആശയങ്ങൾ നിങ്ങൾ വിശ്വസിക്കില്ല. ഇതിനായി നിങ്ങൾ അവർക്ക് ഒരു ടെസ്റ്റ് ബെഞ്ച് വാഗ്ദാനം ചെയ്താൽ, അത് തികച്ചും നല്ലതാണ്.

എന്താണ് നിങ്ങളുടെ ഈ DRP?!

അതിനാൽ നിങ്ങളുടെ ഭീഷണി മോഡൽ നിങ്ങൾ നിർവചിച്ചു. ചെമ്പ് തേടി ഫൈബർ ഒപ്റ്റിക് കേബിളുകൾ മുറിക്കുന്ന പ്രദേശവാസികളെയും വെള്ളിയാഴ്ചകളിൽ 16:46 ന് റേഡിയോ റിലേ ലൈൻ ഡ്രോപ്പ് ചെയ്യുന്ന ഒരു സൈനിക റഡാറും അവർ കണക്കിലെടുത്തിട്ടുണ്ട്. ഇതെല്ലാം എന്തുചെയ്യണമെന്ന് ഇപ്പോൾ നമ്മൾ മനസ്സിലാക്കേണ്ടതുണ്ട്.

അടിയന്തരാവസ്ഥയിൽ തുറക്കുന്ന ചുവന്ന എൻവലപ്പുകൾ എഴുതുക എന്നതാണ് നിങ്ങളുടെ ചുമതല. (എങ്കിലല്ല!) എല്ലാം അവസാനിക്കുമ്പോൾ, ഏറ്റവും അനുഭവപരിചയമില്ലാത്ത ഇന്റേൺ മാത്രമേ സമീപത്തുണ്ടാകൂ, എന്താണ് സംഭവിക്കുന്നതെന്ന ഭയാനകതയിൽ നിന്ന് കൈകൾ ശക്തമായി വിറയ്ക്കുമെന്ന് ഉടനടി പ്രതീക്ഷിക്കുക. മെഡിക്കൽ ഓഫീസുകളിൽ എമർജൻസി സിഗ്നലുകൾ എങ്ങനെയാണ് നടപ്പിലാക്കുന്നതെന്ന് കാണുക. ഉദാഹരണത്തിന്, അനാഫൈലക്റ്റിക് ഷോക്ക് ഉണ്ടായാൽ എന്തുചെയ്യണം. മെഡിക്കൽ സ്റ്റാഫിന് എല്ലാ പ്രോട്ടോക്കോളുകളും ഹൃദ്യമായി അറിയാം, എന്നാൽ സമീപത്തുള്ള ഒരാൾ മരിക്കാൻ തുടങ്ങുമ്പോൾ, മിക്കപ്പോഴും എല്ലാവരും നിസ്സഹായരായി കാണുന്നതെല്ലാം മുറുകെ പിടിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, "അത്തരത്തിലുള്ളവയുടെ പാക്കേജ് തുറക്കുക", "മരുന്നിന്റെ നിരവധി യൂണിറ്റുകൾ ഇൻട്രാവെൻസായി നൽകുക" തുടങ്ങിയ ഇനങ്ങളുള്ള വ്യക്തമായ നിർദ്ദേശങ്ങൾ ചുമരിൽ ഉണ്ട്.

അടിയന്തരാവസ്ഥയിൽ ചിന്തിക്കാൻ പ്രയാസമാണ്! സുഷുമ്നാ പാഴ്സിംഗിന് ലളിതമായ നിർദ്ദേശങ്ങൾ ഉണ്ടായിരിക്കണം.

ഒരു നല്ല DRP നിരവധി ലളിതമായ ബ്ലോക്കുകൾ ഉൾക്കൊള്ളുന്നു:

1. ഒരു അപകടത്തിന്റെ തുടക്കത്തെക്കുറിച്ച് ആരെ അറിയിക്കണം. എലിമിനേഷൻ പ്രക്രിയ കഴിയുന്നത്ര സമാന്തരമാക്കുന്നതിന് ഇത് പ്രധാനമാണ്.
2. എങ്ങനെ ശരിയായി രോഗനിർണയം നടത്താം - ഒരു ട്രെയ്സ് നടത്തുക, systemctl സ്റ്റാറ്റസ് സേവനനാമം നോക്കുക തുടങ്ങിയവ.
3. ഓരോ ഘട്ടത്തിലും നിങ്ങൾക്ക് എത്ര സമയം ചെലവഴിക്കാനാകും? SLA സമയത്തിനുള്ളിൽ ഇത് സ്വമേധയാ ശരിയാക്കാൻ നിങ്ങൾക്ക് സമയമില്ലെങ്കിൽ, വെർച്വൽ മെഷീൻ കൊല്ലപ്പെടുകയും ഇന്നലത്തെ ബാക്കപ്പിൽ നിന്ന് പിൻവാങ്ങുകയും ചെയ്യും.
4. അപകടം അവസാനിച്ചുവെന്ന് എങ്ങനെ ഉറപ്പാക്കാം.

സേവനം പൂർണ്ണമായും പരാജയപ്പെടുമ്പോൾ DRP ആരംഭിക്കുകയും സേവനം പുനഃസ്ഥാപിക്കുമ്പോൾ അവസാനിക്കുകയും ചെയ്യുന്നു, കുറഞ്ഞ കാര്യക്ഷമതയിൽ പോലും. കേവലം ഒരു റിസർവേഷൻ നഷ്‌ടപ്പെടുന്നത് DRP-യെ ട്രിഗർ ചെയ്യാൻ പാടില്ല. നിങ്ങൾക്ക് ഡിആർപിയിൽ ഒരു കപ്പ് ചായയും എഴുതാം. ഗൗരവമായി. സ്ഥിതിവിവരക്കണക്കുകൾ പ്രകാരം, പല അപകടങ്ങളും അസുഖകരമായതിൽ നിന്ന് ദുരന്തത്തിലേക്ക് മാറുന്നു, കാരണം പരിഭ്രാന്തരായ ജീവനക്കാർ എന്തെങ്കിലും ശരിയാക്കാൻ തിരക്കുകൂട്ടുന്നു, ഒരേസമയം ഡാറ്റയുള്ള ഒരേയൊരു ലിവിംഗ് നോഡിനെ കൊല്ലുന്നു അല്ലെങ്കിൽ ഒടുവിൽ ക്ലസ്റ്റർ അവസാനിപ്പിക്കുന്നു. ചട്ടം പോലെ, ഒരു കപ്പ് ചായ ഉപയോഗിച്ച് 5 മിനിറ്റ് ശാന്തമാക്കാനും എന്താണ് സംഭവിക്കുന്നതെന്ന് വിശകലനം ചെയ്യാനും കുറച്ച് സമയം നൽകും.

ഡിആർപിയും സിസ്റ്റം പാസ്‌പോർട്ടും ആശയക്കുഴപ്പത്തിലാക്കരുത്! അനാവശ്യ ഡാറ്റ ഉപയോഗിച്ച് ഇത് ഓവർലോഡ് ചെയ്യരുത്. ഡോക്യുമെന്റേഷന്റെ ആവശ്യമുള്ള വിഭാഗത്തിലേക്ക് പോകുന്നതിനും സേവന ആർക്കിടെക്ചറിന്റെ ആവശ്യമായ വിഭാഗങ്ങളെക്കുറിച്ച് വിപുലീകരിച്ച ഫോർമാറ്റിൽ വായിക്കുന്നതിനും ഹൈപ്പർലിങ്കുകൾ വേഗത്തിലും സൗകര്യപ്രദമായും ഉപയോഗിക്കുന്നത് സാധ്യമാക്കുക. ഡിആർപിയിൽ തന്നെ കോപ്പി-പേസ്റ്റിനുള്ള പ്രത്യേക കമാൻഡുകളുമായി എവിടെ, എങ്ങനെ ബന്ധിപ്പിക്കണം എന്നതിനെക്കുറിച്ചുള്ള നേരിട്ടുള്ള നിർദ്ദേശങ്ങൾ മാത്രമേയുള്ളൂ.

എങ്ങനെ ശരിയായി പരിശോധിക്കാം

ഉത്തരവാദിത്തമുള്ള ഏതൊരു ജീവനക്കാരനും എല്ലാ ഇനങ്ങളും പൂർത്തിയാക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കുക. ഏറ്റവും നിർണായക നിമിഷത്തിൽ, ആവശ്യമായ സിസ്റ്റം ആക്‌സസ് ചെയ്യാൻ എഞ്ചിനീയർക്ക് അവകാശമില്ല, ആവശ്യമായ അക്കൗണ്ടിന് പാസ്‌വേഡുകളൊന്നുമില്ല, അല്ലെങ്കിൽ "സേവന മാനേജുമെന്റ് കൺസോളിലേക്ക് ഒരു പ്രോക്സി വഴി കണക്റ്റുചെയ്യുന്നത് എന്താണെന്ന് അദ്ദേഹത്തിന് അറിയില്ല. ഹെഡ് ഓഫീസ്" എന്നർത്ഥം. ഓരോ പോയിന്റും വളരെ ലളിതമായിരിക്കണം.

തെറ്റാണ് — “വെർച്വലൈസേഷനിലേക്ക് പോയി ഡെഡ് നോഡ് റീബൂട്ട് ചെയ്യുക”
ശരിയായി - "വെബ് ഇന്റർഫേസ് വഴി virt.example.com-ലേക്ക് കണക്റ്റുചെയ്യുക, നോഡുകൾ വിഭാഗത്തിൽ, പിശകിന് കാരണമാകുന്ന നോഡ് റീബൂട്ട് ചെയ്യുക."

അവ്യക്തത ഒഴിവാക്കുക. പേടിച്ചരണ്ട ഇന്റേണിനെ ഓർക്കുക.

ഡിആർപി പരീക്ഷിക്കുന്നത് ഉറപ്പാക്കുക. ഇത് കേവലം പ്രദർശനത്തിനുള്ള ഒരു പദ്ധതിയല്ല - ഇത് നിങ്ങളെയും നിങ്ങളുടെ ക്ലയന്റിനെയും ഒരു നിർണായക സാഹചര്യത്തിൽ നിന്ന് വേഗത്തിൽ കരകയറ്റാൻ അനുവദിക്കുന്ന ഒന്നാണ്. ഇത് നിരവധി തവണ ചെയ്യുന്നതാണ് നല്ലത്:

• ഒരു വിദഗ്ധനും നിരവധി ട്രെയിനികളും ഒരു ടെസ്റ്റ് ബെഞ്ചിൽ പ്രവർത്തിക്കുന്നു, അത് കഴിയുന്നത്ര യഥാർത്ഥ സേവനം അനുകരിക്കുന്നു. വിദഗ്‌ദ്ധൻ സേവനത്തെ വിവിധ രീതികളിൽ തകർക്കുകയും ഡിആർപി അനുസരിച്ച് അത് പുനഃസ്ഥാപിക്കാൻ ട്രെയിനികളെ പ്രാപ്തരാക്കുകയും ചെയ്യുന്നു. എല്ലാ പ്രശ്നങ്ങളും ഡോക്യുമെന്റേഷൻ അവ്യക്തതയും പിശകുകളും രേഖപ്പെടുത്തുന്നു. ട്രെയിനികളെ പരിശീലിപ്പിച്ച ശേഷം, വ്യക്തമല്ലാത്ത സ്ഥലങ്ങളിൽ ഡിആർപി വിപുലീകരിക്കുകയും ലളിതമാക്കുകയും ചെയ്യുന്നു.
• ഒരു യഥാർത്ഥ സേവനത്തിൽ പരീക്ഷിക്കുന്നു. വാസ്തവത്തിൽ, നിങ്ങൾക്ക് ഒരിക്കലും ഒരു യഥാർത്ഥ സേവനത്തിന്റെ മികച്ച പകർപ്പ് സൃഷ്ടിക്കാൻ കഴിയില്ല. അതിനാൽ, വീണ്ടെടുക്കൽ ഓർഡർ വിലയിരുത്തുന്നതിന് വർഷത്തിൽ രണ്ട് തവണ പതിവായി ചില സെർവറുകൾ ഓഫ് ചെയ്യുകയും കണക്ഷനുകൾ വിച്ഛേദിക്കുകയും ഭീഷണികളുടെ പട്ടികയിൽ നിന്ന് മറ്റ് ദുരന്തങ്ങൾ ഉണ്ടാക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്. ഡേറ്റാ നഷ്‌ടത്തോടുകൂടിയ പീക്ക് ലോഡിൽ മണിക്കൂറുകളോളം പെട്ടെന്നുള്ള പരാജയത്തേക്കാൾ നല്ലത് അർദ്ധരാത്രിയിൽ 10 മിനിറ്റ് നേരത്തേക്ക് ആസൂത്രണം ചെയ്ത പരാജയമാണ്.
• യഥാർത്ഥ ട്രബിൾഷൂട്ടിംഗ്. അതെ, ഇതും പരിശോധനയുടെ ഭാഗമാണ്. ഭീഷണികളുടെ പട്ടികയിൽ ഇല്ലാതിരുന്ന ഒരു അപകടം സംഭവിച്ചാൽ, അതിന്റെ അന്വേഷണത്തിന്റെ ഫലത്തെ അടിസ്ഥാനമാക്കി ഡിആർപി സപ്ലിമെന്റ് ചെയ്യുകയും അന്തിമമാക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്.

പ്രധാന പോയിന്റുകൾ

1. ചീത്ത സംഭവിക്കാമെങ്കിൽ, അത് സംഭവിക്കുക മാത്രമല്ല, സാധ്യമായ ഏറ്റവും വിനാശകരമായ സാഹചര്യത്തിൽ അത് ചെയ്യും.
2. അടിയന്തര ലോഡ് ട്രാൻസ്ഫറിനുള്ള ഉറവിടങ്ങൾ നിങ്ങളുടെ പക്കലുണ്ടെന്ന് ഉറപ്പാക്കുക.
3. നിങ്ങൾക്ക് ബാക്കപ്പുകൾ ഉണ്ടെന്ന് ഉറപ്പാക്കുക, അവ യാന്ത്രികമായി സൃഷ്ടിക്കപ്പെടുകയും സ്ഥിരതയ്ക്കായി പതിവായി പരിശോധിക്കുകയും ചെയ്യുന്നു.
4. സാധാരണ ഭീഷണി സാഹചര്യങ്ങളിലൂടെ ചിന്തിക്കുക.
5. സേവനം നൽകുന്നതിന് നിലവാരമില്ലാത്ത ഓപ്ഷനുകൾ കൊണ്ടുവരാൻ എഞ്ചിനീയർമാർക്ക് അവസരം നൽകുക.
6. DRP ലളിതവും മൂർച്ചയുള്ളതുമായ നിർദ്ദേശമായിരിക്കണം. ക്ലയന്റുകളുടെ സേവനം പുനഃസ്ഥാപിച്ചതിന് ശേഷം മാത്രമാണ് എല്ലാ സങ്കീർണ്ണമായ ഡയഗ്നോസ്റ്റിക്സും നടപ്പിലാക്കുന്നത്. കരുതൽ ശേഷിയിലാണെങ്കിൽ പോലും.
7. ഡിആർപിയിൽ പ്രധാന ഫോൺ നമ്പറുകളും കോൺടാക്റ്റുകളും നൽകുക.
8. ഡിആർപിയെക്കുറിച്ചുള്ള ജീവനക്കാരുടെ ധാരണ പതിവായി പരിശോധിക്കുക.
9. പ്രൊഡക്ഷൻ സൈറ്റുകളിൽ ആസൂത്രിതമായ അപകടങ്ങൾ ക്രമീകരിക്കുക. സ്റ്റാൻഡുകൾക്ക് എല്ലാം മാറ്റിസ്ഥാപിക്കാൻ കഴിയില്ല.

അവലംബം: www.habr.com