ເຊີບເວີຄວນຖືກດັບໄຟຖ້າການທົດສອບຄວັນໄຟຂອງສູນຂໍ້ມູນໄຟໄຫມ້ບໍ?

ເຈົ້າຈະຮູ້ສຶກແນວໃດຖ້າມື້ໜຶ່ງໃນລະດູຮ້ອນທີ່ສູນຂໍ້ມູນທີ່ມີອຸປະກອນຂອງເຈົ້າເປັນແບບນີ້?

ສະບາຍດີທຸກຄົນ! ຂ້ອຍຊື່ Dmitry Samsonov, ຂ້ອຍເຮັດວຽກເປັນຜູ້ບໍລິຫານລະບົບຊັ້ນນໍາຢູ່ "Odnoklassniki" ຮູບພາບສະແດງໃຫ້ເຫັນຫນຶ່ງໃນສີ່ສູນຂໍ້ມູນບ່ອນທີ່ອຸປະກອນຮັບໃຊ້ໂຄງການຂອງພວກເຮົາຖືກຕິດຕັ້ງ. ຫລັງ​ຝາ​ເຫຼົ່າ​ນີ້​ມີ​ປະ​ມານ 4 ພັນ​ຂອງ​ອຸ​ປະ​ກອນ​: ເຄື່ອງ​ແມ່​ຂ່າຍ​, ລະ​ບົບ​ການ​ເກັບ​ຂໍ້​ມູນ​, ອຸ​ປະ​ກອນ​ເຄືອ​ຂ່າຍ​, ແລະ​ອື່ນໆ​. - ເກືອບ⅓ຂອງອຸປະກອນທັງໝົດຂອງພວກເຮົາ.
Большинство серверов — это Linux. Есть и несколько десятков серверов на Windows (MS SQL) — наше наследие, от которого мы на протяжении многих лет планомерно отказываемся.
ດັ່ງນັ້ນ, ວັນທີ 5 ມິຖຸນາ 2019 ເວລາ 14:35 ໂມງ, ວິສະວະກອນຢູ່ສູນຂໍ້ມູນແຫ່ງໜຶ່ງຂອງພວກເຮົາໄດ້ແຈ້ງເຫດໄຟໄໝ້.

ການເຈລະຈາ

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

Wrath

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

14: 50 ຂໍ້ມູນໄດ້ຮັບວ່າໄຟກໍາລັງເຂົ້າຫາລະບົບເຮັດຄວາມເຢັນ. ແຕ່ມັນຈະມາບໍ? ຜູ້ເບິ່ງແຍງລະບົບທີ່ຮັບຜິດຊອບເອົາການຈະລາຈອນພາຍນອກອອກຈາກດ້ານຫນ້າຂອງສູນຂໍ້ມູນນີ້.

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

ໄຟຍັງບໍ່ທັນໄດ້ສົ່ງຜົນກະທົບຕໍ່ພວກເຮົາໃນທາງໃດກໍ່ຕາມ - ທັງຜູ້ໃຊ້ແລະອຸປະກອນບໍ່ໄດ້ຮັບຄວາມເສຍຫາຍ. ນີ້ແມ່ນອຸປະຕິເຫດບໍ? ພາກສ່ວນທໍາອິດຂອງເອກະສານ "ແຜນປະຕິບັດງານອຸປະຕິເຫດ" ກໍານົດແນວຄວາມຄິດຂອງ "ອຸປະຕິເຫດ", ແລະພາກສ່ວນຈະສິ້ນສຸດເຊັ່ນນີ້:
«ຖ້າ​ມີ​ຄວາມ​ສົງ​ໄສ​ວ່າ​ມີ​ອຸ​ປະ​ຕິ​ເຫດ​ຫຼື​ບໍ່​ແມ່ນ​ອຸ​ປະ​ຕິ​ເຫດ​!»

14:53 . ມີການແຕ່ງຕັ້ງຜູ້ປະສານງານສຸກເສີນ.

ຜູ້ປະສານງານແມ່ນຜູ້ທີ່ຄວບຄຸມການສື່ສານລະຫວ່າງຜູ້ເຂົ້າຮ່ວມທັງຫມົດ, ປະເມີນຂະຫນາດຂອງອຸປະຕິເຫດ, ນໍາໃຊ້ແຜນການປະຕິບັດການສຸກເສີນ, ດຶງດູດບຸກຄະລາກອນທີ່ຈໍາເປັນ, ຕິດຕາມການສໍາເລັດການສ້ອມແປງ, ແລະສໍາຄັນທີ່ສຸດ, ມອບຫນ້າທີ່ໃດໆ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ນີ້ແມ່ນຜູ້ທີ່ຄຸ້ມຄອງຂະບວນການຕອບສະຫນອງສຸກເສີນທັງຫມົດ.

ຕໍ່ລອງໄດ້

ເວລາ 15:01. ພວກເຮົາເລີ່ມຕົ້ນທີ່ຈະປິດການໃຊ້ງານເຄື່ອງແມ່ຂ່າຍທີ່ບໍ່ກ່ຽວຂ້ອງກັບການຜະລິດ.
ເວລາ 15:03. ພວກເຮົາປິດການບໍລິການທີ່ສະຫງວນໄວ້ທັງໝົດຢ່າງຖືກຕ້ອງ.
ນີ້ປະກອບມີບໍ່ພຽງແຕ່ດ້ານຫນ້າ (ເຊິ່ງໂດຍຈຸດນີ້ຜູ້ໃຊ້ບໍ່ສາມາດເຂົ້າເຖິງໄດ້) ແລະການບໍລິການຊ່ວຍຂອງພວກເຂົາ (ເຫດຜົນທາງທຸລະກິດ, ແຄດ, ແລະອື່ນໆ), ແຕ່ຍັງຖານຂໍ້ມູນຕ່າງໆທີ່ມີປັດໃຈການຈໍາລອງ 2 ຫຼືຫຼາຍກວ່ານັ້ນ (Cassandra, ການເກັບຮັກສາຂໍ້ມູນຖານສອງ, ການເກັບຮັກສາເຢັນ, NewSQL ແລະອື່ນໆ).
15: 06 ຂໍ້ມູນໄດ້ຮັບວ່າໄຟກໍາລັງຂົ່ມຂູ່ຫນຶ່ງໃນຫ້ອງສູນຂໍ້ມູນ. ພວກເຮົາບໍ່ມີອຸປະກອນຢູ່ໃນຫ້ອງນີ້, ແຕ່ຄວາມຈິງທີ່ວ່າໄຟສາມາດແຜ່ລາມຈາກຫລັງຄາໄປຫາຫ້ອງໂຖງໄດ້ປ່ຽນແປງຮູບພາບຂອງສິ່ງທີ່ເກີດຂື້ນ.
(ຕໍ່ມາມັນໄດ້ຫັນອອກວ່າບໍ່ມີໄພຂົ່ມຂູ່ທາງດ້ານຮ່າງກາຍຕໍ່ຫ້ອງໂຖງ, ເພາະວ່າມັນຖືກຜະນຶກເຂົ້າກັນຈາກຫລັງຄາ. ໄພຂົ່ມຂູ່ແມ່ນພຽງແຕ່ລະບົບເຮັດຄວາມເຢັນຂອງຫ້ອງໂຖງ.
ເວລາ 15:07 . ພວກເຮົາອະນຸຍາດໃຫ້ປະຕິບັດຄໍາສັ່ງໃນເຄື່ອງແມ່ຂ່າຍໃນຮູບແບບເລັ່ງໂດຍບໍ່ມີການກວດສອບເພີ່ມເຕີມ (ໂດຍ​ບໍ່​ມີ​ການ​ຄິດ​ໄລ່ favorite ຂອງ​ພວກ​ເຮົາ​).
ເວລາ 15:08 . ອຸນຫະພູມຢູ່ໃນຫ້ອງໂຖງຢູ່ໃນຂອບເຂດປົກກະຕິ.
15: 12 ການເພີ່ມຂຶ້ນຂອງອຸນຫະພູມໃນຫ້ອງໂຖງໄດ້ຖືກບັນທຶກໄວ້.
15:13. ຫຼາຍກວ່າເຄິ່ງຫນຶ່ງຂອງເຄື່ອງແມ່ຂ່າຍໃນສູນຂໍ້ມູນຖືກປິດ. ໃຫ້ສືບຕໍ່.
15:16 . ມີການຕັດສິນໃຈທີ່ຈະປິດອຸປະກອນທັງຫມົດ.
15:21 . ພວກ​ເຮົາ​ເລີ່ມ​ຕົ້ນ​ທີ່​ຈະ​ປິດ​ການ​ພະ​ລັງ​ງານ​ກັບ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ທີ່​ບໍ່​ມີ​ລັດ​ໂດຍ​ບໍ່​ມີ​ການ​ປິດ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ແລະ​ລະ​ບົບ​ປະ​ຕິ​ບັດ​ການ​ຢ່າງ​ຖືກ​ຕ້ອງ​.
15:23. ກຸ່ມຄົນທີ່ຮັບຜິດຊອບ MS SQL ໄດ້ຖືກຈັດສັນ (ມີຈໍານວນຫນ້ອຍຂອງພວກເຂົາ, ການເອື່ອຍອີງຂອງການບໍລິການກ່ຽວກັບພວກມັນແມ່ນບໍ່ຍິ່ງໃຫຍ່, ແຕ່ຂັ້ນຕອນການຟື້ນຟູການເຮັດວຽກໃຊ້ເວລາດົນກວ່າແລະສັບສົນກວ່າ, ຕົວຢ່າງ Cassandra).

ໂລກຊືມເສົ້າ

15: 25 ຂໍ້ມູນໄດ້ຮັບກ່ຽວກັບການປິດໄຟຟ້າຢູ່ໃນສີ່ຫ້ອງໂຖງຈາກ 16 (ສະບັບເລກທີ 6, 7, 8, 9). ອຸປະກອນຂອງພວກເຮົາແມ່ນຕັ້ງຢູ່ໃນຫ້ອງໂຖງ 7 ແລະ 8. ບໍ່ມີຂໍ້ມູນກ່ຽວກັບສອງຫ້ອງໂຖງຂອງພວກເຮົາ (ເລກ 1 ແລະ 3).
ໂດຍປົກກະຕິແລ້ວ, ໃນເວລາເກີດໄຟໄຫມ້, ການສະຫນອງພະລັງງານຈະຖືກປິດທັນທີ, ແຕ່ໃນກໍລະນີນີ້, ຍ້ອນການປະສານງານຂອງເຈົ້າຫນ້າທີ່ດັບເພີງແລະພະນັກງານວິຊາການຂອງສູນຂໍ້ມູນ, ມັນບໍ່ໄດ້ຖືກປິດຢູ່ທົ່ວທຸກແຫ່ງແລະບໍ່ທັນທີ, ແຕ່ຕາມຄວາມຈໍາເປັນ.
(ຕໍ່ມາໄດ້ມີການຄົ້ນພົບວ່າບໍ່ໄດ້ປິດໄຟຢູ່ໃນຫ້ອງໂຖງ 8 ແລະ 9.)
15:28 . ພວກເຮົາເລີ່ມນຳໃຊ້ຖານຂໍ້ມູນ MS SQL ຈາກການສໍາຮອງໃນສູນຂໍ້ມູນອື່ນໆ.
ມັນຈະໃຊ້ເວລາດົນປານໃດ? ມີຄວາມສາມາດເຄືອຂ່າຍພຽງພໍສໍາລັບເສັ້ນທາງທັງຫມົດບໍ?
15: 37 ການປິດບາງສ່ວນຂອງເຄືອຂ່າຍໄດ້ຖືກບັນທຶກໄວ້.
ການຄຸ້ມຄອງແລະເຄືອຂ່າຍການຜະລິດແມ່ນໂດດດ່ຽວຈາກກັນແລະກັນ. ຖ້າເຄືອຂ່າຍການຜະລິດສາມາດໃຊ້ໄດ້, ຫຼັງຈາກນັ້ນທ່ານສາມາດໄປຫາເຄື່ອງແມ່ຂ່າຍ, ຢຸດຄໍາຮ້ອງສະຫມັກແລະປິດ OS. ຖ້າມັນບໍ່ສາມາດໃຊ້ໄດ້, ທ່ານສາມາດເຂົ້າສູ່ລະບົບຜ່ານ IPMI, ຢຸດແອັບພລິເຄຊັນແລະປິດ OS. ຖ້າບໍ່ມີເຄືອຂ່າຍໃດໆ, ຫຼັງຈາກນັ້ນທ່ານບໍ່ສາມາດເຮັດຫຍັງໄດ້. "ຂໍຂອບໃຈ, Cap!", ເຈົ້າຈະຄິດ.
"ແລະໂດຍທົ່ວໄປ, ມີຄວາມວຸ່ນວາຍຫຼາຍ," ທ່ານອາດຈະຄິດ.
ສິ່ງດັ່ງກ່າວແມ່ນວ່າເຄື່ອງແມ່ຂ່າຍ, ເຖິງແມ່ນວ່າບໍ່ມີໄຟໄຫມ້, ສ້າງຄວາມຮ້ອນຈໍານວນຫຼວງຫຼາຍ. ແນ່ນອນກວ່ານັ້ນ, ເມື່ອມີຄວາມເຢັນ, ພວກມັນເຮັດໃຫ້ເກີດຄວາມຮ້ອນ, ແລະເມື່ອບໍ່ມີຄວາມເຢັນ, ພວກມັນສ້າງເປັນ inferno hellish, ເຊິ່ງດີທີ່ສຸດຈະເຮັດໃຫ້ອຸປະກອນທີ່ລະລາຍແລະປິດອີກສ່ວນຫນຶ່ງ, ແລະຮ້າຍແຮງທີ່ສຸດ ... ເຮັດໃຫ້ເກີດໄຟໄຫມ້ພາຍໃນ. ຫ້ອງໂຖງ, ເຊິ່ງເກືອບຮັບປະກັນທີ່ຈະທໍາລາຍທຸກສິ່ງທຸກຢ່າງ.

15:39 . ພວກເຮົາແກ້ໄຂບັນຫາກັບຖານຂໍ້ມູນ conf.

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

15:41 . ເຊັນເຊີອຸນຫະພູມຢູ່ໃນອຸປະກອນເຄືອຂ່າຍຫຼັກບັນທຶກການອ່ານໃກ້ກັບສູງສຸດທີ່ອະນຸຍາດ. ນີ້ແມ່ນກ່ອງທີ່ຄອບຄອງ rack ທັງຫມົດແລະຮັບປະກັນການດໍາເນີນງານຂອງເຄືອຂ່າຍທັງຫມົດພາຍໃນສູນຂໍ້ມູນ.

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

ການຮັບຮອງເອົາ

15:51 . ເຊີບເວີທັງໝົດຍົກເວັ້ນ MS SQL ໄດ້ຖືກປິດຜ່ານ IPMI ໂດຍບໍ່ມີການປິດຢ່າງຖືກຕ້ອງ.
ທ່ານກຽມພ້ອມສໍາລັບການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍຂະຫນາດໃຫຍ່ຜ່ານ IPMI ຖ້າຈໍາເປັນ?

ຊ່ວງເວລາທີ່ການກູ້ໄພຂອງອຸປະກອນໃນສູນຂໍ້ມູນແມ່ນສໍາເລັດໃນຂັ້ນຕອນນີ້. ທຸກສິ່ງທຸກຢ່າງທີ່ສາມາດເຮັດໄດ້ແມ່ນໄດ້ເຮັດແລ້ວ. ເພື່ອນຮ່ວມງານບາງຄົນສາມາດພັກຜ່ອນໄດ້.
16: 13 ຂໍ້ມູນໄດ້ຮັບວ່າທໍ່ freon ຈາກເຄື່ອງປັບອາກາດໄດ້ລະເບີດຢູ່ເທິງຫລັງຄາ - ນີ້ຈະຊັກຊ້າການເປີດຕົວຂອງສູນຂໍ້ມູນຫຼັງຈາກໄຟໄຫມ້ໄດ້ຖືກລົບລ້າງ.
16:19 . ອີງຕາມຂໍ້ມູນທີ່ໄດ້ຮັບຈາກພະນັກງານວິຊາການຂອງສູນຂໍ້ມູນ, ການເພີ່ມຂຶ້ນຂອງອຸນຫະພູມໃນຫ້ອງໂຖງໄດ້ຢຸດເຊົາ.
17:10 . ຖານຂໍ້ມູນ conf ໄດ້ຖືກຟື້ນຟູຄືນມາ. ຕອນນີ້ພວກເຮົາສາມາດປ່ຽນການຕັ້ງຄ່າແອັບພລິເຄຊັນໄດ້.
ເປັນຫຍັງອັນນີ້ຈຶ່ງສຳຄັນຫຼາຍຖ້າທຸກຢ່າງມີຄວາມຜິດ ແລະເຮັດວຽກໄດ້ເຖິງແມ່ນວ່າບໍ່ມີສູນຂໍ້ມູນດຽວ?
ກ່ອນອື່ນ ໝົດ, ບໍ່ແມ່ນທຸກຢ່າງແມ່ນມີຄວາມອົດທົນຕໍ່ຄວາມຜິດ. ມີບໍລິການຂັ້ນສອງທີ່ຍັງບໍ່ທັນລອດຈາກຄວາມລົ້ມເຫຼວຂອງສູນຂໍ້ມູນພຽງພໍ, ແລະມີຖານຂໍ້ມູນຢູ່ໃນຮູບແບບສະແຕນບາຍຕົ້ນສະບັບ. ຄວາມສາມາດໃນການຈັດການການຕັ້ງຄ່າອະນຸຍາດໃຫ້ທ່ານເຮັດທຸກຢ່າງທີ່ຈໍາເປັນເພື່ອຫຼຸດຜ່ອນຜົນກະທົບຂອງຜົນສະທ້ອນຂອງອຸປະຕິເຫດຕໍ່ຜູ້ໃຊ້ເຖິງແມ່ນວ່າຢູ່ໃນສະພາບທີ່ຫຍຸ້ງຍາກ.
ອັນທີສອງ, ມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າການດໍາເນີນງານຂອງສູນຂໍ້ມູນຈະບໍ່ຖືກຟື້ນຟູຢ່າງເຕັມທີ່ໃນຊົ່ວໂມງຂ້າງຫນ້າ, ດັ່ງນັ້ນມັນຈໍາເປັນຕ້ອງໃຊ້ມາດຕະການເພື່ອຮັບປະກັນວ່າຄວາມບໍ່ສາມາດໃຊ້ໄດ້ໃນໄລຍະຍາວຂອງ replicas ບໍ່ໄດ້ນໍາໄປສູ່ບັນຫາເພີ່ມເຕີມເຊັ່ນ: ແຜ່ນເຕັມໃນ. ສູນ​ຂໍ້​ມູນ​ທີ່​ຍັງ​ເຫຼືອ​.
17:29 . ເວລາພິຊຊ່າ! ພວກເຮົາຈ້າງຄົນ, ບໍ່ແມ່ນຫຸ່ນຍົນ.

ການຟື້ນຟູ

ເວລາ 18:02 . ໃນຫ້ອງໂຖງເລກທີ 8 (ຂອງພວກເຮົາ), 9, 10 ແລະ 11 ອຸນຫະພູມໄດ້ສະຖຽນລະພາບ. ຫນຶ່ງໃນສິ່ງທີ່ຍັງຄົງຢູ່ໃນອອບໄລນ໌ (ຫມາຍເລກ 7) ເຮັດໃຫ້ອຸປະກອນຂອງພວກເຮົາ, ແລະອຸນຫະພູມຢູ່ທີ່ນັ້ນຍັງສືບຕໍ່ເພີ່ມຂຶ້ນ.
18:31 . ພວກ​ເຂົາ​ເຈົ້າ​ໄດ້​ໃຫ້​ການ​ເດີນ​ຫນ້າ​ເພື່ອ​ເລີ່ມ​ຕົ້ນ​ການ​ອຸ​ປະ​ກອນ​ໃນ​ຫ້ອງ​ການ​ເລກ 1 ແລະ 3 - ຫ້ອງ​ການ​ເຫຼົ່າ​ນີ້​ບໍ່​ໄດ້​ຮັບ​ຜົນ​ກະ​ທົບ​ຈາກ​ໄຟ​.

ໃນປັດຈຸບັນ, ເຄື່ອງແມ່ຂ່າຍກໍາລັງຖືກເປີດຕົວຢູ່ໃນຫ້ອງໂຖງເລກ 1, 3, 8, ເລີ່ມຕົ້ນດ້ວຍຈຸດສໍາຄັນທີ່ສຸດ. ການດໍາເນີນການທີ່ຖືກຕ້ອງຂອງການບໍລິການແລ່ນທັງຫມົດຖືກກວດສອບ. ຍັງມີບັນຫາກັບຫ້ອງໂຖງເລກ 7.

18:44 . ພະນັກງານວິຊາການຂອງສູນຂໍ້ມູນຄົ້ນພົບວ່າຢູ່ໃນຫ້ອງເລກທີ 7 (ບ່ອນທີ່ມີພຽງແຕ່ອຸປະກອນຂອງພວກເຮົາຕັ້ງຢູ່) ເຄື່ອງແມ່ຂ່າຍຈໍານວນຫຼາຍບໍ່ໄດ້ປິດ. ອີງຕາມຂໍ້ມູນຂອງພວກເຮົາ, 26 ເຊີບເວີຍັງຄົງອອນໄລນ໌ຢູ່ທີ່ນັ້ນ. ຫຼັງຈາກການກວດສອບຄັ້ງທີສອງ, ພວກເຮົາຊອກຫາ 58 ເຄື່ອງແມ່ຂ່າຍ.
20:18. ນັກວິຊາການສູນຂໍ້ມູນເປົ່າລົມຜ່ານຫ້ອງທີ່ບໍ່ມີເຄື່ອງປັບອາກາດຜ່ານທໍ່ມືຖືທີ່ແລ່ນຜ່ານຫ້ອງໂຖງ.
23:08 . admin ທໍາອິດຖືກສົ່ງກັບບ້ານ. ບາງຄົນຕ້ອງການນອນໃນຕອນກາງຄືນເພື່ອສືບຕໍ່ເຮັດວຽກມື້ອື່ນ. ຕໍ່ໄປ, ພວກເຮົາຈະປ່ອຍຜູ້ເບິ່ງແຍງແລະນັກພັດທະນາເພີ່ມເຕີມ.
02:56. ພວກເຮົາເປີດຕົວທຸກຢ່າງທີ່ສາມາດເປີດຕົວໄດ້. ພວກເຮົາເຮັດຫຼາຍການກວດສອບການບໍລິການທັງຫມົດໂດຍໃຊ້ການທົດສອບອັດຕະໂນມັດ.

03:02 . ເຄື່ອງປັບອາກາດໃນສຸດທ້າຍ, ຫ້ອງ 7 ໄດ້ຖືກຟື້ນຟູ.
03:36 . ພວກເຮົາເລີ່ມຕົ້ນການຫມຸນຫນ້າໃນສູນຂໍ້ມູນໃນ DNS. ຈາກເວລານີ້ການຈະລາຈອນຂອງຜູ້ໃຊ້ເລີ່ມຕົ້ນມາຮອດ.
ພວກເຮົາກໍາລັງສົ່ງທີມງານບໍລິຫານສ່ວນໃຫຍ່ກັບບ້ານ. ແຕ່​ພວກ​ເຮົາ​ປະ​ໄວ້​ບໍ່​ພໍ​ເທົ່າ​ໃດ​ປະ​ຊາ​ຊົນ​ຢູ່​ເບື້ອງ​ຫລັງ​.

FAQ ຂະໜາດນ້ອຍ:
ຖາມ: ເກີດຫຍັງຂຶ້ນຈາກ 18:31 ຫາ 02:56?
A: ປະຕິບັດຕາມ “ແຜນປະຕິບັດງານໄພພິບັດ”, ພວກເຮົາເປີດບໍລິການທັງໝົດ, ເລີ່ມຕົ້ນດ້ວຍອັນສຳຄັນທີ່ສຸດ. ໃນກໍລະນີນີ້, ຜູ້ປະສານງານໃນການສົນທະນາອອກການບໍລິການໃຫ້ກັບຜູ້ບໍລິຫານຟຣີ, ຜູ້ທີ່ກວດເບິ່ງວ່າ OS ແລະແອັບພລິເຄຊັນໄດ້ເລີ່ມຕົ້ນ, ມີຂໍ້ຜິດພາດໃດໆ, ແລະຕົວຊີ້ວັດແມ່ນປົກກະຕິ. ຫຼັງຈາກການເປີດຕົວແມ່ນສໍາເລັດ, ລາວລາຍງານກັບການສົນທະນາວ່າລາວບໍ່ເສຍຄ່າແລະໄດ້ຮັບການບໍລິການໃຫມ່ຈາກຜູ້ປະສານງານ.
ຂະບວນການແມ່ນຊ້າລົງຕື່ມອີກໂດຍຮາດແວທີ່ລົ້ມເຫລວ. ເຖິງແມ່ນວ່າການຢຸດ OS ແລະການປິດເຊີບເວີໄດ້ໄປຢ່າງຖືກຕ້ອງ, ບາງເຄື່ອງແມ່ຂ່າຍບໍ່ກັບຄືນມາເນື່ອງຈາກຄວາມລົ້ມເຫຼວຂອງແຜ່ນ, ຫນ່ວຍຄວາມຈໍາແລະ chassis ຢ່າງກະທັນຫັນ. ເມື່ອພະລັງງານສູນເສຍ, ອັດຕາການລົ້ມເຫຼວຈະເພີ່ມຂຶ້ນ.
ຖາມ: ເປັນຫຍັງເຈົ້າຈຶ່ງບໍ່ສາມາດດໍາເນີນການທຸກຢ່າງໃນເວລາດຽວກັນ, ແລະຫຼັງຈາກນັ້ນແກ້ໄຂສິ່ງທີ່ເກີດຂື້ນໃນການຕິດຕາມ?
A: ທຸກສິ່ງທຸກຢ່າງຕ້ອງເຮັດເທື່ອລະກ້າວ, ເພາະວ່າມີການເພິ່ງພາອາໄສລະຫວ່າງການບໍລິການ. ແລະທ່ານຄວນກວດເບິ່ງທຸກຢ່າງທັນທີ, ໂດຍບໍ່ຕ້ອງລໍຖ້າການຕິດຕາມ - ເພາະວ່າມັນດີກວ່າທີ່ຈະແກ້ໄຂບັນຫາທັນທີ, ໂດຍບໍ່ຕ້ອງລໍຖ້າໃຫ້ພວກເຂົາຮ້າຍແຮງຂຶ້ນ.

7:40 . ສຸດທ້າຍ admin (ຜູ້ປະສານງານ) ໄດ້ໄປນອນ. ວຽກງານມື້ທໍາອິດໄດ້ສໍາເລັດ.
8:09 . ຜູ້ພັດທະນາທໍາອິດ, ວິສະວະກອນສູນຂໍ້ມູນແລະຜູ້ບໍລິຫານ (ລວມທັງຜູ້ປະສານງານໃຫມ່) ເລີ່ມເຮັດວຽກຟື້ນຟູ.
ເວລາ 09:37. ພວກເຮົາເລີ່ມຍົກຫ້ອງໂຖງເລກ 7 (ຫ້ອງສຸດທ້າຍ).
ໃນຂະນະດຽວກັນ, ພວກເຮົາສືບຕໍ່ຟື້ນຟູສິ່ງທີ່ບໍ່ໄດ້ແກ້ໄຂຢູ່ໃນຫ້ອງອື່ນໆ: ການປ່ຽນແຜ່ນ / ຫນ່ວຍຄວາມຈໍາ / ເຄື່ອງແມ່ຂ່າຍ, ແກ້ໄຂທຸກສິ່ງທຸກຢ່າງທີ່ "ເຜົາໄຫມ້" ໃນການຕິດຕາມ, ການປ່ຽນບົດບາດກັບຄືນໄປບ່ອນຢູ່ໃນໂຄງການສະແຕນບາຍແລະສິ່ງເລັກນ້ອຍອື່ນໆ, ເຊິ່ງມີ. ຢ່າງໃດກໍຕາມ, ຂ້ອນຂ້າງຫຼາຍ.
ເວລາ 17:08 . ພວກເຮົາອະນຸຍາດໃຫ້ເຮັດວຽກປົກກະຕິທັງຫມົດກັບການຜະລິດ.
21:45 . ວຽກງານຂອງມື້ທີສອງແມ່ນສໍາເລັດ.
ເວລາ 09:45. ມື້​ນີ້​ແມ່ນ​ວັນ​ສຸກ. ຍັງມີບາງບັນຫາເລັກນ້ອຍໃນການຕິດຕາມ. ທ້າຍອາທິດຈະມາເຖິງ, ທຸກຄົນຕ້ອງການພັກຜ່ອນ. ພວກເຮົາສືບຕໍ່ສ້ອມແປງຢ່າງຫຼວງຫຼາຍທຸກສິ່ງທີ່ພວກເຮົາສາມາດເຮັດໄດ້. ວຽກງານບໍລິຫານປົກກະຕິທີ່ສາມາດຖືກເລື່ອນໄດ້ໄດ້ຖືກເລື່ອນອອກໄປ. ຜູ້ປະສານງານແມ່ນໃຫມ່.
ເວລາ 15:40 . ທັນໃດນັ້ນເຄິ່ງໜຶ່ງຂອງອຸປະກອນເຄືອຂ່າຍຫຼັກໃນສູນຂໍ້ມູນອື່ນໄດ້ເປີດຄືນໃໝ່. ດ້ານຫນ້າໄດ້ຖືກເອົາອອກຈາກການຫມຸນເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງ. ບໍ່ມີຜົນຕໍ່ຜູ້ໃຊ້. ຕໍ່ມາມັນໄດ້ຫັນອອກວ່າມັນເປັນຕົວຖັງທີ່ຜິດພາດ. ຜູ້ປະສານງານກໍາລັງດໍາເນີນການສ້ອມແປງອຸບັດຕິເຫດສອງຄັ້ງໃນເວລາດຽວກັນ.
17:17 . ການດໍາເນີນງານຂອງເຄືອຂ່າຍໃນສູນຂໍ້ມູນອື່ນໄດ້ຖືກຟື້ນຟູ, ທຸກສິ່ງທຸກຢ່າງໄດ້ຖືກກວດສອບ. ສູນຂໍ້ມູນຖືກໃສ່ເຂົ້າໃນການຫມຸນ.
18:29 . ວຽກງານຂອງມື້ທີສາມແລະໂດຍທົ່ວໄປ, ການຟື້ນຟູຫຼັງຈາກອຸປະຕິເຫດໄດ້ຖືກສໍາເລັດ.

Afterword

ວັນທີ 04.04.2013/XNUMX/XNUMX, ໃນມື້ຂອງຄວາມຜິດພາດ 404, "ເພື່ອນຮ່ວມຫ້ອງຮຽນ" ໄດ້ລອດຊີວິດຈາກອຸປະຕິເຫດທີ່ໃຫຍ່ທີ່ສຸດ — ເປັນ​ເວ​ລາ​ສາມ​ມື້​ປະ​ຕູ​ແມ່ນ​ຫມົດ​ຫຼື​ບໍ່​ມີ​ບາງ​ສ່ວນ​. ຕະຫລອດເວລານີ້, ຫຼາຍກວ່າ 100 ຄົນຈາກເມືອງຕ່າງໆ, ຈາກບໍລິສັດທີ່ແຕກຕ່າງກັນ (ຂໍຂອບໃຈອີກເທື່ອຫນຶ່ງ!), ຫ່າງໄກສອກຫຼີກແລະໂດຍກົງໃນສູນຂໍ້ມູນ, ດ້ວຍຕົນເອງແລະອັດຕະໂນມັດ, ສ້ອມແປງເຄື່ອງແມ່ຂ່າຍຫຼາຍພັນເຄື່ອງແມ່ຂ່າຍ.
ພວກເຮົາໄດ້ເອົາບົດສະຫຼຸບ. ເພື່ອສະກັດກັ້ນບໍ່ໃຫ້ເຫດການດັ່ງກ່າວເກີດຂຶ້ນອີກ, ພວກເຮົາກໍໄດ້ປະຕິບັດ ແລະ ສືບຕໍ່ປະຕິບັດວຽກງານຢ່າງເລິກເຊິ່ງກວ້າງຂວາງຈົນເຖິງທຸກວັນນີ້.

ຄວາມແຕກຕ່າງຕົ້ນຕໍລະຫວ່າງອຸປະຕິເຫດໃນປະຈຸບັນແລະ 404 ແມ່ນຫຍັງ?

• ພວກເຮົາມີ “ແຜນປະຕິບັດງານອຸປະຕິເຫດ”. ເມື່ອໄຕມາດຫນຶ່ງ, ພວກເຮົາດໍາເນີນການອອກກໍາລັງກາຍ - ພວກເຮົາມີບົດບາດໃນສະຖານະການສຸກເສີນ, ເຊິ່ງກຸ່ມຜູ້ບໍລິຫານ (ທັງຫມົດໃນທາງກັບກັນ) ຕ້ອງລົບລ້າງການນໍາໃຊ້ "ແຜນປະຕິບັດງານສຸກເສີນ". ຜູ້ບໍລິຫານລະບົບຊັ້ນນໍາໄດ້ປ່ຽນບົດບາດເປັນຜູ້ປະສານງານ.
• ທຸກໆໄຕມາດ, ໃນໂຫມດການທົດສອບ, ພວກເຮົາແຍກສູນຂໍ້ມູນ (ທັງຫມົດໃນທາງກັບກັນ) ຜ່ານເຄືອຂ່າຍ LAN ແລະ WAN, ເຊິ່ງຊ່ວຍໃຫ້ພວກເຮົາສາມາດກໍານົດຂໍ້ບົກພ່ອງໄດ້ທັນທີ.
• ແຜ່ນທີ່ແຕກຫັກໜ້ອຍລົງ, ເພາະວ່າພວກເຮົາໄດ້ຮັດແໜ້ນມາດຕະຖານ: ຊົ່ວໂມງເຮັດວຽກໜ້ອຍລົງ, ເກນທີ່ເຂັ້ມງວດສຳລັບ SMART,
• ພວກເຮົາໄດ້ປະຖິ້ມ BerkeleyDB ຢ່າງສົມບູນ, ຖານຂໍ້ມູນເກົ່າແລະບໍ່ຫມັ້ນຄົງທີ່ຕ້ອງການເວລາຫຼາຍທີ່ຈະຟື້ນຕົວຫຼັງຈາກເຄື່ອງແມ່ຂ່າຍໃຫມ່.
• ພວກເຮົາຫຼຸດລົງຈໍານວນເຄື່ອງແມ່ຂ່າຍທີ່ມີ MS SQL ແລະຫຼຸດຜ່ອນການເພິ່ງພາອາໄສທີ່ຍັງເຫຼືອ.
• ພວກເຮົາມີຂອງພວກເຮົາເອງ cloud - one-cloud, ບ່ອນທີ່ພວກເຮົາໄດ້ເຄື່ອນຍ້າຍຢ່າງຫ້າວຫັນການບໍລິການທັງຫມົດສໍາລັບສອງປີໃນປັດຈຸບັນ. ຟັງໄດ້ງ່າຍຂຶ້ນຫຼາຍວົງຈອນການເຮັດວຽກກັບແອັບພລິເຄຊັນ, ແລະໃນກໍລະນີຂອງອຸປະຕິເຫດ, ມັນສະຫນອງເຄື່ອງມືທີ່ເປັນເອກະລັກເຊັ່ນ:
  • ການຢຸດເຊົາທີ່ຖືກຕ້ອງຂອງຄໍາຮ້ອງສະຫມັກທັງຫມົດໃນຫນຶ່ງຄລິກ;
  • ການເຄື່ອນຍ້າຍງ່າຍຂອງຄໍາຮ້ອງສະຫມັກຈາກເຄື່ອງແມ່ຂ່າຍທີ່ລົ້ມເຫລວ;
  • ການຈັດອັນດັບອັດຕະໂນມັດ (ຕາມລໍາດັບຄວາມສໍາຄັນຂອງການບໍລິການ) ການເປີດຕົວສູນຂໍ້ມູນທັງຫມົດ.

ອຸບັດ​ເຫດ​ທີ່​ໄດ້​ອະທິບາຍ​ໃນ​ບົດ​ຄວາມ​ນີ້​ແມ່ນ​ໃຫຍ່​ທີ່​ສຸດ​ນັບ​ແຕ່​ວັນ​ທີ 404 ​ເປັນ​ຕົ້ນ​ມາ. ແນ່ນອນ, ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງໄດ້ໄປຢ່າງລຽບງ່າຍ. ຕົວຢ່າງ, ໃນລະຫວ່າງການບໍ່ມີສູນຂໍ້ມູນຜູ້ຖືກເຄາະຮ້າຍຈາກໄຟໄຫມ້ຢູ່ໃນສູນຂໍ້ມູນອື່ນ, ແຜ່ນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງລົ້ມເຫລວ, ນັ້ນແມ່ນ, ພຽງແຕ່ຫນຶ່ງໃນສາມ replicas ໃນກຸ່ມ Cassandra ຍັງຄົງສາມາດເຂົ້າເຖິງໄດ້, ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າ 4,2% ຂອງແອັບພລິເຄຊັນມືຖື. ຜູ້ໃຊ້ບໍ່ສາມາດເຂົ້າສູ່ລະບົບ . ໃນເວລາດຽວກັນ, ຜູ້ໃຊ້ທີ່ເຊື່ອມຕໍ່ແລ້ວສືບຕໍ່ເຮັດວຽກ. ໃນຈໍານວນທັງຫມົດ, ເປັນຜົນມາຈາກອຸປະຕິເຫດ, ຫຼາຍກ່ວາ 30 ບັນຫາໄດ້ຖືກກໍານົດ - ຈາກແມງໄມ້ banal ກັບຂໍ້ບົກຜ່ອງໃນສະຖາປັດຕະການບໍລິການ.

ແຕ່ຄວາມແຕກຕ່າງທີ່ ສຳ ຄັນທີ່ສຸດລະຫວ່າງອຸປະຕິເຫດໃນປະຈຸບັນແລະ 404th ແມ່ນວ່າໃນຂະນະທີ່ພວກເຮົາ ກຳ ຈັດຜົນສະທ້ອນຂອງໄຟ, ຜູ້ໃຊ້ຍັງສົ່ງຂໍ້ຄວາມແລະໂທວິດີໂອຫາ. Tamtam, ຫຼິ້ນເກມ, ຟັງເພງ, ໃຫ້ຂອງຂວັນເຊິ່ງກັນແລະກັນ, ເບິ່ງວິດີໂອ, ໂທລະພາບແລະຊ່ອງໂທລະພາບໃນ OK, ແລະຍັງ streamed ໃນ ຕົກລົງ Live.

ອຸບັດຕິເຫດຂອງເຈົ້າເປັນແນວໃດ?

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