ຈາກ monoliths ກັບ microservices: ປະສົບການຂອງ M.Video-Eldorado ແລະ MegaFon

ໃນວັນທີ 25 ເດືອນເມສາ, ພວກເຮົາຢູ່ Mail.ru Group ໄດ້ຈັດກອງປະຊຸມກ່ຽວກັບເມຄແລະຮອບ - mailto:CLOUD. ຈຸດເດັ່ນບາງອັນ:

• ຕົ້ນຕໍ ຜູ້ໃຫ້ບໍລິການພາສາລັດເຊຍ — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center ແລະ Yandex.Cloud ໄດ້ເວົ້າກ່ຽວກັບສະເພາະຂອງຕະຫຼາດຄລາວຂອງພວກເຮົາ ແລະການບໍລິການຂອງເຂົາເຈົ້າ;
• ເພື່ອນຮ່ວມງານຈາກ Bitrix24 ບອກວິທີການຂອງເຂົາເຈົ້າ ມາ multicloud;
• Leroy Merlin, Otkritie, Burger King ແລະ Schneider Electric ໄດ້ໃຫ້ຄວາມສົນໃຈ ເບິ່ງຈາກຜູ້ບໍລິໂພກຟັງ — ສິ່ງທີ່ທຸລະກິດຂອງພວກເຂົາຕັ້ງໄວ້ສໍາລັບ IT ແລະເຕັກໂນໂລຢີໃດ, ລວມທັງຄລາວ, ພວກເຂົາເຫັນວ່າເປັນແນວໂນ້ມທີ່ສຸດ.

ທ່ານສາມາດເບິ່ງວິດີໂອທັງໝົດໄດ້ຈາກ mailto:CLOUD conference ການເຊື່ອມຕໍ່, ແລະໃນທີ່ນີ້ທ່ານສາມາດອ່ານວິທີການສົນທະນາກ່ຽວກັບ microservices ໄດ້ໄປ. Alexander Deulin, ຫົວຫນ້າສູນຄົ້ນຄວ້າແລະພັດທະນາລະບົບທຸລະກິດ MegaFon, ແລະ Sergey Sergeev, ຜູ້ອໍານວຍການເຕັກໂນໂລຢີຂໍ້ມູນຂ່າວສານຂອງກຸ່ມ M.Video-Eldorado, ໄດ້ແບ່ງປັນກໍລະນີທີ່ປະສົບຜົນສໍາເລັດຂອງພວກເຂົາໃນການກໍາຈັດ monoliths. ພວກເຮົາຍັງໄດ້ສົນທະນາກ່ຽວກັບບັນຫາທີ່ກ່ຽວຂ້ອງຂອງຍຸດທະສາດ IT, ຂະບວນການແລະແມ້ກະທັ້ງ HR.

ຜູ້ເຂົ້າຮ່ວມກອງປະຊຸມ

• Sergey Sergeev, ກຸ່ມ CIO "M.Video-Eldorado";
• Alexander Deulin, ຫົວໜ້າສູນຄົ້ນຄວ້າ ແລະ ພັດທະນາລະບົບທຸລະກິດ MegaFon;
• ຜູ້​ຄວບ​ຄຸມ — Dmitry Lazarenko, ຫົວຫນ້າທິດທາງ PaaS Mail.ru Cloud Solutions.

ຫຼັງຈາກຄໍາເວົ້າຂອງ Alexander Deulin "ວິທີການ MegaFon ກໍາລັງຂະຫຍາຍທຸລະກິດຂອງຕົນໂດຍຜ່ານເວທີການບໍລິການຈຸນລະພາກ" ລາວໄດ້ຖືກເຂົ້າຮ່ວມສໍາລັບການສົນທະນາໂດຍ Sergey Sergeev ຈາກ M.Video-Eldorado ແລະຜູ້ຄວບຄຸມການສົນທະນາ Dmitry Lazarenko, Mail.ru Cloud Solutions.

ຂ້າງລຸ່ມນີ້ພວກເຮົາໄດ້ກະກຽມບົດບັນທຶກການສົນທະນາສໍາລັບທ່ານ, ແຕ່ທ່ານສາມາດເບິ່ງວິດີໂອໄດ້:

ການຫັນປ່ຽນໄປສູ່ການບໍລິການຈຸລະພາກແມ່ນການຕອບສະຫນອງຄວາມຕ້ອງການຂອງຕະຫຼາດ

Dmitriy:

ທ່ານມີປະສົບການສົບຜົນສໍາເລັດໃນການເຄື່ອນຍ້າຍໄປສູ່ microservices ບໍ? ແລະໂດຍທົ່ວໄປ: ບ່ອນໃດທີ່ທ່ານເຫັນຜົນປະໂຫຍດທາງທຸລະກິດທີ່ໃຫຍ່ທີ່ສຸດຈາກການນໍາໃຊ້ microservices ຫຼືການເຄື່ອນຍ້າຍຈາກ monoliths ໄປຫາ microservices?

Sergey:

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

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

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

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

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

ວິທີການວັດແທກຄວາມສໍາເລັດຂອງການເຄື່ອນຍ້າຍໄປສູ່ microservices

Dmitriy:

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

Sergey:

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

Alexander:

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

Sergey:

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

Microservices ຈະມາ, ແຕ່ຫຼັກຈະຍັງຄົງຢູ່

Dmitriy:

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

Sergey:

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

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

Dmitriy:

ຊີວິດຢູ່ໃນຮູບຮ່າງທີ່ດີ. (ຫົວ)

Alexander:

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

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

ວິທີການຂາຍບໍລິການຈຸລະພາກໃຫ້ແກ່ທຸລະກິດ

Dmitriy:

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

Sergey:

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

Dmitriy:

ທ່ານ somehow ບັນທຶກເວລາຂອງຂັ້ນຕອນຂອງການທໍາອິດ?

Sergey:

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

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

Dmitriy:

ຕົກ​ລົງ. Alexander, ເຈົ້າເວົ້າຫຍັງ?

Alexander:

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

Dmitriy:

ມັນເກີດຂຶ້ນບໍວ່າທຸລະກິດອະນຸຍາດໃຫ້ທ່ານເຮັດສິ່ງຕ່າງໆເຊັ່ນ Google - ໃນມື້ຫນຶ່ງຟຣີຕໍ່ອາທິດ? ເຈົ້າມີທິດທາງດັ່ງກ່າວບໍ?

Alexander:

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

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

Microservices: hype ຫຼືຄວາມຈໍາເປັນ?

Dmitriy:

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

Sergey:

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

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

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

ພວກເຮົາເຫັນການພັດທະນານີ້:

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

​ແຕ່​ໃນ​ຂະນະ​ດຽວ​ກັນ, ຂ້າພະ​ເຈົ້າກໍ​ເປັນ​ຜູ້​ສະໜັບສະໜູນ​ການ​ສືບ​ຕໍ່​ນຳ​ໃຊ້​ຫຼັກການ​ເກົ່າ ຖ້າ​ຫາກ​ໃຊ້​ຢ່າງ​ເໝາະ​ສົມ.

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

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

Alexander:

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

Dmitriy:

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

ວິທີການພັດທະນາບໍລິການຈຸລະພາກທີ່ເຊື່ອຖືໄດ້

Dmitriy:

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

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

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

Alexander:

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

ພວກເຮົາບໍ່ມີຄວາມລົ້ມເຫລວທົ່ວໂລກກັບບໍລິການຈຸລະພາກ. ພວກເຮົານອນຢ່າງສະຫງົບ, ພວກເຮົາມີການປ່ຽນຫນ້າທີ່ 24/7 ທີ່ໃຫ້ບໍລິການ BSS [ລະບົບສະຫນັບສະຫນູນທຸລະກິດ] ທັງຫມົດ.

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

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

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

Microservices ແລະ HR

Sergey:

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

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

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

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

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

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

Dmitriy:

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

Sergey:

ແມ່ນແລ້ວ, ຢ່າງແທ້ຈິງ.

Alexander:

HR ຖາມຄໍາຖາມ: "ຢູນິຄອນສີບົວຂອງເຈົ້າຢູ່ໃສລະຫວ່າງ backend ແລະ frontend?" HR ບໍ່ເຂົ້າໃຈວ່າ microservice ແມ່ນຫຍັງ. ພວກ​ເຮົາ​ໄດ້​ບອກ​ພວກ​ເຂົາ​ຄວາມ​ລັບ​ແລະ​ບອກ​ເຂົາ​ເຈົ້າ​ວ່າ backend ໄດ້​ເຮັດ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​, ແລະ​ບໍ່​ມີ unicorn​. ແຕ່ HR ກໍາລັງປ່ຽນແປງ, ຮຽນຮູ້ຢ່າງໄວວາແລະຮັບສະຫມັກຜູ້ທີ່ມີຄວາມຮູ້ພື້ນຖານ IT.

ວິວັດທະນາການຂອງບໍລິການຈຸລະພາກ

Dmitriy:

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

Sergey:

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

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

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

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

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

Dmitriy:

ເຢັນ. ແມ່ນຫຍັງຢູ່ໃນ MegaFon?

Alexander:

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

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

Dmitriy:

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

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

ຂໍຂອບໃຈກັບຜູ້ເຂົ້າຮ່ວມທັງຫມົດ, ຂອບໃຈ Sergei ແລະ Alexander!

ຄໍາຖາມຈາກຜູ້ຊົມ

ຄຳຖາມຈາກຜູ້ຊົມ (1):

Sergey, ການຄຸ້ມຄອງ IT ມີການປ່ຽນແປງແນວໃດໃນບໍລິສັດຂອງທ່ານ? ຂ້າພະເຈົ້າເຂົ້າໃຈວ່າເມື່ອມີຫຼາຍໆລະບົບຫຼາຍ, ວິທີການຈັດການມັນແມ່ນຂະບວນການທີ່ຊັດເຈນແລະມີເຫດຜົນ. ທ່ານໄດ້ຟື້ນຟູການຄຸ້ມຄອງອົງປະກອບ IT ແນວໃດຫຼັງຈາກຈໍານວນ microservices ຈໍານວນຫລາຍໄດ້ຖືກປະສົມປະສານໃນໄລຍະເວລາສັ້ນໆດັ່ງກ່າວ?

Sergey:

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

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

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

ຄຳຖາມຈາກຜູ້ຊົມ (2):

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

Alexander:

ມີຄວາມຫຍຸ້ງຍາກໃນເວລາທີ່ການເຄື່ອນຍ້າຍຈາກ microservices ໄປສູ່ເວທີ, ແຕ່ພວກເຂົາສາມາດແກ້ໄຂໄດ້.

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

ແລະບັນຫາຂອງພວກເຮົາແມ່ນພຽງແຕ່ຢູ່ໃນທີມງານຂະຫນາດນ້ອຍ. ວິສະວະກອນ QA ນຶ່ງຄົນແມ່ນຕ້ອງການສໍາລັບຜະລິດຕະພັນທີ່ມີເງື່ອນໄຂ. ແລະດັ່ງນັ້ນ, ພວກເຮົາສົ່ງຜະລິດຕະພັນຂອງ 5-7 microservices, ເຊິ່ງ 2-3 ສາມາດພັດທະນາໂດຍພາກສ່ວນທີສາມ. ຕົວຢ່າງ, ພວກເຮົາມີຜະລິດຕະພັນໃນການພັດທະນາທີ່ຜູ້ຂາຍລະບົບການເອີ້ນເກັບເງິນຂອງພວກເຮົາ, ກຸ່ມ Mail.ru ແລະ MegaFon R&D ເຂົ້າຮ່ວມ. ພວກເຮົາຈໍາເປັນຕ້ອງກວມເອົານີ້ດ້ວຍການທົດສອບກ່ອນທີ່ຈະສົ່ງມັນໄປສູ່ການຜະລິດ. ວິສະວະກອນ QA ໄດ້ເຮັດວຽກກ່ຽວກັບຜະລິດຕະພັນນີ້ສໍາລັບເດືອນແລະເຄິ່ງຫນຶ່ງ, ແລະສ່ວນທີ່ເຫຼືອຂອງທີມງານແມ່ນປະໄວ້ໂດຍບໍ່ມີການສະຫນັບສະຫນູນຂອງລາວ.

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

Sergey:

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

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

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

Alexander:

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

ຄຳຖາມຈາກຜູ້ຊົມ (3):

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

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

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

Alexander:

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

Sergey:

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

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

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

Alexander:

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

Sergey:

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

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

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

ສິ້ນສຸດການສົນທະນາ, ແຕ່ບໍ່ແມ່ນທັງຫມົດ

mailto:ກອງປະຊຸມ CLOUD ໄດ້ຖືກຈັດຕັ້ງ Mail.ru Cloud Solutions.

ພວກເຮົາຍັງເຮັດກິດຈະກໍາອື່ນໆ - e.g. @Kubernetes ປະຊຸມ, ບ່ອນທີ່ພວກເຮົາກໍາລັງຊອກຫາລໍາໂພງທີ່ຍິ່ງໃຫຍ່ຢູ່ສະເຫມີ:

• ຕິດຕາມ @Kubernetes ແລະຂ່າວ @Meetup ອື່ນໆໃນຊ່ອງທາງ Telegram ຂອງພວກເຮົາ t.me/k8s_mail
• ມີຄວາມສົນໃຈໃນການເວົ້າຢູ່ໃນຫນຶ່ງໃນ @Meetups? ອອກຈາກການຮ້ອງຂໍສໍາລັບການ mcs.mail.ru/speak

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