ສະຖານະຂອງ DevOps ໃນລັດເຊຍ 2020

ວິທີການເຂົ້າໃຈສະຖານະຂອງບາງສິ່ງບາງຢ່າງ?

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

ແຕ່ມື້ໄດ້ມາຮອດເມື່ອການສຶກສາດັ່ງກ່າວໄດ້ຖືກດໍາເນີນ, ແລະມື້ນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບຜົນໄດ້ຮັບ. ລັດ DevOps ໃນລັດເຊຍໄດ້ຖືກສຶກສາຮ່ວມກັນໂດຍບໍລິສັດ "ດ່ວນ 42"ແລະ"Ontico". Express 42 ຊ່ວຍໃຫ້ບໍລິສັດເຕັກໂນໂລຢີປະຕິບັດແລະພັດທະນາການປະຕິບັດແລະເຄື່ອງມືຂອງ DevOps ແລະເປັນຫນຶ່ງໃນຜູ້ທໍາອິດທີ່ເວົ້າກ່ຽວກັບ DevOps ໃນລັດເຊຍ. ຜູ້ຂຽນຂອງການສຶກສາ, Igor Kurochkin ແລະ Vitaly Khabarov, ມີສ່ວນຮ່ວມໃນການວິເຄາະແລະການໃຫ້ຄໍາປຶກສາຢູ່ທີ່ Express 42, ໃນຂະນະທີ່ມີພື້ນຖານດ້ານວິຊາການຈາກການດໍາເນີນງານແລະປະສົບການໃນບໍລິສັດທີ່ແຕກຕ່າງກັນ. ສໍາລັບ 8 ປີ, ເພື່ອນຮ່ວມງານໄດ້ເບິ່ງຫຼາຍສິບບໍລິສັດແລະໂຄງການ - ຈາກ startups ກັບວິສາຫະກິດ - ມີບັນຫາທີ່ແຕກຕ່າງກັນ, ເຊັ່ນດຽວກັນກັບການໃຫຍ່ເຕັມຕົວຂອງວັດທະນະທໍາແລະວິສະວະກໍາທີ່ແຕກຕ່າງກັນ.

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

ການຄົ້ນຄວ້າ DevOps

ການສົນທະນາໄດ້ເລີ່ມຕົ້ນໂດຍ Igor Kurochkin.

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

ໃນທີ່ນີ້ພວກເຮົາມີບັນຫາທໍາອິດ, ແລະຫຼັງຈາກມັນອີກສອງຢ່າງ:

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

ລອງມາເບິ່ງວິທີການວິເຄາະລັດຂອງ DevOps ໃນທົ່ວໂລກ.

ພື້ນຫລັງປະຫວັດສາດ

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

ໃນປີ 2013, IT Revolution ປາກົດ, ຜູ້ຈັດພິມຫນັງສືໃຫຍ່ທັງຫມົດໃນ DevOps. ຮ່ວມກັນກັບ Puppet, ພວກເຂົາເຈົ້າໄດ້ກະກຽມການພິມ State of DevOps ທໍາອິດ, ບ່ອນທີ່ 4 metrics ທີ່ສໍາຄັນປາກົດເປັນຄັ້ງທໍາອິດ. ໃນປີຕໍ່ມາ, ThoughtWorks, ບໍລິສັດທີ່ປຶກສາທີ່ຮູ້ຈັກສໍາລັບ radars ເຕັກໂນໂລຊີປົກກະຕິຂອງຕົນກ່ຽວກັບການປະຕິບັດອຸດສາຫະກໍາແລະເຄື່ອງມື, ໄດ້ມີສ່ວນຮ່ວມ. ແລະໃນປີ 2015, ພາກສ່ວນທີ່ມີວິທີການໄດ້ຖືກເພີ່ມ, ແລະມັນເຫັນໄດ້ຊັດເຈນວ່າພວກເຂົາປະຕິບັດການວິເຄາະແນວໃດ.

ໃນປີ 2016, ຜູ້ຂຽນຂອງການສຶກສາ, ໄດ້ສ້າງບໍລິສັດຂອງຕົນເອງ DORA (DevOps Research and Assessment), ຈັດພີມມາບົດລາຍງານປະຈໍາປີ. ໃນປີຕໍ່ມາ, DORA ແລະ Puppet ໄດ້ອອກບົດລາຍງານຮ່ວມກັນຄັ້ງສຸດທ້າຍຂອງພວກເຂົາ.

ແລະຫຼັງຈາກນັ້ນບາງສິ່ງບາງຢ່າງທີ່ຫນ້າສົນໃຈໄດ້ເລີ່ມຕົ້ນ:

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

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

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

ສິ່ງທີ່ຢູ່ໃນລັດເຊຍເປັນແນວໃດ?

ພວກເຮົາຍັງບໍ່ໄດ້ເຮັດການຄົ້ນຄວ້າ DevOps. ພວກເຮົາໄດ້ເວົ້າຢູ່ໃນກອງປະຊຸມ, ເລົ່າຄືນຜົນການຄົ້ນພົບຂອງຄົນອື່ນ, ແລະ Raiffeisenbank ໄດ້ແປ "State of DevOps" ສໍາລັບ 2019 (ທ່ານສາມາດຊອກຫາການປະກາດຂອງພວກເຂົາໃນHabré), ຂອບໃຈຫຼາຍໆກັບພວກເຂົາ. ແລະມັນທັງຫມົດ.

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

ຂະບວນການຄົ້ນຄ້ວາ

ບົດລາຍງານແມ່ນພຽງແຕ່ສ່ວນສຸດທ້າຍ. ຂະບວນການຄົ້ນຄ້ວາທັງຫມົດປະກອບດ້ວຍສີ່ຂັ້ນຕອນທີ່ສໍາຄັນ:

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

ຜູ້ເຂົ້າຮ່ວມ

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

ແຜນທີ່ຈາກບົດລາຍງານ Accelerate State of DevOps 2019:

ໃນການສຶກສາຂອງພວກເຮົາ, ພວກເຮົາໄດ້ຈັດການສໍາພາດ 889 ຄົນ - ນີ້ແມ່ນຂ້ອນຂ້າງຫຼາຍ (DORA ການສໍາຫຼວດປະມານຫນຶ່ງພັນຄົນຕໍ່ປີໃນບົດລາຍງານຂອງມັນ) ແລະໃນທີ່ນີ້ພວກເຮົາໄດ້ບັນລຸເປົ້າຫມາຍ:

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

ອຸດສາຫະກໍາແລະຕໍາແຫນ່ງ

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

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

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

ການວິເຄາະແລະການປຽບທຽບ

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

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

ຕົວຊີ້ວັດຫຼັກ

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

ຕົວຊີ້ວັດທີ່ສໍາຄັນ:

1. ຄວາມຖີ່ຂອງການນຳໃຊ້. ເວີຊັນໃໝ່ຂອງແອັບພລິເຄຊັນຖືກນຳໃຊ້ກັບສະພາບແວດລ້ອມການຜະລິດເລື້ອຍໆເທົ່າໃດ (ການປ່ຽນແປງທີ່ວາງແຜນໄວ້, ຍົກເວັ້ນການແກ້ໄຂດ່ວນ ແລະ ການຕອບສະໜອງເຫດການ)?
2. ເວລາຈັດສົ່ງ. ເວລາສະເລ່ຍລະຫວ່າງການປະຕິບັດການປ່ຽນແປງ (ການຂຽນຫນ້າທີ່ເປັນລະຫັດ) ແລະການປະຕິບັດການປ່ຽນແປງໄປສູ່ສະພາບແວດລ້ອມການຜະລິດແມ່ນຫຍັງ?
3. ເວລາຟື້ນຟູ. ມັນໃຊ້ເວລາດົນປານໃດໂດຍສະເລ່ຍເພື່ອຟື້ນຟູແອັບພລິເຄຊັນໄປສູ່ສະພາບແວດລ້ອມການຜະລິດຫຼັງຈາກເຫດການ, ການເຊື່ອມໂຊມຂອງການບໍລິການ, ຫຼືການຄົ້ນພົບຂໍ້ບົກພ່ອງທີ່ສົ່ງຜົນກະທົບຕໍ່ຜູ້ໃຊ້ແອັບພລິເຄຊັນ?
4. ການປ່ຽນແປງທີ່ບໍ່ສໍາເລັດ. ອັດຕາສ່ວນຂອງການນໍາໃຊ້ໃນສະພາບແວດລ້ອມການຜະລິດນໍາໄປສູ່ການເສື່ອມສະພາບຂອງຄໍາຮ້ອງສະຫມັກຫຼືເຫດການແລະຮຽກຮ້ອງໃຫ້ມີການແກ້ໄຂ (rollback ຂອງການປ່ຽນແປງ, ການພັດທະນາຂອງ hotfix ຫຼື patch)?

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

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

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

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

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

ນ້ຳໜັກເທົ່າໃດເປັນກຣາມ?

ພວກເຮົາໃຊ້ການວິເຄາະກຸ່ມແບບລຳດັບ:

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

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

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

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

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

ຫຼັງຈາກນັ້ນ, ຄໍາຖາມທີ່ເກີດຂື້ນ: ວິທີການນໍາໃຊ້ທັງຫມົດນີ້?

ວິທີໃຊ້

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

ພວກເຮົາໄດ້ກວດເບິ່ງ: ພວກເຮົາໄດ້ເອົາຜູ້ຕອບຂອງພວກເຮົາແລະໂປຣໄຟລ໌ການປະຕິບັດຂອງ DORA, ແລະເບິ່ງວ່າມີຈໍານວນຜູ້ຕອບທີ່ເຫມາະສົມກັບໂປຣໄຟລ໌ນີ້ຫຼືນັ້ນ. ພວກເຮົາພົບເຫັນວ່າມີພຽງແຕ່ 16% ຂອງຜູ້ຕອບແນ່ນອນໄດ້ຕົກເຂົ້າໄປໃນຫນຶ່ງຂອງໂປຣໄຟລ໌. ສ່ວນທີ່ເຫຼືອທັງໝົດແມ່ນກະແຈກກະຈາຍຢູ່ບ່ອນໃດບ່ອນໜຶ່ງໃນລະຫວ່າງ:

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

• ເຄື່ອງຄິດເລກ DORA
• ເຄື່ອງຄິດເລກດ່ວນ 42* (ກຳລັງພັດທະນາ)
• ການພັດທະນາຂອງຕົນເອງ (ທ່ານສາມາດສ້າງເຄື່ອງຄິດເລກພາຍໃນຂອງທ່ານເອງ).

ພວກເຂົາຕ້ອງການຫຍັງ? ເພື່ອ​ເຂົ້າ​ໃຈ:

• ທີມງານພາຍໃນອົງການຂອງພວກເຮົາໄດ້ມາດຕະຖານຂອງພວກເຮົາບໍ?
• ຖ້າບໍ່, ພວກເຮົາສາມາດຊ່ວຍມັນໄດ້, ເລັ່ງມັນຢູ່ໃນຂອບຂອງຄວາມຊໍານານທີ່ບໍລິສັດຂອງພວກເຮົາມີບໍ?
• ຖ້າເປັນດັ່ງນັ້ນ, ພວກເຮົາສາມາດເຮັດໄດ້ດີກວ່າບໍ?

ນອກນັ້ນທ່ານຍັງສາມາດໃຊ້ພວກມັນເພື່ອເກັບກໍາສະຖິຕິພາຍໃນບໍລິສັດ:

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

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

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

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

ຂໍໃຫ້ກ້າວໄປສູ່ຄວາມຫວານທີ່ສຸດ - ການປຽບທຽບ.

ປຽບທຽບ

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

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

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

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

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

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

ມີຫຍັງອີກແດ່ທີ່ຊ່ວຍທີມງານຂອງພວກເຮົາ?

ການປະຕິບັດດ້ານວິສະວະກໍາ

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

ເວທີເປັນການບໍລິການ

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

ໂຄງສ້າງພື້ນຖານເປັນລະຫັດ

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

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

ການປະສົມປະສານແລະການຈັດສົ່ງ

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

ຖາປັດຕະຍະ

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

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

ພວກເຮົາຄົ້ນພົບທັງຫມົດນີ້ໄດ້ແນວໃດ?

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

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

ສໍາລັບການປ່ຽນແປງ, ໃຫ້ປ່ຽນຈາກສະຖິຕິທີ່ຊັບຊ້ອນໄປຫາແບບງ່າຍໆ.

ມີຫຍັງອີກແດ່ທີ່ພວກເຮົາຄົ້ນພົບ?

ເຄື່ອງມື

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

ໃນບັນດານັກດົນຕີ, ມັນບໍ່ແມ່ນຄວາມລັບສໍາລັບໃຜ, Kubernetes ເປັນຜູ້ນໍາພາ (52%). ຕໍ່ໄປໃນແຖວ orchestrator ແມ່ນ Docker Swarm (ປະມານ 12%). ລະບົບ CI ທີ່ນິຍົມທີ່ສຸດແມ່ນ Jenkins ແລະ GitLab. ລະບົບການຈັດການການຕັ້ງຄ່າທີ່ນິຍົມຫຼາຍທີ່ສຸດແມ່ນ Ansible, ຕິດຕາມມາດ້ວຍ Shell ທີ່ຮັກແພງຂອງພວກເຮົາ.

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

ຂ້າພະເຈົ້າຜ່ານຊັ້ນໃຫ້ Igor, ຜູ້ທີ່ຈະໃຫ້ສະຖິຕິເພີ່ມເຕີມ.

ການເຜີຍແຜ່ການປະຕິບັດ

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

Agile ແລະ DevOps

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

ຄໍາສັ່ງ topologies

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

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

ອັດຕາສ່ວນ DevQaOps

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

ແຜນການໃນປີ 2021

ໃນແຜນການໃນປີຕໍ່ໄປ, ຜູ້ຕອບແບບສອບຖາມໄດ້ສັງເກດເຫັນກິດຈະກໍາດັ່ງຕໍ່ໄປນີ້:

ທີ່ນີ້ທ່ານສາມາດເບິ່ງຈຸດຕັດກັນກັບກອງປະຊຸມ DevOps Live 2020. ພວກເຮົາໄດ້ທົບທວນຄືນໂຄງການຢ່າງລະມັດລະວັງ:

• ໂຄງສ້າງພື້ນຖານເປັນຜະລິດຕະພັນ
• ການຫັນປ່ຽນ DevOps
• ການແຈກຢາຍການປະຕິບັດ DevOps
• DevSecOps
• ສະໂມສອນກໍລະນີແລະການສົນທະນາ

ແຕ່ເວລາຂອງການນໍາສະເຫນີຂອງພວກເຮົາບໍ່ພຽງພໍທີ່ຈະກວມເອົາຫົວຂໍ້ທັງຫມົດ. ປະໄວ້ທາງຫລັງຂອງ scenes:

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

ບົດລາຍງານ ພວກເຮົາໄດ້ຮັບ voluminous, 50 ຫນ້າ, ແລະທ່ານສາມາດເບິ່ງມັນໃນລາຍລະອຽດເພີ່ມເຕີມ.

Summing up

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

ຜົນໄດ້ຮັບຂອງການສຶກສາຄັ້ງທໍາອິດຂອງລັດ DevOps ໃນລັດເຊຍ:

• ຕົວຊີ້ວັດທີ່ສໍາຄັນ. ພວກເຮົາໄດ້ພົບເຫັນວ່າຕົວຊີ້ວັດທີ່ສໍາຄັນ (ເວລາການຈັດສົ່ງ, ຄວາມຖີ່ຂອງການປະຕິບັດ, ເວລາການຟື້ນຕົວ, ແລະຄວາມລົ້ມເຫຼວຂອງການປ່ຽນແປງ) ແມ່ນເຫມາະສົມສໍາລັບການວິເຄາະປະສິດທິພາບຂອງການພັດທະນາ, ການທົດສອບແລະຂະບວນການປະຕິບັດງານ.
• ໂປຣໄຟລ໌ສູງ, ປານກາງ, ຕ່ຳ. ອີງຕາມຂໍ້ມູນທີ່ເກັບກໍາ, ພວກເຮົາສາມາດຈໍາແນກກຸ່ມທີ່ແຕກຕ່າງກັນທາງສະຖິຕິຂອງສູງ, ກາງ, ຕ່ໍາດ້ວຍລັກສະນະທີ່ໂດດເດັ່ນໃນແງ່ຂອງ metrics, ການປະຕິບັດ, ຂະບວນການແລະເຄື່ອງມື. ຜູ້ຕາງຫນ້າຂອງ High profile ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີກວ່າຕ່ໍາ. ພວກເຂົາມີແນວໂນ້ມທີ່ຈະບັນລຸແລະເກີນເປົ້າຫມາຍຂອງພວກເຂົາ.
• ຕົວຊີ້ວັດ, ພະຍາດລະບາດ ແລະ ແຜນການປີ 2021. ຕົວຊີ້ວັດພິເສດໃນປີນີ້ແມ່ນວິທີທີ່ບໍລິສັດຮັບມືກັບໂລກລະບາດ. ຜູ້ຕາງຫນ້າສູງໄດ້ດີກວ່າ, ມີປະສົບການການມີສ່ວນຮ່ວມຂອງຜູ້ໃຊ້ເພີ່ມຂຶ້ນ, ແລະເຫດຜົນຕົ້ນຕໍສໍາລັບຄວາມສໍາເລັດແມ່ນຂະບວນການພັດທະນາທີ່ມີປະສິດທິພາບແລະວັດທະນະທໍາວິສະວະກໍາທີ່ເຂັ້ມແຂງ.
• ການປະຕິບັດ, ເຄື່ອງມື ແລະການພັດທະນາຂອງ DevOps. ແຜນການຕົ້ນຕໍຂອງບໍລິສັດສໍາລັບປີຕໍ່ໄປລວມມີການພັດທະນາການປະຕິບັດແລະເຄື່ອງມືຂອງ DevOps, ການແນະນໍາການປະຕິບັດ DevSecOps, ແລະການປ່ຽນແປງໃນໂຄງສ້າງອົງການຈັດຕັ້ງ. ແລະການປະຕິບັດທີ່ມີປະສິດທິພາບແລະການພັດທະນາການປະຕິບັດ DevOps ແມ່ນດໍາເນີນໂດຍການຊ່ວຍເຫຼືອຂອງໂຄງການທົດລອງ, ການສ້າງຊຸມຊົນແລະສູນກາງທີ່ດີເລີດ, ການລິເລີ່ມໃນລະດັບເທິງແລະຕ່ໍາຂອງບໍລິສັດ.

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

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