ການ ກະ ກຽມ DRP - ບໍ່ ລືມ ທີ່ ຈະ ເຂົ້າ ໄປ ໃນ ບັນ ຊີ ຂອງ meteorite ໄດ້

ເຖິງແມ່ນວ່າໃນໄລຍະໄພພິບັດມີເວລາສໍາລັບຈອກຊາສະເຫມີ

DRP (ແຜນການຟື້ນຟູໄພພິບັດ) ແມ່ນສິ່ງທີ່ແນ່ນອນຈະບໍ່ຈໍາເປັນ. ແຕ່ຖ້າ beavers ເຄື່ອນຍ້າຍຢ່າງກະທັນຫັນໃນລະຫວ່າງລະດູການຫາຄູ່ gnaw ຜ່ານເສັ້ນໄຍ optical ກະດູກສັນຫຼັງຫຼື admin junior ຫຼຸດລົງພື້ນຖານການຜະລິດ, ທ່ານແນ່ນອນຕ້ອງການໃຫ້ແນ່ໃຈວ່າທ່ານຈະມີແຜນການທີ່ສ້າງຂຶ້ນກ່ອນສໍາລັບສິ່ງທີ່ຈະເຮັດກັບຄວາມອັບອາຍທັງຫມົດນີ້.

ໃນຂະນະທີ່ລູກຄ້າຕົກໃຈເລີ່ມຕັດໂທລະສັບສະຫນັບສະຫນູນດ້ານວິຊາການ, junior ກໍາລັງຊອກຫາ cyanide, ທ່ານສະຫລາດເປີດ envelope ສີແດງແລະເລີ່ມຈັດວາງທຸກສິ່ງທຸກຢ່າງເປັນລະບຽບ.

ໃນບົດຂຽນນີ້, ຂ້ອຍຢາກແບ່ງປັນຄໍາແນະນໍາກ່ຽວກັບວິທີການຂຽນ DRP ແລະສິ່ງທີ່ມັນຄວນຈະມີ. ພວກເຮົາຍັງຈະເບິ່ງສິ່ງຕໍ່ໄປນີ້:

1. ໃຫ້ເຮົາຮຽນຮູ້ທີ່ຈະຄິດຄືກັບຄົນຮ້າຍ.
2. ໃຫ້ເບິ່ງຜົນປະໂຫຍດຂອງຈອກຊາໃນໄລຍະ apocalypse ໄດ້.
3. ໃຫ້ຄິດຂ້າມໂຄງສ້າງ DRP ທີ່ສະດວກ
4. ໃຫ້ເບິ່ງວິທີການທົດສອບມັນ

ບໍລິສັດໃດອາດຈະເປັນປະໂຫຍດ?

ມັນເປັນການຍາກຫຼາຍທີ່ຈະແຕ້ມເສັ້ນໃນເວລາທີ່ພະແນກ IT ເລີ່ມຕ້ອງການສິ່ງດັ່ງກ່າວ. ຂ້ອຍຈະເວົ້າວ່າເຈົ້າຕ້ອງການ DRP ແນ່ນອນຖ້າ:

• ການຢຸດເຊົາເຄື່ອງແມ່ຂ່າຍ, ຄໍາຮ້ອງສະຫມັກຫຼືການສູນເສຍຖານຂໍ້ມູນບາງຢ່າງຈະນໍາໄປສູ່ການສູນເສຍທີ່ສໍາຄັນສໍາລັບທຸລະກິດທັງຫມົດ.
• ເຈົ້າມີພະແນກໄອທີຄົບວົງຈອນ. ໃນຄວາມຮູ້ສຶກຂອງພະແນກໃນຮູບແບບຂອງຫນ່ວຍງານທີ່ເຕັມໄປດ້ວຍບໍລິສັດ, ມີງົບປະມານຂອງຕົນເອງ, ແລະບໍ່ພຽງແຕ່ພະນັກງານທີ່ເມື່ອຍລ້າຈໍານວນຫນ້ອຍທີ່ວາງເຄືອຂ່າຍ, ເຮັດຄວາມສະອາດໄວຣັສແລະການເຕີມເງິນເຄື່ອງພິມ.
• ທ່ານມີງົບປະມານທີ່ແທ້ຈິງສໍາລັບການຊໍ້າຊ້ອນຢ່າງຫນ້ອຍບາງສ່ວນໃນກໍລະນີຂອງການສຸກເສີນ.

ໃນເວລາທີ່ພະແນກ IT ໄດ້ຂໍທານມາເປັນເວລາຫຼາຍເດືອນສໍາລັບຢ່າງຫນ້ອຍສອງສາມ HDDs ເຂົ້າໄປໃນເຄື່ອງແມ່ຂ່າຍເກົ່າສໍາລັບການສໍາຮອງຂໍ້ມູນ, ທ່ານບໍ່ຫນ້າຈະຈັດການການເຄື່ອນໄຫວຢ່າງເຕັມທີ່ຂອງການບໍລິການທີ່ລົ້ມເຫລວເພື່ອສະຫງວນຄວາມສາມາດ. ເຖິງແມ່ນວ່າໃນທີ່ນີ້ເອກະສານຈະບໍ່ superfluous.

ເອກະສານແມ່ນສໍາຄັນ

ເລີ່ມຕົ້ນດ້ວຍເອກະສານ. ສົມມຸດວ່າການບໍລິການຂອງເຈົ້າເຮັດວຽກຢູ່ໃນສະຄິບ Perl ທີ່ຖືກຂຽນໄວ້ສາມລຸ້ນຂອງ admins ກ່ອນຫນ້ານີ້, ແລະບໍ່ມີໃຜຮູ້ວ່າມັນເຮັດວຽກແນວໃດ. ຫນີ້ສິນດ້ານວິຊາການສະສົມແລະການຂາດເອກະສານ inevitably ຈະຍິງທ່ານບໍ່ພຽງແຕ່ຢູ່ໃນຫົວເຂົ່າ, ແຕ່ຍັງຢູ່ໃນປີກອື່ນໆ, ມັນເປັນເລື່ອງຂອງເວລາ.

ເມື່ອທ່ານມີລາຍລະອຽດທີ່ດີຂອງອົງປະກອບການບໍລິການຢູ່ໃນມື, ຍົກສູງສະຖິຕິອຸປະຕິເຫດ. ພວກເຂົາເຈົ້າເກືອບແນ່ນອນວ່າຈະເປັນແບບປົກກະຕິຢ່າງສົມບູນ. ຕົວຢ່າງ, ທ່ານມີແຜ່ນເຕັມເປັນບາງເວລາ, ເຊິ່ງເຮັດໃຫ້ node ລົ້ມເຫລວຈົນກ່ວາມັນຖືກເຮັດຄວາມສະອາດດ້ວຍຕົນເອງ. ຫຼືການບໍລິການລູກຄ້າກາຍເປັນບໍ່ສາມາດໃຊ້ໄດ້ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າຄົນອື່ນລືມຕໍ່ອາຍຸໃບຢັ້ງຢືນ, ແຕ່ລາວບໍ່ສາມາດຫຼືບໍ່ຕ້ອງການຕັ້ງຄ່າ Let's Encrypt.

ຄວາມຄິດຄືຄົນຮ້າຍ

ພາກສ່ວນທີ່ຍາກທີ່ສຸດແມ່ນໃນການຄາດຄະເນອຸປະຕິເຫດທີ່ບໍ່ເຄີຍເກີດຂຶ້ນມາກ່ອນ, ແຕ່ວ່າອາດຈະເຮັດໃຫ້ການບໍລິການຂອງທ່ານເສຍຫາຍຢ່າງສົມບູນ. ທີ່ນີ້ເພື່ອນຮ່ວມງານຂອງຂ້ອຍແລະຂ້ອຍມັກຈະຫຼີ້ນຄົນຮ້າຍ. ເອົາກາເຟຫຼາຍໆອັນ ແລະບາງອັນແຊບໆ ແລະ ລັອກຕົວເອງຢູ່ໃນຫ້ອງປະຊຸມ. ພຽງແຕ່ໃຫ້ແນ່ໃຈວ່າໃນການເຈລະຈາດຽວກັນທ່ານລັອກໃນວິສະວະກອນເຫຼົ່ານັ້ນທີ່ຕົນເອງພັດທະນາການບໍລິການເປົ້າຫມາຍຫຼືເຮັດວຽກເປັນປົກກະຕິກັບມັນ. ຫຼັງຈາກນັ້ນ, ບໍ່ວ່າຈະຢູ່ໃນກະດານຫຼືໃນເຈ້ຍ, ທ່ານເລີ່ມແຕ້ມສິ່ງທີ່ຫນ້າຢ້ານທີ່ເປັນໄປໄດ້ທັງຫມົດທີ່ອາດຈະເກີດຂື້ນກັບການບໍລິການຂອງທ່ານ. ມັນບໍ່ຈໍາເປັນທີ່ຈະເຂົ້າໄປໃນລາຍລະອຽດຂອງແມ່ຍິງທໍາຄວາມສະອາດສະເພາະແລະດຶງສາຍອອກ; ມັນພຽງພໍທີ່ຈະພິຈາລະນາສະຖານະການຂອງ "ການລະເມີດຄວາມສົມບູນຂອງເຄືອຂ່າຍທ້ອງຖິ່ນ."

ໂດຍປົກກະຕິ, ສະຖານະການສຸກເສີນທົ່ວໄປສ່ວນໃຫຍ່ຕົກຢູ່ໃນປະເພດຕໍ່ໄປນີ້:

• ເຄືອຂ່າຍລົ້ມເຫຼວ
• ການບໍລິການ OS ລົ້ມເຫລວ
• ແອັບພລິເຄຊັນລົ້ມເຫລວ
• ຄວາມລົ້ມເຫຼວຂອງທາດເຫຼັກ
• Virtualization ລົ້ມເຫລວ

ພຽງແຕ່ຜ່ານແຕ່ລະປະເພດແລະເບິ່ງສິ່ງທີ່ນໍາໃຊ້ກັບການບໍລິການຂອງທ່ານ. ຕົວຢ່າງ, Nginx daemon ອາດຈະຫຼຸດລົງແລະບໍ່ເພີ່ມຂຶ້ນ - ນີ້ຫມາຍຄວາມວ່າຄວາມລົ້ມເຫລວໃນສ່ວນຂອງ OS. ສະຖານະການທີ່ຫາຍາກທີ່ເຮັດໃຫ້ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ຂອງທ່ານລົ້ມເຫລວແມ່ນຄວາມລົ້ມເຫຼວຂອງຊອບແວ. ໃນຂະນະທີ່ເຮັດວຽກຜ່ານຂັ້ນຕອນນີ້, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຮັດວຽກອອກການວິນິດໄສຂອງບັນຫາ. ວິທີການຈໍາແນກການໂຕ້ຕອບ frozen ໃນ virtualization ຈາກໄດ cis ຫຼຸດລົງແລະອຸປະຕິເຫດເຄືອຂ່າຍ, ສໍາລັບການຍົກຕົວຢ່າງ. ນີ້ແມ່ນສິ່ງສໍາຄັນທີ່ຈະຊອກຫາຜູ້ທີ່ຮັບຜິດຊອບຢ່າງໄວວາແລະເລີ່ມຕົ້ນດຶງຫາງຂອງພວກເຂົາຈົນກ່ວາອຸປະຕິເຫດໄດ້ຮັບການແກ້ໄຂ.

ຫຼັງຈາກບັນຫາປົກກະຕິຖືກຂຽນລົງ, ພວກເຮົາຖອກກາເຟຫຼາຍຂື້ນແລະເລີ່ມພິຈາລະນາສະຖານະການທີ່ແປກປະຫຼາດທີ່ສຸດ, ເມື່ອບາງຕົວກໍານົດການເລີ່ມຕົ້ນໄປໄກກວ່າມາດຕະຖານ. ຍົກ​ຕົວ​ຢ່າງ:

• ຈະເກີດຫຍັງຂຶ້ນຖ້າເວລາຢູ່ໃນໂຫນດທີ່ເຄື່ອນໄຫວເຄື່ອນທີ່ກັບຄືນໄປເປັນນາທີທຽບກັບຄົນອື່ນໃນກຸ່ມ?
• ຖ້າເວລາກ້າວໄປຂ້າງຫນ້າ, ຈະເປັນແນວໃດຖ້າ 10 ປີ?
• ຈະເກີດຫຍັງຂຶ້ນຖ້າ node cluster ສູນເສຍເຄືອຂ່າຍຢ່າງກະທັນຫັນໃນລະຫວ່າງການ synchronization?
• ແລະຈະເກີດຫຍັງຂຶ້ນຖ້າສອງ nodes ບໍ່ແບ່ງປັນຄວາມເປັນຜູ້ນໍາເນື່ອງຈາກການໂດດດ່ຽວຊົ່ວຄາວຂອງກັນແລະກັນຜ່ານເຄືອຂ່າຍ?

ໃນຂັ້ນຕອນນີ້, ວິທີການປີ້ນກັບກັນແມ່ນມີປະໂຫຍດຫຼາຍ. ທ່ານເອົາສະມາຊິກທີ່ແຂງກະດ້າງທີ່ສຸດຂອງທີມງານທີ່ມີຈິນຕະນາການທີ່ເຈັບປ່ວຍແລະໃຫ້ລາວເຮັດວຽກໃນການຈັດຕັ້ງການລ່ວງລະເມີດໃນເວລາອັນສັ້ນທີ່ສຸດທີ່ຈະເຮັດໃຫ້ການບໍລິການຫຼຸດລົງ. ຖ້າມັນຍາກທີ່ຈະວິນິດໄສ, ດີກວ່າ. ເຈົ້າຈະບໍ່ເຊື່ອສິ່ງທີ່ນັກວິສະວະກອນມີຄວາມຄິດທີ່ແປກປະຫຼາດ ແລະ ຄັກໆ ຖ້າເຈົ້າໃຫ້ພວກເຂົາມີຄວາມຄິດທີ່ຈະທຳລາຍບາງສິ່ງບາງຢ່າງ. ແລະຖ້າທ່ານສັນຍາໃຫ້ພວກເຂົາເປັນບ່ອນທົດສອບສໍາລັບການນີ້, ມັນດີແທ້ໆ.

DRP ຂອງເຈົ້າແມ່ນຫຍັງ?

ດັ່ງນັ້ນທ່ານໄດ້ກໍານົດຮູບແບບໄພຂົ່ມຂູ່ຂອງທ່ານ. ພວກເຂົາເຈົ້າຍັງໄດ້ຄໍານຶງເຖິງຊາວທ້ອງຖິ່ນທີ່ຕັດສາຍໃຍແກ້ວນໍາແສງເພື່ອຊອກຫາທອງແດງ, ແລະ radar ທະຫານທີ່ຫຼຸດລົງສາຍ relay ວິທະຍຸຢ່າງເຂັ້ມງວດໃນວັນສຸກເວລາ 16: 46. ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງເຂົ້າໃຈສິ່ງທີ່ຕ້ອງເຮັດກັບສິ່ງທັງຫມົດນີ້.

ວຽກງານຂອງທ່ານແມ່ນເພື່ອຂຽນຊອງຈົດຫມາຍສີແດງຫຼາຍທີ່ຈະເປີດໃນກໍລະນີສຸກເສີນ. ທັນທີທີ່ຄາດຫວັງວ່າເມື່ອ (ບໍ່ແມ່ນຖ້າ!) ທຸກສິ່ງທຸກຢ່າງສິ້ນສຸດລົງ, ມີພຽງແຕ່ຜູ້ຝຶກຫັດທີ່ບໍ່ມີປະສົບການທີ່ສຸດທີ່ຈະຢູ່ໃກ້ໆ, ມືຂອງພວກເຂົາຈະສັ່ນສະເທືອນຢ່າງຮຸນແຮງຈາກຄວາມຢ້ານຂອງສິ່ງທີ່ເກີດຂຶ້ນ. ເບິ່ງວິທີທີ່ປ້າຍສຸກເສີນຖືກປະຕິບັດຢູ່ໃນຫ້ອງການແພດ. ຕົວຢ່າງ, ສິ່ງທີ່ຕ້ອງເຮັດໃນກໍລະນີຂອງອາການຊ໊ອກ anaphylactic. ພະນັກງານແພດຮູ້ຈັກພິທີການທັງໝົດດ້ວຍຫົວໃຈ, ແຕ່ເມື່ອຄົນທີ່ຢູ່ໃກ້ຄຽງເລີ່ມຕາຍ, ສ່ວນຫຼາຍແລ້ວ ທຸກຄົນລ້ວນແຕ່ຈັບມືກັບທຸກສິ່ງທີ່ຢູ່ໃນສາຍຕາ. ເພື່ອເຮັດສິ່ງນີ້, ມີຄໍາແນະນໍາທີ່ຊັດເຈນຢູ່ເທິງກໍາແພງທີ່ມີລາຍການເຊັ່ນ "ເປີດຊຸດຂອງສິ່ງດັ່ງກ່າວ" ແລະ "ປະຕິບັດຫຼາຍຫົວຂອງຢາທາງເສັ້ນເລືອດ."

ມັນຍາກທີ່ຈະຄິດໃນເຫດສຸກເສີນ! ຄວນມີຄໍາແນະນໍາທີ່ງ່າຍດາຍສໍາລັບການວິເຄາະກະດູກສັນຫຼັງ.

A DRP ທີ່ດີປະກອບດ້ວຍຫຼາຍຕັນງ່າຍດາຍ:

1. ໃຜຄວນແຈ້ງກ່ຽວກັບການເລີ່ມຕົ້ນຂອງອຸປະຕິເຫດ. ນີ້ແມ່ນສິ່ງສໍາຄັນເພື່ອຂະຫນານຂະບວນການລົບລ້າງຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້.
2. ວິທີການວິນິດໄສຢ່າງຖືກຕ້ອງ - ພວກເຮົາຕິດຕາມ, ເບິ່ງໃນ systemctl status servicename ແລະອື່ນໆ.
3. ເຈົ້າໃຊ້ເວລາຫຼາຍປານໃດໃນແຕ່ລະເວທີ? ຖ້າທ່ານບໍ່ມີເວລາທີ່ຈະແກ້ໄຂດ້ວຍຕົນເອງພາຍໃນເວລາ SLA, ເຄື່ອງ virtual ໄດ້ຖືກຂ້າຕາຍແລະກັບຄືນຈາກການສໍາຮອງຂໍ້ມູນຂອງມື້ວານນີ້.
4. ເຮັດແນວໃດເພື່ອໃຫ້ແນ່ໃຈວ່າອຸປະຕິເຫດແມ່ນສິ້ນສຸດລົງ.

ຈົ່ງຈື່ໄວ້ວ່າ DRP ເລີ່ມຕົ້ນເມື່ອການບໍລິການລົ້ມເຫລວຢ່າງສົມບູນແລະສິ້ນສຸດລົງເມື່ອການບໍລິການຖືກຟື້ນຟູ, ເຖິງແມ່ນວ່າຈະມີປະສິດທິພາບຫຼຸດລົງ. ພຽງແຕ່ສູນເສຍການຈອງບໍ່ຄວນເຮັດໃຫ້ເກີດ DRP. ນອກນັ້ນທ່ານຍັງສາມາດຂຽນຈອກຊາເຂົ້າໄປໃນ DRP ໄດ້. ຢ່າງຈິງຈັງ. ອີງຕາມສະຖິຕິ, ອຸປະຕິເຫດຈໍານວນຫຼາຍປ່ຽນຈາກຄວາມບໍ່ພໍໃຈໄປສູ່ໄພພິບັດອັນເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າພະນັກງານຢູ່ໃນ panic rush ທີ່ຈະແກ້ໄຂບາງສິ່ງບາງຢ່າງ, ພ້ອມກັນຂ້າພຽງແຕ່ node ດໍາລົງຊີວິດທີ່ມີຂໍ້ມູນຫຼືສຸດທ້າຍໄດ້ຈົບລົງຈາກກຸ່ມ. ຕາມກົດລະບຽບ, 5 ນາທີກັບຈອກຊາຈະເຮັດໃຫ້ເຈົ້າມີເວລາທີ່ຈະສະຫງົບແລະວິເຄາະສິ່ງທີ່ເກີດຂຶ້ນ.

ຢ່າສັບສົນ DRP ແລະຫນັງສືຜ່ານແດນລະບົບ! ຢ່າໂຫຼດມັນເກີນດ້ວຍຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນ. ພຽງແຕ່ເຮັດໃຫ້ມັນເປັນໄປໄດ້ໄວແລະສະດວກໃນການນໍາໃຊ້ hyperlinks ໄປຫາພາກສ່ວນທີ່ຕ້ອງການຂອງເອກະສານແລະອ່ານໃນຮູບແບບຂະຫຍາຍກ່ຽວກັບພາກສ່ວນທີ່ຈໍາເປັນຂອງສະຖາປັດຕະການບໍລິການ. ແລະໃນ DRP ຕົວຂອງມັນເອງມີພຽງແຕ່ຄໍາແນະນໍາໂດຍກົງກ່ຽວກັບບ່ອນແລະວິທີການເຊື່ອມຕໍ່ກັບຄໍາສັ່ງສະເພາະສໍາລັບການຄັດລອກ - ວາງ.

ວິທີການທົດສອບຢ່າງຖືກຕ້ອງ

ໃຫ້ແນ່ໃຈວ່າພະນັກງານທີ່ຮັບຜິດຊອບສາມາດເຮັດສໍາເລັດລາຍການທັງຫມົດ. ໃນຊ່ວງເວລາທີ່ສໍາຄັນທີ່ສຸດ, ມັນອາດຈະເຫັນວ່າວິສະວະກອນບໍ່ມີສິດໃນການເຂົ້າເຖິງລະບົບທີ່ຕ້ອງການ, ບໍ່ມີລະຫັດຜ່ານສໍາລັບບັນຊີທີ່ຕ້ອງການ, ຫຼືລາວບໍ່ຮູ້ວ່າ "ເຊື່ອມຕໍ່ກັບ console ການຄຸ້ມຄອງການບໍລິການຜ່ານຕົວແທນທີ່ ສຳນັກງານໃຫຍ່” ໝາຍເຖິງ. ແຕ່ລະຈຸດຄວນຈະງ່າຍດາຍທີ່ສຸດ.

ຜິດ - "ໄປທີ່ virtualization ແລະ reboot node ຕາຍ"
ສິດ - "ເຊື່ອມຕໍ່ຜ່ານ web interface ກັບ virt.example.com, ໃນສ່ວນ node, reload the node ທີ່ເຮັດໃຫ້ເກີດຄວາມຜິດພາດ."

ຫຼີກເວັ້ນຄວາມບໍ່ແນ່ນອນ. ຈື່ຈໍານັກຝຶກງານທີ່ຢ້ານ.

ໃຫ້ແນ່ໃຈວ່າຈະທົດສອບ DRP. ນີ້ບໍ່ແມ່ນພຽງແຕ່ແຜນການສໍາລັບການສະແດງ - ມັນເປັນສິ່ງທີ່ຈະຊ່ວຍໃຫ້ທ່ານແລະລູກຄ້າຂອງທ່ານອອກຈາກສະຖານະການທີ່ສໍາຄັນຢ່າງໄວວາ. ມັນດີທີ່ສຸດທີ່ຈະເຮັດແບບນີ້ຫຼາຍຄັ້ງ:

• ຜູ້ຊ່ຽວຊານຄົນຫນຶ່ງແລະຜູ້ຝຶກຫັດຫຼາຍຄົນເຮັດວຽກຢູ່ໃນຫ້ອງທົດລອງທີ່ຈໍາລອງການບໍລິການທີ່ແທ້ຈິງຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້. ຜູ້ຊ່ຽວຊານໄດ້ທໍາລາຍການບໍລິການດ້ວຍວິທີຕ່າງໆແລະເຮັດໃຫ້ຜູ້ຝຶກອົບຮົມສາມາດຟື້ນຟູໄດ້ຕາມ DRP. ບັນ​ຫາ​ທັງ​ຫມົດ​, ຄວາມ​ບໍ່​ແນ່​ນອນ​ຂອງ​ເອ​ກະ​ສານ​ແລະ​ຄວາມ​ຜິດ​ພາດ​ແມ່ນ​ໄດ້​ຖືກ​ບັນ​ທຶກ​ໄວ້​. ຫຼັງຈາກນັກຝຶກອົບຮົມໄດ້ຮັບການຝຶກອົບຮົມ, DRP ໄດ້ຖືກຂະຫຍາຍແລະງ່າຍດາຍໃນພື້ນທີ່ທີ່ບໍ່ຊັດເຈນ.
• ການທົດສອບການບໍລິການທີ່ແທ້ຈິງ. ໃນຄວາມເປັນຈິງ, ທ່ານບໍ່ສາມາດສ້າງສໍາເນົາທີ່ສົມບູນແບບຂອງການບໍລິການທີ່ແທ້ຈິງ. ດັ່ງນັ້ນ, ສອງສາມເທື່ອຕໍ່ປີມັນຈໍາເປັນຕ້ອງປິດບາງເຄື່ອງແມ່ຂ່າຍປົກກະຕິ, ຕັດການເຊື່ອມຕໍ່ແລະເຮັດໃຫ້ເກີດໄພພິບັດອື່ນໆຈາກບັນຊີລາຍຊື່ຂອງໄພຂົ່ມຂູ່ເພື່ອປະເມີນຂັ້ນຕອນການຟື້ນຕົວ. ຄວາມລົ້ມເຫຼວທີ່ວາງແຜນໄວ້ເປັນເວລາ 10 ນາທີໃນຕອນກາງຄືນແມ່ນດີກ່ວາຄວາມລົ້ມເຫຼວຢ່າງກະທັນຫັນເປັນເວລາຫຼາຍຊົ່ວໂມງໃນລະຫວ່າງການໂຫຼດສູງສຸດກັບການສູນເສຍຂໍ້ມູນ.
• ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ທີ່​ແທ້​ຈິງ​. ແມ່ນແລ້ວ, ນີ້ແມ່ນສ່ວນຫນຶ່ງຂອງການທົດສອບ. ຖ້າອຸປະຕິເຫດເກີດຂື້ນທີ່ບໍ່ຢູ່ໃນບັນຊີລາຍຊື່ຂອງໄພຂົ່ມຂູ່, ມັນຈໍາເປັນຕ້ອງໄດ້ເພີ່ມເຕີມແລະສະຫຼຸບ DRP ໂດຍອີງໃສ່ຜົນຂອງການສືບສວນຂອງມັນ.

ຈຸດ​ທີ່​ສໍາ​ຄັນ

1. ຖ້າຫາກວ່າ bullshit ສາມາດເກີດຂຶ້ນ, ມັນຈະບໍ່ເກີດຂຶ້ນພຽງແຕ່, ແຕ່ມັນຈະເຮັດມັນຢູ່ໃນສະຖານະການໄພພິບັດທີ່ສຸດ.
2. ໃຫ້ແນ່ໃຈວ່າທ່ານມີຊັບພະຍາກອນສໍາລັບການໂອນການໂຫຼດສຸກເສີນ.
3. ໃຫ້ແນ່ໃຈວ່າທ່ານມີສໍາຮອງຂໍ້ມູນ, ພວກມັນຖືກສ້າງຂື້ນໂດຍອັດຕະໂນມັດແລະຖືກກວດສອບຢ່າງເປັນປົກກະຕິສໍາລັບຄວາມສອດຄ່ອງ.
4. ຄິດຜ່ານສະຖານະການໄພຂົ່ມຂູ່ປົກກະຕິ.
5. ໃຫ້ໂອກາດວິສະວະກອນທີ່ຈະມາກັບທາງເລືອກທີ່ບໍ່ແມ່ນມາດຕະຖານສໍາລັບການໃຫ້ບໍລິການ.
6. DRP ຄວນເປັນຄໍາແນະນໍາທີ່ງ່າຍດາຍແລະຊັດເຈນ. ທຸກໆການວິນິດໄສທີ່ສັບສົນພຽງແຕ່ຫຼັງຈາກລູກຄ້າໄດ້ຟື້ນຟູການບໍລິການ. ເຖິງແມ່ນວ່າຢູ່ໃນຄວາມສາມາດສະຫງວນ.
7. ໃຫ້ເບີໂທລະສັບ ແລະລາຍຊື່ຕິດຕໍ່ທີ່ສໍາຄັນໃນ DRP.
8. ທົດສອບຄວາມເຂົ້າໃຈຂອງພະນັກງານກ່ຽວກັບ DRP ເປັນປະຈໍາ.
9. ວາງແຜນອຸປະຕິເຫດທີ່ສະຖານທີ່ຜະລິດ. ຂາຕັ້ງບໍ່ສາມາດທົດແທນທຸກສິ່ງທຸກຢ່າງໄດ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com