ກ່ຽວກັບຜູ້ບໍລິຫານ, devops, ຄວາມສັບສົນທີ່ບໍ່ມີສິ້ນສຸດແລະການຫັນປ່ຽນ DevOps ພາຍໃນບໍລິສັດ

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

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

ເລື່ອງ "modular" ທັງຫມົດນີ້ແມ່ນດີເລີດ, ແຕ່ ... ມັນເກີດຂຶ້ນທີ່ຜູ້ບໍລິຫານບາງຄົນຖືກຂະຫນານນາມຢ່າງກະທັນຫັນ DevOps, ແລະວິສະວະກອນຂອງ DevOps ຕົວເອງກໍ່ຈໍາເປັນຕ້ອງມີຢ່າງຫນ້ອຍທັກສະຂອງ telepathy ແລະ clairvoyance.

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

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

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

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

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

ຈັບແມ່ນຫຍັງ?

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

ແຕ່ນີ້ຫມາຍຄວາມວ່າແນວໃດສໍາລັບທຸລະກິດ?

ການຈ້າງ, ມັນທັງຫມົດກ່ຽວກັບມັນ.

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

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

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

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

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

ບັນຫາ DevOps ອື່ນ

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

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

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

ສະຖານະການ. DevOps ຈໍາເປັນຕ້ອງໄດ້ນໍາໃຊ້ລະບົບ rollback ສະບັບໂດຍບໍ່ມີການ delving ຢ່າງແທ້ຈິງວ່າມັນຈະເຮັດວຽກແນວໃດ. ໃຫ້ສົມມຸດວ່າພາຍໃນລະບົບຜູ້ໃຊ້ມີຊ່ອງຂໍ້ມູນແຍກຕ່າງຫາກສໍາລັບຊື່, ນາມສະກຸນແລະລະຫັດຜ່ານ. ຮຸ່ນໃຫມ່ຂອງຜະລິດຕະພັນອອກມາ, ແຕ່ສໍາລັບນັກພັດທະນາ, "rollback" ແມ່ນພຽງແຕ່ magic wand ທີ່ຈະແກ້ໄຂທຸກສິ່ງທຸກຢ່າງ, ແລະພວກເຂົາບໍ່ຮູ້ວ່າມັນເຮັດວຽກແນວໃດ. ດັ່ງນັ້ນ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນ patch ຕໍ່ໄປ, ນັກພັດທະນາໄດ້ລວມເອົາພາກສະຫນາມຊື່ແລະນາມສະກຸນ, rolled ມັນອອກໃນການຜະລິດ, ແຕ່ສະບັບແມ່ນຊ້າສໍາລັບບາງເຫດຜົນ. ເກີດ​ຫຍັງ​ຂຶ້ນ? ການຈັດການມາຮອດ devops ແລະເວົ້າວ່າ "ດຶງສະຫຼັບ!", ນັ້ນແມ່ນ, ຂໍໃຫ້ລາວກັບຄືນໄປຫາສະບັບທີ່ຜ່ານມາ. devops ເຮັດຫຍັງ? ມັນ rolls ກັບຄືນໄປບ່ອນສະບັບທີ່ຜ່ານມາ, ແຕ່ເນື່ອງຈາກວ່ານັກພັດທະນາບໍ່ຕ້ອງການທີ່ຈະຄິດອອກວິທີການ rollback ນີ້ເຮັດໄດ້, ບໍ່ມີໃຜບອກທີມງານ devops ວ່າຖານຂໍ້ມູນຍັງຈໍາເປັນຕ້ອງໄດ້ rollback. ດັ່ງນັ້ນ, ທຸກສິ່ງທຸກຢ່າງກໍ່ລົ້ມລົງສໍາລັບພວກເຮົາ, ແລະແທນທີ່ຈະເປັນເວັບໄຊທ໌ຊ້າ, ຜູ້ໃຊ້ເຫັນຂໍ້ຜິດພາດ "500", ເພາະວ່າສະບັບເກົ່າບໍ່ໄດ້ເຮັດວຽກກັບພື້ນທີ່ຂອງຖານຂໍ້ມູນໃຫມ່. Devops ບໍ່ຮູ້ເລື່ອງນີ້. ນັກພັດທະນາມິດງຽບ. ຜູ້ຈັດການເລີ່ມສູນເສຍເສັ້ນປະສາດແລະເງິນຂອງພວກເຂົາແລະຈື່ຈໍາການສໍາຮອງຂໍ້ມູນ, ສະເຫນີໃຫ້ກັບຄືນຈາກພວກເຂົາເພື່ອວ່າ "ຢ່າງຫນ້ອຍບາງສິ່ງບາງຢ່າງຈະເຮັດວຽກ." ດັ່ງນັ້ນ, ຜູ້ໃຊ້ສູນເສຍຂໍ້ມູນທັງຫມົດຂອງເຂົາເຈົ້າໃນໄລຍະເວລາ.

ແກ່ນຫມາກ, ແນ່ນອນ, ໄປຫາ devops, ເຊິ່ງ "ບໍ່ໄດ້ສ້າງລະບົບ rollback ທີ່ເຫມາະສົມ," ແລະບໍ່ມີໃຜສົນໃຈວ່າ moose ໃນເລື່ອງນີ້ແມ່ນນັກພັດທະນາ.

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

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

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

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