ພວກເຮົາສົນທະນາກ່ຽວກັບ DevOps ໃນພາສາທີ່ເຂົ້າໃຈໄດ້

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

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

ດັ່ງນັ້ນ, ທ່ານມັກຈະສາມາດໄດ້ຍິນຄໍາຖາມກ່ຽວກັບ DevOps ເຊັ່ນ, ມັນຄືກັນກັບຄວາມວ່ອງໄວບໍ? ຫຼືນີ້ແມ່ນວິທີການພິເສດບາງຢ່າງ? ຫຼືມັນເປັນຄໍາສັບຄ້າຍຄືກັນກັບຄໍາວ່າ "ການຮ່ວມມື"?

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

DevOps ແມ່ນຫຍັງ: 6 ຄໍານິຍາມແລະການປຽບທຽບ

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

1. DevOps ເປັນການເຄື່ອນໄຫວວັດທະນະທໍາ

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

2. DevOps ແມ່ນກ່ຽວກັບການສ້າງຄວາມເຂັ້ມແຂງໃຫ້ນັກພັດທະນາ.

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

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

3. DevOps ແມ່ນກ່ຽວກັບການຮ່ວມມືໃນການສ້າງ ແລະສົ່ງແອັບພລິເຄຊັນ.

"ເວົ້າງ່າຍໆ, DevOps ແມ່ນວິທີການຜະລິດຊອບແວແລະການຈັດສົ່ງທີ່ທຸກຄົນເຮັດວຽກຮ່ວມກັນ," Gur Staf, ປະທານແລະຫົວຫນ້າຂອງທຸລະກິດດິຈິຕອນອັດຕະໂນມັດຂອງ BMC ກ່າວ.

4. DevOps ເປັນທໍ່

"ການປະກອບລໍາລຽງແມ່ນເປັນໄປໄດ້ພຽງແຕ່ຖ້າທຸກພາກສ່ວນເຂົ້າກັນ."

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

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

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

5. DevOps ແມ່ນການປະສົມປະສານທີ່ຖືກຕ້ອງຂອງປະຊາຊົນ, ຂະບວນການແລະອັດຕະໂນມັດ

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

6. DevOps ແມ່ນເວລາທີ່ນັກຂຽນໂປລແກລມເຮັດວຽກຄືກັບທີມ Formula 1

"ການແຂ່ງຂັນບໍ່ໄດ້ວາງແຜນໄວ້ຕັ້ງແຕ່ຕົ້ນຈົນຈົບ, ແຕ່ກົງກັນຂ້າມ, ຕັ້ງແຕ່ຈົບຈົນເລີ່ມຕົ້ນ."

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

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

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

ວິທີການຂະຫນາດ DevOps: 10 ຄໍາແນະນໍາຈາກຜູ້ຊ່ຽວຊານ

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

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

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

ມັນງ່າຍທີ່ຈະເຫັນວ່າຜົນໄດ້ຮັບແມ່ນວັດທະນະທໍາຂອງການແບ່ງປັນລະຫວ່າງ "ພວກເຮົາ" ແລະ "ພວກເຂົາ".

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

"ແລະບັນຫາວັດທະນະທໍານີ້ແມ່ນພຽງແຕ່ຫນຶ່ງໃນເຫດຜົນທີ່ DevOps ຍາກທີ່ຈະປັບຂະຫນາດ. ທີມງານ DevOps ກໍາລັງປະເຊີນກັບສິ່ງທ້າທາຍທາງດ້ານເຕັກນິກທີ່ເພີ່ມຂຶ້ນທີ່ເປັນປົກກະຕິຂອງບໍລິສັດ IT ທໍາອິດທີ່ເຕີບໂຕໄວ,” Steve Newman, ຜູ້ກໍ່ຕັ້ງແລະປະທານບໍລິສັດ Scalyr ກ່າວ.

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

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

1. ຈົ່ງຈື່ໄວ້ວ່າການປ່ຽນແປງວັດທະນະທໍາຕ້ອງໃຊ້ເວລາ.

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

2. ໃຊ້ເວລາພຽງພໍໃນການວາງແຜນ ແລະເລືອກເວທີ

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

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

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

3. ເອົາຄວາມຜິດອອກຈາກຄວາມຮັບຜິດຊອບ.

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

4. ລ້າງເສັ້ນທາງໄປຂ້າງຫນ້າ

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

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

5. ເຄື່ອງມືປະຊາທິປະໄຕ

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

6. ສ້າງເງື່ອນໄຂທີ່ເຫມາະສົມສໍາລັບການເຮັດວຽກເປັນທີມ

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

7. ຢ່າລືມກ່ຽວກັບກົດຫມາຍຂອງ Conway ແລະກະດານ Kanban

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

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

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

8. ຊອກຫາຮອຍແປ້ວເກົ່າ

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

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

9. ຢ່າສ້າງຕົວເລືອກ DevOps

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

10. ປະກາດມູນຄ່າທຸລະກິດຂອງ DevOps

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

ເງີນ

ກ່ຽວກັບ ​ເວທີ​ປຶກສາ​ຫາລື​ໝວກ​ແດງ​ຣັດ​ເຊຍ DevOps ຂອງພວກເຮົາເອງຈະມາຮອດໃນວັນທີ 13 ກັນຍາ - ແມ່ນແລ້ວ, Red Hat, ໃນຖານະຜູ້ຜະລິດຊອບແວ, ມີທີມງານແລະການປະຕິບັດ DevOps ຂອງຕົນເອງ.

ວິສະວະກອນຂອງພວກເຮົາ Mark Birger, ຜູ້ທີ່ພັດທະນາການບໍລິການອັດຕະໂນມັດພາຍໃນສໍາລັບກຸ່ມອື່ນໆໃນທົ່ວອົງການ, ຈະບອກເລື່ອງຂອງຕົນເອງໃນພາສາລັດເຊຍທີ່ບໍລິສຸດ - ທີມງານ Red Hat DevOps ໄດ້ຍ້າຍແອັບພລິເຄຊັນຈາກ Hat Virtualization virtual ສະພາບແວດລ້ອມທີ່ຄຸ້ມຄອງໂດຍ Ansible ໄປສູ່ຮູບແບບ container ເຕັມຮູບແບບໃນ. ເວທີ OpenShift.

ແຕ່ນັ້ນບໍ່ແມ່ນທັງໝົດ:

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

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