DevOps ແມ່ນໃຜແລະເວລາທີ່ມັນບໍ່ຈໍາເປັນ?

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

ບາງຄົນຂຽນລາຍຊື່ DevOps ໃນຊີວະປະຫວັດຂອງເຂົາເຈົ້າ, ເຖິງແມ່ນວ່າພວກເຂົາບໍ່ຮູ້ຫຼືເຂົ້າໃຈຄວາມສໍາຄັນຂອງຄໍາສັບ. ບາງຄົນຄິດວ່າຫຼັງຈາກຮຽນ Ansible, GitLab, Jenkins, Terraform ແລະອື່ນໆ (ບັນຊີລາຍຊື່ສາມາດສືບຕໍ່ຕາມລົດຊາດຂອງເຈົ້າ), ເຈົ້າຈະກາຍເປັນ "devopsist". ນີ້ແມ່ນ, ແນ່ນອນ, ບໍ່ແມ່ນຄວາມຈິງ.

ສໍາລັບສອງສາມປີຜ່ານມາ, ຂ້າພະເຈົ້າໄດ້ມີສ່ວນຮ່ວມຕົ້ນຕໍໃນການປະຕິບັດ DevOps ໃນບໍລິສັດຕ່າງໆ. ກ່ອນນັ້ນ, ລາວໄດ້ເຮັດວຽກຫຼາຍກວ່າ 20 ປີໃນຕໍາແຫນ່ງຕັ້ງແຕ່ຜູ້ບໍລິຫານລະບົບຈົນເຖິງຜູ້ອໍານວຍການ IT. ໃນປັດຈຸບັນ DevOps Lead Engineer ຢູ່ Playgendary.

DevOps ແມ່ນໃຜ

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

DevOps ບໍ່ແມ່ນຜູ້ຊ່ຽວຊານທີ່ສາມາດຈ້າງໄດ້, ບໍ່ແມ່ນຊຸດຂອງອຸປະກອນ, ແລະບໍ່ແມ່ນພະແນກຂອງນັກພັດທະນາທີ່ມີວິສະວະກອນ.

DevOps ແມ່ນປັດຊະຍາແລະວິທີການ.

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

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

ເປົ້າໝາຍຂອງ DevOps ສາມາດອະທິບາຍໄດ້ໃນສາມຈຸດ:

• ຊອບແວຕ້ອງໄດ້ຮັບການປັບປຸງເປັນປົກກະຕິ.
• ຊອບແວຕ້ອງເຮັດຢ່າງໄວວາ.
• ຊອບ​ແວ​ຄວນ​ໄດ້​ຮັບ​ການ​ປະ​ຕິ​ບັດ​ຢ່າງ​ສະ​ດວກ​ແລະ​ໃນ​ເວ​ລາ​ສັ້ນ​.

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

ແລະນີ້ແມ່ນພຽງແຕ່ສ່ວນຫນຶ່ງຂອງເຄື່ອງມື DevOps

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

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

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

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

— DevOps ຫມາຍຄວາມວ່າແນວໃດກັບທ່ານສ່ວນຕົວ?
- ໂດຍທົ່ວໄປຫຼືຂ້ອຍຮັບຮູ້ມັນແນວໃດ?

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

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

ວິທີການ ແລະປັດຊະຍາຂອງ DevOps

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

ວິທີການ DevOps ແມ່ນພຽງແຕ່ວິທີການເພື່ອບັນລຸເປົ້າຫມາຍ.

ໃນປັດຈຸບັນກ່ຽວກັບສິ່ງທີ່ປັດຊະຍາ DevOps ແມ່ນຫຍັງ. ແລະນີ້ອາດຈະເປັນຄໍາຖາມທີ່ຍາກທີ່ສຸດ.

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

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

ການນໍາໃຊ້ປະສົບການຂອງຂ້ອຍເອງ, ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມສ້າງບາງ "postulates" ຂອງປັດຊະຍານີ້ຢ່າງເປັນທາງການ. ຜົນໄດ້ຮັບແມ່ນດັ່ງຕໍ່ໄປນີ້:

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

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

ສິ່ງທີ່ DevOps ເຮັດ

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

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

ໃນລັດເຊຍ, DevOps ຍັງເປັນຫົວຂໍ້ທີ່ຍັງອ່ອນ, ແຕ່ມີແນວໂນ້ມແລ້ວ. ຕາມ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ຮູ້​ວ່າ, ຢູ່​ມົ​ສ​ກູ​ພຽງ​ແຕ່​ຂາດ​ແຄນ​ຜູ້​ຊ່ຽວ​ຊານ​ດັ່ງ​ກ່າວ​ໃນ​ປີ 2019 ແມ່ນ​ຫຼາຍ​ກ​່​ວາ 1000 ຄົນ. ແລະຄໍາວ່າ Kubernetes ສໍາລັບນາຍຈ້າງແມ່ນເກືອບຄ້າຍຄື rag ສີແດງສໍາລັບ bull ໄດ້. ຜູ້ຍຶດຫມັ້ນຂອງເຄື່ອງມືນີ້ແມ່ນພ້ອມທີ່ຈະໃຊ້ມັນເຖິງແມ່ນວ່າມັນບໍ່ຈໍາເປັນແລະມີກໍາໄລທາງດ້ານເສດຖະກິດ. ນາຍຈ້າງບໍ່ເຂົ້າໃຈສະເໝີວ່າໃນກໍລະນີໃດທີ່ເໝາະສົມກວ່າທີ່ຈະໃຊ້, ແລະມີການນຳໃຊ້ທີ່ເໝາະສົມ, ການຮັກສາກຸ່ມ Kubernetes ມີຄ່າໃຊ້ຈ່າຍຫຼາຍກວ່າການໃຊ້ແອັບພລິເຄຊັ່ນ 2-3 ເທົ່າຂອງກຸ່ມແບບທຳມະດາ. ໃຊ້ມັນບ່ອນທີ່ທ່ານຕ້ອງການແທ້ໆ.

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

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

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

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

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

ເມື່ອ DevOps ບໍ່ຈໍາເປັນ

ມີສະຖານະການໃນເວລາທີ່ DevOps ບໍ່ຈໍາເປັນ. ນີ້ແມ່ນຄວາມຈິງ - ມັນຈໍາເປັນຕ້ອງເຂົ້າໃຈແລະຍອມຮັບ.

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

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

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

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

• DevOops
• DevOpsConf
• ໂຫຼດສູງ ++
• ແປນ
• MailRu Cloud Solution

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

ຖ້າບໍລິສັດຂອງທ່ານຂາຍປາໃນຮ້ານຂະຫນາດນ້ອຍແລະຜະລິດຕະພັນ IT ເທົ່ານັ້ນແມ່ນສອງ 1C: ການຕັ້ງຄ່າວິສາຫະກິດ (ການບັນຊີແລະ UNF), ຫຼັງຈາກນັ້ນມັນບໍ່ມີຄວາມຫມາຍທີ່ຈະເວົ້າກ່ຽວກັບ DevOps.

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

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

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

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

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

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

ເງື່ອນໄຂຕົ້ນຕໍສໍາລັບການເຂົ້າໃຈວ່າ DevOps ແມ່ນຈໍາເປັນ: ມູນຄ່າຜະລິດຕະພັນ IT ຂອງທ່ານມີສໍາລັບບໍລິສັດແລະລູກຄ້າ.

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

ເກມຕ່າງໆມີຢູ່ຍ້ອນເງິນທຶນ: ໂດຍກົງຫຼືທາງອ້ອມຈາກຜູ້ຫຼິ້ນ. ຢູ່ Playgendary, ພວກເຮົາພັດທະນາເກມມືຖືຟຣີທີ່ມີຫຼາຍກວ່າ 200 ຄົນມີສ່ວນຮ່ວມໂດຍກົງໃນການສ້າງຂອງເຂົາເຈົ້າ. ພວກເຮົາໃຊ້ DevOps ແນວໃດ?

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

ຕອນນີ້ພວກເຮົາກຳລັງໃຊ້ Jenkins ຢ່າງຈິງຈັງເປັນເຄື່ອງມືທໍ່ CI/CD ເພື່ອປະຕິບັດທໍ່ປະກອບທັງໝົດດ້ວຍ Unity ແລະການນຳໄປໃຊ້ໃນ App Store ແລະ Play Market. ເພີ່ມເຕີມຈາກຊຸດເຄື່ອງມືຄລາສສິກ:

• Asana - ສໍາລັບການຄຸ້ມຄອງໂຄງການ. ການປະສົມປະສານກັບ Jenkins ໄດ້ຖືກຕັ້ງຄ່າແລ້ວ.
• Google Meet - ສໍາລັບການປະຊຸມວິດີໂອ.
• Slack - ສໍາລັບການສື່ສານແລະການແຈ້ງເຕືອນຕ່າງໆ, ລວມທັງການແຈ້ງເຕືອນຈາກ Jenkins.
• Atlassian Confluence - ສໍາລັບເອກະສານແລະການເຮັດວຽກເປັນກຸ່ມ.

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

ແທນທີ່ຈະເປັນການສະຫລຸບໄດ້

ຂ້າພະເຈົ້າຂໍສິ້ນສຸດດ້ວຍຄວາມຄິດຕໍ່ໄປນີ້: ເພື່ອກາຍເປັນວິສະວະກອນ DevOps ທີ່ມີຄຸນວຸດທິສູງ, ມັນເປັນສິ່ງ ສຳ ຄັນທີ່ຈະຮຽນຮູ້ວິທີການສື່ສານສົດກັບຄົນ.

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

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

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