ເລື່ອງການເປີດຕົວທີ່ມີຜົນກະທົບທຸກຢ່າງ

ສັດຕູຂອງຄວາມເປັນຈິງ ໂດຍ 12f-2

ໃນຕອນທ້າຍຂອງເດືອນເມສາ, ໃນຂະນະທີ່ White Walkers ກໍາລັງປິດລ້ອມ Winterfell, ມີບາງສິ່ງບາງຢ່າງທີ່ຫນ້າສົນໃຈຫຼາຍໄດ້ເກີດຂຶ້ນກັບພວກເຮົາ; ພວກເຮົາໄດ້ເປີດຕົວແບບຜິດປົກກະຕິ. ໃນຫຼັກການ, ພວກເຮົາກໍາລັງອອກຄຸນສົມບັດໃຫມ່ຢ່າງຕໍ່ເນື່ອງໃນການຜະລິດ (ຄືກັນກັບຄົນອື່ນ). ແຕ່ອັນນີ້ແມ່ນແຕກຕ່າງກັນ. ຂະໜາດຂອງມັນແມ່ນຄວາມຜິດທີ່ອາດຈະເກີດຂຶ້ນທີ່ພວກເຮົາສາມາດເຮັດໄດ້ຈະສົ່ງຜົນກະທົບຕໍ່ການບໍລິການ ແລະຜູ້ໃຊ້ທັງໝົດຂອງພວກເຮົາ. ດັ່ງນັ້ນ, ພວກເຮົາ rolled ອອກທຸກສິ່ງທຸກຢ່າງຕາມແຜນການ, ພາຍໃນໄລຍະເວລາທີ່ວາງແຜນໄວ້ແລະປະກາດ, ໂດຍບໍ່ມີຜົນສະທ້ອນຕໍ່ການຂາຍ. ບົດຄວາມແມ່ນກ່ຽວກັບວິທີການທີ່ພວກເຮົາປະສົບຜົນສໍາເລັດນີ້ແລະວິທີທີ່ໃຜສາມາດເຮັດຊ້ໍາມັນຢູ່ເຮືອນ.

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

ປະຫວັດຄວາມເປັນມາ + ການເຮັດວຽກແບບນີ້ແມ່ນຫຍັງ?

ພວກເຮົາກໍາລັງສ້າງເວທີຟັງ Mail.ru Cloud Solutions (MCS), ບ່ອນທີ່ຂ້ອຍເຮັດວຽກເປັນຜູ້ອໍານວຍການດ້ານວິຊາການ. ແລະຕອນນີ້ມັນເຖິງເວລາແລ້ວທີ່ຈະເພີ່ມ IAM (ການລະບຸຕົວຕົນ ແລະການຄຸ້ມຄອງການເຂົ້າເຖິງ) ໃຫ້ກັບແພລດຟອມຂອງພວກເຮົາ, ເຊິ່ງໃຫ້ການຈັດການບັນຊີຜູ້ໃຊ້ທັງໝົດ, ຜູ້ໃຊ້, ລະຫັດຜ່ານ, ບົດບາດ, ບໍລິການ ແລະອື່ນໆອີກ. ເປັນຫຍັງມັນຈໍາເປັນຕ້ອງຢູ່ໃນເມຄແມ່ນຄໍາຖາມທີ່ຊັດເຈນ: ຂໍ້ມູນຜູ້ໃຊ້ທັງຫມົດຖືກເກັບໄວ້ໃນມັນ.

ປົກກະຕິແລ້ວສິ່ງດັ່ງກ່າວເລີ່ມຕົ້ນທີ່ຈະສ້າງຂຶ້ນໃນຕອນເລີ່ມຕົ້ນຂອງໂຄງການໃດໆ. ແຕ່ໃນປະຫວັດສາດມີຄວາມແຕກຕ່າງເລັກນ້ອຍໃນ MCS. MCS ຖືກສ້າງຂຶ້ນໃນສອງພາກສ່ວນ:

• Openstack ກັບໂມດູນການອະນຸຍາດ Keystone ຂອງຕົນເອງ,
• Hotbox (S3 storage) ອີງໃສ່ໂຄງການ Mail.ru Cloud,

ປະມານການບໍລິການໃຫມ່ທີ່ປາກົດຫຼັງຈາກນັ້ນ.

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

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

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

ເຮົາຈະອອກຫຍັງ?

ສະຫຼຸບໄດ້ປະມານ 4 ເດືອນ, ພວກເຮົາກະກຽມສິ່ງຕໍ່ໄປນີ້:

• ພວກເຮົາໄດ້ສ້າງ daemon ໃໝ່ຫຼາຍໆອັນທີ່ລວມເອົາຫນ້າທີ່ເຮັດວຽກໃນເມື່ອກ່ອນຢູ່ໃນພາກສ່ວນຕ່າງໆຂອງໂຄງສ້າງພື້ນຖານ. ສ່ວນທີ່ເຫຼືອຂອງການບໍລິການໄດ້ຖືກກໍາຫນົດໃຫ້ backend ໃຫມ່ໃນຮູບແບບຂອງພວກຜີປີສາດເຫຼົ່ານີ້.
• ພວກ​ເຮົາ​ໄດ້​ຂຽນ​ລະ​ຫັດ​ຜ່ານ​ສູນ​ກາງ​ຂອງ​ພວກ​ເຮົາ​ເອງ repository ແລະ​ກະ​ແຈ​, ມີ​ໃຫ້​ສໍາ​ລັບ​ການ​ບໍ​ລິ​ການ​ທັງ​ຫມົດ​ຂອງ​ພວກ​ເຮົາ​, ຊຶ່ງ​ສາ​ມາດ​ແກ້​ໄຂ​ໄດ້​ຢ່າງ​ເສລີ​ຕາມ​ທີ່​ພວກ​ເຮົາ​ຕ້ອງ​ການ​.
• ພວກເຮົາໄດ້ຂຽນ 4 backends ໃຫມ່ສໍາລັບ Keystone ຈາກ scratch (ຜູ້ໃຊ້, ໂຄງການ, ພາລະບົດບາດ, ການມອບຫມາຍພາລະບົດບາດ), ເຊິ່ງ, ໃນຄວາມເປັນຈິງ, ແທນຖານຂໍ້ມູນຂອງຕົນ, ແລະໃນປັດຈຸບັນເຮັດຫນ້າທີ່ເປັນ repository ດຽວສໍາລັບລະຫັດຜ່ານຜູ້ໃຊ້ຂອງພວກເຮົາ.
• ພວກເຮົາໄດ້ສອນການບໍລິການ Openstack ທັງໝົດຂອງພວກເຮົາໃຫ້ໄປຫາບໍລິການນະໂຍບາຍພາກສ່ວນທີສາມສໍາລັບນະໂຍບາຍຂອງເຂົາເຈົ້າແທນທີ່ຈະອ່ານນະໂຍບາຍເຫຼົ່ານີ້ຢູ່ໃນທ້ອງຖິ່ນຈາກແຕ່ລະເຄື່ອງແມ່ຂ່າຍ (ແມ່ນແລ້ວ, ນັ້ນແມ່ນວິທີທີ່ Openstack ເຮັດວຽກໂດຍຄ່າເລີ່ມຕົ້ນ!)

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

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

ຍຸດທະສາດການເປີດຕົວ

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

Digression: ການເປີດຕົວແມ່ນຫຍັງ?

<ລະມັດລະວັງ, ປັດຊະຍາ>

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

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

ແລະຮູບທັງຫມົດເປັນແບບນີ້. ການ​ອອກ​ມາ​ປະ​ກອບ​ດ້ວຍ​ສີ່​ດ້ານ​ທີ່​ສໍາ​ຄັນ​:

1. ການຈັດສົ່ງລະຫັດ, ລວມທັງການດັດແກ້ຂໍ້ມູນ. ສໍາລັບຕົວຢ່າງ, ການເຄື່ອນຍ້າຍຂອງເຂົາເຈົ້າ.
2. Code rollback ແມ່ນຄວາມສາມາດໃນການກັບຄືນຖ້າມີບາງສິ່ງບາງຢ່າງຜິດພາດ. ຕົວຢ່າງ, ໂດຍຜ່ານການສ້າງສໍາຮອງຂໍ້ມູນ.
3. ເວລາຂອງແຕ່ລະ rollout/rollback ການດໍາເນີນງານ. ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈໄລຍະເວລາຂອງການດໍາເນີນງານໃດໆຂອງສອງຈຸດທໍາອິດ.
4. ການທໍາງານທີ່ໄດ້ຮັບຜົນກະທົບ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະປະເມີນຜົນກະທົບທາງບວກແລະທາງລົບທີ່ເປັນໄປໄດ້.

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

ກົດຫມາຍວ່າດ້ວຍ 1..n, ການກະກຽມສໍາລັບການປ່ອຍ

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

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

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

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

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

ແລະດັ່ງນັ້ນ…

ການກະທໍາສຸດທ້າຍ, ກ່ອນທີ່ຈະເປີດຕົວ

...ມັນເຖິງເວລາແລ້ວທີ່ຈະເປີດຕົວ.

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

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

1. ສົ່ງ​ຜົນ​ກະ​ທົບ (ທີ່​ສັກ​ສິດ​ກັບ​ພວກ​ເຮົາ​, ມີ​ຄ່າ​ທີ່​ສຸດ​) ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​ຜູ້​ໃຊ້​,
2. ຫນ້າທີ່ເຮັດວຽກ: ການນໍາໃຊ້ການບໍລິການຂອງພວກເຮົາຫຼັງຈາກການເປີດຕົວຄວນຈະຄືກັນກັບກ່ອນ.

ມ້ວນອອກ

ສອງມ້ວນ, 8 ບໍ່ແຊກແຊງ

ພວກ​ເຮົາ​ໃຊ້​ເວ​ລາ downtime ສໍາ​ລັບ​ການ​ຮ້ອງ​ຂໍ​ທັງ​ຫມົດ​ຈາກ​ຜູ້​ໃຊ້​ສໍາ​ລັບ 7 ຊົ່ວ​ໂມງ​. ໃນເວລານີ້, ພວກເຮົາມີທັງແຜນການ rollout ແລະແຜນການ rollback.

• ການເປີດຕົວຂອງມັນເອງໃຊ້ເວລາປະມານ 3 ຊົ່ວໂມງ.
• 2 ຊົ່ວໂມງສໍາລັບການທົດສອບ.
• 2 ຊົ່ວໂມງ - ສະຫງວນສໍາລັບການປ່ຽນແປງທີ່ເປັນໄປໄດ້.

ຕາຕະລາງ Gantt ໄດ້ຖືກແຕ້ມຂຶ້ນສໍາລັບແຕ່ລະການປະຕິບັດ, ມັນໃຊ້ເວລາດົນປານໃດ, ສິ່ງທີ່ເກີດຂື້ນຕາມລໍາດັບ, ສິ່ງທີ່ເຮັດໃນຂະຫນານ.

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

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

ປະຫວັດສາດຂອງເຫດການ

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

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

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

ບຸກຄົນທຸກຄົນມີແຜນການເຜີຍແຜ່ທີ່ພິມອອກໂດຍຈຸດ, ທຸກຄົນຮູ້ວ່າໃຜກໍາລັງເຮັດຫຍັງແລະເວລາໃດ. ຫຼັງຈາກການປະຕິບັດແຕ່ລະຄັ້ງ, ພວກເຮົາກວດເບິ່ງເວລາເພື່ອຮັບປະກັນວ່າພວກເຮົາບໍ່ເກີນພວກເຂົາ, ແລະທຸກສິ່ງທຸກຢ່າງແມ່ນໄປຕາມແຜນການ. ຜູ້ທີ່ບໍ່ໄດ້ເຂົ້າຮ່ວມໃນ rollout ໂດຍກົງໃນຂັ້ນຕອນປະຈຸບັນກໍາລັງກະກຽມໂດຍການເປີດຕົວຂອງຫຼິ້ນອອນໄລນ໌ (Xonotic, type 3 quacks) ເພື່ອບໍ່ໃຫ້ລົບກວນເພື່ອນຮ່ວມງານຂອງພວກເຂົາ. 🙂

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

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

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

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

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

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

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

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

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

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

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

07:00. ມີບັນຫາກັບການໂຫຼດ API
ມັນຈະກາຍເປັນທີ່ຊັດເຈນວ່າພວກເຮົາວາງແຜນການໂຫຼດຜິດພາດເລັກນ້ອຍໃນ API ຂອງພວກເຮົາແລະທົດສອບການໂຫຼດນີ້, ເຊິ່ງບໍ່ສາມາດກໍານົດບັນຫາໄດ້. ດັ່ງນັ້ນ, ≈5% ຂອງການຮ້ອງຂໍລົ້ມເຫລວ. ໃຫ້ລະດົມກຳລັງ ແລະຊອກຫາເຫດຜົນ.

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

08:00. ແກ້ໄຂ API
ພວກ​ເຮົາ​ໄດ້​ອອກ​ການ​ແກ້​ໄຂ​ສໍາ​ລັບ​ການ​ໂຫຼດ​ໄດ້​, ຄວາມ​ລົ້ມ​ເຫຼວ​ໄດ້​ໄປ​. ພວກເຮົາເລີ່ມຕົ້ນກັບບ້ານ.

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

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

ດັ່ງນັ້ນ, ການເປີດຕົວສຳເລັດແລ້ວ! ແນ່ນອນ, ມັນອາດຈະດີກວ່າ, ແຕ່ພວກເຮົາໄດ້ສະຫຼຸບກ່ຽວກັບສິ່ງທີ່ບໍ່ພຽງພໍສໍາລັບພວກເຮົາທີ່ຈະບັນລຸຄວາມສົມບູນແບບ.

ລວມ

​ໃນ​ໄລຍະ 2 ​ເດືອນ​ຂອງ​ການ​ເຄື່ອນ​ໄຫວ​ກະກຽມ​ໃຫ້​ແກ່​ການ​ຜັນ​ຂະຫຍາຍ, ​ໄດ້​ປະຕິບັດ​ສຳ​ເລັດ 43 ໜ້າ​ວຽກ, ​ແຕ່​ສອງ​ສາມ​ຊົ່ວ​ໂມງ​ຫາ​ຫຼາຍ​ວັນ.

ໃນລະຫວ່າງການເປີດຕົວ:

• ຜີປີສາດໃຫມ່ແລະປ່ຽນແປງ - 5 ຊິ້ນ, ປ່ຽນແທນ 2 monoliths;
• ການປ່ຽນແປງພາຍໃນຖານຂໍ້ມູນ - ທັງຫມົດ 6 ຖານຂໍ້ມູນຂອງພວກເຮົາກັບຂໍ້ມູນຜູ້ໃຊ້ໄດ້ຮັບຜົນກະທົບ, ການດາວໂຫລດໄດ້ຖືກເຮັດຈາກສາມຖານຂໍ້ມູນເກົ່າໄປຫາຫນຶ່ງໃຫມ່;
• ການ​ອອກ​ແບບ​ຄືນ​ໃຫມ່​ທັງ​ຫມົດ frontend​;
• ຈໍານວນລະຫັດທີ່ດາວໂຫລດ - 33 ພັນເສັ້ນຂອງລະຫັດໃຫມ່, ≈ 3 ພັນເສັ້ນຂອງລະຫັດໃນການທົດສອບ, ≈ 5 ພັນເສັ້ນຂອງລະຫັດການເຄື່ອນຍ້າຍ;
• ຂໍ້​ມູນ​ທັງ​ຫມົດ​ແມ່ນ intact, ບໍ່​ແມ່ນ​ເຄື່ອງ virtual ຂອງ​ລູກ​ຄ້າ​ຄົນ​ດຽວ​ໄດ້​ຮັບ​ຄວາມ​ເສຍ​ຫາຍ. 🙂

ການປະຕິບັດທີ່ດີສໍາລັບການເປີດຕົວທີ່ດີ

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

1. ສິ່ງທໍາອິດທີ່ທ່ານຈໍາເປັນຕ້ອງເຮັດແມ່ນເຂົ້າໃຈວ່າການເປີດຕົວສາມາດຫຼືຜົນກະທົບຕໍ່ຜູ້ໃຊ້ໄດ້ແນວໃດ. ຈະມີການຢຸດເຮັດວຽກບໍ? ຖ້າເປັນດັ່ງນັ້ນ, ເວລາຢຸດເຮັດວຽກແມ່ນຫຍັງ? ນີ້ຈະມີຜົນກະທົບຜູ້ໃຊ້ແນວໃດ? ສະຖານະການກໍລະນີທີ່ດີທີ່ສຸດແລະຮ້າຍແຮງທີ່ສຸດທີ່ເປັນໄປໄດ້ແມ່ນຫຍັງ? ແລະກວມເອົາຄວາມສ່ຽງ.
2. ວາງແຜນທຸກຢ່າງ. ໃນ​ແຕ່​ລະ​ຂັ້ນ​ຕອນ​, ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ເຂົ້າ​ໃຈ​ທຸກ​ດ້ານ​ຂອງ​ການ​ຈັດ​ວາງ​:
   • ການຈັດສົ່ງລະຫັດ;
   • rollback ລະຫັດ;
   • ເວລາຂອງແຕ່ລະການດໍາເນີນງານ;
   • ການທໍາງານທີ່ໄດ້ຮັບຜົນກະທົບ.
3. ຫຼິ້ນຜ່ານສະຖານະການຈົນກ່ວາທຸກຂັ້ນຕອນຂອງການເປີດຕົວ, ເຊັ່ນດຽວກັນກັບຄວາມສ່ຽງຂອງແຕ່ລະຄົນ, ກາຍເປັນທີ່ຊັດເຈນ. ຖ້າທ່ານມີຄວາມສົງໃສ, ທ່ານສາມາດພັກຜ່ອນແລະກວດເບິ່ງຂັ້ນຕອນຄໍາຖາມແຍກຕ່າງຫາກ.
4. ແຕ່ລະຂັ້ນຕອນສາມາດແລະຄວນໄດ້ຮັບການປັບປຸງຖ້າມັນຊ່ວຍຜູ້ໃຊ້ຂອງພວກເຮົາ. ຕົວຢ່າງ, ມັນຈະຫຼຸດຜ່ອນເວລາຢຸດເຮັດວຽກຫຼືເອົາຄວາມສ່ຽງບາງຢ່າງ.
5. ການທົດສອບ Rollback ແມ່ນມີຄວາມສໍາຄັນຫຼາຍກ່ວາການທົດສອບການຈັດສົ່ງລະຫັດ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະກວດເບິ່ງວ່າເປັນຜົນມາຈາກການ rollback ລະບົບຈະກັບຄືນສູ່ສະພາບເດີມ, ແລະຢືນຢັນນີ້ດ້ວຍການທົດສອບ.
6. ທຸກສິ່ງທຸກຢ່າງທີ່ສາມາດອັດຕະໂນມັດຄວນຈະເປັນອັດຕະໂນມັດ. ທຸກສິ່ງທຸກຢ່າງທີ່ບໍ່ສາມາດອັດຕະໂນມັດຄວນຈະຖືກຂຽນລ່ວງຫນ້າຢູ່ໃນແຜ່ນ cheat.
7. ບັນທຶກເກນຄວາມສຳເລັດ. ຫນ້າທີ່ໃດທີ່ຄວນຈະມີແລະເວລາໃດ? ຖ້າອັນນີ້ບໍ່ເກີດຂຶ້ນ, ດໍາເນີນການແຜນການ rollback.
8. ແລະສໍາຄັນທີ່ສຸດ - ປະຊາຊົນ. ບຸກຄົນທຸກຄົນຄວນຈະຮັບຮູ້ສິ່ງທີ່ເຂົາເຈົ້າກໍາລັງເຮັດ, ເປັນຫຍັງແລະສິ່ງທີ່ຂຶ້ນກັບການກະທໍາຂອງເຂົາເຈົ້າໃນຂະບວນການເປີດຕົວ.

ແລະໃນປະໂຫຍກຫນຶ່ງ, ດ້ວຍການວາງແຜນທີ່ດີແລະລະອຽດທ່ານສາມາດມ້ວນສິ່ງທີ່ທ່ານຕ້ອງການໂດຍບໍ່ມີຜົນສະທ້ອນຕໍ່ການຂາຍ. ເຖິງແມ່ນວ່າບາງສິ່ງບາງຢ່າງທີ່ຈະສົ່ງຜົນກະທົບຕໍ່ການບໍລິການທັງຫມົດຂອງທ່ານໃນການຜະລິດ.

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