Seven Transformation Archetypes ອີງຕາມຫຼັກການ DevOps

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

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

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

ກ່ຽວ​ກັບ​ຜູ້​ເວົ້າ​:

ຫຼາຍກວ່າ 35 ປີໃນການຄຸ້ມຄອງ IT, ໄດ້ເຂົ້າຮ່ວມໃນການສ້າງຜູ້ສືບທອດຂອງ OpenCloud ຢູ່ Canonical, ໄດ້ມີສ່ວນຮ່ວມໃນ 10 startups, ສອງແຫ່ງໄດ້ຖືກຂາຍໃຫ້ Dell ແລະ Docker. ໃນປັດຈຸບັນລາວເປັນຮອງປະທານຂອງ DevOps ແລະ Digital Practices ຢູ່ SJ Technologies.

ຕໍ່ໄປແມ່ນເລື່ອງຈາກທັດສະນະຂອງ John.

ຊື່ຂອງຂ້ອຍແມ່ນ John Willis ແລະສະຖານທີ່ທີ່ງ່າຍທີ່ສຸດທີ່ຈະຊອກຫາຂ້ອຍແມ່ນຢູ່ໃນ Twitter, @botchagalupe. ຂ້ອຍມີນາມແຝງດຽວກັນຢູ່ໃນ Gmail ແລະ GitHub. ກ ໂດຍການເຊື່ອມຕໍ່ນີ້ ເຈົ້າສາມາດຊອກຫາບັນທຶກວິດີໂອຂອງບົດລາຍງານຂອງຂ້ອຍແລະບົດສະເຫນີສໍາລັບພວກເຂົາ.

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

DevOps ແມ່ນຫຍັງ?

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

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

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

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

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

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

ວັດທະນະທໍາທີ່ບໍ່ດີກິນວິທີການທີ່ດີສໍາລັບອາຫານເຊົ້າ

ແນວຄວາມຄິດຕົ້ນຕໍແມ່ນນີ້: ບໍ່ມີຈໍານວນ Lean, Agile, SAFE ແລະ DevOps ຈະຊ່ວຍໄດ້ຖ້າວັດທະນະທໍາຂອງອົງການເອງບໍ່ດີ. ມັນຄ້າຍຄືກັບການດໍານ້ໍາລົງໄປຫາຄວາມເລິກໂດຍບໍ່ມີເຄື່ອງມື scuba ຫຼືດໍາເນີນການໂດຍບໍ່ມີການ x-ray. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ເພື່ອປຽບທຽບ Drucker ແລະ Deming: ວັດທະນະທໍາອົງການຈັດຕັ້ງທີ່ບໍ່ດີຈະກືນກິນລະບົບທີ່ດີໃດໆໂດຍບໍ່ມີການ choking ມັນ.

ເພື່ອແກ້ໄຂບັນຫາຕົ້ນຕໍນີ້, ທ່ານຈໍາເປັນຕ້ອງໄດ້ດໍາເນີນຂັ້ນຕອນດັ່ງຕໍ່ໄປນີ້:

1. ເຮັດ​ໃຫ້​ການ​ເຮັດ​ວຽກ​ທັງ​ຫມົດ​ເຫັນ​ໄດ້​: ທ່ານຈໍາເປັນຕ້ອງເຮັດໃຫ້ວຽກງານທັງຫມົດເຫັນໄດ້. ບໍ່ແມ່ນໃນຄວາມຫມາຍວ່າມັນຈະຕ້ອງຖືກສະແດງຢູ່ໃນບາງຫນ້າຈໍ, ແຕ່ໃນຄວາມຫມາຍວ່າມັນຕ້ອງສັງເກດເຫັນ.
2. ລະບົບການຈັດການວຽກລວມ: ລະບົບການຄຸ້ມຄອງຈໍາເປັນຕ້ອງຖືກລວມເຂົ້າກັນ. ໃນບັນຫາຂອງຄວາມຮູ້ "ຊົນເຜົ່າ" ແລະຄວາມຮູ້ສະຖາບັນ, ໃນ 9 ກໍລະນີຂອງ 10 ຄໍຂອດແມ່ນປະຊາຊົນ. ໃນຫນັງສື "ໂຄງການ Phoenix" ບັນຫາແມ່ນຢູ່ກັບຄົນດຽວ, Brent, ຜູ້ທີ່ເປັນສາເຫດໃຫ້ໂຄງການແມ່ນສາມປີຫລັງຕາຕະລາງ. ແລະຂ້ອຍແລ່ນເຂົ້າໄປໃນ "Brents" ເຫຼົ່ານີ້ຢູ່ທົ່ວທຸກແຫ່ງ. ເພື່ອແກ້ໄຂຂໍ້ບົກຜ່ອງເຫຼົ່ານີ້, ຂ້ອຍໃຊ້ສອງລາຍການຕໍ່ໄປໃນບັນຊີລາຍຊື່ຂອງພວກເຮົາ.
3. ທິດ​ສະ​ດີ​ວິ​ທີ​ການ​ຈໍາ​ກັດ​: ທິດ​ສະ​ດີ​ຂອງ​ຂໍ້​ຈໍາ​ກັດ​.
4. Hacks ການ​ຮ່ວມ​ມື​: hacks ການຮ່ວມມື.
5. ໂຕໂຍຕ້າຄາຕາ (ຄູຝຶກ Kata): ຂ້ອຍຈະບໍ່ເວົ້າຫຼາຍກ່ຽວກັບ Toyota Kata. ຖ້າສົນໃຈ, ຢູ່ໃນ github ຂອງຂ້ອຍ ມີການນໍາສະເຫນີ ໃນເກືອບທຸກໆຫົວຂໍ້ເຫຼົ່ານີ້.
6. ອົງ​ການ​ຈັດ​ຕັ້ງ​ທິດ​ທາງ​ຕະ​ຫຼາດ​: ອົງການຈັດຕັ້ງຕະຫຼາດ.
7. ຜູ້ກວດສອບ Shift-ຊ້າຍ: ການກວດສອບໃນຂັ້ນຕອນຕົ້ນຂອງຮອບວຽນ.

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

(ຮູບ​ພາບ​ນີ້​ສາ​ມາດ​ເບິ່ງ​ແຍກ​ຕ່າງ​ຫາກ ເບິ່ງການເຊື່ອມຕໍ່)

ວິທີການຂອງຂ້ອຍແມ່ນອີງໃສ່ການເຮັດວຽກຂອງ William Schneider. ທາງເລືອກ Reengineering). ວິທີການແມ່ນອີງໃສ່ຄວາມຄິດທີ່ວ່າອົງການຈັດຕັ້ງໃດຫນຶ່ງສາມາດແບ່ງອອກເປັນສີ່ຮຽບຮ້ອຍ. ໂຄງ​ການ​ນີ້​ສໍາ​ລັບ​ຂ້າ​ພະ​ເຈົ້າ​ປົກ​ກະ​ຕິ​ແລ້ວ​ແມ່ນ​ຜົນ​ຂອງ​ການ​ເຮັດ​ວຽກ​ຮ່ວມ​ກັບ​ຫຼາຍ​ຮ້ອຍ​ຄົນ​ຂອງ​ໂຄງ​ການ​ອື່ນໆ​ທີ່​ເກີດ​ຂຶ້ນ​ໃນ​ເວ​ລາ​ທີ່​ການ​ວິ​ເຄາະ​ອົງ​ການ​ຈັດ​ຕັ້ງ. ສົມມຸດວ່າພວກເຮົາມີອົງການທີ່ມີການຄວບຄຸມລະດັບສູງ, ແຕ່ມີຄວາມສາມາດຕໍ່າ. ນີ້​ແມ່ນ​ທາງ​ເລືອກ​ທີ່​ບໍ່​ຕ້ອງ​ການ​ທີ່​ສຸດ​: ໃນ​ເວ​ລາ​ທີ່​ທຸກ​ຄົນ​ແມ່ນ toeing ເສັ້ນ​, ແຕ່​ບໍ່​ມີ​ໃຜ​ຮູ້​ວ່າ​ຈະ​ເຮັດ​ແນວ​ໃດ​.

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

(ຮູບ​ພາບ​ນີ້​ສາ​ມາດ​ເບິ່ງ​ແຍກ​ຕ່າງ​ຫາກ ເບິ່ງການເຊື່ອມຕໍ່)

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

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

(ຮູບ​ພາບ​ນີ້​ສາ​ມາດ​ເບິ່ງ​ແຍກ​ຕ່າງ​ຫາກ ເບິ່ງການເຊື່ອມຕໍ່)

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

(ຮູບ​ພາບ​ນີ້​ສາ​ມາດ​ເບິ່ງ​ແຍກ​ຕ່າງ​ຫາກ ເບິ່ງການເຊື່ອມຕໍ່)

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

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

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

(ຮູບ​ພາບ​ນີ້​ສາ​ມາດ​ເບິ່ງ​ແຍກ​ຕ່າງ​ຫາກ ເບິ່ງການເຊື່ອມຕໍ່)

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

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

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

1. ເຮັດໃຫ້ວຽກງານທັງໝົດເຫັນໄດ້ຊັດເຈນ: ເຮັດໃຫ້ວຽກງານເຫັນໄດ້ຊັດເຈນ

ບໍລິສັດສ່ວນໃຫຍ່ທີ່ຂ້ອຍເຮັດວຽກກັບມີອັດຕາສ່ວນສູງຫຼາຍຂອງການເຮັດວຽກທີ່ບໍ່ຮູ້ຈັກ. ຕົວຢ່າງ, ນີ້ແມ່ນເວລາທີ່ພະນັກງານຄົນຫນຶ່ງມາຫາຄົນອື່ນແລະພຽງແຕ່ຂໍໃຫ້ເຮັດບາງສິ່ງບາງຢ່າງ. ໃນອົງການຈັດຕັ້ງຂະຫນາດໃຫຍ່, ອາດຈະມີ 60% ການເຮັດວຽກທີ່ບໍ່ໄດ້ວາງແຜນ. ແລະເຖິງ 40% ຂອງວຽກງານບໍ່ໄດ້ຖືກບັນທຶກໄວ້ໃນທາງໃດກໍ່ຕາມ. ຖ້າມັນເປັນ Boeing, ຂ້ອຍຈະບໍ່ຂຶ້ນຍົນຂອງເຂົາເຈົ້າອີກໃນຊີວິດຂອງຂ້ອຍ. ຖ້າມີເອກະສານພຽງແຕ່ເຄິ່ງຫນຶ່ງ, ມັນບໍ່ຮູ້ວ່າວຽກງານນີ້ຖືກປະຕິບັດຢ່າງຖືກຕ້ອງຫຼືບໍ່. ວິທີການອື່ນໆທັງຫມົດແມ່ນບໍ່ມີປະໂຍດ - ບໍ່ມີຈຸດທີ່ຈະພະຍາຍາມອັດຕະໂນມັດຫຍັງ, ເພາະວ່າ 50% ທີ່ຮູ້ຈັກອາດຈະເປັນສ່ວນທີ່ສອດຄ່ອງແລະຊັດເຈນທີ່ສຸດຂອງການເຮັດວຽກ, ອັດຕະໂນມັດທີ່ຈະບໍ່ໃຫ້ຜົນໄດ້ຮັບທີ່ຍິ່ງໃຫຍ່, ແລະສິ່ງທີ່ຮ້າຍແຮງທີ່ສຸດ. ສິ່ງທີ່ຢູ່ໃນເຄິ່ງທີ່ເບິ່ງບໍ່ເຫັນ. ໃນກໍລະນີທີ່ບໍ່ມີເອກະສານ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຊອກຫາທຸກປະເພດຂອງ hacks ແລະການເຮັດວຽກທີ່ເຊື່ອງໄວ້, ບໍ່ແມ່ນເພື່ອຊອກຫາຂໍ້ບົກຜ່ອງ, "Brents" ທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າມາແລ້ວ. ມີປື້ມທີ່ປະເສີດໂດຍ Dominica DeGrandis "ເຮັດໃຫ້ວຽກງານເບິ່ງເຫັນ". ນາງເປີດເຜີຍ ຫ້າ "ເວລາຮົ່ວໄຫຼ" ທີ່ແຕກຕ່າງກັນ (ຂະ​ໂມຍ​ຂອງ​ເວ​ລາ​)​:

• ເຮັດວຽກຫຼາຍເກີນໄປໃນຂະບວນການ (WIP)
• ການເພິ່ງພາອາໄສທີ່ບໍ່ຮູ້ຈັກ
• ວຽກທີ່ບໍ່ໄດ້ວາງແຜນ
• ບູລິມະສິດທີ່ຂັດແຍ້ງກັນ
• ວຽກງານທີ່ຖືກລະເລີຍ

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

ໂຄງການ Phoenix ແມ່ນເລື່ອງທີ່ປະເສີດກ່ຽວກັບໂຄງການທີ່ຊ້າເກີນໄປສາມປີ. ຫນຶ່ງໃນຕົວລະຄອນປະເຊີນກັບການຖືກໄລ່ອອກຍ້ອນການນີ້, ແລະລາວໄດ້ພົບກັບຕົວລະຄອນອື່ນທີ່ຖືກນໍາສະເຫນີເປັນປະເພດຂອງ Socrates. ລາວຊ່ວຍຄິດອອກວ່າອັນໃດຜິດພາດແທ້. ມັນປະກົດວ່າບໍລິສັດມີຜູ້ເບິ່ງແຍງລະບົບຫນຶ່ງ, ທີ່ມີຊື່ Brent, ແລະການເຮັດວຽກທັງຫມົດແມ່ນຜ່ານລາວ. ໃນກອງປະຊຸມຫນຶ່ງ, ຫນຶ່ງໃນຜູ້ຍ່ອຍໄດ້ຖືກຖາມວ່າ: ເປັນຫຍັງແຕ່ລະວຽກເຄິ່ງຊົ່ວໂມງໃຊ້ເວລາຫນຶ່ງອາທິດ? ຄໍາຕອບແມ່ນເປັນການນໍາສະເຫນີທີ່ງ່າຍດາຍຫຼາຍຂອງທິດສະດີ queuing ແລະກົດຫມາຍຂອງ Little, ແລະໃນການນໍາສະເຫນີນີ້ມັນ turns ໃຫ້ເຫັນວ່າໃນ 90% occupancy, ແຕ່ລະຊົ່ວໂມງຂອງການເຮັດວຽກໃຊ້ເວລາ 9 ຊົ່ວໂມງ. ແຕ່ລະວຽກງານຕ້ອງຖືກສົ່ງໄປຫາຄົນອື່ນໆ 63 ຄົນ, ດັ່ງນັ້ນຊົ່ວໂມງນັ້ນຈະກາຍເປັນ 7 ຊົ່ວໂມງ, 9 ເວລາ XNUMX. ສິ່ງທີ່ຂ້ອຍເວົ້າແມ່ນວ່າເພື່ອໃຊ້ກົດຫມາຍຂອງ Little ຫຼືທິດສະດີການຄິວທີ່ສັບສົນ, ຢ່າງຫນ້ອຍຕ້ອງມີຂໍ້ມູນ.

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

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

2. ລວມລະບົບການຄຸ້ມຄອງວຽກງານ: ການຄຸ້ມຄອງວຽກງານ

archetypes ທີ່ຂ້າພະເຈົ້າເວົ້າກ່ຽວກັບແມ່ນປະເພດຂອງ pyramid. ຖ້າອັນທໍາອິດຖືກເຮັດຢ່າງຖືກຕ້ອງ, ຫຼັງຈາກນັ້ນອັນທີສອງແມ່ນປະເພດຂອງ add-on ແລ້ວ. ຈໍານວນຫຼາຍເຫຼົ່ານີ້ບໍ່ໄດ້ເຮັດວຽກສໍາລັບການເລີ່ມຕົ້ນ, ພວກເຂົາເຈົ້າຈໍາເປັນຕ້ອງໄດ້ເກັບຮັກສາໄວ້ໃນໃຈສໍາລັບບໍລິສັດຂະຫນາດໃຫຍ່ເຊັ່ນ Fortune 5000. ບໍລິສັດສຸດທ້າຍທີ່ຂ້າພະເຈົ້າເຮັດວຽກສໍາລັບມີ 10 ລະບົບປີ້. ທີມງານຫນຶ່ງມີການແກ້ໄຂ, ຄົນອື່ນຂຽນບາງປະເພດຂອງລະບົບຂອງຕົນເອງ, ທີສາມໃຊ້ Jira, ແລະບາງຄົນເຮັດດ້ວຍອີເມວ. ບັນຫາດຽວກັນເກີດຂື້ນຖ້າບໍລິສັດມີ 30 ທໍ່ທີ່ແຕກຕ່າງກັນ, ແຕ່ຂ້ອຍບໍ່ມີເວລາທີ່ຈະປຶກສາຫາລືທຸກກໍລະນີ.

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

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

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

ທໍ່ບໍລິການ

ນີ້ອີກເທື່ອຫນຶ່ງພຽງແຕ່ນໍາໃຊ້ກັບບໍລິສັດຂະຫນາດໃຫຍ່. ຖ້າທ່ານເປັນບໍລິສັດໃຫມ່ໃນພາກສະຫນາມໃຫມ່, ມ້ວນແຂນຂອງທ່ານແລະເຮັດວຽກກັບ Travis CI ຫຼື CircleCI ຂອງທ່ານ. ເມື່ອເວົ້າເຖິງບໍລິສັດ Fortune 5000, ກໍລະນີທີ່ເກີດຂື້ນຢູ່ທີ່ທະນາຄານທີ່ຂ້ອຍເຮັດວຽກ. ກູໂກມາຫາພວກເຂົາແລະພວກເຂົາຖືກສະແດງແຜນວາດຂອງລະບົບ IBM ເກົ່າ. guys ຈາກ Google ຖາມໃນຄວາມສັບສົນ - ບ່ອນທີ່ລະຫັດແຫຼ່ງສໍາລັບການນີ້? ແຕ່ບໍ່ມີລະຫັດແຫຼ່ງ, ບໍ່ແມ່ນ GUI. ນີ້ແມ່ນຄວາມເປັນຈິງທີ່ອົງການຈັດຕັ້ງຂະຫນາດໃຫຍ່ຕ້ອງຈັດການກັບ: ບັນທຶກທະນາຄານອາຍຸ 40 ປີໃນ mainframe ວັດຖຸບູຮານ. ຫນຶ່ງໃນລູກຄ້າຂອງຂ້ອຍໃຊ້ຖັງເກັບ Kubernetes ທີ່ມີຮູບແບບ Circuit Breaker, ບວກກັບ Chaos Monkey, ທັງຫມົດສໍາລັບຄໍາຮ້ອງສະຫມັກ KeyBank. ແຕ່ບັນຈຸເຫຼົ່ານີ້ໃນທີ່ສຸດເຊື່ອມຕໍ່ກັບຄໍາຮ້ອງສະຫມັກ COBOL.

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

3. ທິດສະດີຂໍ້ຈຳກັດ: ທິດສະດີຂໍ້ຈຳກັດ

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

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

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

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

4. hacks ການຮ່ວມມື: hacks ການຮ່ວມມື

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

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

5. ຄູຝຶກ Kata

ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເຕືອນໃນຕອນຕົ້ນ, ຂ້າພະເຈົ້າຈະບໍ່ເວົ້າກ່ຽວກັບເລື່ອງນີ້ໃນມື້ນີ້. ຖ້າທ່ານສົນໃຈ, ທ່ານສາມາດເຂົ້າໄປເບິ່ງໄດ້ ບາງບົດນຳສະເໜີຂອງຂ້ອຍ.

ນອກຈາກນີ້ຍັງມີການສົນທະນາທີ່ດີກ່ຽວກັບຫົວຂໍ້ນີ້ຈາກ Mike Rother:

6. Market Oriented: ການຈັດວາງຕະຫຼາດ

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

ກົດໝາຍຂອງ Conway ເຮັດວຽກຢູ່ທີ່ນີ້ (ກົດໝາຍຂອງ Conway), ເຊິ່ງໃນຮູບແບບທີ່ງ່າຍດາຍທີ່ສຸດສາມາດລະບຸໄວ້ດັ່ງຕໍ່ໄປນີ້: ຖ້າສາມທີມເຮັດວຽກກ່ຽວກັບ compiler, ຫຼັງຈາກນັ້ນຜົນໄດ້ຮັບຈະເປັນ compiler ຂອງສາມສ່ວນ. ດັ່ງນັ້ນ, ຖ້າມີຄວາມໂດດດ່ຽວໃນລະດັບສູງພາຍໃນອົງກອນ, ເຖິງແມ່ນວ່າ Kubernetes, Circuit breaker, API extensibility ແລະສິ່ງອື່ນໆທີ່ແປກປະຫຼາດໃນອົງກອນນີ້ຈະຖືກຈັດລຽງໃນແບບດຽວກັນກັບອົງກອນຂອງມັນເອງ. ຢ່າງເຂັ້ມງວດຕາມ Conway ແລະເຖິງວ່າທຸກ geeks ຫນຸ່ມ.

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

ຫຼາຍຄົນອະທິບາຍໂຄງສ້າງນີ້ໃນທາງທີ່ແຕກຕ່າງກັນ, ຂ້ອຍມັກຄໍາເວົ້າ ສ້າງ/ແລ່ນທີມ, ຢູ່ Amazon ພວກເຂົາໂທຫາມັນ ສອງທີມ pizza. ໃນໂຄງສ້າງນີ້, ຄົນປະເພດ "ຂ້ອຍ" ທັງຫມົດຖືກຈັດເປັນກຸ່ມປະມານຫນຶ່ງການບໍລິການ, ແລະຄ່ອຍໆພວກເຂົາໃກ້ຊິດກັບປະເພດ "T", ແລະຖ້າການຈັດການທີ່ຖືກຕ້ອງ, ພວກເຂົາສາມາດກາຍເປັນ "E". ການໂຕ້ຖຽງທໍາອິດຢູ່ທີ່ນີ້ແມ່ນວ່າໂຄງສ້າງດັ່ງກ່າວມີອົງປະກອບທີ່ບໍ່ຈໍາເປັນ. ເປັນຫຍັງທ່ານຕ້ອງການຜູ້ທົດສອບໃນແຕ່ລະພະແນກຖ້າທ່ານສາມາດມີພະແນກພິເສດຂອງຜູ້ທົດສອບ? ຂ້າພະເຈົ້າຕອບວ່າ: ຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມໃນກໍລະນີນີ້ແມ່ນລາຄາສໍາລັບອົງການທັງຫມົດທີ່ຈະເປັນປະເພດ "E" ໃນອະນາຄົດ. ໃນໂຄງສ້າງນີ້, ຜູ້ທົດສອບຄ່ອຍໆຮຽນຮູ້ກ່ຽວກັບເຄືອຂ່າຍ, ສະຖາປັດຕະຍະກໍາ, ການອອກແບບ, ແລະອື່ນໆ. ດັ່ງນັ້ນ, ທຸກໆຜູ້ເຂົ້າຮ່ວມໃນອົງການຈັດຕັ້ງແມ່ນມີຄວາມຮູ້ກ່ຽວກັບທຸກສິ່ງທີ່ເກີດຂື້ນໃນອົງການຈັດຕັ້ງ. ຖ້າທ່ານຕ້ອງການຮູ້ວ່າໂຄງການນີ້ເຮັດວຽກແນວໃດໃນອຸດສາຫະກໍາ, ອ່ານ Mike Rother, Toyota Kata.

7. Shift-left auditors: ກວດສອບຕົ້ນໃນຮອບວຽນ. ການປະຕິບັດຕາມກົດລະບຽບຄວາມປອດໄພໃນການສະແດງ

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

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

ຜູ້ກວດສອບຈໍາເປັນຕ້ອງໄດ້ຮັບການເຊື້ອເຊີນໃຫ້ເຂົ້າຮ່ວມກັບພວກເຮົາ, ແລະບໍ່ກໍາຈັດພວກມັນ. ບອກພວກເຂົາວ່າທ່ານຂຽນຖັງສອງທີ່ບໍ່ປ່ຽນແປງໄດ້ວ່າ, ຖ້າພວກເຂົາຜ່ານການທົດສອບທັງຫມົດ, ຍັງຄົງບໍ່ປ່ຽນແປງຕະຫຼອດໄປ. ບອກພວກເຂົາວ່າທ່ານມີທໍ່ເປັນລະຫັດແລະອະທິບາຍວ່າມັນຫມາຍຄວາມວ່າແນວໃດ. ສະແດງໃຫ້ພວກເຂົາເຫັນໂຄງການຕໍ່ໄປນີ້: binary ອ່ານເທົ່ານັ້ນທີ່ບໍ່ປ່ຽນແປງໄດ້ໃນຖັງທີ່ຜ່ານການທົດສອບຄວາມອ່ອນແອທັງຫມົດ; ແລະຫຼັງຈາກນັ້ນບໍ່ພຽງແຕ່ບໍ່ມີໃຜແຕະຕ້ອງມັນ, ພວກເຂົາບໍ່ໄດ້ແຕະຕ້ອງລະບົບທີ່ສ້າງທໍ່, ເພາະວ່າມັນຍັງຖືກສ້າງແບບເຄື່ອນໄຫວ. ຂ້ອຍມີລູກຄ້າ, Capital One, ຜູ້ທີ່ໃຊ້ Vault ເພື່ອສ້າງບາງສິ່ງບາງຢ່າງເຊັ່ນ: blockchain. ຜູ້ກວດສອບບໍ່ຈໍາເປັນຕ້ອງສະແດງ "ສູດ" ຈາກ Chef; ມັນພຽງພໍທີ່ຈະສະແດງ blockchain, ເຊິ່ງເຫັນໄດ້ຊັດເຈນວ່າສິ່ງທີ່ເກີດຂື້ນກັບປີ້ Jira ໃນການຜະລິດແລະໃຜເປັນຜູ້ຮັບຜິດຊອບ.

ອີງຕາມການ ລາຍງານ, ສ້າງໃນປີ 2018 ໂດຍ Sonatype, ມີການຮ້ອງຂໍການດາວໂຫຼດ 2017 ຕື້ OSS ໃນປີ 87.

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

ຕົວຢ່າງຂອງລໍາດັບນີ້:


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

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

ຜົນໄດ້ຮັບ

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

ການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ

ນີ້ແມ່ນການສົນທະນາສອງສາມຢ່າງຈາກກອງປະຊຸມ DevOops ທີ່ເຈົ້າອາດຈະເຫັນວ່າເປັນປະໂຫຍດ:

• Sergey Berdnikov, Artyom Kalichkin - ເລື່ອງຄວາມສໍາເລັດ, ຫຼື "Dev+DevOps+Ops" (видео, ຖອດຖອນບົດລາຍງານ)
• Baruch Sadogursky, Leonid Igolnik - DevOps ໃນຂະຫນາດ: ຄວາມໂສກເສົ້າຂອງກເຣັກໃນສາມການກະທໍາ (видео, ຖອດຖອນບົດລາຍງານ)
• Alexander Titov, Kirill Tolkachev - DevOps, ວິສະວະກອນ ແລະຊຸມຊົນ
• Timothy Lister - ລັກສະນະ, ຊຸມຊົນ, ແລະວັດທະນະທໍາ: ປັດໃຈສໍາຄັນສໍາລັບຄວາມຈະເລີນຮຸ່ງເຮືອງ

ເບິ່ງເຂົ້າໄປໃນ ໂຄງການ DevOops 2020 ມອດໂກ — ມັນ​ຍັງ​ມີ​ຫຼາຍ​ສິ່ງ​ທີ່​ຫນ້າ​ສົນ​ໃຈ​ທີ່​ນັ້ນ​.

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