ເປັນຫຍັງຜູ້ບໍລິຫານລະບົບ, ຜູ້ພັດທະນາ ແລະຜູ້ທົດສອບຄວນຮຽນຮູ້ການປະຕິບັດ DevOps?

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

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

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

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

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

ຕໍ່ໄປນີ້ແມ່ນຫຍັງຈາກວິທີການນີ້?

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

  

• DevOps ບໍ່ແມ່ນຮູບແບບຕໍ່ໄປຂອງ sysadmin ທີ່ຈະຍົກລະດັບ. "ວິສະວະກອນ DevOps" ມີສຽງຄ້າຍຄືກັນກັບ "ນັກພັດທະນາ Agile."

  
  

• ຖ້າທີມງານໃຊ້ Kubernetes, Ansible, Prometheus, Mesosphere ແລະ Docker, ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າການປະຕິບັດ DevOps ໄດ້ຖືກປະຕິບັດຢູ່ທີ່ນັ້ນ.

  
  

ຊີວິດຫຼັງຈາກ DevOps ຈະບໍ່ຄືກັນ

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

1. ການກໍານົດຕົນເອງ

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

2. ເຄື່ອງມື ແລະ ການປະຕິບັດ

ນັກຮຽນຮູ້ເທັກໂນໂລຍີສະເພາະຈາກມຸມເບິ່ງຂອງວິທີການ DevOps.

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

ພວກເຮົາຢູ່ໃນຂະບວນການ ແນ່ນອນ ທ່ານຈະໄດ້ຮັບການ immersed ໃນຂະບວນການຂອງການພັດທະນາຄໍາຮ້ອງສະຫມັກທີ່ຄ້າຍຄືກັນກັບ Reddit ທີ່ມີຊື່ສຽງ, ເລີ່ມຕົ້ນດ້ວຍສະບັບ monolithic ຂອງຕົນ, ຍ້າຍຂັ້ນຕອນໂດຍຂັ້ນຕອນເພື່ອ microservices. ຂັ້ນ​ຕອນ​ທີ​ພວກ​ເຮົາ​ຈະ​ຊໍາ​ນິ​ຊໍາ​ນານ​ເຄື່ອງ​ມື​ໃຫມ່​: Git​, Ansible​, Gitlab ແລະ​ສໍາ​ເລັດ​ຮູບ​ດ້ວຍ Kubernetes ແລະ Prometheus​.

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

ຄວາມຮູ້ນີ້ໃຫ້ຫຍັງແກ່ຜູ້ຊ່ຽວຊານແຕ່ລະຄົນ?

ສໍາລັບຜູ້ບໍລິຫານລະບົບ

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

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

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

ນັກພັດທະນາ

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

ສໍາລັບຜູ້ທົດສອບ

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

ສະນັ້ນມັນ turns ອອກວ່າ ທັງສາມຂັ້ນຕອນເກີດຂຶ້ນພ້ອມກັນ. ຕົວຢ່າງ, ມັນອາດຈະເບິ່ງຄືວ່ານີ້:

ນັກພັດທະນາຂຽນລະຫັດ, ທັນທີຂຽນການທົດສອບສໍາລັບມັນ, ແລະອະທິບາຍ docker container ສໍາລັບລະຫັດທີ່ຄວນຈະດໍາເນີນການ. ມັນຍັງອະທິບາຍທັນທີທັນໃດການຕິດຕາມທີ່ຈະຕິດຕາມກວດກາການດໍາເນີນງານຂອງການບໍລິການນີ້ໃນການຜະລິດ, ແລະຄໍາຫມັ້ນສັນຍາທັງຫມົດນີ້.

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

ຂ້ອຍສຶກສາ DevOps, ຕໍ່ໄປແມ່ນຫຍັງ?

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

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

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

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

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

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

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

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

ຂ້າພະເຈົ້າຄິດວ່າຫນຶ່ງໃນ tricks ແນ່ນອນ — ໃນ​ໄລ​ຍະ​ຂອງ​ການ​ຝຶກ​ອົບ​ຮົມ​ນັກ​ຮຽນ​ແຕ່​ລະ​ຄົນ​ກໍາ​ນົດ​ສໍາ​ລັບ​ຕົນ​ເອງ​ວ່າ​ຕົນ​ເອງ​ໃນ​ທິດ​ທາງ​ທີ່​ເຂົາ​ຕ້ອງ​ການ​ພັດ​ທະ​ນາ​. ພວກເຮົາມັກຈະເຫັນການປ່ຽນແປງເມື່ອຜູ້ພັດທະນາກາຍເປັນວິສະວະກອນໂຄງສ້າງພື້ນຖານ, ແລະຜູ້ບໍລິຫານຮູ້ວ່າລາວມີຄວາມສົນໃຈໃນການຂຽນລະຫັດ - ຫຼັງຈາກນັ້ນລາວໄດ້ສຶກສາພາສາຕື່ມອີກແລະເສີມມັນດ້ວຍທັກສະ DevOps ທີ່ໄດ້ຮັບ. ເພາະສະນັ້ນ, ພວກເຮົາຍິນດີຕ້ອນຮັບໂດຍສະເພາະຜູ້ທີ່ຮູ້ສຶກວ່າອາຊີບຂອງເຂົາເຈົ້າຕິດຢູ່ທາງແຍກ. ຫຼັກສູດເລີ່ມຕົ້ນໃນວັນທີ 28 ພຶດສະພາ, ແຕ່ທ່ານສາມາດເຂົ້າຮ່ວມ 2 ອາທິດຫຼັງຈາກການເລີ່ມຕົ້ນຂອງຫ້ອງຮຽນ. ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ໂຄງ​ການ​ແລະ​ການ​ທົດ​ສອບ​ໄດ້​ ການເຊື່ອມຕໍ່. ແລ້ວພົບກັນທີ່ OTUS!

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