🥇ການທົດສອບການຜະລິດ: Canary Deployment

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

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

Andrey Markelov - ວິສະວະກອນຊອບແວຊັ້ນນໍາຂອງ Infobip, ໄດ້ພັດທະນາຄໍາຮ້ອງສະຫມັກ Java ໃນຂົງເຂດການເງິນແລະໂທລະຄົມມະນາຄົມສໍາລັບ 11 ປີ. ພັດທະນາຜະລິດຕະພັນແຫຼ່ງເປີດ, ມີສ່ວນຮ່ວມຢ່າງຈິງຈັງໃນຊຸມຊົນ Atlassian ແລະຂຽນ plugins ສໍາລັບຜະລິດຕະພັນ Atlassian. Prometheus, Docker ແລະ Redis ຜູ້ປະກາດຂ່າວປະເສີດ.

ກ່ຽວກັບ Infobip

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

Infobip ໂຄງສ້າງພື້ນຖານດ້ານໄອທີໃນຕົວເລກ:

ສູນຂໍ້ມູນ 15 ແຫ່ງທົ່ວໂລກ;
500 ການບໍລິການເປັນເອກະລັກໃນການດໍາເນີນງານ;
2500 ການບໍລິການຕົວຢ່າງ, ເຊິ່ງຫຼາຍກ່ວາຄໍາສັ່ງ;
4,5 TB ການຈະລາຈອນປະຈໍາເດືອນ;
4,5 ຕື້ເບີໂທລະສັບ;

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

ການປ່ອຍ

ການປ່ອຍທົ່ວໄປເປັນແບບນີ້. ຕົວຢ່າງ, ມີບໍລິການ A, B, C, D ແລະ E, ແຕ່ລະຄົນແມ່ນພັດທະນາໂດຍທີມງານແຍກຕ່າງຫາກ.

ໃນບາງຈຸດ, ທີມງານບໍລິການ A ຕັດສິນໃຈທີ່ຈະນໍາໃຊ້ສະບັບໃຫມ່, ແຕ່ທີມງານບໍລິການ B, C, D ແລະ E ບໍ່ຮູ້ກ່ຽວກັບມັນ. ມີສອງທາງເລືອກສໍາລັບສິ່ງທີ່ທີມງານບໍລິການ A ຈະເຮັດ.

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

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

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

ດັ່ງນັ້ນພວກເຮົາຕ້ອງການຫຍັງ?

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

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

ບັນຫາໃນການນຳໃຊ້

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

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

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

ສູນຂໍ້ມູນບໍ່ສາມາດຖືກຈໍາລອງຢູ່ເທິງເວທີ. ມີ 200 racks ໃນສູນຂໍ້ມູນຫນຶ່ງ - ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຮັດຊ້ໍາອີກໃນ sandbox.

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

ວິທີແກ້ໄຂຄລາສສິກ

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

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

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

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

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

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

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

ການທົດສອບຄວັນຢາສູບ

ອີກວິທີໜຶ່ງເພື່ອແກ້ໄຂບັນຫາຂອງພວກເຮົາໃນການນຳໃຊ້. ຂໍໃຫ້ເບິ່ງວິທີການທົດສອບຄວັນຢາສູບໃນຕົວຢ່າງທີ່ຜ່ານມາ, ເມື່ອທີມງານ A ຕ້ອງການໃຊ້ເວີຊັນໃຫມ່.

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

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

ຂໍ້ເສຍຂອງການທົດສອບຄວັນຢາສູບ:

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

ໂບນັດພຽງແຕ່ຢູ່ທີ່ນີ້ ທ່ານສາມາດກວດສອບການປະຕິບັດ.

ການປ່ອຍ Canary

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

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

ການປະຕິບັດແລະ nuances

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

ການຈັດວາງເປັນແບບນີ້: ພວກເຮົາເອົາຫນຶ່ງ node ອອກຈາກພາຍໃຕ້ balancer (1), ປ່ຽນສະບັບ (2) ແລະແຍກອອກໃນບາງການຈະລາຈອນ (3).

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

ຂ້າພະເຈົ້າຈະສະແດງໃຫ້ທ່ານ schematically ມັນເບິ່ງຄືວ່າສໍາລັບ microservices ໃນກໍລະນີຫຼາຍທີ່ສຸດ.

ມີ Service Discovery ແລະອີກສອງບໍລິການ: S1N1 ແລະ S2. ການບໍລິການທໍາອິດ (S1N1) ແຈ້ງເຕືອນ Service Discovery ເມື່ອມັນເລີ່ມຕົ້ນ, ແລະ Service Discovery ຈື່ມັນໄວ້. ການບໍລິການທີສອງທີ່ມີສອງ nodes (S2N1 ແລະ S2N2) ຍັງແຈ້ງການບໍລິການຄົ້ນພົບໃນຕອນເລີ່ມຕົ້ນ.

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

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

ພວກເຮົາປ່ຽນສະບັບແລະ Service Discovery ຮູ້ວ່າ node ທີສອງໃນປັດຈຸບັນແມ່ນ canary - ທ່ານສາມາດໃຫ້ມັນໂຫຼດຫນ້ອຍລົງ (5%). ຖ້າທັງຫມົດແມ່ນດີ, ພວກເຮົາປ່ຽນສະບັບ, ສົ່ງຄືນການໂຫຼດແລະກ້າວຕໍ່ໄປ.

ເພື່ອປະຕິບັດທັງຫມົດນີ້, ພວກເຮົາຕ້ອງການ:

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

ການດຸ່ນດ່ຽງ

ນີ້ແມ່ນສິ່ງທໍາອິດທີ່ພວກເຮົາຄວນຄິດກ່ຽວກັບ. ມີສອງຍຸດທະສາດການດຸ່ນດ່ຽງ.

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

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

ການຕິດຕາມ

ພື້ນຖານຂອງການປ່ອຍ canary. ພວກເຮົາຕ້ອງເຂົ້າໃຈຢ່າງແນ່ນອນວ່າເປັນຫຍັງພວກເຮົາຈຶ່ງເຮັດອັນນີ້ ແລະຕົວວັດແທກໃດທີ່ເຮົາຕ້ອງການເກັບກຳ.

ຕົວຢ່າງຂອງການວັດແທກທີ່ພວກເຮົາເກັບຈາກການບໍລິການຂອງພວກເຮົາ.

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

ຕົວຢ່າງຂອງ metrics ໃນລະບົບການຕິດຕາມທີ່ນິຍົມຫຼາຍທີ່ສຸດ.

ວຽກງານຕ້ານການ. ນີ້ແມ່ນບາງມູນຄ່າທີ່ເພີ່ມຂຶ້ນ, ຕົວຢ່າງ, ຈໍານວນຂໍ້ຜິດພາດ. ມັນງ່າຍທີ່ຈະ interpolate metric ນີ້ແລະສຶກສາກາຟ: ມື້ວານນີ້ມີ 2 ຂໍ້ຜິດພາດ, ແລະມື້ນີ້ມີ 500, ຊຶ່ງຫມາຍຄວາມວ່າມີບາງສິ່ງບາງຢ່າງຜິດພາດ.

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

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

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

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

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

ເຄື່ອງມື

ELK Stack. ທ່ານສາມາດປະຕິບັດ canary ໂດຍໃຊ້ Elasticsearch - ພວກເຮົາບັນທຶກຂໍ້ຜິດພາດໃນມັນເມື່ອເຫດການເກີດຂື້ນ. ດ້ວຍການໂທ API ທີ່ງ່າຍດາຍທ່ານສາມາດໄດ້ຮັບຈໍານວນຂໍ້ຜິດພາດໃນທຸກເວລາແລະປຽບທຽບກັບໄລຍະເວລາທີ່ຜ່ານມາ: GET /applg/_cunt?q=level:errr.

Prometheus. ລາວໄດ້ສະແດງຕົນເອງໄດ້ດີໃນ Infobip. ມັນອະນຸຍາດໃຫ້ປະຕິບັດການວັດແທກຫຼາຍມິຕິລະດັບເພາະວ່າປ້າຍຊື່ຖືກນໍາໃຊ້.

ພວກເຮົາສາມາດນໍາໃຊ້ level, instance, service, ສົມທົບພວກເຂົາຢູ່ໃນລະບົບດຽວ. ດ້ວຍການຊ່ວຍເຫຼືອ offset ທ່ານສາມາດເບິ່ງ, ຕົວຢ່າງ, ມູນຄ່າຂອງມູນຄ່າຫນຶ່ງອາທິດກ່ອນຫນ້ານີ້ມີພຽງແຕ່ຫນຶ່ງຄໍາສັ່ງ GET /api/v1/query?query={query}ບ່ອນທີ່ {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

ການວິເຄາະສະບັບ

ມີຫຼາຍຍຸດທະສາດສໍາລັບການວິເຄາະສະບັບ.

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

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

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

ອັດຕະໂນມັດ

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

ໃຫ້ເລີ່ມຕົ້ນ;
ເອົາ node ຈາກພາຍໃຕ້ balancer;
ຕິດຕັ້ງ canary node;
ພວກເຮົາເປີດເຄື່ອງດຸ່ນດ່ຽງທີ່ມີຈໍານວນຈໍາກັດຂອງການຈະລາຈອນ;
ໃຫ້ສົມທຽບ.

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

ນີ້ແມ່ນທໍ່ສົ່ງໄປຫາ Groovy.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

ທີ່ນີ້ໃນ loop ພວກເຮົາກໍານົດວ່າພວກເຮົາຈະປຽບທຽບ node ໃຫມ່ພາຍໃນຫນຶ່ງຊົ່ວໂມງ. ຖ້າຂະບວນການ canary ຍັງບໍ່ທັນໄດ້ສໍາເລັດຂະບວນການ, ໂທຫາຫນ້າທີ່. ນາງລາຍງານວ່າທຸກສິ່ງທຸກຢ່າງດີຫຼືບໍ່: def isOk = compare(srv, canary, time, base, offset, metrics).

ຖ້າຫາກວ່າທັງຫມົດແມ່ນດີ - sleep DEFAULT SLEEP, ສໍາລັບການຍົກຕົວຢ່າງ, ສໍາລັບວິນາທີ, ແລະສືບຕໍ່. ຖ້າບໍ່ແມ່ນ, ອອກຈາກ - ການຕິດຕັ້ງລົ້ມເຫລວ.

ລາຍລະອຽດຂອງ metric. ມາເບິ່ງກັນວ່າຟັງຊັນອາດຈະຄ້າຍຄືແນວໃດ compare ໃຊ້ DSL ເປັນຕົວຢ່າງ.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

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

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

ເປັນຫຍັງທັງໝົດນີ້ຈຶ່ງຕ້ອງການ?

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

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

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

ອຸປະສັກ

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

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

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

ພວກເຮົາໄດ້ຮັບຜົນປະໂຫຍດຈາກການປ່ອຍ canary ແນວໃດ

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

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

ການນຳໃຊ້ອັດຕະໂນມັດ. ນີ້ບໍ່ແມ່ນຂະບວນການຄູ່ມືຄືກັບກ່ອນ, ແຕ່ເປັນອັດຕະໂນມັດແທ້ໆ. ແຕ່ມັນໃຊ້ເວລາດົນກວ່າ.

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

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

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

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

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