ໂປລແກລມ, devops ແລະແມວຂອງ Schrödinger

ຄວາມເປັນຈິງຂອງວິສະວະກອນເຄືອຂ່າຍ (ກັບ noodles ແລະ ... ເກືອ?)

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

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

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

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

ຂ້າ​ພະ​ເຈົ້າ​ເຄີຍ​ສົງ​ໃສ​ວ່າ​ເປັນ​ຫຍັງ​ນີ້​? ແມ່ນ​ຫຍັງ ເຮັດໃຫ້ ນັກຂຽນໂປລແກລມທີ່ຈະວິພາກວິຈານແນວຄວາມຄິດ "ສາເຫດຮາກແມ່ນ myth" ເຊັ່ນນັ້ນ? ເຊັ່ນດຽວກັນກັບລະບົບພູມຕ້ານທານທີ່ຮັບຮູ້ຕົວແທນຕ່າງປະເທດ. ເປັນຫຍັງເຂົາເຈົ້າ react ແບບນີ້, ໃນຂະນະທີ່ devops ຂ້ອນຂ້າງ inclined ພິຈາລະນາຄວາມຄິດນີ້?

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

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

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

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

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

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

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

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

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

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

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

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