Bitrix24: "ສິ່ງທີ່ຖືກຍົກຂຶ້ນມາຢ່າງໄວວາບໍ່ໄດ້ຖືກພິຈາລະນາວ່າຈະຫຼຸດລົງ"

ໃນມື້ນີ້, ການບໍລິການ Bitrix24 ບໍ່ມີການຈະລາຈອນຫຼາຍຮ້ອຍ gigabits, ແລະບໍ່ມີເຮືອເຊີຟເວີຂະຫນາດໃຫຍ່ (ເຖິງແມ່ນວ່າ, ແນ່ນອນ, ມີຈໍານວນຫນ້ອຍທີ່ມີຢູ່). ແຕ່ສໍາລັບລູກຄ້າຈໍານວນຫຼາຍມັນເປັນເຄື່ອງມືຕົ້ນຕໍໃນການເຮັດວຽກໃນບໍລິສັດ; ມັນເປັນຄໍາຮ້ອງສະຫມັກທີ່ສໍາຄັນສໍາລັບທຸລະກິດທີ່ແທ້ຈິງ. ດັ່ງນັ້ນ, ບໍ່ມີທາງທີ່ຈະລົ້ມລົງ. ຈະເປັນແນວໃດຖ້າອຸປະຕິເຫດເກີດຂຶ້ນ, ແຕ່ການບໍລິການ "ຟື້ນຕົວ" ຢ່າງໄວວາທີ່ບໍ່ມີໃຜສັງເກດເຫັນຫຍັງ? ແລະມັນເປັນໄປໄດ້ແນວໃດທີ່ຈະປະຕິບັດການລົ້ມເຫລວໂດຍບໍ່ສູນເສຍຄຸນນະພາບຂອງການເຮັດວຽກແລະຈໍານວນລູກຄ້າ? Alexander Demidov, ຜູ້ ອຳ ນວຍການຝ່າຍບໍລິການຄລາວຢູ່ Bitrix24, ໄດ້ເວົ້າກັບ blog ຂອງພວກເຮົາກ່ຽວກັບວິທີການຈອງໄດ້ພັດທະນາໃນໄລຍະ 7 ປີຂອງການມີຢູ່ຂອງຜະລິດຕະພັນ.

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

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

Bitrix.24 ເປັນ SaaS

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

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

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

ພວກເຮົາໄດ້ສະຫນັບສະຫນູນໃນລະດັບຜະລິດຕະພັນສໍາລັບການເກັບຮັກສາວັດຖຸ cloud ຕ່າງໆ: google storage, amazon s3, ບວກກັບການສະຫນັບສະຫນູນສໍາລັບ open stack swift. ດັ່ງນັ້ນ, ນີ້ແມ່ນສະດວກສໍາລັບພວກເຮົາທັງການບໍລິການແລະສໍາລັບນັກພັດທະນາທີ່ເຮັດວຽກກັບການແກ້ໄຂການຫຸ້ມຫໍ່: ຖ້າພວກເຂົາພຽງແຕ່ໃຊ້ API ຂອງພວກເຮົາສໍາລັບການເຮັດວຽກ, ພວກເຂົາບໍ່ໄດ້ຄິດກ່ຽວກັບບ່ອນທີ່ໄຟລ໌ຈະຖືກບັນທຶກໄວ້ໃນທີ່ສຸດ, ຢູ່ໃນລະບົບໄຟລ໌ຫຼື. ໃນ​ການ​ເກັບ​ຮັກ​ສາ​ໄຟລ​໌​ວັດ​ຖຸ​.

ດັ່ງນັ້ນ, ພວກເຮົາຕັດສິນໃຈທັນທີວ່າພວກເຮົາຈະສະຫງວນຢູ່ໃນລະດັບຂອງສູນຂໍ້ມູນທັງຫມົດ. ໃນປີ 2012, ພວກເຮົາໄດ້ເປີດຕົວທັງຫມົດໃນ Amazon AWS ເພາະວ່າພວກເຮົາມີປະສົບການກັບເວທີນີ້ແລ້ວ - ເວັບໄຊທ໌ຂອງພວກເຮົາເອງໄດ້ຖືກໂຮດຢູ່ທີ່ນັ້ນ. ພວກເຮົາໄດ້ຮັບຄວາມສົນໃຈຈາກຄວາມຈິງທີ່ວ່າໃນແຕ່ລະພາກພື້ນ Amazon ມີຫຼາຍເຂດທີ່ສາມາດໃຊ້ໄດ້ - ໃນຄວາມເປັນຈິງ, (ໃນຄໍາສັບຂອງພວກເຂົາ) ສູນຂໍ້ມູນຈໍານວນຫນຶ່ງທີ່ມີຫຼາຍຫຼືຫນ້ອຍເປັນເອກະລາດຂອງກັນແລະກັນແລະອະນຸຍາດໃຫ້ພວກເຮົາສະຫງວນຢູ່ໃນລະດັບຂອງສູນຂໍ້ມູນທັງຫມົດ: ຖ້າມັນລົ້ມເຫລວຢ່າງກະທັນຫັນ, ຖານຂໍ້ມູນແມ່ນ replicated master-master, web application servers ຖືກສໍາຮອງ, ແລະຂໍ້ມູນຄົງທີ່ຈະຖືກຍ້າຍໄປບ່ອນເກັບມ້ຽນວັດຖຸ s3. ການໂຫຼດແມ່ນມີຄວາມສົມດູນ - ໃນເວລານັ້ນໂດຍ Amazon elb, ແຕ່ເລັກນ້ອຍຕໍ່ມາພວກເຮົາມາຮອດຕົວດຸ່ນດ່ຽງການໂຫຼດຂອງພວກເຮົາເອງ, ເພາະວ່າພວກເຮົາຕ້ອງການເຫດຜົນທີ່ສັບສົນຫຼາຍ.

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

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

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

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

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

ພວກເຮົາໄດ້ສະຫງວນທຸກຢ່າງບໍ?

ພວກເຮົາມີລູກຄ້າຈໍານວນຫຼາຍຈາກອາເມລິກາ, ລູກຄ້າຈໍານວນຫຼາຍຈາກເອີຣົບ, ລູກຄ້າຫຼາຍຄົນທີ່ໃກ້ຊິດກັບຕາເວັນອອກ - ຍີ່ປຸ່ນ, ສິງກະໂປແລະອື່ນໆ. ແນ່ນອນ, ສ່ວນແບ່ງຂະຫນາດໃຫຍ່ຂອງລູກຄ້າແມ່ນຢູ່ໃນລັດເຊຍ. ນັ້ນແມ່ນ, ການເຮັດວຽກບໍ່ແມ່ນຢູ່ໃນພາກພື້ນຫນຶ່ງ. ຜູ້ໃຊ້ຕ້ອງການການຕອບສະຫນອງໄວ, ມີຄວາມຕ້ອງການປະຕິບັດຕາມກົດຫມາຍທ້ອງຖິ່ນຕ່າງໆ, ແລະພາຍໃນແຕ່ລະພາກພື້ນພວກເຮົາສະຫງວນສອງສູນຂໍ້ມູນ, ບວກກັບການບໍລິການເພີ່ມເຕີມບາງຢ່າງ, ເຊິ່ງ, ອີກເທື່ອຫນຶ່ງ, ສະດວກໃນການຈັດວາງພາຍໃນຫນຶ່ງພາກພື້ນ - ສໍາລັບລູກຄ້າທີ່ຢູ່ໃນ. ພາກພື້ນນີ້ເຮັດວຽກ. ຕົວຈັດການ REST, ເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດ, ພວກມັນມີຄວາມສໍາຄັນຫນ້ອຍສໍາລັບການປະຕິບັດງານຂອງລູກຄ້າໂດຍລວມ, ທ່ານສາມາດປ່ຽນຜ່ານພວກມັນດ້ວຍການຊັກຊ້າທີ່ຍອມຮັບໄດ້ເລັກນ້ອຍ, ແຕ່ທ່ານບໍ່ຕ້ອງການສ້າງລໍ້ໃຫມ່ກ່ຽວກັບວິທີການຕິດຕາມພວກເຂົາແລະສິ່ງທີ່ຕ້ອງເຮັດ. ກັບ​ພວກ​ເຂົາ. ດັ່ງນັ້ນ, ພວກເຮົາກໍາລັງພະຍາຍາມໃຊ້ວິທີແກ້ໄຂທີ່ມີຢູ່ໃຫ້ສູງສຸດ, ແທນທີ່ຈະພັດທະນາຄວາມສາມາດບາງຢ່າງໃນຜະລິດຕະພັນເພີ່ມເຕີມ. ແລະບາງບ່ອນທີ່ພວກເຮົາໃຊ້ການສະຫຼັບໃນລະດັບ DNS, ແລະພວກເຮົາກໍານົດຄວາມສົດຊື່ນຂອງການບໍລິການໂດຍ DNS ດຽວກັນ. Amazon ມີບໍລິການເສັ້ນທາງ 53, ແຕ່ມັນບໍ່ແມ່ນພຽງແຕ່ DNS ທີ່ທ່ານສາມາດເຮັດລາຍການແລະນັ້ນແມ່ນມັນ - ມັນມີຄວາມຍືດຫຍຸ່ນແລະສະດວກກວ່າ. ຜ່ານມັນທ່ານສາມາດສ້າງການບໍລິການແຈກຢາຍທາງພູມສາດດ້ວຍສະຖານທີ່ຕັ້ງພູມສາດ, ເມື່ອທ່ານໃຊ້ມັນເພື່ອກໍານົດບ່ອນທີ່ລູກຄ້າມາຈາກແລະໃຫ້ບັນທຶກທີ່ແນ່ນອນ - ດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນ, ທ່ານສາມາດສ້າງສະຖາປັດຕະຍະກໍາທີ່ລົ້ມເຫລວ. ການກວດສອບສຸຂະພາບດຽວກັນໄດ້ຖືກຕັ້ງຄ່າຢູ່ໃນເສັ້ນທາງ 53 ຕົວຂອງມັນເອງ, ທ່ານກໍານົດຈຸດສິ້ນສຸດທີ່ຕິດຕາມ, ກໍານົດຕົວຊີ້ວັດ, ກໍານົດວ່າໂປໂຕຄອນໃດທີ່ຈະກໍານົດ "ຊີວິດ" ຂອງການບໍລິການ - tcp, http, https; ກໍານົດຄວາມຖີ່ຂອງການກວດສອບທີ່ກໍານົດວ່າການບໍລິການມີຊີວິດຢູ່ຫຼືບໍ່. ແລະໃນ DNS ຕົວມັນເອງທ່ານລະບຸສິ່ງທີ່ຈະເປັນປະຖົມ, ສິ່ງທີ່ຈະເປັນຮອງ, ບ່ອນທີ່ຈະປ່ຽນຖ້າການກວດສອບສຸຂະພາບຖືກກະຕຸ້ນພາຍໃນເສັ້ນທາງ 53. ທັງຫມົດນີ້ສາມາດເຮັດໄດ້ດ້ວຍເຄື່ອງມືອື່ນໆ, ແຕ່ເປັນຫຍັງມັນສະດວກ - ພວກເຮົາຕັ້ງມັນ. ຂຶ້ນຄັ້ງໜຶ່ງແລ້ວຢ່າຄິດເລື່ອງມັນເລີຍວ່າພວກເຮົາຈະກວດສອບແນວໃດ, ເຮັດແນວໃດພວກເຮົາປ່ຽນ: ທຸກຢ່າງເຮັດວຽກດ້ວຍຕົວມັນເອງ.

ທໍາອິດ "ແຕ່": ວິທີການແລະສິ່ງທີ່ສະຫງວນເສັ້ນທາງ 53 ຕົວຂອງມັນເອງ? ໃຜຮູ້, ຖ້າບາງສິ່ງບາງຢ່າງເກີດຂື້ນກັບລາວ? ໂຊກດີ, ພວກເຮົາບໍ່ເຄີຍໄດ້ຍ່າງເທິງ rake ນີ້, ແຕ່ອີກເທື່ອຫນຶ່ງ, ຂ້າພະເຈົ້າຈະມີເລື່ອງລ່ວງຫນ້າວ່າເປັນຫຍັງພວກເຮົາຄິດວ່າພວກເຮົາຍັງຈໍາເປັນຕ້ອງໄດ້ຈອງ. ທີ່ນີ້ພວກເຮົາໄດ້ວາງເຟືອງສໍາລັບຕົວເຮົາເອງລ່ວງຫນ້າ. ຫຼາຍໆຄັ້ງຕໍ່ມື້ພວກເຮົາເຮັດການ unload ສໍາເລັດຂອງເຂດທັງຫມົດທີ່ພວກເຮົາມີຢູ່ໃນເສັ້ນທາງ 53. API ຂອງ Amazon ຊ່ວຍໃຫ້ທ່ານສາມາດສົ່ງພວກມັນໄດ້ງ່າຍໃນ JSON, ແລະພວກເຮົາມີເຄື່ອງແມ່ຂ່າຍສໍາຮອງຫຼາຍບ່ອນທີ່ພວກເຮົາປ່ຽນມັນ, ອັບໂຫລດມັນໃນຮູບແບບຂອງການຕັ້ງຄ່າແລະມີ, ປະມານການເວົ້າ, ການຕັ້ງຄ່າສໍາຮອງຂໍ້ມູນ. ຖ້າມີບາງສິ່ງບາງຢ່າງເກີດຂຶ້ນ, ພວກເຮົາສາມາດນໍາມັນໄປໃຊ້ໄດ້ໄວໂດຍບໍ່ມີການສູນເສຍຂໍ້ມູນການຕັ້ງຄ່າ DNS.

ອັນທີສອງ "ແຕ່": ອັນໃດໃນຮູບນີ້ຍັງບໍ່ທັນຈອງ? ຜູ້ດຸ່ນດ່ຽງຕົວມັນເອງ! ການແຈກຢາຍລູກຄ້າຂອງພວກເຮົາຕາມພາກພື້ນແມ່ນເຮັດໃຫ້ງ່າຍດາຍຫຼາຍ. ພວກເຮົາມີໂດເມນ bitrix24.ru, bitrix24.com, .de - ໃນປັດຈຸບັນມີ 13 ໂດເມນທີ່ແຕກຕ່າງກັນ, ເຊິ່ງດໍາເນີນການຢູ່ໃນຫຼາຍໆເຂດ. ພວກເຮົາມາຮອດຕໍ່ໄປນີ້: ແຕ່ລະພາກພື້ນມີຕົວດຸ່ນດ່ຽງຂອງຕົນເອງ. ນີ້ເຮັດໃຫ້ມັນສະດວກກວ່າໃນການແຈກຢາຍໃນທົ່ວພາກພື້ນ, ຂຶ້ນກັບບ່ອນທີ່ການໂຫຼດສູງສຸດໃນເຄືອຂ່າຍ. ຖ້າຫາກວ່ານີ້ແມ່ນຄວາມລົ້ມເຫຼວໃນລະດັບຂອງ balancer ດຽວ, ຫຼັງຈາກນັ້ນພຽງແຕ່ເອົາອອກຈາກການບໍລິການແລະເອົາອອກຈາກ dns. ຖ້າມີບັນຫາບາງຢ່າງກັບກຸ່ມຜູ້ດຸ່ນດ່ຽງ, ຫຼັງຈາກນັ້ນພວກເຂົາຖືກສໍາຮອງຂໍ້ມູນຢູ່ໃນເວັບໄຊທ໌ອື່ນໆ, ແລະການປ່ຽນລະຫວ່າງພວກມັນແມ່ນເຮັດໂດຍໃຊ້ເສັ້ນທາງດຽວກັນ 53, ເພາະວ່າເນື່ອງຈາກ TTL ສັ້ນ, ການສະຫຼັບເກີດຂື້ນພາຍໃນເວລາສູງສຸດ 2, 3, 5 ນາທີ. .

ອັນທີສາມ "ແຕ່": ອັນໃດທີ່ຍັງບໍ່ທັນຈອງ? S3, ຖືກຕ້ອງ. ເມື່ອພວກເຮົາວາງໄຟລ໌ທີ່ພວກເຮົາເກັບຮັກສາໄວ້ສໍາລັບຜູ້ໃຊ້ໃນ s3, ພວກເຮົາເຊື່ອຢ່າງຈິງໃຈວ່າມັນແມ່ນການເຈາະເກາະແລະບໍ່ຈໍາເປັນຕ້ອງສະຫງວນຫຍັງຢູ່ທີ່ນັ້ນ. ແຕ່ປະຫວັດສາດສະແດງໃຫ້ເຫັນວ່າສິ່ງຕ່າງໆເກີດຂື້ນແຕກຕ່າງກັນ. ໂດຍທົ່ວໄປ, Amazon ອະທິບາຍ S3 ເປັນບໍລິການພື້ນຖານ, ເພາະວ່າ Amazon ເອງໃຊ້ S3 ເພື່ອເກັບຮັກສາຮູບພາບເຄື່ອງຈັກ, configs, ຮູບພາບ AMI, snapshots ... ແລະຖ້າ s3 crash, ດັ່ງທີ່ເກີດຂື້ນຄັ້ງດຽວໃນລະຫວ່າງ 7 ປີນີ້, ຕາບໃດທີ່ພວກເຮົາໄດ້ໃຊ້ bitrix24, ມັນປະຕິບັດຕາມມັນຄືກັບພັດລົມ, ມີສິ່ງຫຼາຍຢ່າງທີ່ເກີດຂື້ນ - ຄວາມບໍ່ສາມາດເລີ່ມຕົ້ນເຄື່ອງຈັກ virtual, ຄວາມລົ້ມເຫຼວຂອງ api, ແລະອື່ນໆ.

ແລະ S3 ສາມາດຫຼຸດລົງ - ມັນເກີດຂຶ້ນຄັ້ງດຽວ. ດັ່ງນັ້ນ, ພວກເຮົາມາຮອດໂຄງການດັ່ງຕໍ່ໄປນີ້: ສອງສາມປີກ່ອນບໍ່ມີສະຖານທີ່ເກັບຮັກສາວັດຖຸສາທາລະນະທີ່ຮ້າຍແຮງຢູ່ໃນລັດເຊຍ, ແລະພວກເຮົາພິຈາລະນາທາງເລືອກທີ່ຈະເຮັດບາງສິ່ງບາງຢ່າງຂອງຕົນເອງ ... ໂຊກດີ, ພວກເຮົາບໍ່ໄດ້ເລີ່ມເຮັດສິ່ງນີ້, ເພາະວ່າພວກເຮົາຈະ ໄດ້ຂຸດເຂົ້າໄປໃນຄວາມຊໍານານທີ່ພວກເຮົາບໍ່ມີພວກເຮົາມີ, ແລະອາດຈະລັງກິນອາຫານ. ໃນປັດຈຸບັນ Mail.ru ມີການເກັບຮັກສາທີ່ເຂົ້າກັນໄດ້ s3, Yandex ມີມັນ, ແລະຜູ້ໃຫ້ບໍລິການອື່ນໆຈໍານວນຫນຶ່ງມີມັນ. ໃນທີ່ສຸດພວກເຮົາກໍ່ມາຮອດຄວາມຄິດທີ່ພວກເຮົາຢາກມີ, ທໍາອິດ, ສໍາຮອງຂໍ້ມູນ, ແລະອັນທີສອງ, ຄວາມສາມາດໃນການເຮັດວຽກກັບສໍາເນົາທ້ອງຖິ່ນ. ສໍາລັບພາກພື້ນລັດເຊຍໂດຍສະເພາະ, ພວກເຮົາໃຊ້ບໍລິການ Mail.ru Hotbox, ເຊິ່ງເປັນ API ທີ່ເຂົ້າກັນໄດ້ກັບ s3. ພວກເຮົາບໍ່ຕ້ອງການການດັດແກ້ທີ່ສໍາຄັນໃດໆກັບລະຫັດພາຍໃນແອັບພລິເຄຊັນ, ແລະພວກເຮົາສ້າງກົນໄກຕໍ່ໄປນີ້: ໃນ s3 ມີຕົວກະຕຸ້ນທີ່ເຮັດໃຫ້ເກີດການສ້າງ / ລຶບວັດຖຸ, Amazon ມີບໍລິການທີ່ເອີ້ນວ່າ Lambda - ນີ້ແມ່ນການເປີດຕົວລະຫັດ serverless. ທີ່ຈະຖືກປະຕິບັດພຽງແຕ່ໃນເວລາທີ່ຜົນກະທົບຕໍ່ສະເພາະໃດຫນຶ່ງແມ່ນ triggered.

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

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

ໂອ້ຍ, ແລະ Amazon ແລ່ນຫນີ ...

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

ຖ້າຫາກວ່າບໍລິສັດແມ່ນທົ່ວໂລກແລະລັດເຊຍເປັນສ່ວນຂະຫນາດນ້ອຍຫຼາຍສໍາລັບມັນ, 3-5% - ດີ, ວິທີການຫນຶ່ງຫຼືອື່ນ, ທ່ານສາມາດເສຍສະລະໃຫ້ເຂົາເຈົ້າ.

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

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

ໃນທ້າຍເດືອນມີນາ 2018, Roskomnadzor ໄດ້ສົ່ງຈົດຫມາຍເຖິງຜູ້ປະກອບການທີ່ໃຫຍ່ທີ່ສຸດໂດຍລະບຸວ່າພວກເຂົາວາງແຜນທີ່ຈະບລັອກ Amazon IP ຫຼາຍລ້ານເພື່ອສະກັດ ... ຂ່າວສານ Zello. ຂໍຂອບໃຈກັບຜູ້ໃຫ້ບໍລິການດຽວກັນເຫຼົ່ານີ້ - ພວກເຂົາເຈົ້າສົບຜົນສໍາເລັດຮົ່ວໄຫລຈົດຫມາຍໄປຫາທຸກຄົນ, ແລະມີຄວາມເຂົ້າໃຈວ່າການເຊື່ອມຕໍ່ກັບ Amazon ສາມາດແຕກແຍກ. ມັນແມ່ນວັນສຸກ, ພວກເຮົາໄດ້ແລ່ນໄປດ້ວຍຄວາມຕົກໃຈກັບເພື່ອນຮ່ວມງານຂອງພວກເຮົາຈາກ servers.ru, ໂດຍກ່າວວ່າ: "ເພື່ອນ, ພວກເຮົາຕ້ອງການເຄື່ອງແມ່ຂ່າຍຫຼາຍຢ່າງທີ່ຈະຕັ້ງຢູ່ໃນລັດເຊຍ, ບໍ່ແມ່ນຢູ່ໃນ Amazon, ແຕ່, ສໍາລັບຕົວຢ່າງ, ບາງບ່ອນໃນ Amsterdam," ໃນຄໍາສັ່ງ. ເພື່ອໃຫ້ສາມາດຕິດຕັ້ງ VPN ແລະ proxy ຂອງພວກເຮົາຢ່າງນ້ອຍຢູ່ທີ່ນັ້ນສໍາລັບບາງຈຸດສິ້ນສຸດທີ່ພວກເຮົາບໍ່ສາມາດມີອິດທິພົນໃນທາງໃດກໍ່ຕາມ, ຕົວຢ່າງ endponts ຂອງ s3 ດຽວກັນ - ພວກເຮົາບໍ່ສາມາດພະຍາຍາມຍົກສູງການບໍລິການໃຫມ່ແລະໄດ້ຮັບ ip ທີ່ແຕກຕ່າງກັນ, ພວກເຮົາຍັງຕ້ອງການໄປເຖິງບ່ອນນັ້ນ. ໃນເວລາພຽງສອງສາມມື້, ພວກເຮົາຕັ້ງຄ່າເຄື່ອງແມ່ຂ່າຍເຫຼົ່ານີ້, ເຮັດໃຫ້ພວກເຂົາຂຶ້ນແລະແລ່ນ, ແລະ, ໂດຍທົ່ວໄປ, ການກະກຽມສໍາລັບເວລາທີ່ການປິດກັ້ນໄດ້ເລີ່ມຕົ້ນ. ມັນເປັນເລື່ອງທີ່ຢາກຮູ້ຢາກເຫັນທີ່ RKN, ເບິ່ງຄວາມວຸ່ນວາຍແລະຄວາມຕົກໃຈ, ເວົ້າວ່າ: "ບໍ່, ພວກເຮົາຈະບໍ່ຂັດຂວາງຫຍັງເລີຍ." (ແຕ່ນີ້ແມ່ນແທ້ຈົນກ່ວາເວລາທີ່ Telegram ເລີ່ມຕົ້ນຖືກບລັອກ.) ໂດຍໄດ້ຕັ້ງຄວາມສາມາດທາງຂ້າມແລະຮູ້ວ່າການປິດກັ້ນບໍ່ໄດ້ຖືກນໍາສະເຫນີ, ແນວໃດກໍ່ຕາມ, ພວກເຮົາບໍ່ໄດ້ເລີ່ມຈັດລຽງເລື່ອງທັງຫມົດ. ແມ່ນແລ້ວ, ໃນກໍລະນີ.

ແລະໃນປີ 2019, ພວກເຮົາຍັງຢູ່ໃນເງື່ອນໄຂຂອງການຂັດຂວາງ. ຂ້າພະເຈົ້າໄດ້ເບິ່ງຄືນທີ່ຜ່ານມາ: ປະມານຫນຶ່ງລ້ານ IP ຍັງສືບຕໍ່ຖືກບລັອກ. ແທ້ຈິງແລ້ວ, Amazon ເກືອບຖືກສະກັດຢ່າງສົມບູນ, ໃນຈຸດສູງສຸດຂອງມັນໄດ້ບັນລຸເຖິງ 20 ລ້ານທີ່ຢູ່ ... ໂດຍທົ່ວໄປແລ້ວ, ຄວາມເປັນຈິງແມ່ນອາດຈະບໍ່ມີຄວາມສອດຄ່ອງ, ຄວາມສອດຄ່ອງທີ່ດີ. ທັນໃດນັ້ນ. ມັນອາດຈະບໍ່ມີຢູ່ສໍາລັບເຫດຜົນດ້ານວິຊາການ - ໄຟໄຫມ້, ເຄື່ອງຂຸດ, ທັງຫມົດນັ້ນ. ຫຼື, ດັ່ງທີ່ພວກເຮົາໄດ້ເຫັນ, ບໍ່ແມ່ນດ້ານວິຊາການທັງຫມົດ. ດັ່ງນັ້ນ, ຜູ້ໃດຜູ້ຫນຶ່ງຂະຫນາດໃຫຍ່ແລະຂະຫນາດໃຫຍ່, ດ້ວຍ ASs ຂອງຕົນເອງ, ອາດຈະສາມາດຈັດການນີ້ໃນທາງອື່ນ - ການເຊື່ອມຕໍ່ໂດຍກົງແລະສິ່ງອື່ນໆແມ່ນຢູ່ໃນລະດັບ l2 ແລ້ວ. ແຕ່ໃນສະບັບທີ່ງ່າຍດາຍ, ຄືກັບຂອງພວກເຮົາຫຼືແມ້ກະທັ້ງນ້ອຍກວ່າ, ທ່ານສາມາດ, ພຽງແຕ່ໃນກໍລະນີທີ່, ມີການຊໍ້າຊ້ອນໃນລະດັບຂອງເຄື່ອງແມ່ຂ່າຍທີ່ຍົກຂຶ້ນມາບ່ອນອື່ນ, configured ລ່ວງຫນ້າ vpn, proxy, ມີຄວາມສາມາດໃນການປ່ຽນການຕັ້ງຄ່າຢ່າງໄວວາກັບພວກເຂົາຢູ່ໃນພາກສ່ວນເຫຼົ່ານັ້ນ. ທີ່​ສໍາ​ຄັນ​ສໍາ​ລັບ​ການ​ເຊື່ອມ​ຕໍ່​ຂອງ​ທ່ານ​. ນີ້ເປັນປະໂຫຍດສໍາລັບພວກເຮົາຫຼາຍກວ່າຫນຶ່ງຄັ້ງ, ເມື່ອ Amazon ເລີ່ມຕົ້ນການສະກັດກັ້ນ; ໃນສະຖານະການທີ່ຮ້າຍແຮງທີ່ສຸດ, ພວກເຮົາອະນຸຍາດໃຫ້ການຈະລາຈອນ S3 ຜ່ານພວກມັນ, ແຕ່ຄ່ອຍໆທັງຫມົດນີ້ຖືກແກ້ໄຂ.

ວິທີການຈອງ ... ຜູ້ໃຫ້ບໍລິການທັງຫມົດ?

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

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

ສອງສາມຄໍາກ່ຽວກັບການອັດຕະໂນມັດ

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

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

ສະຫລຸບ

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

ການປະນີປະນອມທີ່ສົມເຫດສົມຜົນລະຫວ່າງຄວາມສົມບູນແບບແລະຄວາມພະຍາຍາມທີ່ແທ້ຈິງ, ເວລາ, ເງິນທີ່ທ່ານສາມາດນໍາໃຊ້ໃນໂຄງການທີ່ທ່ານຈະມີໃນທີ່ສຸດ.

ຂໍ້ຄວາມນີ້ແມ່ນສະບັບປັບປຸງແລະຂະຫຍາຍຂອງບົດລາຍງານຂອງ Alexander Demidov ໃນກອງປະຊຸມ ວັນ​ເວ​ລາ 4.

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