DevOps ແລະຄວາມວຸ່ນວາຍ: ການຈັດສົ່ງຊອບແວໃນໂລກທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງ

Anton Weiss, ຜູ້ກໍ່ຕັ້ງແລະຜູ້ອໍານວຍການຂອງ Otomato Software, ຫນຶ່ງໃນຜູ້ລິເລີ່ມແລະຜູ້ສອນການຢັ້ງຢືນ DevOps ທໍາອິດໃນອິດສະຣາເອນ, ກ່າວໃນປີທີ່ຜ່ານມາ. DevOpsDays Moscow ກ່ຽວກັບທິດສະດີ chaos ແລະຫຼັກການຕົ້ນຕໍຂອງວິສະວະກໍາ chaos, ແລະຍັງໄດ້ອະທິບາຍວິທີການອົງການຈັດຕັ້ງ DevOps ທີ່ເຫມາະສົມໃນອະນາຄົດເຮັດວຽກ.

ພວກເຮົາໄດ້ກະກຽມສະບັບຂໍ້ຄວາມຂອງບົດລາຍງານ.

ສະບາຍດີຕອນເຊົ້າ

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

ຍົກມືຂຶ້ນ ໃຜຄິດວ່າ DevOps ເປັນອາຊີບແລ້ວໃນປີ 2018? ມີດັ່ງກ່າວ. ມີວິສະວະກອນ DevOps ຢູ່ໃນຫ້ອງທີ່ລາຍລະອຽດວຽກເວົ້າວ່າ "DevOps Engineer" ບໍ? ມີຜູ້ຈັດການ DevOps ຢູ່ໃນຫ້ອງບໍ? ບໍ່ມີສິ່ງດັ່ງກ່າວ. ສະຖາປະນິກ DevOps? ຍັງບໍ່ມີ. ບໍ່​ພຽງ​ພໍ. ມັນເປັນຄວາມຈິງແທ້ໆທີ່ບໍ່ມີໃຜເວົ້າວ່າພວກເຂົາເປັນວິສະວະກອນ DevOps?

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

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

ພວກເຮົາເປັນຄົນທີ່ມີຄວາມຄິດສ້າງສັນ, ພວກເຮົາບໍ່ພຽງແຕ່ພັກຜ່ອນໄດ້ງ່າຍ. ພວກເຮົາເວົ້າວ່າ: DevOps ບໍ່ແມ່ນຄໍາທີ່ສົມບູນພຽງພໍ; ມັນຍັງຂາດອົງປະກອບທີ່ແຕກຕ່າງກັນ, ຫນ້າສົນໃຈ. ແລະພວກເຮົາໄປຫາຫ້ອງທົດລອງລັບຂອງພວກເຮົາແລະເລີ່ມຜະລິດການກາຍພັນທີ່ຫນ້າສົນໃຈ: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.

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

ສະນັ້ນຂ້າພະເຈົ້າເອີ້ນວ່າວິທີການນີ້ - "Ops, ແລະບັນຫາໄດ້ຖືກແກ້ໄຂ."

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

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

ລະບົບແມ່ນຫຍັງ?

ແລະຖ້າພວກເຮົາເວົ້າກ່ຽວກັບການຄິດລະບົບ, ໃຫ້ເຕືອນຕົວເອງວ່າລະບົບແມ່ນຫຍັງ.

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

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

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

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

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

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

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

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

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

ທິດສະດີ Chaos

ຄົນ​ທີ່​ສຶກສາ​ຄວາມ​ວຸ່ນວາຍ​ເອີ້ນ​ຕົນ​ເອງ​ວ່າ​ນັກ​ວິຈານ.

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

ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ຫຼາຍ​ທ່ານ​ຍັງ​ມັກ​ຈະ​ຮູ້​ສຶກ​ແບບ​ນີ້​, ສະ​ນັ້ນ​ທ່ານ​ຍັງ chaosologists​. ຂ້າ​ພະ​ເຈົ້າ​ເຊື້ອ​ເຊີນ​ທ່ານ​ກັບ​ເອ​ກະ​ສານ​ອ້າງ​ຂອງ chaosologist ໄດ້​. ລະບົບທີ່ທ່ານແລະຂ້າພະເຈົ້າ, ເພື່ອນ chaosologist ທີ່ຮັກແພງ, ຈະສຶກສາເອີ້ນວ່າ "ລະບົບການປັບຕົວທີ່ສັບສົນ."

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

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

ມີສອງຜົນການຄົ້ນພົບທີ່ຫນ້າສົນໃຈຫຼາຍ.


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

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

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

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

ແລະບໍ່ແມ່ນບໍ່ມີພື້ນຖານ, ໃຫ້ເບິ່ງວ່າລະບົບທີ່ພວກເຮົາສ້າງແມ່ນມີການປ່ຽນແປງແນວໃດ.

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

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

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

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

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

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

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

ຄອມພິວເຕີໝອກ. ຈຸດ​ທີ່​ເຫັນ​ແມ່ນ​ວ່າ​ເມກ​ແມ່ນ​ເປັນ​ກ້ອນ​ຂອງ​ນ​້​ໍ​າ​, ອາຍ​, ກ້ອນ​, ແລະ​ກ້ອນ​ຫີນ​. ແລະ​ໝອກ​ແມ່ນ​ນ້ຳ​ທີ່​ກະ​ແຈກ​ກະຈາຍ​ຢູ່​ອ້ອມ​ຕົວ​ເຮົາ​ໃນ​ບັນຍາກາດ.

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

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

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

hype ປະມານ blockchain ແມ່ນເຂົ້າໃຈໄດ້. ຫລີກໄປທາງຫນຶ່ງ, ເຕັກໂນໂລຢີຂອງມັນເອງຖືຄໍາຫມັ້ນສັນຍາທີ່ໂດດເດັ່ນສໍາລັບອະນາຄົດທີ່ສົດໃສ: ເສລີພາບຫຼາຍ, ເອກະລາດຫຼາຍກວ່າເກົ່າ, ແຈກຢາຍຄວາມໄວ້ວາງໃຈທົ່ວໂລກ. ສິ່ງ​ທີ່​ບໍ່​ຕ້ອງ​ການ​?

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

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

ວິສະວະກໍາ Chaos

ດັ່ງນັ້ນ, ລະບົບທີ່ພວກເຮົາກໍາລັງພັດທະນາແມ່ນມີຄວາມຊັບຊ້ອນ, ສັບສົນຫຼາຍຂຶ້ນ, ແລະມີການປັບຕົວຫຼາຍຂຶ້ນ. Netflix ເປັນຜູ້ບຸກເບີກລະບົບບໍລິການຈຸລະພາກ. ພວກເຂົາແມ່ນ ໜຶ່ງ ໃນບັນດາຄົນ ທຳ ອິດທີ່ເຂົ້າໃຈເລື່ອງນີ້, ພວກເຂົາໄດ້ພັດທະນາຊຸດເຄື່ອງມືທີ່ພວກເຂົາເອີ້ນວ່າກອງທັບ Simian, ທີ່ມີຊື່ສຽງທີ່ສຸດ Chaos Monkey. ພຣະອົງໄດ້ກໍານົດສິ່ງທີ່ເປັນທີ່ຮູ້ຈັກເປັນ "ຫຼັກການຂອງວິສະວະກໍາ chaos".

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

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

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

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

ອະນຸສັນຍາການເຊື່ອມໂຍງລະບົບແຈກຢາຍ

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

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

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

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

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

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

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

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

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

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

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

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

ພື້ນຖານອົງການຈັດຕັ້ງ DevOps

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

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

ນີ້ແມ່ນພື້ນຖານຂອງອົງການຈັດຕັ້ງ DevOps: ຄວາມໂປ່ງໃສຂອງຂໍ້ມູນຂ່າວສານ, ການສື່ສານແບບ asynchronous, ການຫັນເປັນຜູ້ນໍາ, ການແບ່ງແຍກ.

ບາດແຜ

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

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

ອາຊີບວິສະວະກຳ, ດັ່ງທີ່ຂ້ອຍມັກເຕືອນຕົນເອງ, ເປັນອາຊີບທີ່ສ້າງສັນກ່ອນອື່ນໝົດ. ຖ້າພວກເຮົາສູນເສຍຄວາມປາຖະຫນາທີ່ຈະສ້າງບາງສິ່ງບາງຢ່າງ, ຫຼັງຈາກນັ້ນພວກເຮົາກາຍເປັນຂີ້ເທົ່າ, ກາຍເປັນຂີ້ເທົ່າ. ປະຊາຊົນເຜົາໄຫມ້ອອກ, ອົງການຈັດຕັ້ງທັງຫມົດໄຫມ້ອອກ.

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

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

ສິ່ງອື່ນນອກຈາກ Chaos Monkey?

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

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

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

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

ດັ່ງນັ້ນ, ໃນປັດຊະຍາ DevOps, ການບໍລິການຈຸນລະພາກບໍ່ແມ່ນເລື່ອງທີ່ດີບໍ?

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

ຢ່າງໃດກໍຕາມ, ສິ່ງທີ່ເນັ້ນໃສ່ຫຼາຍກວ່ານັ້ນ: ກ່ຽວກັບການເຮັດໃຫ້ການໂຕ້ຕອບງ່າຍຂຶ້ນຫຼືການເຮັດໃຫ້ສ່ວນທີ່ງ່າຍດາຍ?

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

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

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

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

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

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

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

ກອງປະຊຸມປີນີ້ DevOpsDays Moscow ຈະຈັດຂຶ້ນໃນວັນທີ 7 ເດືອນທັນວາທີ່ Technopolis. ພວກ​ເຮົາ​ໄດ້​ຮັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ສໍາ​ລັບ​ການ​ລາຍ​ງານ​ເຖິງ​ວັນ​ທີ 11 ເດືອນ​ພະ​ຈິກ​. ຂຽນ ພວກເຮົາຖ້າທ່ານຕ້ອງການເວົ້າ.

ການລົງທະບຽນສໍາລັບຜູ້ເຂົ້າຮ່ວມແມ່ນເປີດ, ປີ້ລາຄາ 7000 rubles. ເຂົ້າ​ຮ່ວມ​ນໍາ​ພວກ​ເຮົາ!

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