HighLoad++, Evgeniy Kuzovlev (EcommPay IT): ຈະເຮັດແນວໃດເມື່ອເວລາຢຸດພັກໜຶ່ງນາທີມີລາຄາ 100000 ໂດລາ.

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

ກອງປະຊຸມ HighLoad++ ຕໍ່ໄປຈະຈັດຂຶ້ນໃນວັນທີ 6 ແລະ 7 ເມສາ 2020 ທີ່ St. ລາຍລະອຽດແລະປີ້ສໍາລັບ ການເຊື່ອມຕໍ່. ວັນທີ 9 ພະຈິກ, 18:00 ໂມງ. HighLoad++ Moscow 2018, Delhi + ຫ້ອງ Kolkata. ເຫຼົ່າ​ນີ້​ແລະ​ ການ ນຳ ສະ ເໜີ.

Evgeniy Kuzovlev (ຕໍ່ໄປນີ້ - EC): - ເພື່ອນ, ສະບາຍດີ! ຂ້ອຍຊື່ Kuzovlev Evgeniy. ຂ້ອຍມາຈາກບໍລິສັດ EcommPay, ພະແນກສະເພາະແມ່ນ EcommPay IT, ພະແນກ IT ຂອງກຸ່ມບໍລິສັດ. ແລະໃນມື້ນີ້ພວກເຮົາຈະສົນທະນາກ່ຽວກັບການ downtimes - ກ່ຽວກັບວິທີຫຼີກເວັ້ນພວກເຂົາ, ກ່ຽວກັບວິທີການຫຼຸດຜ່ອນຜົນສະທ້ອນຂອງເຂົາເຈົ້າຖ້າຫາກວ່າມັນບໍ່ສາມາດຫຼີກເວັ້ນໄດ້. ຫົວຂໍ້ແມ່ນໄດ້ລະບຸໄວ້ດັ່ງຕໍ່ໄປນີ້: "ຈະເຮັດແນວໃດໃນເວລາທີ່ downtime ຫນຶ່ງນາທີຄ່າໃຊ້ຈ່າຍ $100"? ຊອກຫາລ່ວງຫນ້າ, ຕົວເລກຂອງພວກເຮົາແມ່ນປຽບທຽບ.

EcommPay IT ເຮັດຫຍັງ?

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

ກຸ່ມບໍລິສັດ EcommPay ເປັນຜູ້ຊື້ລະຫວ່າງປະເທດ. ພວກເຮົາປະມວນຜົນການຈ່າຍເງິນທົ່ວໂລກ - ໃນລັດເຊຍ, ເອີຣົບ, ອາຊີຕາເວັນອອກສຽງໃຕ້ (ທົ່ວໂລກ). ພວກເຮົາມີ 9 ຫ້ອງການ, ພະນັກງານທັງໝົດ 500 ຄົນ, ແລະ ປະມານໜ້ອຍກວ່າເຄິ່ງໜຶ່ງແມ່ນຜູ້ຊ່ຽວຊານດ້ານໄອທີ. ທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາເຮັດ, ທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາສ້າງລາຍໄດ້ຈາກ, ພວກເຮົາເຮັດດ້ວຍຕົນເອງ.

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

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

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

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

ເວລາຫວ່າງ. ພຣະບັນຍັດຂອງການດໍາເນີນງານ.

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

ເມື່ອ​ເຮົາ​ເລີ່ມ​ປ່ຽນ​ວິທີ​ທາງ​ຂອງ​ເຮົາ, ເຮົາ​ໄດ້​ສ້າງ​ພຣະ​ບັນຍັດ 4 ຂໍ້. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ນໍາ​ສະ​ເຫນີ​ໃຫ້​ເຂົາ​ເຈົ້າ​ຢູ່​ໃນ slideshow ໄດ້​:

ພຣະບັນຍັດເຫຼົ່ານີ້ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ:

• ກໍານົດບັນຫາຢ່າງໄວວາ.
• ກໍາຈັດມັນໄວຂຶ້ນ.
• ຊ່ວຍເຂົ້າໃຈເຫດຜົນ (ຕໍ່ມາ, ສໍາລັບນັກພັດທະນາ).
• ແລະມາດຕະຖານວິທີການ.

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

ການ​ແກ້​ໄຂ​ບັນ​ຫາ​: ພວກ​ເຂົາ​ເຈົ້າ​ເກີດ​ຂຶ້ນ​ໃນ​ເວ​ລາ​ທີ່​ແລະ​ຈະ​ເຮັດ​ແນວ​ໃດ​ກ່ຽວ​ກັບ​ພວກ​ເຂົາ​?

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

ເພື່ອສ້າງຂໍ້ກໍານົດເຫຼົ່ານີ້, ພວກເຮົາຕັດສິນໃຈຖາມຕົວເອງວ່າ: "ພວກເຮົາມີບັນຫາເວລາໃດ"? ແລະບັນຫາ, ຍ້ອນວ່າມັນໄດ້ຫັນອອກ, ເກີດຂຶ້ນໃນສີ່ກໍລະນີ:

• ຮາດແວລົ້ມເຫຼວ.
• ບໍລິການພາຍນອກລົ້ມເຫລວ.
• ການ​ປ່ຽນ​ແປງ​ສະ​ບັບ​ຊອບ​ແວ (ການ​ນໍາ​ໃຊ້​ດຽວ​ກັນ​)​.
• ການຂະຫຍາຍຕົວການໂຫຼດລະເບີດ.

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

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

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

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

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

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

ການ​ປ່ຽນ​ແປງ​ສະ​ບັບ​ຊອບ​ແວ​. ຖານ

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

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

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

ຄວາມຕ້ອງການສໍາລັບການປ່ຽນສະບັບຊອບແວ

ມີ​ສາມ​ຄວາມ​ຕ້ອງ​ການ​:

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

  
  
  ມັນເປັນທີ່ຮູ້ຈັກດີ, ພວກເຮົາບໍ່ເຄີຍປະດິດມັນ - ນີ້ແມ່ນສີຟ້າ / ສີຂຽວ. ມັນ​ແມ່ນ​ຫຍັງ? ທ່ານຕ້ອງມີສໍາເນົາສໍາລັບແຕ່ລະກຸ່ມຂອງເຄື່ອງແມ່ຂ່າຍທີ່ຄໍາຮ້ອງສະຫມັກຂອງທ່ານຖືກຕິດຕັ້ງ. ສໍາເນົາແມ່ນ "ອົບອຸ່ນ": ບໍ່ມີການຈະລາຈອນກ່ຽວກັບມັນ, ແຕ່ໃນເວລາໃດກໍ່ຕາມການຈະລາຈອນນີ້ສາມາດຖືກສົ່ງໄປຫາສໍາເນົານີ້. ສໍາເນົານີ້ມີສະບັບທີ່ຜ່ານມາ. ແລະໃນເວລາຂອງການນໍາໃຊ້, ທ່ານ roll out the code to a inactive copy . ຫຼັງຈາກນັ້ນ, ທ່ານປ່ຽນສ່ວນຫນຶ່ງຂອງການຈະລາຈອນ (ຫຼືທັງຫມົດ) ກັບສະບັບໃຫມ່. ດັ່ງນັ້ນ, ເພື່ອປ່ຽນການໄຫຼວຽນຂອງການຈະລາຈອນຈາກຮຸ່ນເກົ່າໄປຫາໃຫມ່, ທ່ານຈໍາເປັນຕ້ອງປະຕິບັດພຽງແຕ່ຫນຶ່ງ: ທ່ານຈໍາເປັນຕ້ອງປ່ຽນຕົວດຸ່ນດ່ຽງໃນຕົ້ນນ້ໍາ, ປ່ຽນທິດທາງ - ຈາກຕົ້ນນ້ໍາໄປຫາອີກອັນຫນຶ່ງ. ນີ້ແມ່ນສະດວກຫຼາຍແລະແກ້ໄຂບັນຫາຂອງການສະຫຼັບໄວແລະ rollback ໄວ.

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

  ນຳໃຊ້ສີຟ້າ/ສີຂຽວ. ກຳນົດເສັ້ນທາງ

  ຢ່າງໃດກໍຕາມ, ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍດັ່ງນັ້ນ "ສີຟ້າ / ສີຂຽວ deploy" ... ອົງປະກອບຂອງພວກເຮົາສາມາດແບ່ງອອກເປັນສາມກຸ່ມ:

  • ນີ້ແມ່ນຫນ້າດ້ານຫນ້າ (ຫນ້າການຈ່າຍເງິນທີ່ລູກຄ້າຂອງພວກເຮົາເຫັນ);
  • ຫຼັກການປຸງແຕ່ງ;
  • ອະແດບເຕີສໍາລັບການເຮັດວຽກກັບລະບົບການຈ່າຍເງິນ (ທະນາຄານ, MasterCard, Visa ...).

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

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

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

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

  ນີ້ບໍ່ເຫມາະສົມກັບພວກເຮົາເພາະວ່າພວກເຮົາມີ nginx ປົກກະຕິຢູ່ແລ້ວ. ການປ່ຽນເປັນ nginx+ ບໍ່ແມ່ນວ່າມັນແພງ, ມັນເປັນພຽງແຕ່ວ່າມັນເປັນການເຈັບປວດບາງຢ່າງສໍາລັບພວກເຮົາແລະບໍ່ຖືກຕ້ອງຫຼາຍ. ສໍາລັບຕົວຢ່າງ, "Sticks Sessions", ບໍ່ໄດ້ເຮັດວຽກສໍາລັບພວກເຮົາສໍາລັບເຫດຜົນງ່າຍໆວ່າ "Sticks Sessions" ບໍ່ອະນຸຍາດໃຫ້ກໍານົດເສັ້ນທາງໂດຍອີງໃສ່ "ບໍ່ວ່າຈະຫຼື". ຢູ່ທີ່ນັ້ນທ່ານສາມາດກໍານົດສິ່ງທີ່ພວກເຮົາ "Sticks Sessions" ເຮັດ, ສໍາລັບການຍົກຕົວຢ່າງ, ໂດຍທີ່ຢູ່ IP ຫຼືທີ່ຢູ່ IP ແລະ cookies ຫຼືໂດຍ postparameter, ແຕ່ "ບໍ່ວ່າຈະຫຼື" ແມ່ນສັບສົນຫຼາຍຢູ່ທີ່ນັ້ນ.

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

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

  ນຳໃຊ້ສີຟ້າ/ສີຂຽວ. ຂໍ້ດີແລະຂໍ້ເສຍ

  ແນ່ນອນ, ມັນອາດຈະເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ມັນງ່າຍດາຍເລັກນ້ອຍ (ໃຊ້ "Sticky Sessions" ດຽວກັນ), ແຕ່ພວກເຮົາຍັງມີຄວາມແຕກຕ່າງກັນທີ່ບໍ່ພຽງແຕ່ຜູ້ໃຊ້ພົວພັນກັບພວກເຮົາພາຍໃນກອບຂອງການປຸງແຕ່ງຫນຶ່ງທຸລະກໍາ ... ແຕ່ລະບົບການຈ່າຍເງິນຍັງພົວພັນກັບພວກເຮົາ: ຫຼັງຈາກທີ່ພວກເຮົາດໍາເນີນການເຮັດທຸລະກໍາ (ໂດຍການສົ່ງຄໍາຮ້ອງຂໍໄປຍັງລະບົບການຈ່າຍເງິນ), ພວກເຮົາໄດ້ຮັບ coolback.
  ແລະສົມມຸດວ່າ, ຖ້າຢູ່ໃນວົງຈອນຂອງພວກເຮົາພວກເຮົາສາມາດສົ່ງຕໍ່ທີ່ຢູ່ IP ຂອງຜູ້ໃຊ້ໃນທຸກຄໍາຮ້ອງຂໍແລະແບ່ງຜູ້ໃຊ້ໂດຍອີງໃສ່ທີ່ຢູ່ IP, ຫຼັງຈາກນັ້ນພວກເຮົາຈະບໍ່ບອກ "Visa" ດຽວກັນ: "Dude, ພວກເຮົາເປັນບໍລິສັດ retro, ພວກເຮົາເບິ່ງຄືວ່າ. ເພື່ອໃຫ້ເປັນສາກົນ (ຢູ່ໃນເວັບໄຊທ໌ແລະໃນລັດເຊຍ) ... ກະລຸນາໃຫ້ພວກເຮົາມີທີ່ຢູ່ IP ຂອງຜູ້ໃຊ້ໃນຊ່ອງເພີ່ມເຕີມ, ໂປໂຕຄອນຂອງທ່ານແມ່ນມາດຕະຖານ”! ມັນເປັນທີ່ຊັດເຈນວ່າພວກເຂົາຈະບໍ່ເຫັນດີນໍາ.

  
  
  ດັ່ງນັ້ນ, ນີ້ບໍ່ໄດ້ຜົນສໍາລັບພວກເຮົາ - ພວກເຮົາເຮັດ openresty. ຕາມ​ນັ້ນ​ແລ້ວ, ດ້ວຍ​ການ​ກຳນົດ​ເສັ້ນ​ທາງ​ພວກ​ເຮົາ​ໄດ້​ຮັບ​ບາງ​ສິ່ງ​ດັ່ງ​ນີ້:

  ການນຳໃຊ້ສີຟ້າ/ສີຂຽວມີຂໍ້ດີທີ່ຂ້ອຍໄດ້ກ່າວມາ ແລະ ຂໍ້ເສຍ.

  ສອງ​ຂໍ້​ເສຍ​:

  • ທ່ານຕ້ອງການ bother ກັບ routing;
  • ຂໍ້ເສຍຕົ້ນຕໍທີສອງແມ່ນຄ່າໃຊ້ຈ່າຍ.

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

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

  ເຮັດແນວໃດເພື່ອເຮັດໃຫ້ການນໍາໃຊ້ໄວ?

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

  
  
  ມັນສັ້ນແລະງ່າຍດາຍຢູ່ທີ່ນີ້.

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

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

  ການຂະຫຍາຍຕົວການໂຫຼດລະເບີດ

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

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

  ແລະໃນທີ່ນີ້ມັນ turns ໃຫ້ເຫັນວ່າທ່ານຕ້ອງການ somehow ຂະຫນາດພະນັກງານ, ທ່ານຈໍາເປັນຕ້ອງ somehow ຂະຫນາດການບໍລິການຂອງທ່ານ, ແຕ່ໃນເວລາດຽວກັນປ້ອງກັນບໍ່ໃຫ້ bloat ຊັບພະຍາກອນ.

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

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

  ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ເບິ່ງ Nomad, ເຊິ່ງມີ IP ເປີດ, ແລະຂຽນສິ່ງຂອງພວກເຮົາເອງ, Scale-Nomad - ScaleNo, ເຊິ່ງເຮັດປະມານດັ່ງຕໍ່ໄປນີ້: ມັນຕິດຕາມການຂະຫຍາຍຕົວຂອງແຖວແລະຫຼຸດຜ່ອນຫຼືເພີ່ມຈໍານວນແຮງງານໂດຍອີງຕາມນະໂຍບາຍດ້ານ. ຂອງແຖວ. ເມື່ອພວກເຮົາເຮັດມັນ, ພວກເຮົາຄິດວ່າ: "ບາງທີພວກເຮົາສາມາດເປີດແຫຼ່ງມັນໄດ້ບໍ?" ຫຼັງຈາກນັ້ນ, ພວກເຂົາເບິ່ງນາງ - ນາງງ່າຍດາຍຄືກັບສອງ kopecks.

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

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

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

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

  ການຕິດຕາມ. ວິທີການກໍານົດບັນຫາຢ່າງໄວວາ?

  ໃນປັດຈຸບັນຈຸດທໍາອິດແມ່ນ "ວິທີການກໍານົດບັນຫາຢ່າງໄວວາ?" ຕິດຕາມ! ພວກເຮົາຕ້ອງເຂົ້າໃຈບາງສິ່ງທີ່ໄວ. ສິ່ງທີ່ພວກເຮົາຄວນເຂົ້າໃຈໄວ?

  
  
  ສາມຢ່າງ!

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

  ຂ້ອຍອາດຈະບໍ່ບອກເຈົ້າຫຍັງທີ່ເຢັນໆຢູ່ທີ່ນີ້. ຂ້ອຍຈະເປັນ Captain Obvious. ພວກເຮົາຊອກຫາສິ່ງທີ່ຢູ່ໃນຕະຫຼາດ. ພວກເຮົາມີ "ສວນສັດມ່ວນ". ນີ້ແມ່ນສວນສັດທີ່ພວກເຮົາມີໃນປັດຈຸບັນ:

  
  
  ພວກເຮົາໃຊ້ Zabbix ເພື່ອຕິດຕາມຮາດແວ, ເພື່ອຕິດຕາມຕົວຊີ້ວັດຕົ້ນຕໍຂອງເຄື່ອງແມ່ຂ່າຍ. ພວກເຮົາໃຊ້ Okmeter ສໍາລັບຖານຂໍ້ມູນ. ພວກເຮົາໃຊ້ "Grafana" ແລະ "Prometheus" ສໍາລັບຕົວຊີ້ວັດອື່ນໆທັງຫມົດທີ່ບໍ່ເຫມາະສົມກັບສອງອັນທໍາອິດ, ບາງອັນມີ "Grafana" ແລະ "Prometheus", ແລະບາງຕົວມີ "Grafana" ກັບ "Influx" ແລະ Telegraf.

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

  ແລະມີເຄື່ອງມືຫນຶ່ງທີ່ພວກເຮົາປະຕິບັດຕົວເອງ - ນີ້ແມ່ນ Debugger. ທຳອິດ ພວກເຮົາເອີ້ນມັນວ່າ “Bagger,” ແຕ່ຫຼັງຈາກນັ້ນຄູສອນພາສາອັງກິດຄົນໜຶ່ງໄດ້ຍ່າງຜ່ານໄປ, ຫົວເຍາະເຍີ້ຍ, ແລະປ່ຽນຊື່ມັນວ່າ “Debagger.” ມັນ​ແມ່ນ​ຫຍັງ? ນີ້ແມ່ນເຄື່ອງມືທີ່, ໃນຄວາມເປັນຈິງ, ໃນ 15-30 ວິນາທີໃນແຕ່ລະອົງປະກອບ, ເຊັ່ນ "ກ່ອງສີດໍາ" ຂອງລະບົບ, ດໍາເນີນການທົດສອບກ່ຽວກັບການປະຕິບັດໂດຍລວມຂອງອົງປະກອບ.

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

  ຕົວຊີ້ວັດໃດທີ່ສໍາຄັນສໍາລັບການຕິດຕາມກວດກາ?

  ພວກເຮົາຕິດຕາມຫຍັງເປັນສ່ວນໃຫຍ່? ຕົວຊີ້ວັດອັນໃດສໍາຄັນຕໍ່ພວກເຮົາ?

  
  

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

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

  ສິ່ງທີ່ມັນເບິ່ງຄືວ່າສໍາລັບພວກເຮົາແມ່ນຕົວຢ່າງຂອງຫນຶ່ງໃນກະດານຂອງພວກເຮົາ:

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

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

  
  
  ເສັ້ນສະແດງສະແດງໃຫ້ພວກເຮົາເຫັນວ່າຫນຶ່ງໃນລະບົບການຈ່າຍເງິນເລີ່ມຕົ້ນຕອບສະຫນອງໃນ 3 ວິນາທີ - ພວກເຮົາມີບັນຫາ. ຍິ່ງໄປກວ່ານັ້ນ, ສິ່ງນີ້ຈະປະຕິກິລິຍາເມື່ອບັນຫາເລີ່ມຕົ້ນ, ໃນໄລຍະ 20-30 ວິນາທີ.

  ແລະຊັ້ນທີສາມຂອງການກວດສອບຄວາມຜິດພາດທີ່ມີຢູ່ແມ່ນການກວດສອບຢ່າງມີເຫດຜົນ.

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

  
  
  ຂ້ອຍຫມາຍຄວາມວ່າແນວໃດໂດຍການຕິດຕາມກວດກາຢ່າງມີເຫດຜົນ? ດີ, ຈິນຕະນາການ: ທ່ານເຮັດໃຫ້ຕົວທ່ານເອງເປັນລະບົບ (ຕົວຢ່າງ, clone Tinder); ເຈົ້າໄດ້ເຮັດມັນ, ເປີດມັນ. ຜູ້ຈັດການສົບຜົນສໍາເລັດຂອງລູກຄ້າ Vasya Pupkin ໄດ້ວາງມັນຢູ່ໃນໂທລະສັບຂອງລາວ, ເຫັນເດັກຍິງຢູ່ທີ່ນັ້ນ, ມັກນາງ ... ແລະສິ່ງທີ່ຄ້າຍຄືບໍ່ໄດ້ໄປຫາເດັກຍິງ - ຄືກັບຜູ້ຮັກສາຄວາມປອດໄພ Mikhalych ຈາກສູນທຸລະກິດດຽວກັນ. ຜູ້ຈັດການລົງໄປຊັ້ນລຸ່ມ, ແລະຫຼັງຈາກນັ້ນສົງໄສວ່າ: "ເປັນຫຍັງເຈົ້າຫນ້າທີ່ຮັກສາຄວາມປອດໄພ Mikhalych ຍິ້ມໃຫ້ລາວຢ່າງມີຄວາມສຸກ?"

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

  ນີ້ແມ່ນກ່ຽວກັບວິທີການກໍານົດບັນຫາຢ່າງໄວວາ.

  ວິທີການກໍານົດເຫດຜົນສໍາລັບການນໍາໃຊ້

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

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

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

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

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

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

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

  ຕາມ​ນັ້ນ​ແລ້ວ, ສິ່ງ​ຕ່າງໆ​ໄດ້​ເປັນ​ໄປ​ດ້ວຍ​ດີ​ສຳລັບ​ພວກ​ເຮົາ. ພວກເຮົາຂຽນການຂະຫຍາຍຂອງພວກເຮົາເອງແລະພວກເຮົາເປີດແຫຼ່ງມັນ. ຖ້າທ່ານຕ້ອງການເຮັດວຽກກັບການຕິດຕາມ, ຖ້າທ່ານຕ້ອງການເຮັດວຽກກັບ "Jager" ໃນ PHP, ມີການຂະຫຍາຍຂອງພວກເຮົາ, ຍິນດີຕ້ອນຮັບການນໍາໃຊ້, ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ:

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

  ມາດຕະຖານຂອງບໍລິສັດ

  ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບສາມພຣະບັນຍັດ. ພຣະບັນຍັດຂໍ້ທີສີ່ແມ່ນເພື່ອມາດຕະຖານວິທີການ. ອັນນີ້ກ່ຽວກັບຫຍັງ? ມັນກ່ຽວກັບເລື່ອງນີ້:

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

  
  

  • ພວກເຮົາມີກົດລະບຽບການນໍາໃຊ້. ພວກ​ເຮົາ​ບໍ່​ໄດ້​ເຄື່ອນ​ຍ້າຍ​ໄປ​ບ່ອນ​ໃດ​ທີ່​ບໍ່​ມີ​ພຣະ​ອົງ​, ພວກ​ເຮົາ​ເຮັດ​ບໍ່​ໄດ້​. ພວກເຮົາປະຕິບັດປະມານ 60 ເທື່ອຕໍ່ອາທິດ, ນັ້ນແມ່ນ, ພວກເຮົາປະຕິບັດເກືອບຕະຫຼອດເວລາ. ໃນຂະນະດຽວກັນ, ຕົວຢ່າງ, ພວກເຮົາມີຂໍ້ຫ້າມກ່ຽວກັບການປະຕິບັດໃນວັນສຸກ - ໃນຫຼັກການ, ພວກເຮົາບໍ່ໄດ້ປະຕິບັດ.
  • ພວກເຮົາຕ້ອງການເອກະສານ. ບໍ່ແມ່ນອົງປະກອບໃຫມ່ດຽວເຂົ້າໄປໃນການຜະລິດຖ້າບໍ່ມີເອກະສານສໍາລັບມັນ, ເຖິງແມ່ນວ່າມັນເກີດພາຍໃຕ້ປາກກາຂອງຜູ້ຊ່ຽວຊານ RnD ຂອງພວກເຮົາ. ພວກເຮົາຕ້ອງການຈາກພວກເຂົາຄໍາແນະນໍາໃນການນໍາໃຊ້, ແຜນທີ່ການຕິດຕາມແລະຄໍາອະທິບາຍແບບຫຍາບໆ (ດີ, ຍ້ອນວ່ານັກຂຽນໂປລແກລມສາມາດຂຽນ) ຂອງອົງປະກອບນີ້ເຮັດວຽກ, ວິທີການແກ້ໄຂບັນຫາ.
  • ພວກເຮົາແກ້ໄຂບໍ່ແມ່ນສາເຫດຂອງບັນຫາ, ແຕ່ບັນຫາ - ສິ່ງທີ່ຂ້ອຍເວົ້າແລ້ວ. ມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາທີ່ຈະປົກປ້ອງຜູ້ໃຊ້ຈາກບັນຫາ.
  • ພວກເຮົາມີການເກັບກູ້. ຕົວຢ່າງ, ພວກເຮົາບໍ່ໄດ້ພິຈາລະນາມັນ downtime ຖ້າພວກເຮົາສູນເສຍ 2% ຂອງການຈະລາຈອນພາຍໃນສອງນາທີ. ນີ້ບໍ່ໄດ້ລວມຢູ່ໃນສະຖິຕິຂອງພວກເຮົາໂດຍພື້ນຖານ. ຖ້າມັນເປັນເປີເຊັນຫຼືຊົ່ວຄາວ, ພວກເຮົານັບແລ້ວ.
  • ແລະພວກເຮົາສະເຫມີຂຽນ postmortems. ສິ່ງໃດກໍ່ຕາມທີ່ເກີດຂື້ນກັບພວກເຮົາ, ສະຖານະການໃດກໍ່ຕາມທີ່ຜູ້ໃດຜູ້ ໜຶ່ງ ປະພຶດຕົວຜິດປົກກະຕິໃນການຜະລິດຈະຖືກສະແດງຢູ່ໃນການເສຍຊີວິດ. postmortem ແມ່ນເອກະສານທີ່ທ່ານຂຽນສິ່ງທີ່ເກີດຂຶ້ນກັບເຈົ້າ, ໄລຍະເວລາລາຍລະອຽດ, ສິ່ງທີ່ທ່ານໄດ້ເຮັດເພື່ອແກ້ໄຂມັນແລະ (ນີ້ແມ່ນການບັງຄັບ!) ສິ່ງທີ່ທ່ານຈະເຮັດເພື່ອປ້ອງກັນບໍ່ໃຫ້ເຫດການນີ້ເກີດຂຶ້ນໃນອະນາຄົດ. ນີ້ແມ່ນການບັງຄັບແລະມີຄວາມຈໍາເປັນສໍາລັບການວິເຄາະຕໍ່ໄປ.

  ແມ່ນຫຍັງຖືວ່າເປັນເວລາຢຸດເຮັດວຽກ?

  
  
  ທັງຫມົດນີ້ນໍາໄປສູ່ຫຍັງ?

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

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

  ຫມົດ​ເທົ່າ​ນີ້! ຄໍາຖາມຂອງເຈົ້າ.

  
  

  ກ່ຽວກັບການດຸ່ນດ່ຽງແລະການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ

  ຄໍາຖາມຈາກຜູ້ຊົມ (ຕໍ່ໄປນີ້ - B): - ສະບາຍດີຕອນແລງ. ຂອບໃຈຫຼາຍໆສຳລັບລາຍງານ admin ແບບນີ້! ຄໍາຖາມສັ້ນໆກ່ຽວກັບຜູ້ດຸ່ນດ່ຽງຂອງທ່ານ. ທ່ານໄດ້ກ່າວເຖິງວ່າທ່ານມີ WAF, ນັ້ນແມ່ນ, ຕາມທີ່ຂ້ອຍເຂົ້າໃຈມັນ, ທ່ານໃຊ້ຕົວດຸ່ນດ່ຽງພາຍນອກບາງປະເພດ ...

  EK: - ບໍ່, ພວກເຮົາໃຊ້ບໍລິການຂອງພວກເຮົາເປັນຕົວດຸ່ນດ່ຽງ. ໃນກໍລະນີນີ້, WAF ແມ່ນສະເພາະແຕ່ເປັນເຄື່ອງມືປ້ອງກັນ DDoS ສໍາລັບພວກເຮົາ.

  ໃນ: – ເຈົ້າສາມາດເວົ້າສອງສາມຄຳກ່ຽວກັບການດຸ່ນດ່ຽງໄດ້ບໍ?

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

  ໃນ: – ຍັງ​ເປັນ​ຄໍາ​ຖາມ​ທີ່​ງ່າຍ​ດາຍ​. ນີ້ແມ່ນການນຳໃຊ້ສີຟ້າ/ສີຂຽວ. ທ່ານເຮັດແນວໃດ, ສໍາລັບການຍົກຕົວຢ່າງ, ກັບການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ?

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

  ເພື່ອນໆ, ຂ້ອຍຍັງມີລາງວັນເລັກນ້ອຍທີ່ຈະກະຕຸ້ນເຈົ້າ - ປື້ມ. ແລະຂ້ອຍຄວນໄດ້ຮັບລາງວັນມັນສໍາລັບຄໍາຖາມທີ່ດີທີ່ສຸດ.

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

  EK: - "ຜູ້ຄ້າ" ສໍາລັບພວກເຮົາໃນກໍລະນີນີ້ແມ່ນການບໍລິການພາຍນອກດຽວກັນກັບລະບົບການຈ່າຍເງິນ. ພວກເຮົາຕິດຕາມຄວາມໄວການຕອບໂຕ້ຂອງຜູ້ຄ້າ.

  ກ່ຽວກັບການເຂົ້າລະຫັດຖານຂໍ້ມູນ

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

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

  ໃນ: – ເຈົ້າຕ້ອງການ 2 ກິໂລໄບດຽວນີ້ບໍ?

  EK: – ມັນ​ເບິ່ງ​ຄື​ວ່າ​ພຽງ​ແຕ່​ມື້​ວານ​ນີ້​ມັນ​ແມ່ນ 256 ... ດີ, ບ່ອນ​ທີ່​ອື່ນ?!

  ຕາມນັ້ນແລ້ວ, ນີ້ແມ່ນຄັ້ງທໍາອິດ. ແລະອັນທີສອງ, ການແກ້ໄຂທີ່ມີຢູ່, ມັນສະຫນັບສະຫນູນຂັ້ນຕອນການເຂົ້າລະຫັດຄືນໃຫມ່ - ມີສອງຄູ່ຂອງ "keks" (ຄີ), ເຊິ່ງໃຫ້ "decks" ທີ່ເຂົ້າລະຫັດ (ກຸນແຈແມ່ນກະແຈ, dek ແມ່ນມາຈາກກຸນແຈທີ່ເຂົ້າລະຫັດ) . ແລະຖ້າຫາກວ່າຂັ້ນຕອນໄດ້ຖືກລິເລີ່ມ (ມັນເກີດຂຶ້ນເປັນປົກກະຕິ, ຈາກ 3 ເດືອນເຖິງ±ບາງ), ພວກເຮົາດາວນ໌ໂຫລດຄູ່ໃຫມ່ຂອງ "cakes", ແລະພວກເຮົາ re-encrypt ຂໍ້ມູນ. ພວກ​ເຮົາ​ມີ​ການ​ບໍ​ລິ​ການ​ແຍກ​ຕ່າງ​ຫາກ​ທີ່​ຖອດ​ອອກ​ຂໍ້​ມູນ​ທັງ​ຫມົດ​ແລະ​ການ​ເຂົ້າ​ລະ​ຫັດ​ໃນ​ວິ​ທີ​ການ​ໃຫມ່​; ຂໍ້ມູນຈະຖືກເກັບໄວ້ຂ້າງຕົວລະບຸຂອງລະຫັດທີ່ມັນຖືກເຂົ້າລະຫັດ. ຕາມນັ້ນແລ້ວ, ທັນທີທີ່ພວກເຮົາເຂົ້າລະຫັດຂໍ້ມູນດ້ວຍກະແຈໃໝ່, ພວກເຮົາລຶບລະຫັດເກົ່າອອກ.

  ບາງຄັ້ງຕ້ອງຈ່າຍເງິນດ້ວຍຕົນເອງ...

  ໃນ: - ນັ້ນແມ່ນ, ຖ້າການຄືນເງິນໄດ້ມາຮອດສໍາລັບການປະຕິບັດງານບາງຢ່າງ, ເຈົ້າຍັງຈະຖອດລະຫັດມັນດ້ວຍລະຫັດເກົ່າບໍ?

  EK: - ແມ່ນແລ້ວ.

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

  EK: - ແມ່ນແລ້ວ, ບາງຄັ້ງ.

  ໃນ: – ເຈົ້າໄດ້ຂໍ້ມູນນີ້ມາຈາກໃສ? ຫຼືເຈົ້າໄປບ່ອນເກັບມ້ຽນນີ້ເອງບໍ?

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

  
  
  ໃນ: – ຂ້າ​ພະ​ເຈົ້າ​ມີ​ສອງ​ຄໍາ​ຖາມ​. ຫນຶ່ງໃນນັ້ນແມ່ນການສືບຕໍ່ຂອງເຂດ PCI ​​DSS: ເຈົ້າເຂົ້າສູ່ລະບົບວົງຈອນຂອງພວກເຂົາແນວໃດ? ຄໍາຖາມນີ້ແມ່ນຍ້ອນວ່ານັກພັດທະນາສາມາດເອົາສິ່ງໃດໃນບັນທຶກ! ຄໍາ​ຖາມ​ທີ​ສອງ​: ວິ​ທີ​ການ​ທີ່​ທ່ານ​ອອກ​ແກ້​ໄຂ​ດ່ວນ​? ການນໍາໃຊ້ຕົວຈັບໃນຖານຂໍ້ມູນແມ່ນທາງເລືອກຫນຶ່ງ, ແຕ່ອາດຈະມີການແກ້ໄຂຮ້ອນຟຣີ - ຂັ້ນຕອນແມ່ນຫຍັງຢູ່ທີ່ນັ້ນ? ແລະຄໍາຖາມທີສາມແມ່ນອາດຈະກ່ຽວຂ້ອງກັບ RTO, RPO. ການມີຢູ່ຂອງເຈົ້າແມ່ນ 99,97, ເກືອບສີ່ເກົ້າ, ແຕ່ຕາມທີ່ຂ້ອຍເຂົ້າໃຈມັນ, ທ່ານມີສູນຂໍ້ມູນທີສອງ, ສູນຂໍ້ມູນທີສາມ, ແລະສູນຂໍ້ມູນທີຫ້າ ... ເຈົ້າຊິ້ງຂໍ້ມູນ, ເຮັດຊ້ໍາກັນແນວໃດ, ແລະສິ່ງອື່ນໆ?

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

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

  ໃນ: – ຖ້າເຈົ້າໄດ້ອັນທີສອງ, ເປັນຫຍັງເຈົ້າຈຶ່ງບໍ່ໄດ້ຮັບອັນທີສາມ? ເພາະ​ຍັງ​ບໍ່​ທັນ​ມີ​ຄົນ​ທີ່​ມີ​ສະ​ຫມອງ​ແຕກ.

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

  ໃນ: - ສະ​ບາຍ​ດີ​ຕອນ​ແລງ. ຂອບໃຈສໍາລັບບົດລາຍງານ. ທ່ານໄດ້ເວົ້າກ່ຽວກັບ debugger ຂອງທ່ານ, ເຊິ່ງດໍາເນີນການທົດສອບບາງທຸລະກໍາໃນການຜະລິດ. ແຕ່ບອກພວກເຮົາກ່ຽວກັບການເຮັດທຸລະກໍາການທົດສອບ! ມັນເລິກປານໃດ?

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

  ໃນ: - ເຈົ້າຕັດມັນໄປໃສ? ນີ້ Core ສົ່ງ ...

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

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

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

  ຖ້າການບໍລິການຢູ່ໃນເຊີບເວີຖືກທໍາລາຍ ...

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

  
  
  EK: - ແມ່ນແລ້ວ, ແນ່ນອນ. ຄວາມຕ້ອງການຄວາມປອດໄພແມ່ນຂ້ອນຂ້າງຮ້າຍແຮງ. ກ່ອນອື່ນ ໝົດ, ພວກເຮົາມີການເຄື່ອນໄຫວຂໍ້ມູນເປີດ, ແລະທ່າເຮືອແມ່ນພຽງແຕ່ສິ່ງທີ່ພວກເຮົາຄາດວ່າຈະມີການເຄື່ອນໄຫວການຈະລາຈອນລ່ວງຫນ້າ. ຖ້າອົງປະກອບສື່ສານກັບຖານຂໍ້ມູນ (ເວົ້າວ່າ, ກັບ Muskul) ຜ່ານ 5-4-3-2, ພຽງແຕ່ 5-4-3-2 ຈະເປີດໃຫ້ມັນ, ແລະທ່າເຮືອອື່ນໆແລະເສັ້ນທາງການຈະລາຈອນອື່ນໆຈະບໍ່ສາມາດໃຊ້ໄດ້. ນອກຈາກນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າໃນການຜະລິດຂອງພວກເຮົາມີປະມານ 10 loops ຄວາມປອດໄພທີ່ແຕກຕ່າງກັນ. ແລະເຖິງແມ່ນວ່າຄໍາຮ້ອງສະຫມັກໄດ້ຖືກປະນີປະນອມ somehow, ພຣະເຈົ້າຫ້າມ, ຜູ້ໂຈມຕີຈະບໍ່ສາມາດເຂົ້າເຖິງ console ການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍ, ເນື່ອງຈາກວ່ານີ້ແມ່ນເຂດຄວາມປອດໄພເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນ.

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

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

  ວິທີການເຮັດວຽກຂອງ Visa, MasterCard ແລະ Sberbank

  ໃນ: – ຂ້າ​ພະ​ເຈົ້າ​ຕ້ອງ​ການ​ທີ່​ຈະ​ແຈ້ງ​ຈຸດ​ກ່ຽວ​ກັບ​ການ​ສະ​ຫຼັບ​ຜູ້​ໃຊ້​ຈາກ​ສູນ​ຂໍ້​ມູນ​ຫນຶ່ງ​ກັບ​ສູນ​ອື່ນ​. ເທົ່າທີ່ຂ້າພະເຈົ້າຮູ້, Visa ແລະ MasterCard ດໍາເນີນການໂດຍໃຊ້ 8583 binary synchronous protocol, ແລະມີການປະສົມຢູ່ທີ່ນັ້ນ. ແລະຂ້ອຍຢາກຮູ້ວ່າ, ຕອນນີ້ພວກເຮົາຫມາຍເຖິງການປ່ຽນ - ມັນແມ່ນ "Visa" ແລະ "MasterCard" ໂດຍກົງຫຼືກ່ອນລະບົບການຈ່າຍເງິນ, ກ່ອນທີ່ຈະດໍາເນີນການບໍ?

  EK: - ນີ້ແມ່ນກ່ອນທີ່ຈະປະສົມ. ການປະສົມຂອງພວກເຮົາແມ່ນຕັ້ງຢູ່ໃນສູນຂໍ້ມູນດຽວກັນ.

  ໃນ: - ເວົ້າປະມານ, ທ່ານມີຈຸດເຊື່ອມຕໍ່ຫນຶ່ງບໍ?

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

  ໃນ: – ເຂົາເຈົ້າສາມາດສະຫງວນໄດ້ແນວໃດ? ຂ້ອຍຮູ້ວ່າ Visa ອະນຸຍາດໃຫ້ມີການເຊື່ອມຕໍ່ດຽວໃນຫຼັກການ!

  EK: - ພວກເຂົາສະຫນອງອຸປະກອນດ້ວຍຕົນເອງ. ໃນກໍລະນີໃດກໍ່ຕາມ, ພວກເຮົາໄດ້ຮັບອຸປະກອນທີ່ຊ້ໍາຊ້ອນພາຍໃນ.

  ໃນ: – ດັ່ງນັ້ນຈຸດຢືນແມ່ນມາຈາກ Connects Orange ຂອງພວກເຂົາ?..

  EK: - ແມ່ນແລ້ວ.

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

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

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

  
  
  

  ບາງໂຄສະນາ🙂

  ຂອບໃຈສໍາລັບການຢູ່ກັບພວກເຮົາ. ເຈົ້າມັກບົດຄວາມຂອງພວກເຮົາບໍ? ຕ້ອງການເບິ່ງເນື້ອຫາທີ່ຫນ້າສົນໃຈຫຼາຍບໍ? ສະຫນັບສະຫນູນພວກເຮົາໂດຍການວາງຄໍາສັ່ງຫຼືແນະນໍາໃຫ້ຫມູ່ເພື່ອນ, cloud VPS ສໍາລັບນັກພັດທະນາຈາກ $4.99, ການປຽບທຽບທີ່ເປັນເອກະລັກຂອງເຊີບເວີລະດັບເຂົ້າ, ເຊິ່ງຖືກປະດິດໂດຍພວກເຮົາສໍາລັບທ່ານ: ຄວາມຈິງທັງໝົດກ່ຽວກັບ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ຈາກ $19 ຫຼືວິທີການແບ່ງປັນເຄື່ອງແມ່ຂ່າຍ? (ສາມາດໃຊ້ໄດ້ກັບ RAID1 ແລະ RAID10, ສູງສຸດ 24 cores ແລະສູງສຸດ 40GB DDR4).

  Dell R730xd 2x ລາຄາຖືກກວ່າຢູ່ໃນສູນຂໍ້ມູນ Equinix Tier IV ໃນ Amsterdam? ທີ່ນີ້ເທົ່ານັ້ນ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ຈາກ $199 ໃນປະເທດເນເທີແລນ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ຈາກ $99! ອ່ານກ່ຽວກັບ ວິທີການສ້າງໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດ. ຫ້ອງຮຽນທີ່ມີການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍຂອງ Dell R730xd E5-2650 v4 ມູນຄ່າ 9000 ເອີໂຣສໍາລັບເງິນບໍ?

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