DevOps ແມ່ນໃຜ?

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

ພວກເຮົາຍັງຊອກຫາເພື່ອນຮ່ວມງານຢູ່, ເພາະວ່າຢູ່ເບື້ອງຫຼັງປ້າຍ DevOps ມີຊັ້ນໃຫຍ່ຂອງວິສະວະກອນປະເພດຕ່າງໆເຊື່ອງຢູ່.

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

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

ດັ່ງນັ້ນໃຜເປັນວິສະວະກອນ DevOps?

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

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

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

ວົງຈອນຫຼັງຈາກຮອບວຽນ, ລະບົບຕ່າງໆປາກົດວ່າເຮັດໃຫ້ການພັດທະນາແລະ / ຫຼືການບໍລິຫານງ່າຍດາຍ, ລະບົບ orchestration ປາກົດ, ເຊິ່ງ, ຈົນກ່ວາທ່ານຈໍາເປັນຕ້ອງໄດ້ deviate ຈາກຂະບວນການມາດຕະຖານ, ແມ່ນງ່າຍທີ່ຈະນໍາໃຊ້. ສະຖາປັດຕະຍະກໍາ Microservice ຍັງປາກົດຂຶ້ນດ້ວຍຈຸດປະສົງເພື່ອເຮັດໃຫ້ທຸກສິ່ງທຸກຢ່າງທີ່ອະທິບາຍຂ້າງເທິງນີ້ງ່າຍຂຶ້ນ - ການພົວພັນຫນ້ອຍ, ງ່າຍຕໍ່ການຄຸ້ມຄອງ. ໃນປະສົບການຂອງຂ້ອຍ, ຂ້ອຍບໍ່ພົບສະຖາປັດຕະຍະກໍາ microservice ຢ່າງສົມບູນ, ຂ້ອຍຈະເວົ້າວ່າ 50 ຫາ 50 - 50 ເປີເຊັນຂອງ microservices, ກ່ອງດໍາ, ເຂົ້າມາ, ອອກມາປຸງແຕ່ງ, ອີກ 50 ແມ່ນ monolith torn, ບໍລິການບໍ່ສາມາດເຮັດວຽກແຍກຕ່າງຫາກຈາກອື່ນໆ. ອົງປະກອບ. ທັງຫມົດນີ້ອີກເທື່ອຫນຶ່ງ imposed ຂໍ້ຈໍາກັດກ່ຽວກັບລະດັບຄວາມຮູ້ຂອງທັງນັກພັດທະນາແລະຜູ້ບໍລິຫານ.

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

ວິສະວະກອນກໍ່ສ້າງ / ວິສະວະກອນປ່ອຍ

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

Ops ແມ່ນແຕກຕ່າງກັນຫຼາຍ

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

• TechOps - ຜູ້ບໍລິຫານລະບົບ enikey aka HelpDesk Engineer
• LiveOps - ຜູ້ບໍລິຫານລະບົບຕົ້ນຕໍແມ່ນຮັບຜິດຊອບຕໍ່ສະພາບແວດລ້ອມການຜະລິດ
• CloudOps - ຜູ້ບໍລິຫານລະບົບທີ່ຊ່ຽວຊານໃນຟັງສາທາລະນະ Azure, AWS, GCP, ແລະອື່ນໆ.
• PlatOps/InfraOps/SysOps - ຜູ້ບໍລິຫານລະບົບໂຄງສ້າງພື້ນຖານ.
• NetOps - ຜູ້ບໍລິຫານເຄືອຂ່າຍ
• SecOps - ຜູ້ບໍລິຫານລະບົບທີ່ຊ່ຽວຊານດ້ານຄວາມປອດໄພຂໍ້ມູນ - ການປະຕິບັດຕາມ PCI, ການປະຕິບັດຕາມ CIS, patching, ແລະອື່ນໆ.

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

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

ນີ້ແມ່ນຄວາມຈິງໃນບໍລິສັດຂອງເຈົ້າບໍ? - ຂ້າພະເຈົ້າສົງໃສ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ນີ້ແມ່ນ IT ຫຼື R&D.

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

ຕະຫຼາດຊັບພະຍາກອນ DevOps

ຂໍໃຫ້ເບິ່ງຫຼາຍບ່ອນຫວ່າງສໍາລັບຕໍາແຫນ່ງ DevOps ຈາກບໍລິສັດທີ່ແຕກຕ່າງກັນ.

ພວກເຮົາພ້ອມທີ່ຈະພົບກັບທ່ານຖ້າທ່ານ:

1. ເຈົ້າເປັນເຈົ້າຂອງ Zabbix ແລະຮູ້ວ່າ Prometheus ແມ່ນຫຍັງ;
2. Iptables;
3. ນັກສຶກສາປະລິນຍາເອກ BASH;
4. ອາຈານ Ansible;
5. Linux Guru;
6. ຮູ້ວິທີການໃຊ້ debugging ແລະຊອກຫາບັນຫາຂອງແອັບພລິເຄຊັນຮ່ວມກັນກັບນັກພັດທະນາ (php/java/python);
7. ເສັ້ນທາງບໍ່ໄດ້ເຮັດໃຫ້ທ່ານ hysterical;
8. ເອົາໃຈໃສ່ທີ່ສໍາຄັນຕໍ່ຄວາມປອດໄພຂອງລະບົບ;
9. ສຳຮອງຂໍ້ມູນ “ອັນໃດອັນໜຶ່ງ ແລະ ທຸກຢ່າງ”, ແລະ ຍັງຟື້ນຟູ “ອັນໃດອັນໜຶ່ງ ແລະ ທຸກຢ່າງ” ຢ່າງສຳເລັດຜົນ;
10. ທ່ານຮູ້ວິທີການ configure ລະບົບດັ່ງກ່າວໃນວິທີການທີ່ຈະໄດ້ຮັບການສູງສຸດອອກຈາກຕໍາ່ສຸດທີ່;
11. ຕັ້ງຄ່າການຈໍາລອງກ່ອນນອນໃນ Postgres ແລະ MySQL;
12. ການ​ຕັ້ງ​ຄ່າ​ແລະ​ປັບ CI/CD ແມ່ນ​ເປັນ​ສິ່ງ​ຈໍາ​ເປັນ​ສໍາ​ລັບ​ທ່ານ​ເປັນ​ອາ​ຫານ​ເຊົ້າ / ອາ​ຫານ​ທ່ຽງ / ຄ່​ໍາ​.
13. ມີປະສົບການກັບ AWS;
14. ພ້ອມທີ່ຈະພັດທະນາກັບບໍລິສັດ;

ດັ່ງນັ້ນ:

• ຈາກ 1 ຫາ 6 - ຜູ້ເບິ່ງແຍງລະບົບ
• 7 - ການ​ບໍ​ລິ​ຫານ​ເຄືອ​ຂ່າຍ​ພຽງ​ເລັກ​ນ້ອຍ​, ເຊິ່ງ​ຍັງ​ເຫມາະ​ສົມ​ກັບ​ຜູ້​ບໍ​ລິ​ຫານ​ລະ​ບົບ​, ລະ​ດັບ​ກາງ​
• 8 - ຄວາມ​ປອດ​ໄພ​ເລັກ​ນ້ອຍ​, ຊຶ່ງ​ເປັນ​ການ​ບັງ​ຄັບ​ສໍາ​ລັບ​ຜູ້​ບໍ​ລິ​ຫານ​ລະ​ບົບ​ລະ​ດັບ​ກາງ​
• 9-11 – ຜູ້ເບິ່ງແຍງລະບົບກາງ
• 12 — ຂຶ້ນ​ກັບ​ວຽກ​ງານ​ທີ່​ໄດ້​ຮັບ​ມອບ​ຫມາຍ​, ທັງ​ຜູ້​ບໍ​ລິ​ຫານ​ລະ​ບົບ​ກາງ​ຫຼື​ວິ​ສະ​ວະ​ກອນ​ການ​ກໍ່​ສ້າງ​
• 13 - Virtualization - ຜູ້ເບິ່ງແຍງລະບົບກາງ, ຫຼືທີ່ເອີ້ນວ່າ CloudOps, ຄວາມຮູ້ຂັ້ນສູງກ່ຽວກັບການບໍລິການຂອງສະຖານທີ່ໂຮດຕິ້ງສະເພາະ, ສໍາລັບການນໍາໃຊ້ທຶນທີ່ມີປະສິດທິພາບແລະການຫຼຸດຜ່ອນການໂຫຼດໃນການຮັກສາ.

ສະຫຼຸບການຫວ່າງງານນີ້, ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າຜູ້ເບິ່ງແຍງລະບົບລະດັບກາງ/ອາວຸໂສແມ່ນພຽງພໍສໍາລັບພວກ.

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

ຂໍ​ໃຫ້​ພິຈາລະນາ​ບ່ອນ​ຫວ່າງ​ອື່ນ:

1. ປະສົບການໃນການກໍ່ສ້າງລະບົບການໂຫຼດສູງ;
2. ຄວາມຮູ້ທີ່ດີເລີດຂອງ Linux OS, ຊອບແວລະບົບທົ່ວໄປ ແລະເວັບ stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. ປະສົບການກັບລະບົບ virtualization (KVM, VMWare, LXC/Docker);
4. ຄວາມ​ສາ​ມາດ​ໃນ​ພາ​ສາ scripting​;
5. ຄວາມເຂົ້າໃຈກ່ຽວກັບຫຼັກການການດໍາເນີນງານຂອງເຄືອຂ່າຍໂປໂຕຄອນເຄືອຂ່າຍ;
6. ຄວາມເຂົ້າໃຈກ່ຽວກັບຫຼັກການຂອງການກໍ່ສ້າງລະບົບຄວາມຜິດ-ທົນທານຕໍ່;
7. ເອກະລາດແລະການລິເລີ່ມ;

ລອງເບິ່ງ:

• 1 – ຜູ້ເບິ່ງແຍງລະບົບອາວຸໂສ
• 2 - ອີງຕາມຄວາມຫມາຍທີ່ວາງໄວ້ໃນ stack ນີ້ - ຜູ້ເບິ່ງແຍງລະບົບກາງ / ອາວຸໂສ
• 3 - ປະສົບການການເຮັດວຽກ, ລວມທັງ, ອາດຈະຫມາຍຄວາມວ່າ - "ກຸ່ມບໍ່ໄດ້ຍົກຂຶ້ນມາ, ແຕ່ໄດ້ສ້າງແລະຈັດການ virtual machines, ມີ Docker host ຫນຶ່ງ, ການເຂົ້າເຖິງ containers ບໍ່ສາມາດໃຊ້ໄດ້" - Middle System Administrator
• 4 - Junior System Administrator - ແມ່ນແລ້ວ, admin ຜູ້ທີ່ບໍ່ຮູ້ວິທີຂຽນ script automation ພື້ນຖານ, ບໍ່ວ່າຈະເປັນພາສາໃດກໍ່ຕາມ, ບໍ່ແມ່ນ admin - enikey.
• 5 - ຜູ້ບໍລິຫານລະບົບກາງ
• 6 – ຜູ້ເບິ່ງແຍງລະບົບອາວຸໂສ

ເພື່ອສະຫຼຸບ - ຜູ້ບໍລິຫານລະບົບກາງ/ອາວຸໂສ

ອີກອັນນຶ່ງ:

1. Devops ປະສົບການ;
2. ມີປະສົບການໃນການນໍາໃຊ້ຫນຶ່ງຫຼືຫຼາຍຜະລິດຕະພັນເພື່ອສ້າງຂະບວນການ CI / CD. Gitlab CI ຈະເປັນປະໂຫຍດ;
3. ເຮັດວຽກກັບບັນຈຸແລະ virtualization; ຖ້າທ່ານໃຊ້ docker, ດີ, ແຕ່ຖ້າທ່ານໃຊ້ k8s, ດີຫຼາຍ!
4. ປະສົບການເຮັດວຽກໃນທີມທີ່ວ່ອງໄວ;
5. ຄວາມຮູ້ກ່ຽວກັບພາສາການຂຽນໂປຼແກຼມໃດໆ;

ໃຫ້ເບິ່ງ:

• 1 - ຮືມ... ຜູ້ຊາຍໝາຍເຖິງຫຍັງ? =) ສ່ວນຫຼາຍແລ້ວເຂົາເຈົ້າເອງບໍ່ຮູ້ວ່າມີຫຍັງເຊື່ອງຢູ່ເບື້ອງຫຼັງ
• 2 - ວິສະວະກອນກໍ່ສ້າງ
• 3 - ຜູ້ບໍລິຫານລະບົບກາງ
• 4 - ທັກສະອ່ອນ, ພວກເຮົາຈະບໍ່ພິຈາລະນາມັນສໍາລັບຕອນນີ້, ເຖິງແມ່ນວ່າ Agile ແມ່ນອີກສິ່ງຫນຶ່ງທີ່ຖືກຕີຄວາມຫມາຍໃນວິທີທີ່ສະດວກ.
• 5 - verbose ເກີນໄປ - ມັນອາດຈະເປັນພາສາຂຽນຫຼືລວບລວມ. ຂ້ອຍສົງໄສວ່າການຂຽນພາສາ Pascal ແລະ Basic ຢູ່ໂຮງຮຽນຈະເຫມາະສົມກັບພວກເຂົາບໍ? =)

ຂ້າພະເຈົ້າຍັງຢາກຈະອອກບັນທຶກກ່ຽວກັບຈຸດ 3 ເພື່ອສ້າງຄວາມເຂົ້າໃຈວ່າເປັນຫຍັງຈຸດນີ້ຖືກຄຸ້ມຄອງໂດຍຜູ້ເບິ່ງແຍງລະບົບ. Kubernetes ແມ່ນພຽງແຕ່ການ orchestration, ເຄື່ອງມືທີ່ກວມເອົາຄໍາສັ່ງໂດຍກົງກັບໄດເວີເຄືອຂ່າຍແລະ virtualization / isolation hosts ໃນສອງສາມຄໍາສັ່ງແລະອະນຸຍາດໃຫ້ທ່ານເພື່ອເຮັດໃຫ້ການສື່ສານກັບເຂົາເຈົ້າບໍ່ມີຕົວຕົນ, ນັ້ນແມ່ນທັງຫມົດ. ຕົວຢ່າງ, ໃຫ້ເອົາ 'ສ້າງກອບ' ເຮັດ, ເຊິ່ງ, ໂດຍວິທີທາງການ, ຂ້ອຍບໍ່ພິຈາລະນາກອບ. ແມ່ນແລ້ວ, ຂ້ອຍຮູ້ກ່ຽວກັບຄົນອັບເດດ: shoving Make ທຸກບ່ອນ, ບ່ອນທີ່ມັນເປັນສິ່ງຈໍາເປັນແລະບໍ່ຈໍາເປັນ - wrapping Maven in Make, ສໍາລັບການຍົກຕົວຢ່າງ, ຢ່າງຮຸນແຮງ?
ໂດຍພື້ນຖານແລ້ວ, Make ແມ່ນພຽງແຕ່ wrapper ຢູ່ເທິງແກະ, ເຮັດໃຫ້ການລວບລວມ, ການເຊື່ອມໂຍງ, ແລະຄໍາສັ່ງສະພາບແວດລ້ອມການລວບລວມງ່າຍ, ຄືກັນກັບ k8s.

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

ໃຫ້ພວກເຮົາສະຫຼຸບອີກເທື່ອຫນຶ່ງ - ຜູ້ເບິ່ງແຍງລະບົບກາງ / ອາວຸໂສຈະພຽງພໍສໍາລັບພວກເຂົາ.

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

ລະດັບເງິນເດືອນທີ່ສະເໜີໃຫ້ສຳລັບຕຳແໜ່ງວ່າງທີ່ລະບຸໄວ້ແມ່ນ 90k-200k
ຕອນນີ້ຂ້ອຍຢາກແຕ້ມຂະຫນານລະຫວ່າງລາງວັນເງິນຂອງຜູ້ເບິ່ງແຍງລະບົບແລະວິສະວະກອນ DevOps.

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

ປະສົບການ:

1. ເຖິງ 3 ປີ – Junior
2. ເຖິງ 6 ປີ - ກາງ
3. ຫຼາຍກ່ວາ 6 - ອາວຸໂສ

ເວັບໄຊທ໌ຄົ້ນຫາພະນັກງານສະເຫນີ:
ຜູ້ເບິ່ງແຍງລະບົບ:

1. Junior - 2 ປີ - 50k rub.
2. ກາງ - 5 ປີ - 70k rub.
3. ຜູ້ອາວຸໂສ - 11 ປີ - 100k rub.

ວິສະວະກອນ DevOps:

1. Junior - 2 ປີ - 100k rub.
2. ກາງ - 3 ປີ - 160k rub.
3. ຜູ້ອາວຸໂສ - 6 ປີ - 220k rub.

ອີງຕາມປະສົບການຂອງ "DevOps", ປະສົບການໄດ້ຖືກນໍາໃຊ້ຢ່າງນ້ອຍມີຜົນກະທົບ SDLC.

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

ຂະບວນການຂອງການຝຶກອົບຮົມວິສະວະກອນ DevOps ຍັງຖືກຈໍາກັດພຽງແຕ່ຊຸດຂອງວຽກງານສະເພາະ, ປະໂຫຍດ, ແລະບໍ່ໃຫ້ຄວາມເຂົ້າໃຈທົ່ວໄປກ່ຽວກັບຂະບວນການແລະຄວາມຂຶ້ນກັບຂອງເຂົາເຈົ້າ. ມັນແນ່ນອນວ່າມັນດີເມື່ອບຸກຄົນໃດຫນຶ່ງສາມາດນໍາໄປໃຊ້ AWS EKS ໂດຍໃຊ້ Terraform, ໂດຍສົມທົບກັບ sidecar Fluentd ໃນກຸ່ມນີ້ແລະ AWS ELK stack ສໍາລັບລະບົບການຕັດໄມ້ໃນ 10 ນາທີ, ໂດຍໃຊ້ຄໍາສັ່ງດຽວໃນ console, ແຕ່ຖ້າລາວບໍ່ເຂົ້າໃຈ. ຫຼັກການຂອງການປຸງແຕ່ງຕົວມັນເອງບັນທຶກແລະສິ່ງທີ່ພວກເຂົາຕ້ອງການ, ຖ້າທ່ານບໍ່ຮູ້ວິທີການເກັບກໍາຂໍ້ມູນແລະຕິດຕາມການເສື່ອມໂຊມຂອງການບໍລິການ, ມັນຈະຍັງຄົງເປັນ enikey ດຽວກັນຜູ້ທີ່ຮູ້ວິທີການນໍາໃຊ້ຜົນປະໂຫຍດບາງຢ່າງ.

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

ດັ່ງນັ້ນພວກເຂົາແມ່ນໃຜ? DevOps ຫຼືຜູ້ບໍລິຫານລະບົບທີ່ໂລບມາກ? =)

ສືບຕໍ່ດໍາລົງຊີວິດແນວໃດ?

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

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

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