ຂະບວນການບັນທຶກການຕັດສິນໃຈດ້ານສະຖາປັດຕະຍະກຳຂອງ AWS

https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html

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

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

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

ຂອບເຂດຂອງຂະບວນການ ADR

ສະມາຊິກໂຄງການຄວນສ້າງ ADR ສຳລັບທຸກການຕັດສິນໃຈທີ່ມີນັຍສຳຄັນຕໍ່ສະຖາປັດຕະຍະກຳ ທີ່ມີຜົນຕໍ່ໂຄງການ ຫຼື ຜະລິດຕະພັນຊອບແວ ລວມເຖິງສິ່ງຕໍ່ໄປນີ້ (Richards ແລະ Ford 2020):

ໂຄງສ້າງ (ຕົວຢ່າງ ຮູບແບບເຊັ່ນ microservices)
ຄວາມຕ້ອງການທີ່ບໍ່ແມ່ນດ້ານໜ້າທີ່ (ຄວາມປອດໄພ, ຄວາມພ້ອມໃຊ້ງານສູງ ແລະ ການທົນຕໍ່ຄວາມຜິດພາດ)
ຄວາມຂຶ້ນກັບກັນ (ການເຊື່ອມໂຍງຂອງອົງປະກອບ)
ສ່ວນຕໍ່ປະສານ (API ແລະ ສັນຍາທີ່ເຜີຍແຜ່)
ເຕັກນິກການກໍ່ສ້າງ (ໄລບຣາຣີ, ເຟຣມເວີກ, ເຄື່ອງມື ແລະ ຂະບວນການ)
ຄວາມຕ້ອງການດ້ານໜ້າທີ່ ແລະ ທີ່ບໍ່ແມ່ນດ້ານໜ້າທີ່ ແມ່ນຂໍ້ມູນນຳເຂົ້າທົ່ວໄປທີ່ສຸດຂອງຂະບວນການ ADR.

ເນື້ອຫາຂອງ ADR

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

ຂະບວນການຮັບເອົາ ADR

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

ຫຼັງຈາກທີມລະບຸການຕັດສິນໃຈດ້ານສະຖາປັດຕະຍະກຳ ແລະ ເຈົ້າຂອງຂອງມັນແລ້ວ ເຈົ້າຂອງ ADR ຈະສົ່ງ ADR ໃນສະຖານະ ສະເໜີ (Proposed) ໃນຕອນເລີ່ມຕົ້ນຂອງຂະບວນການ. ADR ໃນສະຖານະສະເໜີພ້ອມສຳລັບການທົບທວນ.

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

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

ທີມຍັງສາມາດຕັດສິນໃຈປະຕິເສດ ADR ໄດ້. ໃນກໍລະນີນີ້ ເຈົ້າຂອງ ADR ຈະເພີ່ມເຫດຜົນຂອງການປະຕິເສດ ເພື່ອປ້ອງກັນການສົນທະນາຫົວຂໍ້ດຽວກັນໃນອະນາຄົດ. ເຈົ້າຂອງປ່ຽນສະຖານະ ADR ເປັນ ປະຕິເສດ (Rejected).

ຖ້າທີມອະນຸມັດ ADR ເຈົ້າຂອງຈະເພີ່ມຕາປະທັບເວລາ, ເວີຊັນ ແລະ ລາຍຊື່ຜູ້ມີສ່ວນໄດ້ສ່ວນເສຍ. ຈາກນັ້ນເຈົ້າຂອງອັບເດດສະຖານະເປັນ ຍອມຮັບ (Accepted).

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

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

ຂະບວນການທົບທວນ ADR

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