ເພງຂອງນ້ຳກ້ອນ (ບໍລິສັດເລືອດ) ແລະໄຟ (DevOps ແລະ IaC)

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

ເນື່ອງຈາກຫົວຂໍ້ຂອງບົດຄວາມເປັນແບບນີ້, Daenerys, ຜູ້ທີ່ໄດ້ໄປຂ້າງຄຽງຂອງວິສາຫະກິດ, ຈະປະຕິບັດເປັນ cat ໄດ້.

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

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

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

ດັ່ງນັ້ນ, ທ່ານເອົາ jenkins, ພໍ່ຄົວ, terraform, nexus, ແລະອື່ນໆ, ແລະນໍາໃຊ້ມັນທັງຫມົດຢ່າງມີຄວາມສຸກກັບ dev ຂອງທ່ານ. ແຕ່ເວລາມາສົ່ງກັບ QA, UAT ແລະ PROD. ທ່ານມີສິ່ງປະດິດຂອງ Nexus ແລະທ່ານໄດ້ຮັບຈົດຫມາຍຈາກ DBA ດ້ວຍບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

ທີ່ຮັກແພງ,

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

ດ້ວຍຄວາມນັບຖື, DBA ຂອງທ່ານທີ່ໄດ້ເຮັດວຽກຢູ່ທີ່ນີ້ນັບຕັ້ງແຕ່ວັນເວລາຂອງ mainframe.

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

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

ໂດຍວິທີທາງການ, ໃນເວລາຫນຶ່ງຂ້າພະເຈົ້າໄດ້ພະຍາຍາມສ້າງໄຟລ໌ສໍາລັບ terraform, ແຕ່ມັນບໍ່ໄດ້ຜົນ. ຂ້າພະເຈົ້າໄດ້ stumbled ໃນໄລຍະຄວາມຫມາຍຂອງໂຄດຄໍາສັ່ງ 'Project Accounting Billing Code', ທີ່ຂ້ອຍບໍ່ເຄີຍຈັດການ - ຂ້ອຍບໍ່ມີທັກສະອ່ອນພຽງພໍ.

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

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

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

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