ລະບົບ ISP, ໃຫ້ອະໄພ ແລະອຳລາ! ເປັນຫຍັງແລະວິທີທີ່ພວກເຮົາຂຽນກະດານຄວບຄຸມເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ

ສະບາຍດີ! ພວກເຮົາແມ່ນ "Hosting Technologies" ແລະເປີດຕົວ 5 ປີກ່ອນຫນ້ານີ້ VDSina — vds hosting ທໍາອິດທີ່ສ້າງຂຶ້ນໂດຍສະເພາະສໍາລັບນັກພັດທະນາ. ພວກເຮົາພະຍາຍາມເຮັດໃຫ້ມັນສະດວກ, ຄືກັບ DigitalOcean, ແຕ່ດ້ວຍການສະຫນັບສະຫນູນພາສາລັດເຊຍ, ວິທີການຊໍາລະເງິນແລະເຄື່ອງແມ່ຂ່າຍໃນລັດເຊຍ. ແຕ່ DigitalOcean ບໍ່ພຽງແຕ່ຄວາມຫນ້າເຊື່ອຖືແລະລາຄາ, ມັນຍັງເປັນການບໍລິການ.

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

ລະບົບ ISP ຂ້າຄວາມສະດວກສະບາຍແນວໃດ

ບັກ

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

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

ໄພຂົ່ມຂູ່ຕໍ່ເວລາຢຸດເຮັດວຽກ

ການອັບເດດສາມາດສ້າງເວລາຢຸດເຮັດວຽກທີ່ບໍ່ສາມາດຄາດເດົາໄດ້ທີ່ເຮັດໃຫ້ເກີດຄວາມຜິດພາດໃໝ່.

ແຕ່ລະການປັບປຸງແມ່ນ lottery: ຂ້າພະເຈົ້າໄດ້ກວມເອົາເຖິງການເອີ້ນເກັບເງິນແລະເຮັດໃຫ້ການເສຍສະລະກັບພຣະເຈົ້າຂອງການປັບປຸງ - ສອງສາມຄັ້ງການປັບປຸງເຮັດໃຫ້ downtime ສໍາລັບ 10-15 ນາທີ. ຜູ້ເບິ່ງແຍງຂອງພວກເຮົາໃນເວລານີ້ໄດ້ນັ່ງເບິ່ງພວກເຂົາ - ພວກເຮົາບໍ່ເຄີຍຮູ້ວ່າເວລາຢຸດຈະຢູ່ດົນປານໃດແລະບໍ່ສາມາດຄາດເດົາໄດ້ວ່າລະບົບ ISP ຈະຕັດສິນໃຈປ່ອຍການປັບປຸງໃຫມ່ເມື່ອໃດ.

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

ການໂຕ້ຕອບແຜງບໍ່ສະດວກ

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

ການໂຕ້ຕອບດັ່ງກ່າວໃຊ້ເວລາ - ທັງຂອງພວກເຮົາແລະລູກຄ້າຂອງພວກເຮົາ '. ບໍ່ມີຄໍາຖາມກ່ຽວກັບຄວາມສະດວກສະບາຍໃດໆ, ເຊັ່ນດຽວກັບ DigitalOcean, ໃນສະຖານະການດັ່ງກ່າວ.

ວົງຈອນຊີວິດສັ້ນທີ່ມີການອັບເດດ API ເລື້ອຍໆ

ພວກເຮົາຂຽນ plugins ຂອງພວກເຮົາເອງ - ຕົວຢ່າງ, plugin ທີ່ມີວິທີການຊໍາລະເງິນເພີ່ມເຕີມທີ່ບໍ່ມີຢູ່ໃນ VMManager.

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

ບໍ່ສາມາດແກ້ໄຂໄດ້

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

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

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

ແລະພວກເຮົາໄດ້ເລີ່ມຕົ້ນການພັດທະນາ.

ສະຖາປັດຕະຍະກໍາ Panel ໃຫມ່

ພວກເຮົາມີທີມງານພັດທະນາຕົນເອງ, ສະນັ້ນພວກເຮົາຂຽນກະດານດ້ວຍຕົນເອງ.
ວຽກງານຕົ້ນຕໍແມ່ນເຮັດໂດຍວິສະວະກອນສາມຄົນ - ຜູ້ອໍານວຍການດ້ານວິຊາການ Sergey ມາກັບສະຖາປັດຕະຍະກໍາແລະຂຽນຕົວແທນເຊີຟເວີ, Alexey ເຮັດການເອີ້ນເກັບເງິນ, ແລະດ້ານຫນ້າແມ່ນປະກອບໂດຍ Artysh ດ້ານຫນ້າຂອງພວກເຮົາ.

ຂັ້ນຕອນທີ 1: ຕົວແທນເຊີບເວີ

ຕົວແທນເຊີບເວີແມ່ນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ python ທີ່ຄຸ້ມຄອງຫ້ອງສະຫມຸດ ເສລີພາບ, ຊຶ່ງ​ໃນ​ການ​ປົກ​ຄອງ​ Qemu-kvm hypervisor.

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

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

ຕົວແທນແມ່ນສິ່ງທໍາອິດທີ່ພວກເຮົາເຮັດ, ເນື່ອງຈາກວ່າມັນບໍ່ຈໍາເປັນຕ້ອງມີການໂຕ້ຕອບໃດໆແລະມັນເປັນໄປໄດ້ທີ່ຈະທົດສອບໂດຍກົງຈາກ server console.

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

ຂັ້ນຕອນທີ 2. ໃບບິນ

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

ພວກເຮົາເອີ້ນການເອີ້ນເກັບເງິນລະຫວ່າງຕົວເຮົາເອງວ່າ "ກະດານຄວບຄຸມ": ມັນບໍ່ພຽງແຕ່ປະກອບມີເງິນແລະການບໍລິການ, ແຕ່ຍັງການຄຸ້ມຄອງຂອງພວກເຂົາ, ການສະຫນັບສະຫນູນລູກຄ້າແລະອື່ນໆອີກ.

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

ການເອີ້ນເກັບເງິນໃຫມ່ໄດ້ນໍາໃຊ້ສອງ stacks: PHP ຄລາສສິກ, MySQL (ແລະໃນອະນາຄົດມັນໄດ້ຖືກວາງແຜນທີ່ຈະປ່ຽນເປັນ PostgreSQL), Yii2 ເປັນກອບໃນ backend ແລະ VueJS ຢູ່ດ້ານຫນ້າ. Stacks ເຮັດວຽກເປັນເອກະລາດເຊິ່ງກັນແລະກັນ, ຖືກພັດທະນາໂດຍຄົນທີ່ແຕກຕ່າງກັນ, ແລະຕິດຕໍ່ສື່ສານໂດຍໃຊ້ JSON API. ສໍາລັບການພັດທະນາຫຼັງຈາກນັ້ນແລະໃນປັດຈຸບັນພວກເຮົານໍາໃຊ້ ພາຍຸ PHPS и webstorm ຈາກ JetBrains ແລະຮັກພວກເຂົາຢ່າງສຸດໃຈ (hey guys!)

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

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

ຂັ້ນຕອນທີ 3 ການໂຕ້ຕອບ

ການໂຕ້ຕອບແມ່ນຄວາມຄິດຂອງທີມງານຂອງພວກເຮົາ.

ທໍາອິດ, ພວກເຮົາໄດ້ເບິ່ງສິ່ງທີ່ຈະເກີດຂຶ້ນຖ້າພວກເຮົາສ້າງ add-on ໃນໄລຍະ ISPsystem API ໂດຍບໍ່ມີການປ່ຽນແປງພື້ນຖານໃນການໂຕ້ຕອບ. ມັນ​ໄດ້​ຫັນ​ອອກ​ດັ່ງ​ນັ້ນ​ແລະ​ພວກ​ເຮົາ​ໄດ້​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ເຮັດ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ຈາກ scratch​.

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

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

ດ້ານໜ້າ

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

ການ​ເຊື່ອມ​ຕໍ່​ຫນ້າ​ກັບ backend ໄດ້​

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

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

ຂັ້ນ​ຕອນ​ທີ 4. ໂຄງ​ການ​ທົດ​ສອບ​ແລະ​ການ​ເຄື່ອນ​ຍ້າຍ​

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

ຫຼັງຈາກນັ້ນ, ພວກເຮົາຂຽນສະຄິບງ່າຍໆທີ່ໂອນຖານຂໍ້ມູນຈາກໃບບິນເກົ່າໄປຫາອັນໃຫມ່.

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

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

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

ໃນທີ່ສຸດ: ມັນມີຊີວິດຢູ່!

ຈົບງາມ

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

ການທົບທວນຄືນຄັ້ງທໍາອິດຫຼັງຈາກການເປີດຕົວຂອງຄະນະກໍາມະໃຫມ່

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

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

ຈະເປັນແນວໃດຕໍ່ໄປ?

ພວກເຮົາກໍາລັງເຕີບໂຕ, ຈໍານວນຂໍ້ມູນ, ລູກຄ້າ, ຂໍ້ມູນຂອງລູກຄ້າກໍາລັງເຕີບໂຕ. ຂ້ອຍຕ້ອງເພີ່ມເຄື່ອງແມ່ຂ່າຍ Memcached ແລະຜູ້ຈັດການຄິວສອງຄົນທີ່ມີວຽກທີ່ແຕກຕ່າງກັນກັບ backend. ດ້ານໜ້າມີຖານຄວາມຈຳ ແລະຄິວຂອງຕົນເອງ.

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

ໃນບົດຄວາມຕໍ່ໄປ, ພວກເຮົາຈະບອກທ່ານວ່າອັດຕາພາສີ Hi-CPU ໄດ້ຖືກເປີດຕົວແນວໃດ: ກ່ຽວກັບຮາດແວ, ຊອບແວ, ສິ່ງທີ່ພວກເຮົາແກ້ໄຂແລະສິ່ງທີ່ພວກເຮົາເຮັດ.

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