ລາຍການກວດສອບຄວາມພ້ອມຂອງການຜະລິດ

ການແປພາສາຂອງບົດຄວາມໄດ້ຖືກກະກຽມໂດຍສະເພາະສໍາລັບນັກສຶກສາຂອງຫຼັກສູດ "ການປະຕິບັດແລະເຄື່ອງມື DevOps", ເຊິ່ງເລີ່ມມື້ນີ້!

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

ບໍລິສັດສ່ວນໃຫຍ່ສິ້ນສຸດການຮັບຮອງເອົາວິທີການ "Wild West" ໃນເວລາທີ່ມັນມາກັບການປະຕິບັດການດໍາເນີນງານອຸດສາຫະກໍາ. ແຕ່ລະທີມຕັດສິນໃຈກ່ຽວກັບເຄື່ອງມືຂອງຕົນເອງແລະການປະຕິບັດທີ່ດີທີ່ສຸດໂດຍຜ່ານການທົດລອງແລະຄວາມຜິດພາດ. ແຕ່ນີ້ມັກຈະມີຜົນກະທົບບໍ່ພຽງແຕ່ຜົນສໍາເລັດຂອງໂຄງການ, ແຕ່ຍັງວິສະວະກອນ.

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

ອົງການຈັດຕັ້ງທີ່ປະສົບຜົນສໍາເລັດ:

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

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

ເມື່ອໃດທີ່ຈະກວດສອບການບໍລິການສໍາລັບຄວາມພ້ອມສໍາລັບການຜະລິດ?

ມັນເປັນປະໂຫຍດທີ່ຈະດໍາເນີນການກວດສອບຄວາມພ້ອມໃນການຜະລິດບໍ່ພຽງແຕ່ທັນທີກ່ອນທີ່ຈະປ່ອຍ, ແຕ່ຍັງໃນເວລາທີ່ໂອນມັນໄປຫາທີມງານປະຕິບັດງານອື່ນຫຼືພະນັກງານໃຫມ່.

ກວດເບິ່ງເວລາ:

• ທ່ານກໍາລັງປ່ອຍການບໍລິການໃຫມ່ເຂົ້າໄປໃນການຜະລິດ.
• ທ່ານໂອນການດໍາເນີນງານຂອງການບໍລິການການຜະລິດໄປຫາທີມງານອື່ນ, ເຊັ່ນ SRE.
• ທ່ານໂອນການດໍາເນີນງານຂອງການບໍລິການການຜະລິດໃຫ້ແກ່ພະນັກງານໃຫມ່.
• ຈັດຕັ້ງການສະຫນັບສະຫນູນດ້ານວິຊາການ.

ລາຍການກວດສອບຄວາມພ້ອມຂອງການຜະລິດ

ບາງຄັ້ງກ່ອນຫນ້ານີ້, ເປັນຕົວຢ່າງ, I ຈັດພີມມາ ບັນຊີລາຍການສໍາລັບການທົດສອບຄວາມພ້ອມສໍາລັບການຜະລິດ. ເຖິງແມ່ນວ່າລາຍຊື່ນີ້ມີຕົ້ນກຳເນີດມາຈາກລູກຄ້າ Google Cloud, ແຕ່ມັນຈະເປັນປະໂຫຍດ ແລະສາມາດນຳໃຊ້ໄດ້ຢູ່ນອກ Google Cloud.

ການອອກແບບແລະການພັດທະນາ

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

ການຈັດການການຕັ້ງຄ່າ

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

ການຄຸ້ມຄອງການປ່ອຍ

• ບັນທຶກຂັ້ນຕອນການປ່ອຍຕົວໃຫ້ລະອຽດ. ອະທິບາຍວິທີການປ່ອຍຜົນກະທົບຕໍ່ SLOs (ຕົວຢ່າງ, ການເພີ່ມຂື້ນຊົ່ວຄາວໃນ latency ເນື່ອງຈາກ cache misses).
• ການປ່ອຍເອກະສານ canary.
• ພັດທະນາແຜນການທົບທວນການປ່ອຍ canary ແລະ, ຖ້າເປັນໄປໄດ້, ກົນໄກ rollback ອັດຕະໂນມັດ.
• ໃຫ້ແນ່ໃຈວ່າ rollbacks ສາມາດນໍາໃຊ້ຂະບວນການດຽວກັນກັບການນໍາໃຊ້.

ການສັງເກດການ

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

ການປົກປ້ອງແລະຄວາມປອດໄພ

• ໃຫ້ແນ່ໃຈວ່າການເຊື່ອມຕໍ່ພາຍນອກທັງຫມົດຖືກເຂົ້າລະຫັດ.
• ໃຫ້ແນ່ໃຈວ່າໂຄງການການຜະລິດຂອງທ່ານມີການຕັ້ງຄ່າ IAM ທີ່ຖືກຕ້ອງ.
• ໃຊ້ເຄືອຂ່າຍເພື່ອແຍກກຸ່ມຂອງ virtual machine instances.
• ໃຊ້ VPN ເພື່ອເຊື່ອມຕໍ່ຢ່າງປອດໄພກັບເຄືອຂ່າຍທາງໄກ.
• ເອກະສານແລະຕິດຕາມກວດກາການເຂົ້າເຖິງຂໍ້ມູນຂອງຜູ້ໃຊ້. ໃຫ້ແນ່ໃຈວ່າຜູ້ໃຊ້ທຸກຄົນເຂົ້າເຖິງຂໍ້ມູນຖືກກວດສອບ ແລະເຂົ້າສູ່ລະບົບ.
• ໃຫ້ແນ່ໃຈວ່າຈຸດສິ້ນສຸດການດີບັກຖືກຈຳກັດໂດຍ ACLs.
• ອະນາໄມວັດສະດຸປ້ອນຂອງຜູ້ໃຊ້. ກໍານົດຂອບເຂດຈໍາກັດຂະຫນາດ payload ສໍາລັບການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້.
• ໃຫ້ແນ່ໃຈວ່າການບໍລິການຂອງທ່ານສາມາດສະກັດການຈະລາຈອນຂາເຂົ້າສໍາລັບຜູ້ໃຊ້ແຕ່ລະຄົນ. ນີ້ຈະຕັນການລະເມີດໂດຍບໍ່ມີການສົ່ງຜົນກະທົບຕໍ່ຜູ້ໃຊ້ອື່ນໆ.
• ຫຼີກເວັ້ນຈຸດສິ້ນສຸດພາຍນອກທີ່ລິເລີ່ມການດໍາເນີນງານພາຍໃນຫຼາຍ.

ການວາງແຜນຄວາມອາດສາມາດ

• ເອກະສານວິທີການຂະຫນາດການບໍລິການຂອງທ່ານ. ຕົວຢ່າງ: ຈໍານວນຜູ້ໃຊ້, ຂະຫນາດຂອງ payload ຂາເຂົ້າ, ຈໍານວນຂໍ້ຄວາມຂາເຂົ້າ.
• ເອກະສານຄວາມຕ້ອງການຊັບພະຍາກອນສໍາລັບການບໍລິການຂອງທ່ານ. ຕົວຢ່າງ: ຈໍານວນຂອງຕົວຢ່າງເຄື່ອງ virtual ທີ່ອຸທິດຕົນ, ຈໍານວນຂອງຕົວຢ່າງ Spanner, ຮາດແວພິເສດເຊັ່ນ GPU ຫຼື TPU.
• ຂໍ້ຈໍາກັດຂອງຊັບພະຍາກອນເອກະສານ: ປະເພດຊັບພະຍາກອນ, ພາກພື້ນ, ແລະອື່ນໆ.
• ຂໍ້ຈຳກັດໂຄຕ້າເອກະສານສຳລັບການສ້າງຊັບພະຍາກອນໃໝ່. ຕົວຢ່າງ, ການຈໍາກັດຈໍານວນຄໍາຮ້ອງຂໍ GCE API ຖ້າທ່ານໃຊ້ API ເພື່ອສ້າງຕົວຢ່າງໃຫມ່.
• ພິຈາລະນາການແລ່ນການທົດສອບການໂຫຼດເພື່ອວິເຄາະການເສື່ອມສະພາບປະສິດທິພາບ.

ຫມົດ​ເທົ່າ​ນີ້. ແລ້ວພົບກັນໃນຫ້ອງຮຽນ!

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