ຫຼັກສູດສະຖາປະນິກ Cloud (The Cloud Architect Course)

ຈາກຄວາມຮູ້ສູນ ສູ່ການອອກແບບລະບົບ cloud ທີ່ບໍລິສັດກ້າເອົາທຸລະກິດຂອງຕົນມາວາງເດີມພັນ.

ຫຼັກສູດນີ້ເຮັດວຽກແນວໃດ

ທ່ານບໍ່ໄດ້ຝຶກເພື່ອ ປະຕິບັດງານ ລະບົບ cloud. ທ່ານກຳລັງຝຶກເພື່ອ ອອກແບບ ພວກມັນ: ເອົາບັນຫາທຸລະກິດທີ່ຍຸ່ງເຫຍີງ (“ພວກເຮົາຕ້ອງຂາຍໃຫ້ລູກຄ້າໜຶ່ງລ້ານຄົນ ແລະ ຫ້າມເສຍຄຳສັ່ງຊື້ຈັກອັນ”) ມາປ່ຽນເປັນແຜນເຕັກນິກທີ່ແຕ້ມແລ້ວ, ຄິດໄລ່ຕົ້ນທຶນແລ້ວ, ປົກປ້ອງໄດ້, ແລ້ວຊັກຊວນທັງວິສະວະກອນທີ່ຈະສ້າງມັນ ແລະ ຜູ້ບໍລິຫານທີ່ຈະຈ່າຍເງິນໃຫ້ມັນ. ນັ້ນຄືວຽກຂອງ ສະຖາປະນິກ cloud (ປະກາດຮັບໃນຊື່ solutions architect, cloud solutions architect, ຫຼື cloud domain architect ນຳ), ແລະ ມັນຄືຝີມືວິຊາຊີບທີ່ຮຽນຮູ້ໄດ້ ພ້ອມຫຼັກສູດທີ່ຈະແຈ້ງ — ອັນນີ້ເອງ.

ຫຼັກສູດນີ້ມີຫ້າໄລຍະ. ໄລຍະທີ 1 (ອາທິດທີ 1–6): ອົງປະກອບພື້ນຖານ, ໃນຖານະການຕັດສິນໃຈ. ທຸກສ່ວນປະກອບຂອງ cloud, ສອນຄືນໃໝ່ ບໍ່ແມ່ນເປັນຂໍ້ເທັດຈິງ ແຕ່ເປັນ ທາງເລືອກທີ່ມີການແລກປ່ຽນ (trade-off) — ເພາະຫົວໜ່ວຍວຽກຂອງສະຖາປະນິກ ຄືການຕັດສິນໃຈ. ໄລຍະທີ 2 (ອາທິດທີ 7–14): ຂອບເຂດການອອກແບບ. ຫົກເສົາຫຼັກຂອງ Well-Architected Framework — reliability, security, performance, cost, operations, sustainability — ແຕ່ລະອັນສອນຢ່າງເລິກ ພ້ອມຮູບແບບມາດຕະຖານຂອງມັນ ແລະ ການອອກແບບຕົວຢ່າງ. ໄລຍະທີ 3 (ອາທິດທີ 15–20): ຄັງລວມ pattern. ສະຖາປັດຕະຍະກຳສິບກວ່າແບບ ທີ່ແກ້ 95% ຂອງບັນຫາຕົວຈິງ, ແລະ — ສຳຄັນກວ່ານັ້ນ — ເມື່ອໃດ ບໍ່ຄວນ ໃຊ້ແຕ່ລະອັນ. ໄລຍະທີ 4 (ອາທິດທີ 21–26): ການ migrate ແລະ ໂລກຕົວຈິງ. ການຍ້າຍບໍລິສັດທີ່ມີຢູ່ແລ້ວຂຶ້ນ cloud, ແລະ ຂໍ້ຈຳກັດ (ກົດໝາຍ, ລະບົບເກົ່າ, lock-in) ທີ່ເຮັດໃຫ້ສະຖາປັດຕະຍະກຳຕົວຈິງ ຍາກກວ່າສະຖາປັດຕະຍະກຳເທິງກະດານຂາວ. ໄລຍະທີ 5 (ເດືອນທີ 7–12): ຝີມືວິຊາຊີບ. ເອກະສານ, ແຜນວາດ, ການທົບທວນ, ການນຳສະເໜີ, ແລະ certification ທີ່ເຮັດໃຫ້ທ່ານ ຖືກຈ້າງໄດ້ ໃນຖານະສະຖາປະນິກ, ປິດທ້າຍດ້ວຍສາມໂຄງການອອກແບບລະດັບ portfolio.

ຫຼັກສູດນີ້ສຳລັບໃຜ. ມັນສົມມຸດວ່າບໍ່ມີຄວາມຮູ້ມາກ່ອນເລີຍ: ທຸກສິ່ງທີ່ມັນອາໄສ ຖືກສອນຄືນສັ້ນໆກ່ອນຖືກໃຊ້. ຖ້າທ່ານຮຽນຈົບ The Cloud Engineer Course ແລ້ວ (ຫຼືທ່ານເຮັດວຽກ cloud ແບບລົງມືຢູ່ທຸກມື້ນີ້), ໄລຍະທີ 1 ຈະຄຸ້ນເຄີຍ — ອ່ານກວາດຜ່ານໄດ້, ແຕ່ເຮັດບົດຝຶກຫັດຂອງມັນຢູ່ດີ, ເພາະມັນປັບກອບສິ່ງທີ່ທ່ານຮູ້ເປັນຂໍ້ເທັດຈິງ ໃຫ້ກາຍເປັນສິ່ງທີ່ທ່ານຕ້ອງຊັ່ງນ້ຳໜັກເປັນການຕັດສິນໃຈ, ແລະ ການປັບກອບນັ້ນເອງ ຄືການປ່ຽນຜ່ານທັງໝົດ ຈາກວິສະວະກອນສູ່ສະຖາປະນິກ.

ກົດລະບຽບຕະຫຼອດຫຼັກສູດ: ຮຽນ ມື້ລະໜຶ່ງຊົ່ວໂມງ, ຫົກມື້ຕໍ່ອາທິດ — ຄວາມສະໝໍ່າສະເໝີຊະນະຄວາມໜັກໜ່ວງ. ທຸກ module ຈົບລົງດ້ວຍ ຕາຕະລາງຄຳສັບ (ຄຳທີ່ທ່ານຕ້ອງເປັນເຈົ້າຂອງ), ບົດຝຶກຫັດ (ວຽກອອກແບບ, ບໍ່ແມ່ນການອ່ານ — ສະຖາປັດຕະຍະກຳຮຽນຮູ້ດ້ວຍການແຕ້ມ ແລະ ການຕັດສິນໃຈ), ແລະ Milestone (ຫຼັກໝາຍ — ຫຼັກຖານວ່າທ່ານພ້ອມກ້າວຕໍ່; ຢ່າຂ້າມ milestone ທີ່ຍັງບໍ່ບັນລຸ). ແລະ ຕັ້ງແຕ່ອາທິດທີ 1, ໃຫ້ຮັກສາ Design Journal (ປຶ້ມບັນທຶກການອອກແບບ): ທຸກສະຖາປັດຕະຍະກຳທີ່ທ່ານແຕ້ມ, ທຸກ trade-off ທີ່ທ່ານຊີ້, ທຸກຄຳທຳນາຍທີ່ທ່ານເຮັດກ່ຽວກັບຕົ້ນທຶນ ຫຼື ຄວາມລົ້ມເຫຼວ. ອີກສິບເດືອນຈາກນີ້ ມັນຈະກາຍເປັນ portfolio ສຳພາດຂອງທ່ານ; ບໍ່ມີຫຍັງປະທັບໃຈຄະນະກຳມະການຈ້າງງານ ເທົ່າກັບປຶ້ມບັນທຶກມີວັນທີ ຂອງສີ່ສິບການອອກແບບ ພ້ອມບັນທຶກຊື່ສັດວ່າທ່ານຜິດຢູ່ໃສ.

ສະຖາປະນິກ cloud ເຮັດຫຍັງແທ້ໆ

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

ປ່ຽນອິດເປັນ server ແລ້ວນັ້ນຄືວຽກນີ້. ອາທິດຂອງສະຖາປະນິກ cloud ປະກອບດ້ວຍສ່ວນປະສົມຂອງ: ການຟັງ ຜູ້ມີສ່ວນໄດ້ເສຍທາງທຸລະກິດ ແລະ ສະກັດຄວາມຕ້ອງການຕົວຈິງ ອອກຈາກຄວາມປາຖະໜາທີ່ມົວ; ການອອກແບບ — ເລືອກສ່ວນປະກອບ, ແຕ້ມແຜນວາດ, ຂຽນບັນທຶກການຕັດສິນໃຈ ແລະ ເຫດຜົນ; ການທົບທວນ ການອອກແບບຂອງຄົນອື່ນ ຕໍ່ຫົກເສົາຫຼັກ; ການປະເມີນ ວ່າການອອກແບບໜຶ່ງຈະມີຄ່າໃຊ້ຈ່າຍເດືອນລະເທົ່າໃດ ແລະ ປົກປ້ອງຕົວເລກນັ້ນຕໍ່ຝ່າຍການເງິນ; ການວາງແຜນ migrate ລະບົບເກົ່າຂຶ້ນ cloud; ການນຳສະເໜີ — ການອອກແບບອັນດຽວກັນ ອະທິບາຍທາງໜຶ່ງໃຫ້ວິສະວະກອນ ແລະ ອີກທາງທີ່ຕ່າງກັນສິ້ນເຊີງໃຫ້ຜູ້ບໍລິຫານ; ແລະ ການເປັນພີ່ລ້ຽງ ວິສະວະກອນ ເພື່ອໃຫ້ມາດຕະຖານຢູ່ລອດເມື່ອປະທະກັບເສັ້ນຕາຍ. ໃນຫຼາຍທີມຍັງມີ pre-sales: ນັ່ງຂ້າງນັກຂາຍ ຕໍ່ໜ້າລູກຄ້າມຸ່ງຫວັງ, ແຕ້ມຮ່າງ solution ທີ່ຊະນະດີລ.

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

ປະກາດຮັບສະໝັກວຽກ ທີ່ທ່ານກຳລັງຝຶກໄປຫາ

ໃນເດືອນສິງຫາ 2026 ພວກເຮົາໄດ້ດຶງປະກາດ ແລະ ແມ່ແບບວຽກ Cloud/Solutions Architect ຕົວຈິງ — ແມ່ແບບ cloud-architect ຂອງ recruiter (KORE1), ປະກາດວຽກຂອງບໍລິສັດຈັດຫາງານ (4 Corner Resources), ນິຍາມບົດບາດສະຖາປະນິກຂອງ Microsoft ເອງໃນ Azure Well-Architected Framework, ປະກາດ Solutions Architect ສາຍ pre-sales (Arpio, AWS disaster-recovery), ປະກາດ Solution Architect ລະດັບວິສາຫະກິດ (Intel, ຜ່ານ Built In), ແລະ ປະກາດ Cloud Domain Architect ລະດັບວິສາຫະກິດ (Halliburton, Azure-first). ເມື່ອປອກລົດຊາດຂອງແຕ່ລະບໍລິສັດອອກ ຂໍ້ກຳນົດສິບສອງຢ່າງດຽວກັນກໍປາກົດຊ້ຳແລ້ວຊ້ຳອີກ. ຫຼັກສູດນີ້ຖືກສ້າງຕາມລາຍການນັ້ນ — ນີ້ຄືບ່ອນທີ່ແຕ່ລະຂໍ້ຖືກສອນແທ້ໆ:

Certification, ກວດສອບຕໍ່ຕະຫຼາດດຽວກັນ: ບັນໄດມາດຕະຖານຄື AWS Certified Solutions Architect – Associate (SAA-C03) — ໃບຢັ້ງຢືນດ່ຽວທີ່ຖືກຮຽກຫາຫຼາຍທີ່ສຸດ, ປົກກະຕິກຽມ 2–3 ເດືອນ — ຕາມດ້ວຍ AWS Certified Solutions Architect – Professional (SAP-C02), ປົກກະຕິອີກ 4–8 ເດືອນ; ບໍລິສັດສາຍ Azure ຮຽກຫາ AZ-305 (Azure Solutions Architect Expert); ວິສາຫະກິດຂະໜາດໃຫຍ່ບາງແຫ່ງເພີ່ມ TOGAF ສຳລັບວິທີການ enterprise-architecture. ແຜນເຕັມຢູ່ໃນໄລຍະທີ 5, Module 14.

ໄລຍະທີ 1 — ອົງປະກອບພື້ນຖານ, ໃນຖານະການຕັດສິນໃຈ (ອາທິດທີ 1–6)

ຜູ້ຈົບ Cloud Engineer Course: ອ່ານກວາດຄຳອະທິບາຍໄດ້, ແຕ່ເຮັດທຸກບົດຝຶກຫັດ. ຂໍ້ເທັດຈິງຄືເກົ່າ; ຄຳຖາມແມ່ນໃໝ່.

Module 1 (ອາທິດທີ 1–2): Cloud ແມ່ນຫຍັງ, ແລະ ສະຖາປະນິກຄິດແນວໃດ

Cloud ໃນໜຶ່ງວັກ (ບົດທວນສຳລັບຜູ້ເລີ່ມຈາກສູນ). Cloud (ຄລາວ) ຄື ຄອມພິວເຕີຂອງຄົນອື່ນ, ເຊົ່າເປັນຊົ່ວໂມງ, ຄຸ້ມຄອງດ້ວຍ software. AWS, Microsoft Azure, ແລະ Google Cloud ດຳເນີນສາງເຕັມໄປດ້ວຍ server (data center — ສູນຂໍ້ມູນ) ຈັດກຸ່ມເປັນ Region (ພາກພື້ນ) ຕາມພູມສາດ (ເຊັ່ນ “Asia Pacific (Bangkok)”); ແຕ່ລະ region ບັນຈຸ Availability Zone (AZ) ທີ່ແຍກອິດສະຫຼະຫຼາຍແຫ່ງ — ອາຄານແຍກກັນ ມີໄຟຟ້າເປັນເອກະລາດ, ໃກ້ພໍໃຫ້ເຊື່ອມຕໍ່ໄວ, ໄກພໍທີ່ນ້ຳຖ້ວມ ຫຼື ໄຟໄໝ້ຄັ້ງດຽວ ຈະເອົາສອງແຫ່ງໄປພ້ອມກັນບໍ່ໄດ້. ທ່ານເຊົ່າສ່ວນແບ່ງຂອງທັງໝົດນີ້ຕໍ່ວິນາທີ: ເຄື່ອງດິບ (IaaS — ທ່ານຄຸ້ມຄອງທຸກຢ່າງເທິງມັນ), ແພລດຟອມ managed (PaaS — ທ່ານເອົາມາແຕ່ແອັບພລິເຄຊັນຂອງທ່ານ), ຫຼື software ສຳເລັດຮູບ (SaaS — ທ່ານພຽງໃຊ້ມັນ). ນັ້ນຄືພື້ນຖານທັງໝົດ. ທຸກສິ່ງທີ່ສະຖາປະນິກອອກແບບ ຖືກຈັດວາງເທິງມັນ.

ຕໍ່ໄປຄືທ່າຂອງສະຖາປະນິກ: ປ່ຽນທຸກຂໍ້ເທັດຈິງເປັນຄຳຖາມ. ວິສະວະກອນຮຽນວ່າ “AZ ຄື data center ທີ່ແຍກອິດສະຫຼະ.” ສະຖາປະນິກຖາມທັນທີ: “workload ນີ້ສົມຄວນໄດ້ຈັກ AZ?” — ເພາະສອງ AZ ແພງກວ່າໜຶ່ງ, ສາມແພງກວ່າສອງ, ແລະ ເວັບໂບຼຊົວການຕະຫຼາດ ບໍ່ສົມຄວນໄດ້ຮັບສິ່ງທີ່ລະບົບຊຳລະເງິນສົມຄວນໄດ້ຮັບ. ນີ້ຄືແນວຄິດທຳອິດ ແລະ ສຳຄັນທີ່ສຸດຂອງຫຼັກສູດ:

ສະຖາປັດຕະຍະກຳ ຄືວິໄນຂອງການເຮັດໃຫ້ trade-off ຈະແຈ້ງອອກມາ. ເກືອບບໍ່ມີສ່ວນປະກອບທີ່ຜິດ — ມີແຕ່ສ່ວນປະກອບທີ່ຜິດ ສຳລັບ workload ນີ້, ງົບນີ້, ທີມນີ້, ເສັ້ນຕາຍນີ້.

ສາມຫຼ່ຽມ trade-off. ທຸກການອອກແບບເຈລະຈາລະຫວ່າງສາມແຈ: ໄວ (performance — ໄວສຳລັບຜູ້ໃຊ້, ໄວໃນການສ້າງ), ຖືກ (ໃບບິນລາຍເດືອນຕໍ່າ, ແຮງງານວິສະວະກຳຕໍ່າ), ແລະ ທົນທານ (ຢູ່ລອດຄວາມລົ້ມເຫຼວ, ຂະຫຍາຍໄດ້, ປອດໄພຢູ່ສະເໝີ). ທ່ານດັນໄປຫາສອງແຈໃດກໍໄດ້; ແຈທີສາມຈ່າຍລາຄາໃຫ້. Prototype ຂອງ startup ຄວນໄວ ແລະ ຖືກ — ຄວາມທົນທານລໍໄດ້. ບັນຊີແຍກປະເພດຫຼັກຂອງທະນາຄານຕ້ອງທົນທານ ແລະ ໄວ — ມັນຈະບໍ່ຖືກ. ເມື່ອຜູ້ມີສ່ວນໄດ້ເສຍເວົ້າວ່າ “ພວກເຮົາຢາກໄດ້ທັງສາມ,” ວຽກຂອງທ່ານຄືຍິ້ມ ແລ້ວຖາມວ່າເຂົາຢາກໄດ້ອັນໃດ ທີ່ສຸດ, ເພາະການອອກແບບເລີ່ມບໍ່ໄດ້ຈົນກວ່າເຂົາຈະຕອບ. ແຕ້ມສາມຫຼ່ຽມນີ້ໄວ້ເທິງສຸດຂອງທຸກການອອກແບບທີ່ທ່ານເຮັດໃນຫຼັກສູດນີ້, ແລະ ໝາຍວ່າ workload ນັ້ນນັ່ງຢູ່ໃສ. ມັນຈະຊ່ວຍທ່ານພົ້ນຈາກການຖຽງກັນພັນຄັ້ງ.

Requirements: ວັດຖຸດິບຂອງການອອກແບບ. ສະຖາປະນິກແຍກ functional requirements (ຄວາມຕ້ອງການດ້ານໜ້າທີ່ — ລະບົບເຮັດຫຍັງ: “ລູກຄ້າສັ່ງອາຫານທ່ຽງໄດ້”) ອອກຈາກ non-functional requirements (NFRs) (ຄວາມຕ້ອງການທີ່ບໍ່ແມ່ນໜ້າທີ່ — ມັນຕ້ອງເຮັດໄດ້ດີປານໃດ: “ພາຍໃນ 2 ວິນາທີ, ສຳລັບນັກຮຽນ 10,000 ຄົນພ້ອມກັນ, 99.9% ຂອງເວລາ, ພາຍໃນ PDPA”). ມືໃໝ່ໝົກມຸ້ນກັບລາຍການທຳອິດ; ສະຖາປະນິກຫາເງິນເດືອນຈາກລາຍການທີສອງ, ເພາະ NFR ຄືສິ່ງທີ່ກຳນົດສະຖາປັດຕະຍະກຳແທ້ໆ. ສອງຄຳຖາມວິເສດ ສະກັດ NFR ອອກຈາກຜູ້ມີສ່ວນໄດ້ເສຍ ທີ່ບໍ່ຮູ້ວ່າຕົນມີມັນ: “ຈະເກີດຫຍັງຂຶ້ນກັບທຸລະກິດ ຖ້າອັນນີ້ລົ້ມໄປໜຶ່ງຊົ່ວໂມງ?” ແລະ “ຄວາມສຳເລັດມີໜ້າຕາແນວໃດ ທີ່ຂະໜາດສິບເທົ່າຂອງມື້ນີ້?”

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້ (ລິ້ງກວດສອບແລ້ວ):

ເບິ່ງທົວຂອງ Fireship ສອງເທື່ອ: ເທື່ອໜຶ່ງຕອນນີ້ເພື່ອແຜນທີ່, ເທື່ອໜຶ່ງທ້າຍໄລຍະທີ 1 — ທ່ານຈະແປກໃຈວ່າຕອນນີ້ທ່ານ ວາງຕຳແໜ່ງ ບໍລິການໄດ້ຈັກອັນໃນການອອກແບບ.

ບົດຝຶກຫັດ: (1) ເລືອກສາມແອັບທີ່ທ່ານໃຊ້ທຸກມື້ (ແອັບທະນາຄານ, ແອັບສົ່ງອາຫານ, ແອັບວິດີໂອ) ແລ້ວ, ສຳລັບແຕ່ລະອັນ, ຂຽນສາມ NFR ອັນດັບຕົ້ນຂອງມັນ ແລະ ໝາຍມັນລົງເທິງສາມຫຼ່ຽມ trade-off. (2) ສຳພາດໝູ່ກ່ຽວກັບໄອເດຍທຸລະກິດສິບນາທີ ແລ້ວສະກັດ requirement ຫ້າອັນແບບ functional ແລະ ຫ້າອັນແບບ non-functional — ສັງເກດວ່າ NFR ອອກມາກໍຕໍ່ເມື່ອທ່ານຖາມສອງຄຳຖາມວິເສດ. (3) ເລີ່ມ Design Journal ຂອງທ່ານດ້ວຍບັນທຶກ #1: ສາມຫຼ່ຽມ, ແລະ ໜຶ່ງວັກວ່າເປັນຫຍັງ “ເຮົາຈະເສຍສະລະແຈໃດ?” ຈຶ່ງເປັນຄຳຖາມທຸລະກິດ, ບໍ່ແມ່ນຄຳຖາມເຕັກນິກ.

Milestone: ເມື່ອໄດ້ຄຳບັນຍາຍລະບົບໃດກໍຕາມໜຶ່ງປະໂຫຍກ, ທ່ານສາມາດອອກ NFR ທີ່ເປັນໄປໄດ້ຂອງມັນ ແລະ ຕຳແໜ່ງຂອງມັນເທິງສາມຫຼ່ຽມ ພາຍໃນຫ້ານາທີ, ອອກສຽງ, ໂດຍບໍ່ເບິ່ງບັນທຶກ.

Module 2 (ອາທິດທີ 3–4): Compute, storage, database, network — ສີ່ການຕັດສິນໃຈ

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

ການຕັດສິນໃຈທີ 1 — Compute: VM, container, ຫຼື serverless? Virtual machine (VM) (ເຄື່ອງຈັກເສມືອນ) ຄືສ່ວນແບ່ງເຊົ່າຂອງ server ທີ່ປະພຶດຄືຄອມພິວເຕີເຕັມໜ່ວຍ — ຄວບຄຸມສູງສຸດ, ບຳລຸງຮັກສາສູງສຸດ (ທ່ານ patch ມັນ, ທ່ານ scale ມັນ, ທ່ານຈ່າຍຂະນະມັນຫວ່າງ). Container ຫຸ້ມຫໍ່ແອັບພລິເຄຊັນໜຶ່ງອັນພ້ອມທຸກສິ່ງທີ່ມັນຕ້ອງການ ເພື່ອໃຫ້ມັນແລ່ນຄືກັນທຸກປະການໃນທຸກບ່ອນ; orchestrator (Kubernetes) ແລ່ນ ແລະ ຮັກສາຝູງຂອງພວກມັນ — ຄວາມໜາແໜ້ນ ແລະ ຄວາມເຄື່ອນຍ້າຍໄດ້ດີເລີດ, ແຕ່ທ່ານໄດ້ຮັບເອົາແພລດຟອມທີ່ຊັບຊ້ອນ ທີ່ຕ້ອງການຄົນມີທັກສະ. Serverless (AWS Lambda, Azure Functions) ແລ່ນໂຄດຂອງທ່ານສະເພາະເມື່ອຖືກກະຕຸ້ນ ແລະ ຄິດເງິນຕໍ່ການເອີ້ນ — ບຳລຸງຮັກສາເກືອບສູນ ແລະ ສົມບູນແບບສຳລັບ traffic ແບບພຸ່ງເປັນຊ່ວງ, ແຕ່ມີຂໍ້ຈຳກັດ (ເພດານເວລາປະມວນຜົນ, cold start, ແລະ ການແຕ່ງງານເລິກກວ່າກັບຜູ້ໃຫ້ບໍລິການດຽວ). ຕາຕະລາງການຕັດສິນໃຈ ທີ່ທ່ານຄວນສ້າງຄືນຈາກຄວາມຈຳໄດ້:

ຄວາມເຂົ້າໃຈຂັ້ນອາວຸໂສ: ນີ້ຄືທາງເລືອກຕໍ່ workload, ບໍ່ແມ່ນສາສະໜາຂອງບໍລິສັດ. ລະບົບຕົວຈິງແລ່ນທັງສາມແບບຄຽງຄູ່ກັນ, ຢ່າງຖືກຕ້ອງ.

ການຕັດສິນໃຈທີ 2 — Storage: object, block, ຫຼື file — ແລະ ຮ້ອນປານໃດ? Object storage (Amazon S3) ຄືຖັງບໍ່ມີກົ້ນສຳລັບໄຟລ໌ — ຖືກ, ທົນທານແບບເຫຼືອເຊື່ອ (“eleven nines”), ຄຳຕອບມາດຕະຖານຂອງ “ໄຟລ໌ໄປໄວ້ໃສ?” Block storage (EBS) ຄືດິສເສມືອນທີ່ຕິດກັບ VM. File storage (EFS) ຄືໄດຣຟ໌ແບ່ງປັນ ທີ່ຫຼາຍເຄື່ອງ mount ພ້ອມກັນ. ມິຕິເສີມຂອງສະຖາປະນິກຄື ອຸນຫະພູມ: ຂໍ້ມູນ hot (ເຂົ້າເຖິງຕະຫຼອດ, ຕັ້ງລາຄາເພື່ອຄວາມໄວ) ທຽບກັບຂັ້ນ cold/archive (Glacier — ຫຼຽນເສດ, ແຕ່ໃຊ້ນາທີຫາຊົ່ວໂມງໃນການດຶງຄືນ). ການອອກແບບ lifecycle rule ທີ່ຄ່ອຍໆເລື່ອນຂໍ້ມູນເກົ່າໄປຂັ້ນ cold ຄືໄຊຊະນະຕົ້ນທຶນທີ່ຖືກທີ່ສຸດໃນ cloud; ການລືມເຮັດ ຄືສິ່ງທີ່ພົບເລື້ອຍທີ່ສຸດ.

ການຕັດສິນໃຈທີ 3 — Database: SQL ຫຼື NoSQL (ແລະ ລົດຊາດ managed ອັນໃດ)? Database ແບບ relational/SQL (PostgreSQL, MySQL; ແບບ managed ຄື RDS/Aurora) ເກັບຂໍ້ມູນໃນຕາຕະລາງເຄັ່ງຄັດ ພ້ອມ consistency ທີ່ຮັບປະກັນ — ຄ່າມາດຕະຖານສຳລັບທຸກຢ່າງທີ່ຄວາມຖືກຕ້ອງເປັນສິ່ງສັກສິດ: ເງິນ, ຄຳສັ່ງຊື້, ສາງສິນຄ້າ, ຜູ້ໃຊ້. Database ແບບ NoSQL (DynamoDB, MongoDB) ແລກໂຄງສ້າງເຄັ່ງຄັດ ກັບຄວາມຍືດຍຸ່ນ ແລະ ການຂະຫຍາຍແນວນອນເກືອບບໍ່ຈຳກັດ — ຄ່າມາດຕະຖານສຳລັບ session, catalog, feed, telemetry. ຫຼັກຕັດສິນ: ເລີ່ມດ້ວຍ SQL ເວັ້ນແຕ່ທ່ານບອກຊື່ເຫດຜົນສະເພາະທີ່ມັນຈະໃຊ້ບໍ່ໄດ້ (ຂະໜາດສຸດຂີດ, schema ຍືດຍຸ່ນ, ການອ່ານທົ່ວໂລກລະດັບ millisecond ຫຼັກດຽວ). ແລະ ໃນ cloud, “database” ເກືອບສະເໝີຄວນໝາຍເຖິງ “managed database” — ຜູ້ໃຫ້ບໍລິການຈັດການ backup, patch, ແລະ failover; ທີມທີ່ແລ່ນ database ຂອງຕົນເອງເທິງ VM ຄວນມີເຫດຜົນເປັນລາຍລັກອັກສອນ. ເພີ່ມຜູ້ຊ່ຽວຊານສະເພາະໃສ່ຄຳສັບຂອງທ່ານ: cache (Redis — ຂໍ້ມູນ hot ໃນ memory, ອ່ານລະດັບ microsecond), warehouse (ການວິເຄາະຂະໜາດໃຫຍ່ — ໄລຍະທີ 3), queue (ບໍ່ແມ່ນ database, ແຕ່ມັກເປັນຊິ້ນສ່ວນທີ່ຂາດ — ໄລຍະທີ 3).

ການຕັດສິນໃຈທີ 4 — Network: ຮູບຮ່າງຂອງໂລກສ່ວນຕົວ. VPC (Virtual Private Cloud) ຄືສ່ວນທີ່ມີຮົ້ວກັ້ນຂອງທ່ານ ໃນເຄືອຂ່າຍຂອງຜູ້ໃຫ້ບໍລິການ. ພາຍໃນມັນ, public subnet ຖືສິ່ງທີ່ອິນເຕີເນັດແຕະຕ້ອງໄດ້ (load balancer), ແລະ private subnet ຖືທຸກຢ່າງອື່ນ — app server ແລະ, ສະເໝີ, database. “The database sits in a private subnet” (database ຢູ່ໃນ private subnet) ຄືປະໂຫຍກທີ່ຖືກເວົ້າຊ້ຳຫຼາຍທີ່ສຸດ ໃນການທົບທວນສະຖາປັດຕະຍະກຳ; ເຫດຜົນ — ບໍ່ມີຫຍັງໂຈມຕີສິ່ງທີ່ບໍ່ມີເສັ້ນທາງຈາກອິນເຕີເນັດໄດ້ — ຄືເຄິ່ງໜຶ່ງຂອງຄວາມປອດໄພເຄືອຂ່າຍ. ອ້ອມ VPC: load balancer ກະຈາຍ traffic ໃຫ້ຫຼາຍ server ແລະ ອ້ອມຜ່ານເຄື່ອງທີ່ບໍ່ສະບາຍ; DNS (Route 53) ປ່ຽນຊື່ເປັນທີ່ຢູ່; CDN (CloudFront) cache ເນື້ອຫາໄວ້ໃນຫຼາຍຮ້ອຍເມືອງ ໃຫ້ໄວທຸກບ່ອນ; API gateway ຄືໂຕະຕ້ອນຮັບແບບ managed ຂອງ API ຂອງທ່ານ (ການຢັ້ງຢືນຕົວຕົນ, ຈຳກັດອັດຕາ, ບັນທຶກ log). ການເຊື່ອມກັບໂລກເກົ່າ: VPN (ອຸໂມງເຂົ້າລະຫັດຜ່ານອິນເຕີເນັດ) ຫຼື Direct Connect (ສາຍກາຍະພາບສ່ວນຕົວ) — ສາຍແຮ່ຂອງທຸກການອອກແບບ hybrid ໃນໄລຍະທີ 4.

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້ (ລິ້ງກວດສອບແລ້ວ):

ບົດຝຶກຫັດ: (1) ສຳລັບຫ້າ workload ເຫຼົ່ານີ້, ເລືອກ compute, database, ແລະ storage, ພ້ອມຂຽນເຫດຜົນອັນລະໜຶ່ງປະໂຫຍກ: ເວັບສັ່ງອາຫານທ່ຽງຂອງໂຮງຮຽນ; ບັນຊີທຸລະກຳຂອງທະນາຄານ; ແອັບແບ່ງປັນຮູບ; ຕົວສ້າງລາຍງານກາງຄືນທີ່ແລ່ນ 20 ນາທີ; ແອັບແຊັດສຳລັບຜູ້ໃຊ້ 5 ລ້ານຄົນ. (2) ເອົາທາງເລືອກໜຶ່ງຂອງທ່ານ ແລ້ວໂຕ້ແຍ້ງທາງເລືອກ ກົງກັນຂ້າມ ໃຫ້ໜ້າເຊື່ອທີ່ສຸດເທົ່າທີ່ເຮັດໄດ້ — ສະຖາປະນິກທີ່ steel-man ທາງເລືອກອື່ນບໍ່ໄດ້ ຍັງບໍ່ເຂົ້າໃຈ trade-off. (3) ປຶ້ມບັນທຶກ: ຕາຕະລາງການຕັດສິນໃຈ compute ຂອງທ່ານ, ຈາກຄວາມຈຳ.

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

Module 3 (ອາທິດທີ 5–6): ການອ່ານ ແລະ ແຕ້ມແຜນວາດສະຖາປັດຕະຍະກຳ

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

ແຜນວາດຕົ້ນແບບ — ຮຽນອັນນີ້ກ່ອນ. Three-tier architecture (ສະຖາປັດຕະຍະກຳສາມຊັ້ນ) ຄື “ໂຄງສ້າງປະໂຫຍກ” ຂອງແຜນວາດ cloud; ການອອກແບບສ່ວນໃຫຍ່ຄືການປ່ຽນແປງຂອງມັນ:

Users → DNS → CDN → Load Balancer → [Web/App servers, ×N, multi-AZ, auto-scaled]
                                          → [Cache]
                                          → [Database: primary + standby, private subnets]

ຊັ້ນ 1 (presentation): ສິ່ງທີ່ຜູ້ໃຊ້ແຕະຕ້ອງ — ເນື້ອຫາ static ຈາກ CDN, ຄຳຮ້ອງຂໍຜ່ານ load balancer. ຊັ້ນ 2 (application): ຝູງ server ທີ່ແທນກັນໄດ້ ແລ່ນ logic ຂອງທ່ານ, ໃນ private subnet, ຂະຫຍາຍໂດຍອັດຕະໂນມັດ. ຊັ້ນ 3 (data): database, ເລິກທີ່ສຸດ ແລະ ຖືກປົກປ້ອງທີ່ສຸດ, ພ້ອມ standby ໃນ AZ ທີສອງ. Traffic ໄຫຼທາງດຽວ: ຜູ້ໃຊ້ບໍ່ແຕະຊັ້ນ app ໂດຍກົງຈັກເທື່ອ, ຊັ້ນ app ເທົ່ານັ້ນທີ່ເວົ້າກັບຊັ້ນ data. ຝຶກແຕ້ມອັນນີ້ຈົນມືເຮັດເອງໂດຍສະໝອງບໍ່ຕ້ອງສັ່ງ — ມັນຄືບົດເປີດການສຳພາດກະດານຂາວ ຢູ່ທຸກມຸມໂລກ.

ທຳນຽມສັນຍາລັກ ທີ່ເຮັດໃຫ້ທ່ານເບິ່ງເປັນມືອາຊີບ (ເພາະມັນເຮັດໃຫ້ທ່ານ ຄິດ ແບບມືອາຊີບ): ກ່ອງຄືສ່ວນປະກອບ — ຕິດປ້າຍແຕ່ລະອັນວ່າມັນແມ່ນຫຍັງ ແລະ ໃຊ້ບໍລິການໃດ (“App servers — EC2, auto-scaling group”). ລູກສອນສະແດງທິດທາງທີ່ ຄຳຮ້ອງຂໍ ໄຫຼ, ຕິດປ້າຍ protocol ເມື່ອສຳຄັນ. ຂອບເສັ້ນປະສະແດງຂອບເຂດ — VPC, ແຕ່ລະ subnet, ແຕ່ລະ AZ (ແຕ້ມຂອບ AZ ແລ້ວ multi-AZ ຈະເບິ່ງເຫັນໄດ້ ແທນທີ່ຈະເປັນພຽງຄຳອ້າງ). ຜູ້ໃຊ້/actor ຢືນຢູ່ນອກລະບົບ. ຕົວເລກເທິງລູກສອນ (1, 2, 3…) ໃຫ້ທ່ານບັນຍາຍການເດີນທາງຂອງຄຳຮ້ອງຂໍ. ແລະ ທຸກແຜນວາດມີຫົວຂໍ້, ວັນທີ, ແລະ legend. ກົດທີ່ເລິກກວ່າ: ໜຶ່ງແຜນວາດ, ໜຶ່ງກຸ່ມຜູ້ຟັງ, ໜຶ່ງຄຳຖາມ. ແຜນວາດທີ່ສະແດງທຸກຢ່າງ ບໍ່ສະແດງຫຍັງເລີຍ; ທ່ານຈະໄດ້ຮຽນຊຸດມາດຕະຖານຂອງລະດັບ zoom (context → container → deployment) ໃນໄລຍະທີ 5.

ການອ່ານແຜນວາດຂອງຄົນອື່ນ — x-ray ຂອງສະຖາປະນິກ. ເມື່ອໄດ້ຮັບແຜນວາດ, ແລ່ນການສະແກນນີ້ອອກສຽງ: ອິນເຕີເນັດແຕະລະບົບນີ້ຢູ່ໃສ (ທຸກຈຸດສຳຜັດຄື attack surface)? ຂໍ້ມູນຢູ່ໃສ, ແລະ ມັນຢູ່ໃນ private subnet ບໍ? ຫຍັງມີຄູ່ (ທົນທານ) ແລະ ຫຍັງເປັນ single point of failure — ກ່ອງທີ່ບໍ່ມີແຝດ? ບ່ອນໃດຈະເຈັບເມື່ອ traffic 10×? ແຕ່ລະກ່ອງມີຄ່າໃຊ້ຈ່າຍເດືອນລະເທົ່າໃດ? ຫ້າຄຳຖາມ, ສາມສິບວິນາທີ, ແລ້ວທ່ານໄດ້ອ່ານແຜນວາດ ຄືກັບທີ່ໝໍອ່ານ x-ray. ທ່ອງ AWS Architecture Center (https://aws.amazon.com/architecture/) ແລ້ວແລ່ນການສະແກນໃສ່ reference architecture ທີ່ຕີພິມສາມອັນ.

ຄຳສັບ:

ບົດຝຶກຫັດ: (1) ແຕ້ມແຜນວາດສາມຊັ້ນຈາກຄວາມຈຳ, ຫ້າມື້ຕິດຕໍ່ກັນ, ຈົນມັນໃຊ້ເວລາຕໍ່າກວ່າສີ່ນາທີ ພ້ອມຂອບເຂດທັງໝົດ (VPC, subnet, ສອງ AZ) ຖືກແຕ້ມ. (2) ເອົາຫ້າ workload ຂອງ Module 2 ມາແຕ້ມແຕ່ລະອັນ — ຊາວນາທີຕໍ່ແຜນວາດ, ບັງຄັບໃຊ້ກົດສັນຍາລັກ. (3) ຊອກຫາແຜນວາດສະຖາປັດຕະຍະກຳຈິງໃດກໍໄດ້ອອນລາຍ (AWS Architecture Center ມີຫຼາຍຮ້ອຍ) ແລ້ວຂຽນການສະແກນ x-ray ຫ້າຄຳຖາມຂອງມັນ ໃນປຶ້ມບັນທຶກ. (4) ບົດຝຶກບັນຍາຍ: ແຜນວາດຢູ່ຕໍ່ໜ້າ, ບັນຍາຍການຄລິກຂອງຜູ້ໃຊ້ຄົນໜຶ່ງ ຈາກ browser ຫາ database ແລ້ວກັບຄືນ, ອອກສຽງ, ນັບເລກລູກສອນໄປນຳ.

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

ໄລຍະທີ 2 — ຂອບເຂດການອອກແບບ (ອາທິດທີ 7–14)

ແຜນທີ່ຂອງໄລຍະນີ້ຄື AWS Well-Architected Framework — ລາຍການກວດສອບຮ່ວມຂອງວົງການ ວ່າ “ອອກແບບຢ່າງຖືກຕ້ອງ” ໝາຍເຖິງຫຍັງ, ຈັດເປັນຫົກເສົາຫຼັກ: operational excellence (ຄວາມເປັນເລີດດ້ານປະຕິບັດການ), security (ຄວາມປອດໄພ), reliability (ຄວາມໜ້າເຊື່ອຖື), performance efficiency (ປະສິດທິພາບ), cost optimization (ການເພີ່ມປະສິດທິພາບຕົ້ນທຶນ), sustainability (ຄວາມຍືນຍົງ). (Azure ມີ framework ທີ່ເກືອບຄືກັນ; ຮຽນອັນໜຶ່ງໃຫ້ເລິກ ແລ້ວທ່ານໄດ້ຮຽນທັງສອງ.) ປະກາດຮັບສະໝັກວຽກຮຽກຫາສະຖາປະນິກທີ່ “run Well-Architected reviews” ໄດ້ໂດຍລະບຸຊື່, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງເອົາເສົາຫຼັກມາທີ່ລະອັນ, ແລະ ສຳລັບແຕ່ລະອັນ ທ່ານຈະຮຽນສາມສິ່ງ: ຄຳຖາມຫຼັກ ຂອງເສົານັ້ນ, pattern ມາດຕະຖານ ຂອງມັນ (ຄຳຕອບທີ່ໜ້າເບື່ອ ແຕ່ພິສູດແລ້ວ — ສະຖາປະນິກປະກອບກ່ອນຈະປະດິດ), ແລະ ຕົວຢ່າງທີ່ເຮັດໃຫ້ເບິ່ງ ເທິງສະຖານະການທີ່ແລ່ນຕໍ່ເນື່ອງ.

ສະຖານະການທີ່ແລ່ນຕໍ່ເນື່ອງຕະຫຼອດໄລຍະທີ 2: ThaiTicket, ແພລດຟອມຂາຍປີ້ງານສົມມຸດໃນບາງກອກ. ໂຫຼດປົກກະຕິ: ຜູ້ເຂົ້າຊົມ 2,000 ຄົນ/ຊົ່ວໂມງ. ແຕ່ເມື່ອປີ້ຂອງສິນລະປິນດັງເປີດຂາຍ 10:00 ໂມງເຊົ້າ, ມັນຮັບຜູ້ເຂົ້າຊົມ 400,000 ຄົນໃນສິບນາທີ, ການຊຳລະເງິນຫ້າມຂາຍບ່ອນນັ່ງຊ້ຳ, ແລະ ຂໍ້ມູນສ່ວນບຸກຄົນຂອງລູກຄ້າໄທຢູ່ພາຍໃຕ້ PDPA. ໄວ, ຖືກ, ທົນທານ — ThaiTicket ຕ້ອງການທັງສາມ ແລະ ມີທັງສາມບໍ່ໄດ້, ຊຶ່ງນັ້ນເອງເຮັດໃຫ້ມັນເປັນຄົນເຈັບຝຶກຫັດທີ່ສົມບູນແບບ.

ເບິ່ງກ່ອນ Module 4 (ລິ້ງກວດສອບແລ້ວ):

ແລະ bookmark ຕົວ framework ເອງໄວ້ — https://aws.amazon.com/architecture/well-architected/ ແລະ ເອກະສານສະບັບເຕັມທີ່ https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html — ທ່ານຈະໃຊ້ຊີວິດຢູ່ໃນນັ້ນແປດອາທິດ.

Module 4 (ອາທິດທີ 7–8): Reliability — ອອກແບບເພື່ອມື້ທີ່ສິ່ງຕ່າງໆພັງ

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

ຄຳຖາມຫຼັກ (ຖາມສິ່ງເຫຼົ່ານີ້ຕໍ່ທຸກການອອກແບບ, ຕະຫຼອດໄປ): ຈະເກີດຫຍັງເມື່ອແຕ່ລະສ່ວນປະກອບລົ້ມເຫຼວ — ມີ “ແລ້ວແນວໃດຕໍ່” ຢູ່ສະເໝີບໍ? ລະບົບຮັບມືໂຫຼດ 10× ແນວໃດ? ພວກເຮົາ ຮູ້ ໄດ້ແນວໃດວ່າມີສິ່ງໜຶ່ງລົ້ມເຫຼວ ກ່ອນລູກຄ້າຈະບອກ? RTO ແລະ RPO ຂອງພວກເຮົາແມ່ນເທົ່າໃດ — ແລະ ໃຜໃນຝ່າຍທຸລະກິດເປັນຄົນເຊັນຮັບຮອງມັນ? ພວກເຮົາ ທົດສອບ ການກູ້ຄືນຄັ້ງສຸດທ້າຍເມື່ອໃດ?

RTO ແລະ RPO — ສອງຕົວເລກທີ່ຄືບົດສົນທະນາເລື່ອງໄພພິບັດທັງໝົດ. Recovery Time Objective: ພວກເຮົາລົ້ມໄດ້ດົນປານໃດ? Recovery Point Objective: ພວກເຮົາເສຍຂໍ້ມູນໄດ້ຫຼາຍປານໃດ (ນັ້ນຄື backup ດີອັນສຸດທ້າຍເກົ່າໄດ້ປານໃດ)? RTO 4 ຊົ່ວໂມງ ແລະ RPO 1 ຊົ່ວໂມງ ໝາຍວ່າ: ກັບມາພາຍໃນສີ່ຊົ່ວໂມງ, ໂດຍເສຍຂໍ້ມູນຫຼາຍສຸດໜຶ່ງຊົ່ວໂມງ. ນີ້ຄືການຕັດສິນໃຈ ທາງທຸລະກິດ ທີ່ມີປ້າຍລາຄາແບບເລກກຳລັງ — RPO 24 ຊົ່ວໂມງ ຄື backup ກາງຄືນ (ຖືກ); RPO ~ສູນ ຄື replication ຕໍ່ເນື່ອງ (ແພງ); RTO ລະດັບນາທີ ໝາຍເຖິງໂຄງສ້າງພື້ນຖານທີ່ອຸ່ນຢູ່ ຫວ່າງລໍຖ້າເປັນ standby (ແພງຫຼາຍ). ວຽກຂອງສະຖາປະນິກຄືເຮັດໃຫ້ຝ່າຍທຸລະກິດເລືອກຕົວເລກ ຢ່າງຮູ້ຕົວ — ແລ້ວອອກແບບໃຫ້ຕົງກັບມັນພໍດີ, ບໍ່ແມ່ນເກີນມັນຢ່າງເພີ້ຝັນ.

Pattern ມາດຕະຖານ: redundancy (ມີສອງອັນສຳລັບທຸກສິ່ງທີ່ສຳຄັນ — N+1) · multi-AZ (ຕົວສຳເນົາຂ້າມ data center; load balancer ແລະ managed database failover ເຮັດໃຫ້ມັນອັດຕະໂນມັດ) · auto-scaling (ຄວາມຈຸຕາມຄວາມຕ້ອງການ) · health check + self-healing (instance ທີ່ຕາຍຖືກກວດພົບ ແລະ ປ່ຽນແທນໂດຍເຄື່ອງຈັກ, ບໍ່ແມ່ນຄົນ) · backup ທີ່ຖືກທົດສອບ (backup ທີ່ບໍ່ໄດ້ທົດສອບຄືຄວາມຫວັງ, ບໍ່ແມ່ນແຜນ — ຈັດຕາຕະລາງຊ້ອມ restore) · graceful degradation (ເມື່ອໂຫຼດເກີນ, ຖິ້ມຄຸນສົມບັດທີ່ສຳຄັນນ້ອຍທີ່ສຸດກ່ອນ: ThaiTicket ຕັດການສະແດງຕົວຢ່າງແຜນຜັງບ່ອນນັ່ງໄດ້ ແລະ ຮັກສາການຊຳລະເງິນໄວ້) · queue ເປັນຕົວດູດແຮງກະແທກ (ໄລຍະທີ 3) · ຫຼີກລ້ຽງ cascading failure (timeout, retry ພ້ອມ backoff, circuit breaker — ເພື່ອບໍ່ໃຫ້ dependency ຊ້າອັນດຽວ ຈົມທັງຝູງ).

ຕົວຢ່າງທີ່ເຮັດໃຫ້ເບິ່ງ — ການອອກແບບ reliability ຂອງ ThaiTicket. ສອງ AZ ໃນ region ບາງກອກ. ຊັ້ນ app ແບບ stateless ໃນ auto-scaling group ຫຼັງ load balancer, ອຸ່ນເຄື່ອງໄວ້ລ່ວງໜ້າຕາມຕາຕະລາງ ກ່ອນເວລາເປີດຂາຍທີ່ປະກາດໄວ້ (auto-scaling ຕອບສະໜອງເປັນນາທີ; ການເປີດຂາຍ 10:00 ຕ້ອງມີຄວາມຈຸພ້ອມແຕ່ 09:45). Database Aurora, primary ຢູ່ AZ-a, standby ແບບ synchronous ຢູ່ AZ-b, failover ອັດຕະໂນມັດ ≈ ຕໍ່າກວ່າໜຶ່ງນາທີ. Queue ຢູ່ລະຫວ່າງການຄລິກ “ຊື້” ກັບການປະມວນຜົນຊຳລະເງິນ ເພື່ອວ່າຄວາມຊ້າຂອງຜູ້ໃຫ້ບໍລິການຊຳລະເງິນ ຈະເຮັດໃຫ້ຄຳສັ່ງຊື້ເຂົ້າຄິວ ແທນທີ່ຈະເຮັດໃຫ້ເວັບລົ້ມ. Backup: ຕໍ່ເນື່ອງ, restore ຍ້ອນເວລາໄດ້, ຊ້ອມ restore ທຸກເດືອນ. ຕົວເລກທີ່ຕົກລົງກັບຝ່າຍທຸລະກິດ: RTO 15 ນາທີ, RPO ~ສູນ ສຳລັບຄຳສັ່ງຊື້ (ມັນຄືເງິນ), RPO 24 ຊົ່ວໂມງ ສຳລັບຂໍ້ມູນວິເຄາະ (ມັນບໍ່ແມ່ນ). ບົດຝຶກໃນປຶ້ມບັນທຶກ: ອັນນີ້ເອົາຫຍັງໄປຈາກແຈ “ຖືກ” ຂອງສາມຫຼ່ຽມ?

ຄຳສັບ:

ບົດຝຶກຫັດ: (1) ເອົາການອອກແບບເວັບສັ່ງອາຫານທ່ຽງຈາກໄລຍະທີ 1 ມາຍົກລະດັບໃຫ້ຢູ່ລອດ: instance ຕາຍ, AZ ຫາຍ, database ລົ້ມເຫຼວ, ແລະ ຊ່ວງອາຫານທ່ຽງພຸ່ງ 10× — ແຕ້ມກ່ອນ ແລະ ຫຼັງ. (2) ຂຽນບົດສົນທະນາ RTO/RPO ສຳລັບສາມທຸລະກິດ (ບຼັອກ, ເວັບອີຄອມເມີຊ, ລະບົບເວດຊະລະບຽນໂຮງໝໍ) ເປັນບົດສົນທະນາສັ້ນລະຫວ່າງສະຖາປະນິກກັບເຈົ້າຂອງ — ຝຶກເຮັດໃຫ້ຕົ້ນທຶນເບິ່ງເຫັນໄດ້ໃນບົດສົນທະນາ. (3) ປຶ້ມບັນທຶກ: ລາຍຊື່ SPOF ທຸກອັນໃນການອອກແບບ ThaiTicket ຂ້າງເທິງ. ມີຢ່າງໜ້ອຍໜຶ່ງອັນທີ່ຖືກປະໄວ້ໂດຍເຈດຕະນາ. (ໃບ້: ຈັກ region?)

Milestone: ທ່ານດຳເນີນການສອບຖາມ “ຈະເກີດຫຍັງເມື່ອອັນນີ້ລົ້ມເຫຼວ?” ເທິງແຜນວາດໃດກໍໄດ້ ຕິດຕໍ່ກັນສິບນາທີໂດຍບໍ່ໝົດຄຳຖາມ, ແລະ ທ່ານອະທິບາຍ RTO ທຽບ RPO ໃຫ້ເຈົ້າຂອງທີ່ບໍ່ແມ່ນສາຍເຕັກນິກ ດ້ວຍການປຽບທຽບຮ້ານຄ້າຖືກນ້ຳຖ້ວມ ພາຍໃນເກົ້າສິບວິນາທີ.

Module 5 (ອາທິດທີ 9–10): Security — ອອກແບບລະບົບທີ່ທຳຮ້າຍໄດ້ຍາກ

ກອບຄິດ: shared responsibility model (ແບບຈຳລອງຄວາມຮັບຜິດຊອບຮ່ວມ). ຜູ້ໃຫ້ບໍລິການຮັກສາຄວາມປອດໄພຂອງ ຕົວ cloud ເອງ — ອາຄານ, ຮາດແວ, hypervisor. ທ່ານຮັກສາຄວາມປອດໄພຂອງທຸກສິ່ງທີ່ທ່ານ ເອົາເຂົ້າໄປໃນມັນ — ຂໍ້ມູນ, ຕົວຕົນ, ການຕັ້ງຄ່າ, ໂຄດ. ເກືອບທຸກກໍລະນີການລະເມີດ cloud ທີ່ດັງ ຄືການຕັ້ງຄ່າຜິດຢູ່ຝັ່ງລູກຄ້າ (bucket ສາທາລະນະ, key ຮົ່ວ, role ທີ່ໃຫ້ສິດເກີນ), ຊຶ່ງເປັນເຫດຜົນວ່າຄວາມປອດໄພຄືບັນຫາ ສະຖາປັດຕະຍະກຳ ກ່ອນທີ່ຈະເປັນບັນຫາເຄື່ອງມື: ປະກາດຮັບສະໝັກວຽກເວົ້າວ່າ “integrate security into the design rather than bolting it on,” ແລະ module ນີ້ຄືວິທີເຮັດ.

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

Pattern ມາດຕະຖານ: least privilege (ສິດຂັ້ນຕໍ່າ — ທຸກຄົນ ແລະ ທຸກໂປຣແກຣມ ໄດ້ສິດເຂົ້າເຖິງໜ້ອຍທີ່ສຸດເທົ່າທີ່ວຽກຕ້ອງການ — ກົດທອງທີ່ໃຊ້ຕັດສິນທຸກ IAM policy) · MFA ທຸກບ່ອນ, root ລັອກເກັບໄວ້ · ເຂົ້າລະຫັດຕອນເກັບ ແລະ ຕອນສົ່ງ, ເປີດຢູ່ສະເໝີ (ມັນຄືກ່ອງໝາຍຖືກໃນ cloud; ບໍ່ມີຂໍ້ອ້າງ) · network segmentation (ການແບ່ງສ່ວນເຄືອຂ່າຍ — public/private subnet, security group ເປັນ firewall ຕໍ່ server; blast radius ຂອງການລະເມີດ ຖືກນິຍາມໂດຍກຳແພງທີ່ທ່ານແຕ້ມໄວ້ລ່ວງໜ້າ) · secret ຢູ່ໃນ vault, ບໍ່ເຄີຍຢູ່ໃນໂຄດ · zero trust (ຢືນຢັນທຸກຄຳຮ້ອງຂໍຢ່າງຊັດເຈນ — ຕົວຕົນ, ອຸປະກອນ, ບໍລິບົດ — ບໍ່ໄວ້ໃຈຫຍັງພຽງເພາະມັນ “ຢູ່ໃນເຄືອຂ່າຍ”; ປະກາດວຽກລະບຸຊື່ມັນ, ທ່ານກໍຕ້ອງລະບຸ) · defense in depth (ປ້ອງກັນເປັນຊັ້ນ, ເພື່ອວ່າການຄວບຄຸມທີ່ລົ້ມເຫຼວອັນດຽວ ບໍ່ແມ່ນຈົບເກມ) · audit logging (ບັນທຶກແບບ CloudTrail ວ່າໃຜເຮັດຫຍັງ — ແກ້ໄຂບໍ່ໄດ້, ຖືກເຝົ້າຕິດຕາມ) · ຄວາມປອດໄພເປັນ guardrail, ບໍ່ແມ່ນປະຕູກັ້ນ (ເຂົ້າລະຫັດກົດເປັນ policy ອັດຕະໂນມັດ ທີ່ເຮັດໃຫ້ເສັ້ນທາງປອດໄພເປັນເສັ້ນທາງງ່າຍທີ່ສຸດ, ແທນທີ່ຈະເປັນກອງປະຊຸມທົບທວນ ທີ່ເຮັດໃຫ້ຄວາມປອດໄພກາຍເປັນສັດຕູຂອງການສົ່ງມອບ).

ຕົວຢ່າງທີ່ເຮັດໃຫ້ເບິ່ງ — ການອອກແບບ security ຂອງ ThaiTicket. ຂໍ້ມູນລູກຄ້າ (ຊື່, ອີເມວ, ເລກອ້າງອີງການຊຳລະ) ຖືກຈັດປະເພດເປັນຂໍ້ມູນສ່ວນບຸກຄົນຕາມ PDPA → ເກັບແບບເຂົ້າລະຫັດໃນ Aurora ໃນ region ບາງກອກ (data residency), ກະແຈຢູ່ໃນ KMS. ເຄືອຂ່າຍ: ມີແຕ່ load balancer ທີ່ເປັນສາທາລະນະ; ຊັ້ນ app ເປັນ private; subnet ຂອງ database ຮັບການເຊື່ອມຕໍ່ ສະເພາະ ຈາກ security group ຂອງຊັ້ນ app. ຄົນ: SSO + MFA; ວິສະວະກອນໄດ້ສິດເຂົ້າເຖິງ production ແບບອ່ານຢ່າງດຽວເປັນຄ່າມາດຕະຖານ ແລະ ໄດ້ສິດຍົກລະດັບແບບຈຳກັດເວລາເມື່ອຮ້ອງຂໍ (least privilege ພ້ອມຮ່ອງຮອຍກວດສອບ). ການຈັດການບັດຊຳລະຖືກມອບໃຫ້ຜູ້ໃຫ້ບໍລິການຊຳລະເງິນທີ່ໄດ້ຮັບການຢັ້ງຢືນ ເພື່ອວ່າເລກບັດດິບຈະບໍ່ແຕະລະບົບຂອງພວກເຮົາຈັກເທື່ອ — ການຕັດສິນໃຈ ອອກແບບ ທີ່ຕັດພາລະ compliance ທັງກ້ອນອອກໄປ, ຊຶ່ງນັ້ນຄືສະຖາປັດຕະຍະກຳຄວາມປອດໄພໃນຮູບແບບທີ່ດີທີ່ສຸດ. ເປີດ CloudTrail, ຕັ້ງແຈ້ງເຕືອນເມື່ອມີການເຂົ້າເຖິງຜິດປົກກະຕິ. ຄຳຖາມເລື່ອງການລະເມີດຖືກຕອບໄວ້ລ່ວງໜ້າ: PDPA ມີໜ້າທີ່ແຈ້ງພາຍໃນ 72 ຊົ່ວໂມງ — log ແລະ runbook ຕ້ອງເຮັດໃຫ້ພວກເຮົາເລົ່າເລື່ອງໄດ້ໃນເວລາໜ້ອຍກວ່ານັ້ນ.

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້ (ລິ້ງກວດສອບແລ້ວ): The AWS Shared Responsibility Model — Digital Cloud Training — ~4 ນາທີ — https://www.youtube.com/watch?v=ESPBBEK-cvo

ບົດຝຶກຫັດ: (1) ແຕ້ມແຜນວາດ ThaiTicket ແລ້ວວາງຊັ້ນຄວາມປອດໄພທັບ: ໝາຍທຸກຂອບເຂດຄວາມໄວ້ວາງໃຈ, ທຸກຈຸດເຂົ້າລະຫັດ, ທຸກບ່ອນທີ່ຂໍ້ມູນປະຈຳຕົວອາໄສຢູ່. ນິໄສວາງຊັ້ນທັບນີ້ — ແຜນວາດອັນເກົ່າ, ເລນສ໌ຄວາມປອດໄພ — ຄືສິ່ງທີ່ການທົບທວນຮຽກຮ້ອງຈາກທ່ານພໍດີ. (2) ອ່ານບົດ post-mortem ສາທາລະນະໜຶ່ງບົດ ກ່ຽວກັບການລະເມີດຈາກການຕັ້ງຄ່າ cloud ຜິດ (Capital One 2019 ຄືກໍລະນີສອນຄລາສສິກ) ແລ້ວຂຽນໃນປຶ້ມບັນທຶກວ່າ pattern ອັນໃດຂ້າງເທິງ ຈະປ້ອງກັນມັນໄດ້. (3) ສະແດງບົດບາດກັບ AI: ມັນເປັນຜູ້ກໍ່ຕັ້ງ startup ທີ່ເວົ້າວ່າ “ເຮົາຄ່ອຍເພີ່ມຄວາມປອດໄພທີຫຼັງ” — ຊັກຊວນເຂົາອອກຈາກຄວາມຄິດນັ້ນດ້ວຍເລກຄະນິດຂອງຕົ້ນທຶນການລະເມີດ, ຢ່າງອ່ອນໂຍນ.

Milestone: ທ່ານເອົາແຜນວາດໃດກໍໄດ້ຈາກໄລຍະທີ 1 ມາຜະລິດຊັ້ນຄວາມປອດໄພທັບໄດ້ພາຍໃນຊາວນາທີ, ແລະ ອະທິບາຍ least privilege, zero trust, ແລະ shared responsibility model ໃຫ້ຜູ້ມີສ່ວນໄດ້ເສຍທີ່ບໍ່ແມ່ນສາຍເຕັກນິກໄດ້ ໂດຍບໍ່ໃຊ້ສັບແສງ.

Module 6 (ອາທິດທີ 11–12): Performance ແລະ cost — ຄວາມໄວ ແລະ ເງິນ, ສອງເສົາທີ່ຄູ່ກັນ

ສອງເສົານີ້ຖືກສອນຄູ່ກັນ ເພາະພວກມັນຄືຄັນໂຍກອັນດຽວກັນທີ່ຖືກດັນໄປຄົນລະທາງ, ແລະ ສະຖາປະນິກຄືຄົນທີ່ມືຢູ່ເທິງຄັນໂຍກນັ້ນ.

Performance efficiency — ຄຳຖາມຫຼັກ: ຜູ້ໃຊ້ຈະຮູ້ສຶກເຖິງຄວາມຊ້າຢູ່ໃສກ່ອນ? ຫຍັງຖືກຄິດໄລ່ຊ້ຳໆ ທັງທີ່ຄິດເທື່ອດຽວແລ້ວ cache ໄວ້ໄດ້? ແຕ່ລະສ່ວນປະກອບເປັນ ເຄື່ອງມືທີ່ຖືກຕ້ອງ ບໍ (SQL ທີ່ເຮັດວຽກຂອງ search engine ຄື bug ປະສິດທິພາບຂອງສະຖາປັດຕະຍະກຳ, ບໍ່ແມ່ນຂອງໂຄດ)? ປະສິດທິພາບປ່ຽນແນວໃດທີ່ 10× — ແລະ ຄໍຂວດອັນທຳອິດຢູ່ໃສ?

Pattern ດ້ານ performance: ຊັ້ນ caching — pattern ປະສິດທິພາບທີ່ໃຫ້ຜົນຄຸ້ມທີ່ສຸດອັນດຽວ: browser cache → CDN ທີ່ຂອບ (ເນື້ອຫາ static ຖືກສົ່ງຈາກເມືອງໃກ້ຜູ້ໃຊ້; ດູດຊັບ traffic ອ່ານສ່ວນໃຫຍ່ໄດ້) → application cache (Redis ວາງໜ້າ database ສຳລັບການອ່ານ hot: ແຜນຜັງບ່ອນນັ່ງ, session, ໜ້າສິນຄ້າ) → database query cache. ແຕ່ລະຊັ້ນຕອບຄຳຮ້ອງຂໍກ່ອນມັນຈະໄປເຖິງແກນທີ່ແພງ; ຄຳຖາມການອອກແບບຄືສະເໝີວ່າ ຫຍັງ cache ໄດ້, ດົນປານໃດ, ແລະ ຈະ invalidate ແນວໃດເມື່ອຄວາມຈິງປ່ຽນ. ຈາກນັ້ນ: read replica (ສຳເນົາ database ທີ່ບໍລິການການອ່ານ ເພື່ອໃຫ້ primary ຍັງຂຽນຕໍ່ໄດ້) · asynchronous processing (ຢ່າໃຫ້ຜູ້ໃຊ້ລໍວຽກທີ່ເຮັດພາຍຫຼັງໄດ້ — ໃບຮັບທາງອີເມວ, ຮູບຫຍໍ້, ລາຍງານ) · ເຄື່ອງມືທີ່ຖືກຕ້ອງຕໍ່ວຽກ (ຄົ້ນຫາ → search engine; ວິເຄາະ → warehouse; ການເບິ່ງຄ່າ hot → key-value store) · ແລະ ວັດແທກກ່ອນ (ວຽກປະສິດທິພາບໂດຍບໍ່ວັດແທກ ຄືຄວາມເຊື່ອງົມງວາຍ).

Cost optimization — ຄຳຖາມຫຼັກ: ການອອກແບບນີ້ມີຄ່າໃຊ້ຈ່າຍເດືອນລະເທົ່າໃດທີ່ໂຫຼດປັດຈຸບັນ — ແລະ ຕໍ່ ຫົວໜ່ວຍ (ຕໍ່ຄຳສັ່ງຊື້, ຕໍ່ລູກຄ້າ)? ຫຍັງແລ່ນຢູ່ຕອນຕີສາມທັງທີ່ບໍ່ຈຳເປັນ? ການໃຊ້ງານຄົງທີ່ອັນໃດຜູກມັດເພື່ອຮັບສ່ວນຫຼຸດໄດ້? ຝ່າຍການເງິນຈະບອກວ່າແນວໂນ້ມເປັນແນວໃດ?

Pattern ດ້ານຕົ້ນທຶນ: rightsizing (ຝູງເຄື່ອງສ່ວນໃຫຍ່ຖືກຈັດຊັບພະຍາກອນເກີນຢ່າງງຽບໆ; ຫຍໍ້ລົງໃຫ້ພໍດີກັບຄວາມຕ້ອງການທີ່ວັດແທກໄດ້ ຄືເງິນຟຣີ) · ຍຸດທະສາດການຈອງ — ເມນູລາຄາ: on-demand (ລາຄາເຕັມ, ອິດສະຫຼະເຕັມ) ສຳລັບໂຫຼດພຸ່ງ/ຄາດເດົາບໍ່ໄດ້, reserved instance / savings plan (ຜູກມັດ 1–3 ປີ, ຫຼຸດ 30–70%) ສຳລັບຖານໂຫຼດຄົງທີ່, spot (ຫຼຸດເຖິງ 90%, ຖືກຮຽກຄືນໄດ້ໃນເວລາອັນສັ້ນ) ສຳລັບວຽກ batch ທີ່ຂັດຈັງຫວະໄດ້; ທ່າຂອງສະຖາປະນິກຄືວາງເປັນຊັ້ນ: ຈອງພື້ນ, auto-scale ຊັ້ນກາງແບບ on-demand, ໃຊ້ spot ກັບ batch · storage lifecycle (ການແບ່ງຂັ້ນຂອງ Module 2, ແບບອັດຕະໂນມັດ) · ປິດສິ່ງທີ່ບໍ່ໃຊ້ (ສະພາບແວດລ້ອມທີ່ບໍ່ແມ່ນ production ຫຼັບກາງຄືນ ແລະ ວັນພັກ ຫຼຸດຄ່າໃຊ້ຈ່າຍໄດ້ສອງສ່ວນສາມ) · ເຝົ້າ egress (ຂໍ້ມູນທີ່ ອອກ ຈາກ cloud ຖືກຄິດເງິນ; ການອອກແບບຂ້າມ region ທີ່ຄຸຍກັນຫຼາຍ ແລະ ການດາວໂຫຼດສາທາລະນະຂະໜາດໃຫຍ່ ເຮັດໃຫ້ທຸກຄົນຕົກໃຈຢ່າງໜ້ອຍເທື່ອໜຶ່ງ) · tagging ແລະ showback (ທຸກຊັບພະຍາກອນຖືກຕິດປ້າຍເຈົ້າຂອງ/ໂຄງການ ເພື່ອໃຫ້ທຸກບາດລະບຸທີ່ມາໄດ້) · ແລະ ຕົວຊີ້ວັດມົງກຸດ, unit economics (ເສດຖະສາດຕໍ່ຫົວໜ່ວຍ): ບໍ່ແມ່ນ “ໃບບິນ ฿800k/ເດືອນ” ແຕ່ “ຕົ້ນທຶນຕໍ່ປີ້ທີ່ຂາຍໄດ້ ฿1.90 ແລະ ກຳລັງຫຼຸດລົງ.” ໃບບິນທີ່ໃຫຍ່ຂຶ້ນນັ້ນບໍ່ເປັນຫຍັງ; ຕົ້ນທຶນຕໍ່ຫົວໜ່ວຍ ທີ່ໃຫຍ່ຂຶ້ນຕ່າງຫາກຄືກິ່ນຜິດປົກກະຕິຂອງສະຖາປັດຕະຍະກຳ. ວິໄນນີ້ມີຊື່ — FinOps — ແລະ ສະຖາປະນິກນັ່ງຢູ່ໃຈກາງຂອງມັນ.

ຕົວຢ່າງທີ່ເຮັດໃຫ້ເບິ່ງ — ThaiTicket, ທັງສອງເລນສ໌. Performance: CloudFront ບໍລິການໜ້າສິນລະປິນ ແລະ ຮູບແຜນຜັງບ່ອນນັ່ງ (ຄົນເບິ່ງ 400,000 ຄົນສ່ວນໃຫຍ່ບໍ່ເຄີຍແຕະ server ເລີຍ); Redis cache ຄວາມພ້ອມຂອງບ່ອນນັ່ງດ້ວຍ TTL 2 ວິນາທີ — ເກົ່າພໍທີ່ຈະຖືກ, ສົດພໍທີ່ການຊຳລະເງິນ (ຊຶ່ງກວດຊ້ຳກັບ Aurora, ແຫຼ່ງຄວາມຈິງ) ຈະປ້ອງກັນການຂາຍຊ້ຳ; ໃບຮັບ ແລະ ປີ້ຖືກສ້າງແບບ asynchronous ຫຼັງການຊຳລະ. ຕົ້ນທຶນ: ຖານໂຫຼດຄົງທີ່ 2,000 ຄົນ/ຊົ່ວໂມງ ແລ່ນເທິງ savings plan (≈ຫຼຸດ 40%); ຊ່ວງເປີດຂາຍພຸ່ງ ແລ່ນແບບ on-demand ສະເພາະຊົ່ວໂມງທີ່ມັນມີ; ວຽກວິເຄາະແລ່ນເທິງ spot ຕອນກາງຄືນ; staging ຫຼັບນອກເວລາລັດຖະການ; ທຸກຊັບພະຍາກອນຕິດປ້າຍ project:thaiticket. ຂໍ້ສະເໜີເຖິງ CFO ອ່ານວ່າ: “฿62,000/ເດືອນ ເປັນຖານ, ≈฿9,000 ຕໍ່ເຫດການເປີດຂາຍໃຫຍ່ໜຶ່ງຄັ້ງ, ຕົ້ນທຶນຕໍ່ປີ້ ≈฿1.90 ຫຼຸດລົງຕາມປະລິມານ” — ແລະ ປະໂຫຍກນັ້ນເອງ ຄືສຽງຂອງສະຖາປະນິກທີ່ຄ່ອງເລື່ອງຕົ້ນທຶນ.

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້ (ລິ້ງກວດສອບແລ້ວ): What is FinOps? — FinOps Foundation (ທາງການ) — ~2 ນາທີ — https://www.youtube.com/watch?v=Y-c_xw9bHFw

ບົດຝຶກຫັດ: (1) ຄິດລາຄາຖານຂອງ ThaiTicket ໃນ AWS pricing calculator (ຄົ້ນຫາ “AWS pricing calculator” — ບົດຝຶກແຈກແຈງລາຍການຂອງການອອກແບບຈິງເທື່ອດຽວ ຈະຄາຍຄວາມລຶກລັບຂອງທຸກບົດສົນທະນາເລື່ອງຕົ້ນທຶນໃນອະນາຄົດ); ທຽບຍອດລວມຂອງທ່ານກັບ ฿62,000 ຂ້າງເທິງ ແລ້ວອະທິບາຍຊ່ອງວ່າງ. (2) ເພີ່ມຊັ້ນ caching ທັບໃສ່ສອງແຜນວາດຈາກໄລຍະທີ 1: ໝາຍທຸກ cache, TTL ຂອງມັນ, ແລະ ເລື່ອງລາວການ invalidate ຂອງມັນ. (3) AI ສະແດງເປັນວິສະວະກອນທີ່ຢາກໃຫ້ທຸກຢ່າງເປັນ on-demand “ເພື່ອໃຫ້ງ່າຍ” — ເຈລະຈາຍຸດທະສາດການຈອງ, ພ້ອມຕົວເລກ.

Milestone: ສຳລັບການອອກແບບໃດກໍໄດ້ທີ່ທ່ານແຕ້ມ, ທ່ານບອກລາຍການຕົ້ນທຶນສາມອັນໃຫຍ່ທີ່ສຸດ ແລະ ຄໍຂວດອັນທຳອິດທີ່ເປັນໄປໄດ້ຂອງມັນ — ແລະ ສະເໜີການປ່ຽນແປງໜຶ່ງຢ່າງທີ່ປັບປຸງທັງສອງພ້ອມກັນ (ເກືອບສະເໝີມີໜຶ່ງ; ປົກກະຕິແມ່ນ caching).

Module 7 (ອາທິດທີ 13–14): Operational excellence, sustainability — ແລະ ການແລ່ນທັງຫົກເສົາພ້ອມກັນ

Operational excellence ຄືເສົາທີ່ຖາມວ່າ: ຄົນແລ່ນສິ່ງນີ້ໄດ້ຈິງບໍ, ຢ່າງສະຫງົບ? ຄຳຖາມຫຼັກ: ການປ່ຽນແປງໄປເຖິງ production ແນວໃດ — ຜ່ານ pipeline ອັດຕະໂນມັດທີ່ຖືກທົດສອບ, ຫຼື ຜ່ານວິລະບຸລຸດທີ່ເປັນຄົນ? ພວກເຮົາຮູ້ໄດ້ແນວໃດວ່າລະບົບແຂງແຮງ ຢູ່ຕອນນີ້? ເມື່ອມັນພັງຕອນຕີສາມ, ວິສະວະກອນເວນ on-call ເຮັດຫຍັງແທ້? Pattern: infrastructure as code (ສະພາບແວດລ້ອມຖືກນິຍາມເປັນຂໍ້ຄວາມທີ່ຖືກທົບທວນ ແລະ ຄວບຄຸມເວີຊັນ — Terraform/CloudFormation — ເພື່ອໃຫ້ມັນສ້າງຄືນໄດ້ ແລະ ກວດສອບໄດ້; ສະຖາປັດຕະຍະກຳທີ່ມີຢູ່ພຽງໃນຮູບການຄລິກ console ຄືນິທານພື້ນບ້ານ, ບໍ່ແມ່ນວິສະວະກຳ) · CI/CD pipeline ພ້ອມຍຸດທະສາດ deploy ທີ່ປອດໄພ (blue-green: ຕັ້ງເວີຊັນໃໝ່ຂຶ້ນຂ້າງເວີຊັນເກົ່າແລ້ວສະຫຼັບ; canary: ໃຫ້ເວີຊັນໃໝ່ຮັບ traffic 5% ແລ້ວເຝົ້າເບິ່ງ) · observability (log, metric, trace, ແລະ ການແຈ້ງເຕືອນທີ່ຜູກກັບອາການທີ່ ຜູ້ໃຊ້ເຫັນ, ບໍ່ແມ່ນເລື່ອງຫຍຸບຫຍັບຂອງເຄື່ອງ) · runbook (ຄູ່ມືລາຍລັກອັກສອນວ່າຕ້ອງເຮັດຫຍັງ ສຳລັບແຕ່ລະຄວາມລົ້ມເຫຼວທີ່ຮູ້ຈັກ) · blameless post-mortem (ຫຼັງເຫດການ: ຫຍັງລົ້ມເຫຼວ, ເປັນຫຍັງ, ຫຍັງປ້ອງກັນການເກີດຊ້ຳ — ບໍ່ມີຜູ້ຮ້າຍ, ບໍ່ດັ່ງນັ້ນຄົນຈະເຊົາເວົ້າຄວາມຈິງ). ສ່ວນຂອງສະຖາປະນິກ: ອອກແບບ ເພື່ອຄວາມສາມາດໃນການປະຕິບັດງານ — ລະບົບທີ່ສະຫຼາດເປັນສອງເທົ່າ ແຕ່ສັງເກດເຫັນໄດ້ເຄິ່ງດຽວ ຄືລະບົບທີ່ແຍ່ກວ່າ.

Sustainability, ເສົາທີຫົກ, ຮຽກຮ້ອງໃຫ້ທ່ານສິ້ນເປືອງໂລກກາຍະພາບໜ້ອຍລົງ: rightsize (CPU ທີ່ຫວ່າງເຜົາໄຟຟ້າຈິງ), ຂະຫຍາຍຕາມຄວາມຕ້ອງການແທນການຈັດຊັບພະຍາກອນຕາມຈຸດສູງສຸດ, ໃຊ້ບໍລິການ managed ແລະ serverless (ໂຄງສ້າງພື້ນຖານທີ່ແບ່ງປັນຄືໂຄງສ້າງພື້ນຖານທີ່ເຕັມກວ່າ), ແບ່ງຂັ້ນ storage, ແລະ ລຶບສິ່ງທີ່ຕາຍແລ້ວ. ສະດວກດີ, ທາງເລືອກທີ່ຍືນຍົງ ແລະ ທາງເລືອກທີ່ຖືກ ປົກກະຕິແມ່ນທາງເລືອກອັນດຽວກັນ — ເວົ້າທັງສອງໃນການທົບທວນ ແລ້ວທ່ານຈະຄອງຫ້ອງໄດ້ສອງເທົ່າ.

ການແລ່ນເສົາທັງໝົດພ້ອມກັນ — Well-Architected review ຄັ້ງທຳອິດຂອງທ່ານ. ໃນການທົບທວນຕົວຈິງ ເສົາຫຼັກ ຂັດແຍ້ງກັນ: ຄວາມໜ້າເຊື່ອຖືແບບ multi-region ຕີກັບຕົ້ນທຶນ; ການທົບທວນຄວາມປອດໄພທີ່ເຄັ່ງຄັດຕີກັບຄວາມໄວໃນການປະຕິບັດງານ; caching ເພື່ອປະສິດທິພາບຕີກັບຄວາມຖືກຕ້ອງຂອງຄວາມສົດຂອງຂໍ້ມູນ. Framework ບໍ່ໄດ້ແກ້ຂໍ້ຂັດແຍ້ງໃຫ້ທ່ານ — ມັນບັງຄັບໃຫ້ພວກມັນອອກມາຢູ່ທີ່ແຈ້ງ, ບ່ອນທີ່ຝ່າຍທຸລະກິດເລືອກໄດ້. ນັ້ນຄືອັດສະລິຍະພາບທັງໝົດຂອງມັນ, ແລະ ເປັນອາວຸດຂອງທ່ານ. ຕົວວິທີການທົບທວນເອງ (ຊຸດຄຳຖາມ, ການຈັດລຳດັບຄວາມສຳຄັນຂອງສິ່ງທີ່ພົບ, ບົດລາຍງານ) ຖືກສອນເຕັມຮູບແບບໃນໄລຍະທີ 5, Module 12; ສອງອາທິດນີ້ທ່ານຊ້ອມທັກສະດິບ: ການສອບຖາມການອອກແບບອັນດຽວຈາກຫົກທິດທາງ ໃນການນັ່ງເທື່ອດຽວ.

ຄຳສັບ:

ບົດຝຶກຫັດ: (1) ບົດຝຶກຫົກເລນສ໌: ເອົາແຜນວາດທີ່ດີທີ່ສຸດຂອງທ່ານ ແລ້ວໃຊ້ເວລາສິບນາທີຕໍ່ເສົາຂຽນສິ່ງທີ່ພົບ — ຫົກສິບນາທີ, ໜຶ່ງການອອກແບບ, ຫົກເລນສ໌; ບົດຝຶກນີ້ ຄື ໄລຍະທີ 2 ແບບຫຍໍ້, ເຮັດຊ້ຳທຸກອາທິດຈາກນີ້ໄປ. (2) ອ່ານບົດລາຍງານຫຼັງເຫດການຂອງ AWS ສອງບົດ (ຕີພິມເທິງໜ້າ status ຫຼັງເຫດຂັດຂ້ອງໃຫຍ່) ແລ້ວລະບຸວ່າ pattern ຂອງເສົາໃດລົ້ມເຫຼວ. (3) ປຶ້ມບັນທຶກ: ສຳລັບ ThaiTicket, ຂຽນຂໍ້ຂັດແຍ້ງລະຫວ່າງເສົາສາມຂໍ້ທີ່ທ່ານຈະຍົກຂຶ້ນໃຫ້ຝ່າຍທຸລະກິດ, ແຕ່ລະຂໍ້ເປັນທາງເລືອກໜຶ່ງປະໂຫຍກ (“ດ້ວຍງົບນີ້ ເຮົາໄດ້ X ຫຼື Y — ເອົາອັນໃດ?”).

Milestone — ຈົບໄລຍະທີ 2: ການທົບທວນຈຳລອງ: AI ສ້າງສະຖາປັດຕະຍະກຳທີ່ມີຂໍ້ບົກຜ່ອງໃຫ້ startup ສິນເຊື່ອອອນລາຍຂອງໄທ; ທ່ານຕ້ອງຜະລິດສິ່ງທີ່ພົບເປັນລາຍລັກອັກສອນຄົບທັງຫົກເສົາ, ລວມຢ່າງໜ້ອຍ: ຊ່ອງວ່າງດ້ານ reliability (database ຂອງເຂົາຢູ່ AZ ດຽວ), ຊ່ອງວ່າງດ້ານ security (IAM ກວ້າງເກີນ), ຊ່ອງວ່າງດ້ານຕົ້ນທຶນ (ທຸກຢ່າງເປັນ on-demand), ຊ່ອງວ່າງດ້ານປະຕິບັດການ (ບໍ່ມີ IaC), ແລະ ບົດສົນທະນາ RTO/RPO ທີ່ເຂົາບໍ່ເຄີຍມີ — ແຕ່ລະຂໍ້ຄົ້ນພົບຖືກຮຽບຮຽງເປັນຄຳຖາມທີ່ເພື່ອນຮ່ວມງານຟັງໄດ້ໂດຍບໍ່ຫົດຫູ່. ເມື່ອລາຍການສິ່ງທີ່ພົບຂອງທ່ານອ່ານແລ້ວຄືເພື່ອນຮ່ວມງານອາວຸໂສທີ່ຢາກຊ່ວຍ ແທນທີ່ຈະຄືຜູ້ກວດສອບ, ໄລຍະທີ 2 ຈົບແລ້ວ.

ໄລຍະທີ 3 — ຄັງລວມ pattern (ອາທິດທີ 15–20)

ສະຖາປະນິກບໍ່ປະດິດ; ພວກເຂົາ ເລືອກ. ໄລຍະນີ້ຄືຄັງລວມສະຖາປັດຕະຍະກຳມາດຕະຖານຂອງທ່ານ — ສຳລັບແຕ່ລະອັນ: ມັນແມ່ນຫຍັງ, ໃຊ້ເມື່ອໃດ, ບໍ່ ໃຊ້ເມື່ອໃດ, ແລະ ໂປຣໄຟລ໌ຕົ້ນທຶນ/ຄວາມຊັບຊ້ອນຂອງມັນ. ຖັນ “ເມື່ອໃດບໍ່ຄວນໃຊ້” ຄືເນື້ອແທ້ຂອງໄລຍະນີ້: ຫຼັກສູດໃດກໍບອກທ່ານໄດ້ວ່າ microservices ແມ່ນຫຍັງ; ການຮູ້ວ່າເມື່ອໃດພວກມັນຈະທຳລາຍບໍລິສັດ ຄືສິ່ງທີ່ທ່ານໄດ້ຄ່າຈ້າງ. ຂະນະຮຽນ, ໃຫ້ທ່ອງ reference architecture ຈິງຢູ່ https://aws.amazon.com/architecture/ ຕໍ່ໄປ — ການສັງເກດ pattern ໃນທຳມະຊາດ ຄືບົດຝຶກທີ່ເຮັດໃຫ້ຄັງລວມນີ້ຕິດແໜ້ນ.

Module 8 (ອາທິດທີ 15–17): Pattern ຂອງແອັບພລິເຄຊັນ

Monolith ທຽບ microservices — ການຖຽງທີ່ດັງທີ່ສຸດຂອງວົງການ, ຕັດສິນຢ່າງສະຫງົບ. Monolith ຄືແອັບພລິເຄຊັນ deploy ໄດ້ອັນດຽວ ທີ່ບັນຈຸທຸກຄຸນສົມບັດ; microservices ແຍກລະບົບເປັນ service ນ້ອຍຫຼາຍອັນ ທີ່ deploy ອິດສະຫຼະ, ແຕ່ລະອັນເປັນເຈົ້າຂອງຂໍ້ມູນຕົນເອງ, ເວົ້າກັນຜ່ານ API ແລະ event. ຕາຕະລາງແບບຊື່ສັດ:

ຄຳຕັດສິນຂອງສະຖາປະນິກ: ເລີ່ມແບບ monolithic, ແຕ່ເປັນ module ຢູ່ພາຍໃນ; ແຍກ service ອອກເມື່ອ — ແລະ ສະເພາະເມື່ອ — ຄວາມເຈັບປວດຈາກການຂະຫຍາຍທີມ ຫຼື ການຂະຫຍາຍໂຫຼດມາເຖິງແທ້ໆ. ການເວົ້າສິ່ງນີ້ໃນການສຳພາດ, ພ້ອມເຫດຜົນ, ບົ່ງບອກວ່າທ່ານເປັນຜູ້ອາວຸໂສ; ອຸດົມການໄປທາງໃດທາງໜຶ່ງ ບົ່ງບອກວ່າທ່ານເປັນຜູ້ນ້ອຍ.

Event-driven architecture — queue ແລະ topic, ຕົວດູດແຮງກະແທກ. ແທນທີ່ສ່ວນປະກອບຈະເອີ້ນຫາກັນແລ້ວ ລໍຖ້າ (synchronous), ສ່ວນປະກອບເຜີຍແຜ່ event (“OrderPlaced”) ໄປຫາ queue (SQS — ຜູ້ບໍລິໂພກຄົນດຽວຮັບແຕ່ລະຂໍ້ຄວາມ, ຕາມຈັງຫວະຂອງຕົນ) ຫຼື topic (SNS — ທຸກຜູ້ສະໝັກຮັບໄດ້ສຳເນົາ; fan-out). ຜູ້ຜະລິດບໍ່ຮູ້ ແລະ ບໍ່ສົນວ່າໃຜກຳລັງຟັງ. ໃຊ້ເມື່ອ: ສ່ວນປະກອບຄວນຢູ່ລອດການຂັດຂ້ອງຂອງກັນ ແລະ ກັນ (queue ຖືຂໍ້ຄວາມໄວ້ຂະນະຜູ້ບໍລິໂພກລົ້ມ — ໄດ້ທັງຄວາມທົນທານ ແລະ ການແຍກຂາດຈາກກັນໃນການຊື້ຄັ້ງດຽວ); ໂຫຼດພຸ່ງເປັນຊ່ວງ (queue ດູດຊັບການພຸ່ງ; worker ຄ່ອຍໆລະບາຍມັນ); ເຫດການໜຶ່ງກະຕຸ້ນປະຕິກິລິຍາຫຼາຍຢ່າງ (ສັ່ງຊື້ແລ້ວ → ຫັກເງິນ, ອີເມວ, ສາງ, ວິເຄາະ — ສີ່ຜູ້ສະໝັກຮັບ, ຜູກຕິດເປັນສູນ). ຫ້າມໃຊ້ເມື່ອ: ຜູ້ໃຊ້ຕ້ອງການຄຳຕອບ ດຽວນີ້ (ການຊຳລະເງິນຈະ “ຄ່ອຍ” ຢືນຢັນບໍ່ໄດ້); ຫຼື ທີມນ້ອຍ ແລະ ການເອີ້ນແບບ synchronous ງ່າຍໆກໍພຽງພໍ — ທຸກ queue ເພີ່ມ semantics ຂອງການສົ່ງມອບ (at-least-once ໝາຍວ່າຜູ້ບໍລິໂພກຕ້ອງ idempotent — ແລ່ນສອງເທື່ອກໍປອດໄພ), ການຈັດການ dead-letter, ແລະ ພາລະການເຝົ້າຕິດຕາມ. ຕົ້ນທຶນ/ຄວາມຊັບຊ້ອນ: ສ່ວນປະກອບຖືກ, ການ debug ແພງກວ່າ — ເລື່ອງລາວຂອງຄຳຮ້ອງຂໍໜຶ່ງອັນ ຕອນນີ້ກະຈາຍຢູ່ຕາມ service ແລະ queue, ຊຶ່ງເປັນເຫດຜົນວ່າ observability (Module 7) ເຊົາເປັນທາງເລືອກຢູ່ຈຸດນີ້.

Three-tier: ເປັນຂອງທ່ານແລ້ວ (Module 3). ໃຊ້ສຳລັບ: ໃຈກາງອັນກວ້າງຂອງແອັບພລິເຄຊັນເວັບ — ມັນຄື pattern ທີ່ອັນອື່ນຖືກວັດທຽບກັບ. ບໍ່ໃຊ້ສຳລັບ: workload ທີ່ພຸ່ງແຮງພ້ອມຮ່ອງເວລາຫວ່າງ (serverless ຖືກກວ່າ) ຫຼື ຜະລິດຕະພັນຫຼາຍທີມທີ່ໃຫຍ່ແທ້ (ເບິ່ງຂ້າງເທິງ). ໂປຣໄຟລ໌: ເຂົ້າໃຈກັນດີທຸກບ່ອນ, ຈ້າງຄົນງ່າຍ, ຕົ້ນທຶນປານກາງ.

Serverless-first: ປະກອບຊິ້ນສ່ວນ managed — API Gateway → Lambda function → DynamoDB, S3, ແລະ queue — ໂດຍບໍ່ເປັນເຈົ້າຂອງ server ເລີຍ. ໃຊ້ເມື່ອ: traffic ພຸ່ງເປັນຊ່ວງ ຫຼື ຕໍ່າ (scale-to-zero ໝາຍວ່າຕົ້ນທຶນຕອນຫວ່າງ ~ບໍ່ມີ), ທີມນ້ອຍ, ຕ້ອງອອກຕະຫຼາດໄວ, ກາວເຊື່ອມແບບ event-driven. ຫ້າມໃຊ້ເມື່ອ: compute ທີ່ແລ່ນດົນ ຫຼື ສະເພາະທາງ (ຂໍ້ຈຳກັດ runtime), ເສັ້ນທາງທີ່ອ່ອນໄຫວຕໍ່ latency ສຸດຂີດ (cold start), ໂຫຼດ ຄົງທີ່ ຂະໜາດມະຫາສານ (ລາຄາຕໍ່ການເອີ້ນ ອາດເກີນ server ທີ່ຈອງໄວ້ — ຄິດເລກທີ່ຂະໜາດຈິງ), ຫຼື ເມື່ອຄວາມເຄື່ອນຍ້າຍໄດ້ລະຫວ່າງ cloud ເປັນຂໍ້ກຳນົດແທ້ (ນີ້ຄື lock-in ທີ່ເລິກທີ່ສຸດໃນບັນດາ pattern — ມັກຄຸ້ມ, ແຕ່ໃຫ້ເວົ້າອອກມາດັງໆ). ໂປຣໄຟລ໌: ພາລະປະຕິບັດການຕໍ່າທີ່ສຸດໃນຄັງລວມ; ຕົ້ນທຶນຍອດຢ້ຽມທີ່ຂະໜາດຕໍ່າ/ພຸ່ງເປັນຊ່ວງ, ຕ້ອງກວດທີ່ຂະໜາດຄົງທີ່ສູງ.

ຄຳສັບ:

ບົດຝຶກຫັດ: (1) ອອກແບບກະແສຄຳສັ່ງຊື້ຂອງ ThaiTicket ສອງເທື່ອ — ແບບ synchronous three-tier, ແລ້ວແບບ event-driven ດ້ວຍ SQS/SNS — ແລ້ວຂຽນໜຶ່ງວັກວ່າແຕ່ລະສະບັບເຮັດຫຍັງເມື່ອຜູ້ໃຫ້ບໍລິການຊຳລະເງິນຂັດຂ້ອງ; ວັກນັ້ນຄືເຫດຜົນທັງໝົດຂອງ event. (2) ສຳລັບສີ່ບໍລິສັດ (startup 3 ຄົນ, scale-up ວິສະວະກອນ 50 ຄົນ, ທະນາຄານ, ແອັບໂຫວດລາຍການໂທລະທັດທີ່ໃຊ້ 4 ຄືນຕໍ່ປີ), ເລືອກ pattern ແລ້ວປົກປ້ອງມັນ — ຈາກນັ້ນບອກຊື່ຕົວກະຕຸ້ນທີ່ຈະເຮັດໃຫ້ແຕ່ລະບໍລິສັດປ່ຽນ pattern. (3) ຊອກຫາເລື່ອງຈາກບຼັອກວິສະວະກຳຈິງໜຶ່ງເລື່ອງແບບ “ພວກເຮົາຍ້າຍໄປ microservices ແລ້ວເສຍໃຈ” ແລະ ອີກເລື່ອງທີ່ສຳເລັດ; ບັນທຶກຄວາມຕ່າງ (ເກືອບສະເໝີແມ່ນຂະໜາດທີມ ແລະ ຄວາມເປັນຜູ້ໃຫຍ່ຂອງ domain).

Milestone: ເມື່ອໄດ້ຄຳບັນຍາຍບໍລິສັດ, ທ່ານແນະນຳ pattern ພ້ອມທາງອອກຂອງມັນ ໄດ້ — “ເລີ່ມທີ່ນີ້; ເມື່ອ X ເກີດຂຶ້ນ, ວິວັດໄປສູ່ Y” — ພາຍໃນຫ້ານາທີ. ເສັ້ນທາງວິວັດ, ບໍ່ແມ່ນຄຳຕັດສິນ, ຄືວິທີທີ່ສະຖາປະນິກເວົ້າກັນຈິງ.

Module 9 (ອາທິດທີ 18–20): Pattern ດ້ານຂໍ້ມູນ, ທົ່ວໂລກ, ແລະ hybrid

ສະຖາປັດຕະຍະກຳຂໍ້ມູນ — lake ທຽບ warehouse. Database ແບບທຸລະກຳ (ໄລຍະທີ 1) ດຳເນີນທຸລະກິດ; ການວິເຄາະຢາກ ຖາມຄຳຖາມ ຕໍ່ມັນ ໂດຍບໍ່ເຮັດໃຫ້ມັນຊ້າ. Data warehouse (Redshift, Snowflake, BigQuery) ເກັບຂໍ້ມູນ ທີ່ມີໂຄງສ້າງ, ທຳຄວາມສະອາດແລ້ວ ປັບແຕ່ງມາເພື່ອການວິເຄາະ SQL ໄວ — ໃຊ້ເມື່ອຮູ້ຄຳຖາມແລ້ວ ແລະ dashboard ຕ້ອງໄວ; ແພງກວ່າຕໍ່ TB, ຕ້ອງມີວິໄນການສ້າງແບບຈຳລອງແຕ່ຕົ້ນ. Data lake (S3 + catalog + query engine ເຊັ່ນ Athena) ເກັບ ທຸກຢ່າງ, ດິບ, ຖືກ — log, clickstream, ຮູບ — ແລ້ວໃສ່ໂຄງສ້າງຕອນອ່ານ; ໃຊ້ເມື່ອທ່ານຢາກເກັບທຸກຢ່າງໄວ້ກ່ອນ ແລ້ວຄ່ອຍຕັດສິນຄຳຖາມພາຍຫຼັງ; ແຕ່ຖ້າບໍ່ມີການກຳກັບ ມັນຈະເສື່ອມເປັນເລື່ອງຕະຫຼົກຂອງວົງການ, data swamp (ໜອງຂໍ້ມູນ). ຂໍ້ສະຫຼຸບຮ່ວມສະໄໝແມ່ນເອົາທັງສອງ, ວາງເປັນຊັ້ນ (“lakehouse”): ຄວາມຈິງດິບຢູ່ໃນ lake, mart ທີ່ຄັດສັນຢູ່ໃນ warehouse, ປ້ອນໂດຍ ETL/ELT pipeline. ກົດຂອງສະຖາປະນິກ: ການວິເຄາະບໍ່ query database production ຈັກເທື່ອ (replica ຫຼື pipeline ເປັນຜູ້ປ້ອນ), ແລະ ທຸກຊຸດຂໍ້ມູນມີເຈົ້າຂອງ, ມີລາຍການໃນ catalog, ແລະ ມີນະໂຍບາຍການເກັບຮັກສາ — ແຖວການກຳກັບນັ້ນຄືໜຶ່ງປະໂຫຍກໃນການອອກແບບຂອງທ່ານ ແລະ ຄືຄວາມເຈັບປວດໜຶ່ງປີຖ້າທ່ານລືມມັນ.

Multi-region: active-passive ທຽບ active-active. ເມື່ອ region ດຽວບໍ່ພຽງພໍ — ເພາະທຸລະກິດຮຽກຮ້ອງ DR ຈາກໄພພິບັດລະດັບ region, ຫຼື ຜູ້ໃຊ້ກະຈາຍຢູ່ຫຼາຍທະວີບ — ທ່ານເລືອກ:

ປະໂຫຍກລະດັບສຳພາດ: “Multi-AZ is table stakes; multi-region is a business case.” (Multi-AZ ຄືເງື່ອນໄຂພື້ນຖານ; multi-region ຄືກໍລະນີທາງທຸລະກິດ.) ໃຫ້ຝ່າຍທຸລະກິດລະບຸ RTO/RPO, ຕີລາຄາທາງເລືອກ, ແລ້ວປ່ອຍໃຫ້ຕົວເລກເປັນຜູ້ເລືອກ.

Hybrid cloud. ສ່ວນໜຶ່ງ on-prem, ສ່ວນໜຶ່ງ cloud, ເຊື່ອມກັນດ້ວຍ VPN ຫຼື Direct Connect — ສຳລັບວິສາຫະກິດທີ່ຕັ້ງໝັ້ນແລ້ວສ່ວນໃຫຍ່ ນີ້ບໍ່ແມ່ນ pattern ແຕ່ເປັນ ຄວາມເປັນຈິງທີ່ຍາວເປັນທົດສະວັດ: mainframe ທີ່ຍ້າຍບໍ່ໄດ້, ລະບົບໂຮງງານທີ່ຜູກກັບ latency, ຂໍ້ມູນທີ່ຖືກກຳກັບໃຫ້ປັກຢູ່ on-prem, ແລະ ການ migrate (ໄລຍະທີ 4) ທີ່ກຳລັງຜ່ານໄປ. ໃຊ້ໃນຖານະ: ຂົວທີ່ຈົງໃຈ ພ້ອມທິດທາງການເດີນທາງ. ຫ້າມຍອມຮັບ: “hybrid” ໃນຄວາມໝາຍອ້ອມຄ້ອມວ່າ “ພວກເຮົາບໍ່ເຄີຍຕັດສິນໃຈ.” ບັນທຶກການອອກແບບ: ຕົວຕົນຕ້ອງເປັນອັນດຽວກັນກ່ອນ (login ດຽວຂ້າມທັງສອງໂລກ — ນີ້ຄືສິ່ງທີ່ປະກາດວຽກວິສາຫະກິດໝາຍເຖິງດ້ວຍຄຳວ່າ “hybrid identity integration”); ລະບຸວ່າລະບົບໃດເປັນແຫຼ່ງຄວາມຈິງ; ເຝົ້າຕົ້ນທຶນ egress ຂ້າມສາຍ; ແລະ ຄາດໄວ້ວ່າສາຍເຊື່ອມຕໍ່ ຄື SPOF ເວັ້ນແຕ່ຈະມີສອງເສັ້ນ. ຄວາມຊັບຊ້ອນ: ທຸກຢ່າງເປັນສອງກອງມູນ — ນັ້ນຄືເຫດຜົນຊື່ສັດວ່າເປັນຫຍັງສະຖາປະນິກຈຶ່ງຍູ້ໃຫ້ຫຍໍ້ຝັ່ງ on-prem ລົງເລື້ອຍໆ.

ຄຳສັບ:

ບົດຝຶກຫັດ: (1) ThaiTicket ຂະຫຍາຍສູ່ພາກພື້ນ: ອອກແບບການຂະຫຍາຍໄປສິງກະໂປສອງເທື່ອ — active-passive (ບາງກອກເປັນ primary) ແລະ active-active — ພ້ອມຕົວຄູນຕົ້ນທຶນ ແລະ RTO/RPO ຂອງແຕ່ລະອັນ; ຂຽນຄຳແນະນຳໜຶ່ງໜ້າ ແລ້ວ ຕັດສິນໃຈ. (2) ຮ້ານຄ້າປີກແຫ່ງໜຶ່ງມີຂໍ້ມູນການຂາຍ 15 ປີໃນ database SQL production ແລະ ຢາກໄດ້ “ການວິເຄາະທີ່ພ້ອມສຳລັບ AI”; ຮ່າງການອອກແບບ lake + warehouse ແລ້ວຂຽນສາມປະໂຫຍກເລື່ອງການກຳກັບ. (3) ສັງເກດ pattern: ເລືອກ reference architecture ສາມອັນຈາກ https://aws.amazon.com/architecture/ ແລ້ວບອກຊື່ທຸກ pattern ໃນຄັງລວມທີ່ປາກົດໃນແຕ່ລະອັນ.

Milestone — ຈົບໄລຍະທີ 3: ດ່ານທົດສອບຄັງລວມ: AI ໃຫ້ສະຖານະການໄວໆຫົກອັນ; ສຳລັບແຕ່ລະອັນ ທ່ານບອກຊື່ pattern, ເຫດຜົນ, ຄຳເຕືອນ “ເມື່ອໃດບໍ່ຄວນໃຊ້”, ແລະ ໂປຣໄຟລ໌ຕົ້ນທຶນ/ຄວາມຊັບຊ້ອນ — ອັນລະຕໍ່າກວ່າຫ້ານາທີ. ການໂຕ້ຕອບແບບນີ້ພໍດີ, ທີ່ຄວາມໄວນີ້ພໍດີ, ຄືໜຶ່ງສ່ວນສາມກາງຂອງການສຳພາດສະຖາປະນິກຕົວຈິງ.

ໄລຍະທີ 4 — ການ migrate ແລະ ໂລກຕົວຈິງ (ອາທິດທີ 21–26)

ການອອກແບບ greenfield ຄືສ່ວນນ້ອຍຂອງວຽກນີ້. ສະຖາປັດຕະຍະກຳສ່ວນໃຫຍ່ເກີດຂຶ້ນໃນບໍລິສັດທີ່ມີຢູ່ແລ້ວ — ພ້ອມຫ້ອງ server, software ບູຮານທີ່ທຸລະກິດເພິ່ງພາ, ສັນຍາ, ແລະ ກົດໝາຍ. ໄລຍະນີ້ຄືໂລກນັ້ນ, ແລະ ມັນຄືບ່ອນທີ່ “lead migration and modernization initiatives” — ຂໍ້ໜຶ່ງໃນເກືອບທຸກປະກາດວຽກທີ່ພວກເຮົາສຶກສາ — ຖືກສອນ.

Module 10 (ອາທິດທີ 21–23): ການ migrate — ຍ້າຍບໍລິສັດໜຶ່ງຂຶ້ນ cloud

7 Rs — ຄຳສັບຮ່ວມຂອງທຸກບົດສົນທະນາເລື່ອງ migration. ສຳລັບແຕ່ລະ workload ໃນກອງມູນ, ທ່ານເລືອກໜຶ່ງອັນ:

ວິທີການ migrate: assess → mobilize → migrate. Assess (ປະເມີນ): ສຳຫຼວດທຸກຢ່າງ (ເຄື່ອງມື discovery ບວກກັບໂບຮານຄະດີຂອງການໄປຖາມຄົນ), ແລ້ວໃຫ້ຄະແນນແຕ່ລະ workload ດ້ານຄຸນຄ່າທຸລະກິດ ແລະ ຄວາມຍາກໃນການ migrate — ຜົນຜະລິດ: ບັນຊີລາຍການແອັບພລິເຄຊັນທີ່ມີ R ຕໍ່ແຖວ, ແລະ business case (TCO ຂອງການຢູ່ຕໍ່ ທຽບກັບການຍ້າຍ; ຈົ່ງຊື່ສັດວ່າໃບບິນຈະ ສູງຂຶ້ນ ໃນຊ່ວງທັບຊ້ອນທີ່ທັງສອງກອງມູນແລ່ນພ້ອມກັນ — ຜູ້ນຳທີ່ບໍ່ຖືກເຕືອນເລື່ອງ migration bubble ຈະກາຍເປັນຜູ້ນຳທີ່ຍົກເລີກ migration ກາງທາງ). Mobilize (ລະດົມ): ສ້າງ landing zone — ພື້ນຖານ cloud ທີ່ສ້າງໄວ້ລ່ວງໜ້າ ແລະ ຖືກກຳກັບ ກ່ອນ workload ອັນທຳອິດຈະລົງຈອດ: ໂຄງສ້າງຫຼາຍບັນຊີ (ບັນຊີແຍກຕໍ່ສະພາບແວດລ້ອມ ແລະ ຕໍ່ທີມ, ເພື່ອໃຫ້ blast radius ນ້ອຍ), ຕົວຕົນ ແລະ logging ແບບລວມສູນ, ຮັບເຄືອຂ່າຍ (VPC ແບບ hub-and-spoke, Direct Connect ກັບໄປ on-prem), ແລະ guardrail — policy ອັດຕະໂນມັດທີ່ເຮັດໃຫ້ເສັ້ນທາງທີ່ປອດໄພ, ຕິດປ້າຍ, ແລະ ສອດຄ່ອງ ເປັນຄ່າມາດຕະຖານ (AWS Control Tower ຄືຊຸດເລີ່ມຕົ້ນແບບ managed). ປະກາດວຽກເວົ້າວ່າ “design the landing zone every workload inherits” — ນີ້ຄືອັນນັ້ນ. ການຂ້າມມັນເພື່ອ “ເລີ່ມ migrate ໄປກ່ອນ” ຄືການສ້າງ data center ທີ່ຮົກເຮື້ອຂຶ້ນມາໃໝ່ໃນ cloud ດ້ວຍຕົ້ນທຶນສູງກວ່າ; ນັ້ນຄືລາຍເຊັນຄລາສສິກຂອງ migration ທີ່ລົ້ມເຫຼວ. Migrate ເປັນ wave (ຄື້ນ): ຈັດ workload ເປັນຄື້ນລະສອງສາມອັນ, ຮຽງງ່າຍກ່ອນ: Wave 1 ຖືກເລືອກໃຫ້ເດີມພັນຕໍ່າໂດຍເຈດຕະນາ (ຮຽນເຄື່ອງຈັກໃນບ່ອນທີ່ຄວາມຜິດພາດຖືກ), ຄື້ນຕໍ່ມາຈຶ່ງເອົາເພັດຍອດມົງກຸດ ພ້ອມການ cutover ທີ່ຊ້ອມມາແລ້ວ, ແຕ່ລະຄື້ນມີແຜນ rollback ແລະ ຊ່ວງ hypercare ຂອງການເຝົ້າຕິດຕາມເຂັ້ມຂຸ້ນ. ສຳລັບການຍ້າຍ database ແຕ່ລະຄັ້ງ, ສອງຄຳຖາມທີ່ສຳຄັນຄືຕົວເລກຂອງ Module 4 ໃນຄາບແປງໂສມ: ການ cutover ໃຊ້ downtime ໄດ້ຫຼາຍປານໃດ (RTO) — ແລະ replication ຕໍ່ເນື່ອງພ້ອມການສະຫຼັບສັ້ນໆ ມີໄວ້ສຳລັບເມື່ອຄຳຕອບຄື “ເກືອບບໍ່ໄດ້ເລີຍ.”

ຄຳສັບ:

ບົດຝຶກຫັດ: (1) Migration ເທິງເຈ້ຍ: AI ສ້າງບັນຊີລາຍການບໍລິສັດສົມມຸດ 40 server (ທ່ານຈະພົບມັນອີກໃນຖານະ Capstone 2); ກຳນົດ R ໃຫ້ທຸກແຖວ ແລ້ວປົກປ້ອງສິບການຕັດສິນໃຈທີ່ຍາກທີ່ສຸດ. (2) ຮ່າງ landing zone: ແຜນວາດບັນຊີ, ກະແສຕົວຕົນ, ຮັບເຄືອຂ່າຍ hub-and-spoke, ຫ້າ guardrail ທີ່ທ່ານຈະບັງຄັບໃຊ້ຕັ້ງແຕ່ມື້ທຳອິດ. (3) ຂຽນຄຳເຕືອນ “migration bubble” ສອງວັກເຖິງ CFO — ການຝຶກແຈ້ງຂ່າວຮ້າຍແຕ່ຫົວທີ ຄືການອອກກຳລັງກາຍຂອງສະຖາປະນິກ.

Milestone: ເມື່ອໄດ້ບັນຊີລາຍການ ~20 workload ພ້ອມຄຳບັນຍາຍ, ທ່ານຜະລິດຕາຕະລາງ R-ຕໍ່-workload ທີ່ປົກປ້ອງໄດ້, ແຜນສາມຄື້ນພ້ອມເຫດຜົນ, ແລະ ຮ່າງ landing zone — ໃນການນັ່ງເທື່ອດຽວ.

Module 11 (ອາທິດທີ 24–26): ຂໍ້ຈຳກັດ — ກົດໝາຍ, ລະບົບເກົ່າ, ແລະ lock-in

Data residency ແລະ ກົດໝາຍຄວາມເປັນສ່ວນຕົວ ໃນຖານະຂໍ້ມູນນຳເຂົ້າຂອງສະຖາປັດຕະຍະກຳ. ກົດໝາຍຂໍ້ມູນສ່ວນບຸກຄົນ — PDPA ຂອງໄທ, GDPR ຂອງເອີຣົບ, ແລະ ຍາດພີ່ນ້ອງຂອງພວກມັນທົ່ວໂລກ — ມີຮູບຮ່າງຮ່ວມກັນທີ່ສະຖາປະນິກຕ້ອງແມ່ນຢຳ: ຂໍ້ມູນສ່ວນບຸກຄົນຕ້ອງມີຖານທາງກົດໝາຍ (ມັກເປັນການຍິນຍອມ); ບຸກຄົນມີສິດ (ເຂົ້າເຖິງ, ແກ້ໄຂ, ລຶບ — ການອອກແບບຂອງທ່ານຕ້ອງ ຫາ ແລະ ລຶບຂໍ້ມູນຂອງຄົນໜຶ່ງຄົນ ໄດ້, ຊຶ່ງຍາກຖ້າທ່ານກະຈາຍມັນໄປຕາມສຳເນົາທີ່ບໍ່ມີການກຳກັບ); ການລະເມີດມີໜ້າທີ່ ແຈ້ງພາຍໃນ 72 ຊົ່ວໂມງ (logging ຂອງທ່ານຕ້ອງໃຫ້ທ່ານເລົ່າເລື່ອງໄດ້ໃນເວລາໜ້ອຍກວ່ານັ້ນ); ແລະ ກົດການໂອນຂ້າມຊາຍແດນ ຈຳກັດວ່າຂໍ້ມູນຢູ່ບ່ອນໃດໄດ້ທາງກາຍະພາບ — ຊຶ່ງເປັນຂໍ້ຈຳກັດຂອງ ການເລືອກ region, ຂໍ້ຈຳກັດຂອງ ການອອກແບບ replication (ສຳເນົາວິເຄາະຢູ່ສິງກະໂປອາດເປັນເຫດການທາງກົດໝາຍ), ແລະ ເປັນເຫດຜົນທີ່ region ພາຍໃນປະເທດມີຢູ່. ວິທີການຂອງສະຖາປະນິກ, ຕາມລຳດັບ: ຈັດປະເພດຂໍ້ມູນ (ອັນໃດເປັນຂໍ້ມູນສ່ວນບຸກຄົນ?), ແຕ້ມແຜນການເດີນທາງຂອງມັນ (ທຸກບ່ອນເກັບ, ທຸກສຳເນົາ, ທຸກຊາຍແດນທີ່ຂ້າມ — ກະແສທີ່ບໍ່ມີໃຜແຕ້ມ ຄືບ່ອນທີ່ການລະເມີດອາໄສຢູ່), ແລ້ວອອກແບບການຄວບຄຸມ: region ທີ່ສອດຄ່ອງກັບ residency, ການເຂົ້າລະຫັດ, ຕາຕະລາງການເກັບຮັກສາ, ແລະ ເສັ້ນທາງການລຶບທີ່ໄປເຖິງວັນໝົດອາຍຸຂອງ backup ແທ້ໆ. ເວົ້າວ່າ “data protection by design” — ມັນຄືວະລີທີ່ກົດໝາຍທັງສອງໃຊ້, ແລະ ມັນຄືຕຳແໜ່ງງານຂອງທ່ານໃນຮູບປະໂຫຍກ.

ການບູລະນາການກັບລະບົບເກົ່າ (legacy). ລະບົບອອກໃບບິນເທິງ mainframe ຈະບໍ່ຍ້າຍໃນປີນີ້, ແລະ ແອັບ cloud ໃໝ່ເອີ່ຍຕ້ອງເວົ້າກັບມັນ. Pattern: anti-corruption layer — service ແປພາສາລະຫວ່າງໃໝ່ ແລະ ເກົ່າ, ເພື່ອບໍ່ໃຫ້ຮູບຮ່າງຂໍ້ມູນແປກໆຂອງລະບົບເກົ່າຮົ່ວເຂົ້າມາທຳລາຍການອອກແບບໃໝ່ຂອງທ່ານ; strangler fig (ຕົ້ນໄຮລັດ) — ນຳ traffic ຜ່ານໜ້າກາກ, ແລ້ວປອກໜ້າທີ່ອອກຈາກລະບົບເກົ່າເທື່ອລະອັນ ຈົນອີກຫຼາຍປີຕໍ່ມາ ມັນຖືກປິດໄດ້ (ຕັ້ງຊື່ຕາມຕົ້ນໄຮທີ່ຄ່ອຍໆຫຸ້ມຕົ້ນໄມ້ເຈົ້າບ້ານ; ມັນເໜືອກວ່າການຂຽນໃໝ່ແບບ big-bang, ຊຶ່ງລົ້ມເຫຼວໃນອັດຕາທີ່ເປັນຕຳນານ); ຂົວແບບ batch ແລະ ຈຸດແຕະ event ສຳລັບຂໍ້ມູນທີ່ຕ້ອງໄຫຼລະຫວ່າງສອງໂລກ; ແລະ ຄວາມເຄົາລົບຕໍ່ຟີຊິກຂອງ latency ໃນການເອີ້ນ cloud-ຫາ-on-prem ທີ່ຄຸຍກັນຫຼາຍ (Direct Connect ຊ່ວຍ; ດີກວ່ານັ້ນ, ອອກແບບເອົາການຄຸຍນັ້ນອອກໄປ). ກົດ: ກັກລະບົບເກົ່າໄວ້, ຢ່າຕິດເຊື້ອຈາກມັນ — ທຸກສ່ວນປະກອບໃໝ່ຄວນຖືກສ້າງຄືກັບວ່າລະບົບເກົ່າຫາຍໄປແລ້ວ.

ເສດຖະສາດຂອງ vendor lock-in. ທຸກບໍລິການ managed ທີ່ສະດວກ ເຮັດໃຫ້ການແຕ່ງງານກັບຜູ້ໃຫ້ບໍລິການລາຍດຽວເລິກຂຶ້ນ; ຄວາມເຄື່ອນຍ້າຍໄດ້ (abstraction ແບບ multi-cloud, ຄຸ້ມຄອງເອງທຸກຢ່າງ) ຄືທາງເລືອກຈິງ ທີ່ມີຕົ້ນທຶນຈິງໃນຮູບຄວາມຊັບຊ້ອນ ແລະ ຄວາມໄວທີ່ຕ້ອງເສຍໄປ. ບໍ່ມີອັນໃດເປັນບາບ — ຄວາມລົ້ມເຫຼວບໍ່ແມ່ນການ ເລືອກ lock-in, ແຕ່ຄືການບໍ່ ສັງເກດເຫັນ ມັນ. ເຄື່ອງມືຂອງສະຖາປະນິກຄືການປະເມີນຕົ້ນທຶນການອອກ ຂຽນໄວ້ໃນການອອກແບບ: “ການໃຊ້ DynamoDB ປະຢັດ ≈2 ປີ-ວິສະວະກອນ ຕອນນີ້; ການປ່ຽນພາຍຫຼັງ ≈ ການຂຽນຊັ້ນຂໍ້ມູນໃໝ່ 6 ເດືອນ — ພວກເຮົາຍອມຮັບສິ່ງນີ້, ແລະ ນີ້ຄືຂອບເຂດ interface ທີ່ຈະຫຍໍ້ການຂຽນໃໝ່ນັ້ນ.” ສາມປະໂຫຍກ, ຕີລາຄາຢ່າງຊື່ສັດ, ບັນທຶກການຕັດສິນໃຈໄວ້ (ADR ໃນໄລຍະທີ 5) — ນັ້ນຄືການຈັດການ lock-in ແບບຜູ້ໃຫຍ່. Multi-cloud ໃນຖານະຍຸດທະສາດ (ແລ່ນ workload ອັນດຽວກັນແບບເຄື່ອນຍ້າຍໄດ້ເທິງສອງ cloud) ປົກກະຕິຄືຄຳຕອບທີ່ແພງທີ່ສຸດເທົ່າທີ່ເປັນໄປໄດ້ ແລະ ຖືກຊື້ໂດຍອົງກອນທີ່ຂະໜາດ ຫຼື ຜູ້ຄຸມກົດຮຽກຮ້ອງເທົ່ານັ້ນ; multi-cloud ໃນຖານະຂໍ້ເທັດຈິງ (workload ຕ່າງກັນຢູ່ cloud ຕ່າງກັນ ຕາມປະຫວັດສາດ ຫຼື ຄວາມເໝາະສົມ) ຄືຊີວິດປົກກະຕິ.

ຄຳສັບ:

ບົດຝຶກຫັດ: (1) ແຕ້ມແຜນກະແສຂໍ້ມູນລູກຄ້າຂອງ ThaiTicket: ທຸກບ່ອນເກັບ, ທຸກສຳເນົາ (ຢ່າລືມ log, backup, pipeline ວິເຄາະ, ໄຟລ໌ export ຂອງທີມສະໜັບສະໜູນ), ທຸກຊາຍແດນ; ຈາກນັ້ນຂຽນເສັ້ນທາງການລຶບ. ຮູ້ສຶກເບິ່ງວ່າແຜນທີ່ຫາບັນຫາທີ່ແຜນວາດເຊື່ອງໄວ້ໄດ້ແນວໃດ. (2) ອອກແບບແຜນ strangler fig ໃຫ້ລະບົບຄຸ້ມຄອງສາງ on-prem ອາຍຸ 20 ປີ, ບອກຊື່ສາມການປອກທຳອິດ. (3) ຂຽນວັກ lock-in ແບບ DynamoDB (ປະໂຫຍດຕອນນີ້, ຕົ້ນທຶນການອອກພາຍຫຼັງ, ຍອມຮັບ ຫຼື ຫຼຸດຜ່ອນ) ສຳລັບສາມບໍລິການທີ່ທ່ານຈະໃຊ້ຈິງ.

Milestone — ຈົບໄລຍະທີ 4: ດ່ານທົດສອບຂໍ້ຈຳກັດ: ໂຈດການອອກແບບອັນດຽວທີ່ຖັກທໍທັງສາມເຂົ້າກັນ (“ບໍລິສັດປະກັນໄພໄທ, ຂໍ້ມູນລູກຄ້າ, ລະບົບກົມທະບຽນເທິງ mainframe, ຄະນະກຳມະການກັງວົນເລື່ອງການເພິ່ງພາ AWS”) — ທ່ານຜະລິດແນວທາງໜຶ່ງໜ້າ ທີ່ແຕະທັງ residency, ການບູລະນາການ, ແລະ lock-in, ແຕ່ລະອັນມີ pattern ທີ່ບອກຊື່ໄດ້ ແລະ ຕົ້ນທຶນທີ່ຊື່ສັດ. ເມື່ອຂໍ້ຈຳກັດເຮັດໃຫ້ທ່ານຕື່ນເຕັ້ນຫຼາຍກວ່າ greenfield — ເພາະຂໍ້ຈຳກັດຄືບ່ອນທີ່ສະຖາປະນິກຫາໄດ້ຫຼາຍກວ່າຄົນແຕ້ມແຜນວາດ — ໄລຍະທີ 4 ຈົບແລ້ວ.

ໄລຍະທີ 5 — ຝີມືວິຊາຊີບຂອງສະຖາປະນິກ (ເດືອນທີ 7–12)

ທຸກສິ່ງມາຮອດຕອນນີ້ ເຮັດໃຫ້ທ່ານ ອອກແບບ ໄດ້. ໄລຍະນີ້ເຮັດໃຫ້ທ່ານ ເຮັດວຽກໃນຖານະສະຖາປະນິກ ໄດ້ — ເອກະສານ, ການທົບທວນ, ການນຳສະເໜີ, ແລະ ຫຼັກຖານ ທີ່ບົດບາດນີ້ປະກອບຂຶ້ນຈິງ, ບວກກັບ certification ທີ່ພາທ່ານຜ່ານ HR, ແລະ capstone ສາມອັນທີ່ກາຍເປັນ portfolio ຂອງທ່ານ.

Module 12 (ເດືອນທີ 7–8): ຜົນງານສົ່ງມອບ — ADR, ຊຸດແຜນວາດ, ແລະ ການດຳເນີນການທົບທວນ

Architecture Decision Records (ADRs). ADR ຄືເອກະສານໜຶ່ງໜ້າທີ່ຈັບການຕັດສິນໃຈສຳຄັນອັນໜຶ່ງໄວ້: ພວກເຮົາເລືອກຫຍັງ, ບໍ່ເລືອກຫຍັງ, ແລະ ເປັນຫຍັງ — ຂຽນ ຕອນທີ່ຕັດສິນໃຈ, ໃສ່ໝາຍເລກ, ແລະ ເກັບໄວ້ໃນ repository ຂອງໂຄງການຕະຫຼອດໄປ. ເປັນຫຍັງປະກາດວຽກຈຶ່ງເອີ່ຍຊື່ມັນ: ອີກສອງປີ, ຈະມີຄົນຖາມວ່າ “ເປັນຫຍັງອັນນີ້ຈຶ່ງເປັນ DynamoDB?” ແລະ ADR ຕອບໄດ້ໃນສາມສິບວິນາທີ — ພ້ອມບໍລິບົດ, ຂໍ້ຈຳກັດ, ແລະ ທາງເລືອກທີ່ຖືກພິຈາລະນາຢ່າງຊື່ສັດ. ທີມທີ່ມີ ADR ບໍ່ຕ້ອງຮື້ຄະດີເກົ່າມາຖຽງໃໝ່; ທີມທີ່ບໍ່ມີ ຖຽງເປັນວົງກົມທຸກປີ. ແມ່ແບບ — ຈື່ໃຫ້ຂຶ້ນໃຈ:

# ADR-014: Use DynamoDB for the session store
Status: Accepted            Date: 2026-08-13
Context:     What situation forced a decision? (Load, constraints, deadlines — the facts.)
Decision:    What we chose, in one sentence, active voice: "We will…"
Options considered:  2–3 real alternatives, each with honest pros/cons — including the one you rejected reluctantly.
Consequences: What becomes easier; what becomes harder; the risks we accept; the exit cost.

ຂຽນ ADR ໜຶ່ງສະບັບຕໍ່ໜຶ່ງການຕັດສິນໃຈສຳຄັນ ໃນທຸກ capstone. Portfolio ສຳພາດທີ່ມີ ADR ຈິງ ຄືສິ່ງທີ່ຫາຍາກ ແລະ ມີພະລັງຮ້າຍກາດ.

ຊຸດແຜນວາດ — ໜຶ່ງລະບົບ, ສາມລະດັບ zoom. ເອກະສານສະຖາປັດຕະຍະກຳຕົວຈິງຄື ຊຸດ (ແບບຈຳລອງ C4 ເປັນຜູ້ເຮັດໃຫ້ວິໄນນີ້ແພ່ຫຼາຍ): context diagram — ລະບົບເປັນກ່ອງດຽວ, ພ້ອມຜູ້ໃຊ້ ແລະ ລະບົບພາຍນອກທີ່ມັນສຳຜັດ; ມຸມມອງສຳລັບຜູ້ບໍລິຫານ/ຄົນເຂົ້າໃໝ່, ແລະ ເປັນອັນທີ່ທ່ານຈະນຳສະເໜີຕໍ່ຜູ້ນຳ. Container diagram — ຊູມເຂົ້າ: ຊິ້ນສ່ວນຫຼັກທີ່ແລ່ນຢູ່ (ເວັບແອັບ, API, database, queue, cache) ແລະ ວິທີທີ່ພວກມັນເວົ້າກັນ; ມຸມມອງວິສະວະກຳປະຈຳວັນ, ປະມານແຜນວາດຂອງທ່ານໃນໄລຍະທີ 1–3. Deployment diagram — ທຸກຢ່າງແລ່ນຢູ່ໃສທາງກາຍະພາບ: region, AZ, VPC, subnet, scaling group; ມຸມມອງສຳລັບການທົບທວນ, ຄວາມປອດໄພ, ແລະ ປະຕິບັດການ. ໜຶ່ງລະບົບ, ສາມກຸ່ມຜູ້ຟັງ, ສາມແຜນວາດ — ຮັກສາໃຫ້ທັນສະໄໝ, ໃສ່ວັນທີ, ຢູ່ໃນ version control ຂ້າງ ADR. ແຜນວາດທີ່ຫາບໍ່ພົບ ຫຼື ເຊື່ອບໍ່ໄດ້ ຄືແຜນວາດທີ່ບໍ່ມີຢູ່.

ການດຳເນີນ Well-Architected review. ທ່ານຮູ້ຫົກເສົາແລ້ວ (ໄລຍະທີ 2); ນີ້ຄືຕົວກອງປະຊຸມເອງ. ກ່ອນ: ເລືອກ workload ແລະ ຂອບເຂດ, ເຮັດຊຸດແຜນວາດໃຫ້ທັນສະໄໝ, ເຊີນຄົນທີ່ ປະຕິບັດງານ ສິ່ງນັ້ນ (ບໍ່ແມ່ນສະເພາະຄົນອອກແບບ), ແລະ ວາງໂທນ — ນີ້ຄືການກວດສຸຂະພາບເພື່ອປະໂຫຍດຂອງທີມ, ບໍ່ແມ່ນການກວດສອບເພື່ອເຂົ້າແຟ້ມໃຜ. ລະຫວ່າງ (ເຄິ່ງມື້): ເດີນຜ່ານເສົາຫຼັກດ້ວຍຊຸດຄຳຖາມຂອງ framework (AWS ຕີພິມພວກມັນ, ພ້ອມ Well-Architected Tool ຟຣີໃນ console ທີ່ຈັດໂຄງສ້າງໃຫ້ທັງບົດຝຶກ — https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html); ສຳລັບແຕ່ລະຄຳຕອບ, ບັນທຶກສິ່ງທີ່ພົບ, ແລະ ຈັດລຳດັບຄວາມສຳຄັນໄປພ້ອມກັນ — ບັນຫາຄວາມສ່ຽງສູງບໍ່ຫຼາຍຂໍ້, ບໍ່ແມ່ນຂໍ້ຈຸກຈິກຮ້ອຍຂໍ້. ໂທນຄຳຖາມຂອງທ່ານຄືຕົວການທົບທວນເອງ: “ຊ່ວຍໃຫ້ຂ້ອຍເຂົ້າໃຈວ່າເກີດຫຍັງເມື່ອຜູ້ໃຫ້ບໍລິການຊຳລະເງິນ timeout” ເປີດປະຕູ ຂະນະທີ່ “ພວກເຈົ້າບໍ່ຈັດການ timeout ບໍ?” ປິດປະຕູດັງປັງ. ຫຼັງ: ບົດລາຍງານສັ້ນ — ສິ່ງທີ່ພົບອັນດັບຕົ້ນ, ແຕ່ລະອັນມີຄວາມສ່ຽງ, ແຮງງານ, ແລະ ຄຳແນະນຳ — ແລະ ລາຍການປັບປຸງຕ້ອງລົງໄປໃນ backlog ຈິງຂອງທີມ ພ້ອມເຈົ້າຂອງ, ບໍ່ດັ່ງນັ້ນການທົບທວນກໍເປັນລະຄອນ. ຝຶກ: ດຳເນີນການທົບທວນເຕັມຮູບແບບຕໍ່ການອອກແບບ Capstone 1 ຂອງທ່ານເອງ; ການພົບຂໍ້ບົກຜ່ອງຂອງຕົນເອງຢ່າງເປັນລະບົບ ຄືທັກສະທີ່ທົບຕົ້ນທົບດອກໄວທີ່ສຸດໃນຫຼັກສູດນີ້.

ບົດຝຶກຫັດ: (1) ຂຽນ ADR ຍ້ອນຫຼັງໃຫ້ການຕັດສິນໃຈໃຫຍ່ຫ້າອັນ ໃນການອອກແບບຈາກປຶ້ມບັນທຶກໄລຍະທີ 2–3 ຂອງທ່ານ — ທ່ານຈະພົບຢ່າງໜ້ອຍໜຶ່ງອັນທີ່ຕອນນີ້ທ່ານປົກປ້ອງບໍ່ໄດ້ອີກແລ້ວ, ຊຶ່ງນັ້ນເອງຄືບົດຮຽນ. (2) ຜະລິດຊຸດແຜນວາດສາມອັນຄົບຊຸດສຳລັບ ThaiTicket. (3) ດຳເນີນການທົບທວນຈຳລອງຂ້າງເທິງ, ຜະລິດບົດລາຍງານສິ່ງທີ່ພົບໜຶ່ງໜ້າ.

Milestone: ຄົນແປກໜ້າ (ຫຼື AI ທີ່ສະແດງເປັນຄົນແປກໜ້າ) ຢິບຊຸດ ThaiTicket ຂອງທ່ານຂຶ້ນມາ — ສາມແຜນວາດ + ຫ້າ ADR — ແລ້ວຕອບໄດ້ຢ່າງຖືກຕ້ອງວ່າ “ນີ້ແມ່ນຫຍັງ, ມັນແລ່ນແນວໃດ, ແລະ ເປັນຫຍັງຈຶ່ງສ້າງແບບນີ້?” ໂດຍທ່ານບໍ່ຢູ່ໃນຫ້ອງ. ຊຸດນັ້ນ ຄື ຜົນງານສົ່ງມອບຂອງວຽກສະຖາປະນິກ.

Module 13 (ເດືອນທີ 8–9): ຝີມືດ້ານມະນຸດ — ການນຳສະເໜີ, ການຄິດຕົ້ນທຶນ, ການຮັບແຮງຕ້ານ, ແລະ ການເປັນພີ່ລ້ຽງ

ການນຳສະເໜີຕໍ່ຜູ້ບໍລິຫານ ທຽບກັບຕໍ່ວິສະວະກອນ — ໜຶ່ງການອອກແບບ, ສອງພາສາ. ຜູ້ບໍລິຫານຊື້ຜົນລັບ; ວິສະວະກອນຊື້ກົນໄກ. ຕໍ່ຜູ້ບໍລິຫານ: ນຳດ້ວຍການຕັດສິນໃຈ ແລະ ຕົວເລກ (“ການອອກແບບນີ້ຮອງຮັບເປົ້າໝາຍລູກຄ້າໜຶ່ງລ້ານຄົນ ທີ່ ฿1.90 ຕໍ່ຄຳສັ່ງຊື້, ແລະ ນີ້ຄືສອງການຕັດສິນໃຈທີ່ຂ້ອຍຕ້ອງການຈາກທ່ານ”); ສະໄລດ໌ດຽວ, ໃຊ້ແຜນວາດ context, ນຳສະເໜີຄວາມສ່ຽງໃນຮູບຄວາມສ່ຽງທາງທຸລະກິດ (ລາຍຮັບ, compliance, ຊື່ສຽງ), ແລະ ຢ່າເວົ້າຄຳວ່າ “Kubernetes” ເມື່ອຄຳວ່າ “ແພລດຟອມ” ພຽງພໍ. ກຽມພ້ອມສຳລັບສາມຄຳຖາມທີ່ຜູ້ບໍລິຫານຖາມສະເໝີ: ມີຄ່າໃຊ້ຈ່າຍເທົ່າໃດ, ຫຍັງອາດຜິດພາດ, ເປັນຫຍັງບໍ່ເອົາທາງເລືອກທີ່ຖືກກວ່າ? ຕໍ່ວິສະວະກອນ: ນຳດ້ວຍບັນຫາ ແລະ ຂໍ້ຈຳກັດ ກ່ອນ ວິທີແກ້ (ວິສະວະກອນທີ່ຮູ້ສຶກເຖິງບັນຫາ ຈະຍອມຮັບວິທີແກ້; ວິສະວະກອນທີ່ຖືກຍື່ນຄຳຕັດສິນໃສ່ມື ຈະລ່າຂໍ້ບົກຜ່ອງເປັນຫຼັກການ), ສະແດງແຜນວາດ container ແລະ deployment, ບອກຊື່ trade-off ແລະ ທາງເລືອກທີ່ຖືກປະຕິເສດດ້ວຍຕົນເອງ (ຄວາມໜ້າເຊື່ອຖືມາຈາກສິ່ງທີ່ທ່ານຍອມຮັບ), ແລະ ເປີດຊ່ອງຈິງໆໃຫ້ປ່ຽນການອອກແບບ — ຄຳຖາມໃນຫ້ອງຄືການທົບທວນຟຣີ. ນິໄສທີ່ຮ້າຍທີ່ສຸດຂອງສະຖາປະນິກຄືໃຊ້ສະໄລດ໌ຊຸດດຽວກັບຜູ້ຟັງທັງສອງກຸ່ມ; ນິໄສທີ່ດີທີ່ສຸດຄືຂຽນບົດສະຫຼຸບສຳລັບຜູ້ບໍລິຫານ ກ່ອນ, ເພາະຖ້າການອອກແບບຢູ່ລອດການບີບອັດເປັນຫ້າປະໂຫຍກບໍ່ໄດ້, ມັນຍັງບໍ່ສຳເລັດ.

ການປະເມີນຕົ້ນທຶນສຳລັບຂໍ້ສະເໜີ. ວິທີການ: ແຍກການອອກແບບເປັນສ່ວນປະກອບທີ່ມີຕົ້ນທຶນ ~10 ອັນ; ຕີລາຄາແຕ່ລະອັນທີ່ໂຫຼດຄາດໝາຍ ໃນ pricing calculator; ລະບຸສົມມຸດຕິຖານຂອງທ່ານເປັນລາຍລັກອັກສອນ (ຄຳຮ້ອງຂໍ/ມື້, ການເຕີບໂຕຂອງຂໍ້ມູນ, egress — ສົມມຸດຕິຖານຄືຕົວປະເມີນ; ເມື່ອພວກມັນປ່ຽນ, ຕົວເລກກໍຂຶ້ນລົງດ້ວຍຈິດໃຈທີ່ສະບາຍ); ໃຊ້ຍຸດທະສາດການຈອງກັບສ່ວນທີ່ຄົງທີ່; ເພີ່ມສະຖານະການການເຕີບໂຕ (ມື້ນີ້, 2×, 10× — ຜູ້ບໍລິຫານຈື່ຕົວເລກ 10×); ແລະ ນຳສະເໜີເປັນ ຊ່ວງພ້ອມຕົວຂັບເຄື່ອນ (“฿55–70k/ເດືອນ, ຂັບເຄື່ອນຫຼັກໂດຍ egress — ນີ້ຄືຄັນໂຍກ”), ບໍ່ແມ່ນຕົວເລກດ່ຽວທີ່ແມ່ນຢຳແບບຫຼອກ. ໃສ່ migration bubble ເຂົ້າໄປນຳ ຖ້າມີ. ການປະເມີນຕໍ່າເພື່ອໃຫ້ໄດ້ຮັບອະນຸມັດ ຄືບາບຄລາສສິກຂອງສະຖາປະນິກມືໃໝ່; ໂຄງການຈື່ໄດ້.

ການຮັບມືກັບແຮງຕ້ານ. ທ່ານຈະຖືກຍູ້ເລື່ອງຕົ້ນທຶນ (“ແພງເກີນ” → ກັບໄປຫາສາມຫຼ່ຽມ: “ພວກເຮົາຕັດ ฿30k ໄດ້ຖ້າຍອມຮັບ single-AZ — ນີ້ຄືເລກຄະນິດຂອງການຂັດຂ້ອງ; ທ່ານເປັນຜູ້ຕັດສິນ, ແລະ ຂ້ອຍຈະບັນທຶກໄວ້” — ການເຮັດໃຫ້ການແລກປ່ຽນຈະແຈ້ງ ແລະ ຖືກບັນທຶກ ປ່ຽນແຮງຕ້ານສ່ວນໃຫຍ່ໃຫ້ເປັນການເຫັນດີ ຫຼື ຄວາມສ່ຽງທີ່ຮັບຮູ້ແລ້ວຍອມຮັບ, ຊຶ່ງທັງສອງກໍດີ); ເລື່ອງລົດນິຍົມ (“ວິສະວະກອນມັກ stack ອື່ນ” → steel-man ມັນອອກສຽງ, ແລ້ວເອົາໄປສູ່ເກນ, ບໍ່ແມ່ນຄວາມມັກ: ຄວາມເໝາະສົມກັບ NFR, ທັກສະທີມ, ລະບົບນິເວດ, ຕົ້ນທຶນການອອກ — ແລະ ເມື່ອມັນສູສີກັນແທ້, ໃຫ້ຄວາມມັກຂອງວິສະວະກອນຜູ້ລົງມືເປັນຝ່າຍຊະນະ, ຊື້ຄວາມມຸ່ງໝັ້ນມາຢ່າງຖືກ); ແລະ ເລື່ອງອຳນາດ (“ໝູ່ຂອງ CTO ບອກໃຫ້ໃຊ້ X” → ຢ່າສູ້ຄວາມເຫັນດ້ວຍຄວາມເຫັນ; ຂໍເກນມາ, ເອົາ X ຜ່ານການປະເມີນສາທາລະນະອັນດຽວກັນກັບທຸກຢ່າງ, ປ່ອຍໃຫ້ຕາຕະລາງເປັນຜູ້ຕອບຢ່າງສຸພາບ). ແລະ ເມື່ອທ່ານຜິດ — ທ່ານຈະອອກແບບບາງສິ່ງທີ່ລົ້ມເຫຼວ; ສະຖາປະນິກທຸກຄົນເປັນ — ທ່າທີ່ຄື blameless post-mortem ນຳໃຊ້ກັບຕົນເອງ, ຢູ່ທີ່ແຈ້ງ, ພ້ອມອັບເດດ ADR. ບໍ່ມີຫຍັງສ້າງຄວາມໜ້າເຊື່ອຖືລະດັບທົດສະວັດໄດ້ໄວກວ່ານີ້; ແລະ ບໍ່ມີຫຍັງທຳລາຍມັນໄວກວ່າການປົກປ້ອງສົບ.

ການເປັນພີ່ລ້ຽງວິສະວະກອນ. ວະລີໃນປະກາດວຽກຄື “mentor the engineers who build against your standards,” ແລະ ຮູບແບບການປະຕິບັດຄື: ຊົ່ວໂມງໃຫ້ຄຳປຶກສາການທົບທວນການອອກແບບ (ປະຕູທີ່ເປີດປະຈຳ, ເພື່ອໃຫ້ຄຳແນະນຳເກີດກ່ອນໂຄດ, ບໍ່ແມ່ນຫຼັງ); ການທົບທວນການອອກແບບຂອງເຂົາຢ່າງເມດຕາ — ຄຳຖາມກ່ອນຄຳຕັດສິນ, ແລະ ສະເໝີຕ້ອງມີ ເປັນຫຍັງ ຢູ່ເບື້ອງຫຼັງມາດຕະຖານ (guardrail ທີ່ອະທິບາຍ ໄດ້ພັນທະມິດ; guardrail ທີ່ບັງຄັບ ໄດ້ວິທີຫຼົບຫຼີກ); ການມອບການຕັດສິນໃຈຈິງ ພ້ອມຕາໜ່າງນິລະໄພ (“ເຈົ້າເປັນເຈົ້າຂອງການອອກແບບ cache; ນີ້ຄືຂໍ້ຈຳກັດ; ຂ້ອຍຈະທົບທວນ, ແລະ ຂ້ອຍຈະໜູນຫຼັງການຕັດສິນໃຈຂອງເຈົ້າ”); ແລະ ການສອນຢູ່ທີ່ແຈ້ງ — ທຸກ ADR, ທຸກບົດສະຫຼຸບການທົບທວນ, ທຸກກອງປະຊຸມແລກປ່ຽນຕອນທ່ຽງ ຂະຫຍາຍທ່ານອອກໄປເກີນຊົ່ວໂມງຂອງທ່ານເອງ. ຄວາມຈິງກົງໆເລື່ອງອາຊີບ: ສະຖາປະນິກອັດສະລິຍະໂດດດ່ຽວມີເພດານ; ສະຖາປະນິກທີ່ບົ່ມວິສະວະກອນຫ້າຄົນໃຫ້ກາຍເປັນເພື່ອນຮ່ວມງານທີ່ອອກແບບໄດ້ ຄືຜູ້ດຳເນີນວິຊາຊີບນີ້.

ບົດຝຶກຫັດ: (1) ນຳສະເໜີ ThaiTicket ສອງເທື່ອ — ສະບັບຜູ້ບໍລິຫານ 5 ນາທີ ແລະ ສະບັບວິສະວະກຳ 20 ນາທີ — ບັນທຶກທັງສອງ, ແລ້ວຟັງຫາສັບແສງທີ່ຮົ່ວເຂົ້າສະບັບທຳອິດ. (2) ຜະລິດຂໍ້ສະເໜີຕົ້ນທຶນເປັນລາຍລັກອັກສອນຄົບຖ້ວນ (ສົມມຸດຕິຖານ, ຊ່ວງ, ຕົວຂັບເຄື່ອນ, ສະຖານະການ 2×/10×). (3) ລະຄອນແຮງຕ້ານກັບ AI: ສາມຮອບ — ການໂຈມຕີເລື່ອງຕົ້ນທຶນຈາກ CFO, ຄວາມມັກເລື່ອງ stack ຈາກວິສະວະກອນອາວຸໂສ, ການອ້າງອຳນາດແບບ “ໝູ່ຂອງ CTO” — ບັນທຶກວ່າຫຍັງໃຊ້ໄດ້ຜົນ. (4) ທົບທວນການອອກແບບຂອງນ້ອງໃໝ່ (AI ສ້າງອັນທີ່ມີຂໍ້ບົກຜ່ອງໄດ້) ເປັນລາຍລັກອັກສອນ, ຄຳຖາມມາກ່ອນ, ແລ້ວໃຫ້ AI ໃຫ້ຄະແນນໂທນຂອງທ່ານ.

Milestone: ບົດຄູ່: ນຳສະເໜີ pitch ຕໍ່ຜູ້ບໍລິຫານ ແລ້ວຢູ່ລອດການຖາມ-ຕອບແບບປະສົມທີ່ດຸແຕ່ຍຸຕິທຳຊາວນາທີ (ຄະນະ AI: CFO ໜຶ່ງຄົນ, ວິສະວະກອນຂີ້ສົງໄສໜຶ່ງຄົນ) ໂດຍບໍ່ຂ້າມສາຍສັບແສງ, ບໍ່ຕັ້ງທ່າປ້ອງກັນຕົວ, ແລະ ບໍ່ມີ trade-off ອັນໃດທີ່ບໍ່ໄດ້ຂຽນໄວ້.

Module 14 (ເດືອນທີ 9–12): Certification ແລະ capstone ສາມອັນ

ເສັ້ນທາງ certification, ພ້ອມກຳນົດເວລາທີ່ຊື່ສັດ. Certification ບໍ່ໄດ້ເຮັດໃຫ້ທ່ານເປັນສະຖາປະນິກ — ສິບສາມ module ກ່ອນໜ້ານີ້ຕ່າງຫາກທີ່ເຮັດ — ແຕ່ພວກມັນເຮັດໃຫ້ທ່ານໄດ້ສຳພາດ, ແລະ ການກຽມສອບຝັງບໍລິການຂອງຜູ້ໃຫ້ບໍລິການເຂົ້າສູ່ປາຍນິ້ວຂອງທ່ານ. ບັນໄດ, ທີ່ຈັງຫວະມື້ລະໜຶ່ງຊົ່ວໂມງ: AWS Certified Solutions Architect – Associate (SAA-C03) — 2–3 ເດືອນ; ໃບຢັ້ງຢືນສະຖາປະນິກທີ່ຖືກຮຽກຫາຫຼາຍທີ່ສຸດໃນປະກາດວຽກ, ແລະ ຫຼັງໄລຍະທີ 1–3 ຫຼາຍສ່ວນຂອງມັນຈະຮູ້ສຶກຄືການທວນຄືນທີ່ຕິດຊື່ບໍລິການເຂົ້າໄປ; ເອົາອັນນີ້ກ່ອນ. AWS Certified Solutions Architect – Professional (SAP-C02) — 4–8 ເດືອນ ຫຼັງ Associate; ອີງສະຖານະການ, ຍາກແທ້, ແລະ ເປັນແຖວດຽວທີ່ແຂງແຮງທີ່ສຸດໃນ resume ຂອງສາຍງານນີ້; ເນື້ອຫາ migration ແລະ multi-account ຂອງໄລຍະທີ 4 ຄືເຄິ່ງໜຶ່ງຂອງຫຼັກສູດສອບ. Azure AZ-305 (Azure Solutions Architect Expert) — ເພີ່ມຖ້າຕະຫຼາດຂອງທ່ານໜັກໄປທາງ Microsoft (ຕະຫຼາດວິສາຫະກິດສ່ວນໃຫຍ່ຢ່າງໜ້ອຍໃຊ້ສອງພາສາ); ຄາດ 2–3 ເດືອນ ໂດຍຄວາມຮູ້ AWS ໂອນມາໄດ້ຢ່າງຄຸ້ມຄ່າ (ເລີ່ມທີ່ https://learn.microsoft.com/en-us/credentials/certifications/azure-solutions-architect/). TOGAF Foundation — ທາງເລືອກ, 2–4 ອາທິດ; ວິສາຫະກິດຂະໜາດໃຫຍ່ບາງແຫ່ງຮຽກຫາ; ມັນຢັ້ງຢືນ ວິທີການ ແລະ ຄຳສັບຂອງ enterprise architecture ຫຼາຍກວ່າທັກສະ cloud. ລຳດັບສຳລັບຫຼັກສູດນີ້: ຮຽນ SAA ຄຽງຄູ່ເດືອນທີ 7–8, ສອບປະມານເດືອນທີ 8; ຈາກນັ້ນເລືອກ SA Pro (ເສັ້ນທາງເລິກທາງເຕັກນິກ) ຫຼື AZ-305 (ເສັ້ນທາງກວ້າງ) ຕະຫຼອດເຖິງເດືອນທີ 12, ໂດຍ SA Pro ຈົບໃນເດືອນທີ 14–16 ຕາມຈັງຫວະທີ່ຊື່ສັດ.

Capstone ສາມອັນ. ແຕ່ລະອັນຄືຊຸດຄົບຖ້ວນລະດັບ portfolio: ຊຸດແຜນວາດສາມລະດັບ, ADR 5+ ສະບັບ, ການປະເມີນຕົ້ນທຶນພ້ອມສົມມຸດຕິຖານ, ແລະ Well-Architected review ທີ່ທ່ານດຳເນີນເອງພ້ອມສິ່ງທີ່ພົບ. ໃຊ້ເວລາອັນລະ 3–4 ອາທິດ. ສາມຊິ້ນງານນີ້, ບວກກັບປຶ້ມບັນທຶກຂອງທ່ານ, ຄື ຫຼັກຖານໃນການສຳພາດຂອງທ່ານເລື່ອງ “end-to-end solution design.”

Capstone 1 — greenfield: ແພລດຟອມອີຄອມເມີຊໄທ ສຳລັບຜູ້ໃຊ້ 1 ລ້ານຄົນ. ໂຈດ: marketplace, ຜູ້ໃຊ້ລົງທະບຽນ 1 ລ້ານຄົນ, 50k ພ້ອມກັນທີ່ຈຸດສູງສຸດຂອງ flash sale, mobile-first, ການເຊື່ອມຕໍ່ຊຳລະເງິນແບບ PromptPay, ສອດຄ່ອງ PDPA, availability 99.9%, ງົບແບບ seed-stage ທີ່ຕ້ອງລະວັງ. ຕ້ອງມີ: ການເລືອກ pattern ພ້ອມເສັ້ນທາງວິວັດ, ຍຸດທະສາດ caching, ບົດສົນທະນາ RTO/RPO ຂຽນເປັນບົດສົນທະນາ, ການປະເມີນ unit economics, ແຜນກະແສຂໍ້ມູນສ່ວນບຸກຄົນ.

Capstone 2 — brownfield: ການ migrate ບໍລິສັດ on-prem 40 server. ໂຈດ: ບໍລິສັດໂລຈິສຕິກໄທ; 40 server (ERP ເທິງ Oracle, ແອັບຄຸ້ມຄອງສາງອາຍຸ 12 ປີ, file share, AD, ແອັບຂອງພະແນກຕ່າງໆ — ສ້າງບັນຊີລາຍການເຕັມດ້ວຍ AI ແລ້ວຕຶງມັນໄວ້); ສັນຍາເຊົ່າ data center ໝົດອາຍຸໃນ 14 ເດືອນ; ຄະນະກຳມະການຢາກອອກ. ຕ້ອງມີ: ຕາຕະລາງບັນຊີລາຍການ 7-R ຄົບຖ້ວນ, ແຜນສາມຄື້ນພ້ອມເຫດຜົນເລື່ອງ dependency, ການອອກແບບ landing zone, ເສັ້ນເວລາຕົ້ນທຶນຂອງ migration bubble, ແລະ ບົດບັນທຶກເຖິງ CFO.

Capstone 3 — ອັນຍາກ: multi-region DR ສຳລັບ fintech. ໂຈດ: ບໍລິສັດຊຳລະເງິນທີ່ຖືກກຳກັບໃຫ້ RTO ≤ 15 ນາທີ / RPO ≈ 0 ສຳລັບບັນຊີແຍກປະເພດ, ພ້ອມຂໍ້ຈຳກັດ data residency ຕໍ່ຂໍ້ມູນລູກຄ້າ ແລະ ການທົດສອບ failover ປະຈຳປີທີ່ຜູ້ຄຸມກົດເປັນພະຍານ. ຕ້ອງມີ: ການວິເຄາະ active-passive ທຽບ active-active ພ້ອມຕົ້ນທຶນ, ການອອກແບບ replication ພ້ອມແຜນ residency, runbook ຂອງ failover, ແລະ ແຜນການຊ້ອມ.

ເກນປະເມີນຕົນເອງ (ນຳໃຊ້ກັບແຕ່ລະ capstone, ຢ່າງຊື່ສັດ, ໃນປຶ້ມບັນທຶກ):

ໃຫ້ຄະແນນທຸກມິຕິ 4+ ໃນທັງສາມ capstone — ແກ້ໄຂຈົນກວ່າຈະໄດ້ — ແລ້ວທ່ານກໍຈົບຫຼັກສູດນີ້.

ສິບຄຳຖາມສຳພາດສະຖາປະນິກ (ພ້ອມຄຳຕອບທີ່ແຂງແຮງ)

ຝຶກສິ່ງເຫຼົ່ານີ້ອອກສຽງ; ຄວາມແຂງແຮງຢູ່ທີ່ ໂຄງສ້າງ ຂອງແຕ່ລະຄຳຕອບ, ຊຶ່ງຕອນນີ້ເປັນຂອງທ່ານແລ້ວ.

1. “Design a URL shortener / ticketing site / photo app for a million users.” (ອອກແບບຕົວຫຍໍ້ URL / ເວັບຂາຍປີ້ / ແອັບຮູບ ສຳລັບຜູ້ໃຊ້ໜຶ່ງລ້ານຄົນ.) ຮູບແບບທີ່ແຂງແຮງ: requirement ກ່ອນ, ອອກສຽງ (“ການອ່ານຫຼາຍກວ່າການຂຽນບໍ? ເປົ້າ availability? ງົບ?”) → ວາງຕຳແໜ່ງເທິງສາມຫຼ່ຽມ → ໂຄງກະດູກ three-tier ຫຼື serverless-first ພ້ອມ multi-AZ, cache, CDN → ບອກຊື່ trade-off ໂດຍບໍ່ຕ້ອງໃຫ້ຖາມ → ຈົບດ້ວຍລຳດັບຂະໜາດຂອງຕົ້ນທຶນ ແລະ ເສັ້ນທາງວິວັດ 10×. ຜູ້ສຳພາດໃຫ້ຜ່ານດ້ວຍ ຄຳຖາມທີ່ທ່ານຖາມ, ບໍ່ແມ່ນກ່ອງທີ່ທ່ານແຕ້ມ.

2. “When would you choose NoSQL over a relational database?” (ເມື່ອໃດທ່ານຈະເລືອກ NoSQL ແທນ relational database?) “ຂ້ອຍໃຊ້ SQL ເປັນຄ່າມາດຕະຖານ — ການຮັບປະກັນຄວາມຖືກຕ້ອງ ແລະ ທັກສະທີ່ມີຢູ່ທົ່ວໄປ — ຈົນກວ່າຈະມີເຫດຜົນທີ່ບອກຊື່ໄດ້ມາລົບລ້າງ: ການຂະຫຍາຍແນວນອນສຸດຂີດ, schema ຍືດຍຸ່ນ, ຫຼື ການເຂົ້າເຖິງແບບ key-value ລະດັບ millisecond ຫຼັກດຽວ. ຈາກນັ້ນຂ້ອຍເລືອກລົດຊາດ NoSQL ໃຫ້ຕົງກັບ access pattern, ແລະ ຂ້ອຍຂຽນ ADR ລວມທັງສິ່ງທີ່ພວກເຮົາຍອມເສຍ: join, ແລະ semantics ບາງຢ່າງຂອງ consistency.”

3. “Explain RTO and RPO, and how they drive design.” (ອະທິບາຍ RTO ແລະ RPO, ແລະ ພວກມັນຂັບເຄື່ອນການອອກແບບແນວໃດ.) ນິຍາມທັງສອງໃຫ້ຄົມ → “ພວກມັນຄືການຕັດສິນໃຈທາງທຸລະກິດທີ່ມີປ້າຍລາຄາແບບເລກກຳລັງ” → ບັນໄດ: backup ກາງຄືນ → replication ຕໍ່ເນື່ອງ → warm standby → active-active, ຕົ້ນທຶນສູງຂຶ້ນທຸກຂັ້ນ → “ວຽກຂອງຂ້ອຍຄືເຮັດໃຫ້ຝ່າຍທຸລະກິດເລືອກຢ່າງຮູ້ຕົວ, ແລ້ວອອກແບບໃຫ້ຕົງກັບຕົວເລກນັ້ນພໍດີ — ແລະ ຊ້ອມມັນ, ເພາະ failover ທີ່ບໍ່ໄດ້ທົດສອບຄືຄວາມຫວັງ.”

4. “Monolith or microservices?” (Monolith ຫຼື microservices?) ຄຳຕັດສິນຂອງ Module 8, ຄຳຕໍ່ຄຳ: ເລີ່ມແບບ modular-monolith; ແຍກອອກເມື່ອຄວາມເຈັບປວດຈາກການຂະຫຍາຍທີມ ຫຼື ໂຫຼດມາເຖິງແທ້ໆ; microservices ຄືເຄື່ອງມືຂະຫຍາຍທີມ ທີ່ເກັບພາສີລະບົບກະຈາຍ. ໄດ້ຄະແນນເພີ່ມສຳລັບ “ຂ້ອຍຢາກແລ່ນ monolith ທີ່ດີ ຫຼາຍກວ່າລະບົບກະຈາຍທີ່ບໍ່ດີ.”

5. “How do you handle a large cloud bill / cost optimization?” (ທ່ານຈັດການໃບບິນ cloud ກ້ອນໃຫຍ່ / ການເພີ່ມປະສິດທິພາບຕົ້ນທຶນແນວໃດ?) “ຄວາມເບິ່ງເຫັນໄດ້ກ່ອນ — tagging ແລະ showback; ຈາກນັ້ນເກັບກ່ຽວຕາມລຳດັບແຮງງານ: ຂ້າຊັບພະຍາກອນທີ່ຕາຍແລ້ວ, rightsize ຈາກການວັດແທກ, ແບ່ງຂັ້ນ storage, ຈັດຕາຕະລາງໃຫ້ non-prod ຫຼັບ, ແລ້ວຈຶ່ງຈອງຖານໂຫຼດຄົງທີ່. ແລະ ຂ້ອຍລາຍງານ unit economics, ບໍ່ແມ່ນຍອດລວມ — ໃບບິນທີ່ໃຫຍ່ຂຶ້ນພ້ອມຕົ້ນທຶນຕໍ່ຄຳສັ່ງຊື້ທີ່ຫຼຸດລົງ ຄືຄວາມສຳເລັດ, ບໍ່ແມ່ນບັນຫາ.”

6. “How would you migrate a legacy on-prem application?” (ທ່ານຈະ migrate ແອັບພລິເຄຊັນ on-prem ເກົ່າແນວໃດ?) “ປະເມີນກ່ອນຍ້າຍ — ບັນຊີລາຍການ, dependency, ແລະ R ຕໍ່ workload ຈາກ 7 Rs; ສ້າງ landing zone ກ່ອນຄື້ນທຳອິດ; ຄື້ນຮຽງງ່າຍກ່ອນ ພ້ອມ cutover ທີ່ຊ້ອມແລ້ວ ແລະ ແຜນ rollback; ແລະ ສຳລັບ database ເພັດຍອດມົງກຸດ, ໃຊ້ cutover ອີງ replication ທີ່ຂະໜາດພໍດີກັບ downtime ທີ່ຝ່າຍທຸລະກິດເຊັນຮັບຮອງ. ອີກຢ່າງ: ຄຳເຕືອນເລື່ອງ migration bubble ຢ່າງຊື່ສັດແຕ່ຫົວທີ.”

7. “How do you secure a cloud architecture?” (ທ່ານເຮັດໃຫ້ສະຖາປັດຕະຍະກຳ cloud ປອດໄພແນວໃດ?) ເດີນຜ່ານທີ່ລະຊັ້ນ: ຕົວຕົນ (least privilege, MFA, ບໍ່ໃຊ້ root ປະຈຳວັນ) → ເຄືອຂ່າຍ (private subnet, ການແບ່ງສ່ວນ, attack surface ຕໍ່າສຸດ) → ຂໍ້ມູນ (ເຂົ້າລະຫັດຕອນເກັບ/ຕອນສົ່ງ, ການຈັດປະເພດ, residency) → ການກວດພົບ (audit log, ການແຈ້ງເຕືອນ) → “ແລະ ດ້ວຍການອອກແບບ, ບໍ່ແມ່ນຕິດເສີມພາຍຫຼັງ — ການຄວບຄຸມຄວາມປອດໄພທີ່ຖືກທີ່ສຸດ ຄືການຕັດສິນໃຈສະຖາປັດຕະຍະກຳທີ່ຕັດຄວາມສ່ຽງອອກໄປໝົດ, ເຊັ່ນ ການບໍ່ແຕະເລກບັດດິບເລີຍ.”

8. “Tell me about a design decision you got wrong.” (ເລົ່າໃຫ້ຟັງເລື່ອງການຕັດສິນໃຈອອກແບບທີ່ທ່ານເຮັດຜິດ.) ເຂົາທົດສອບອັດຕາ, ບໍ່ແມ່ນປະຫວັດສາດ. ຮູບແບບ: ຕົວຢ່າງຈິງ (capstone) → ສິ່ງທີ່ທ່ານເຊື່ອ → ສິ່ງທີ່ຄວາມເປັນຈິງບອກ → post-mortem, ADR ທີ່ອັບເດດ, pattern ທີ່ຕອນນີ້ທ່ານກວດຫາ. ສະຖາປະນິກທີ່ໃຫ້ຄຳຕອບນີ້ບໍ່ໄດ້ ຄືສະຖາປະນິກທີ່ບໍ່ເຄີຍຖືກທົບທວນ.

9. “How do you explain a complex technical decision to a non-technical executive?” (ທ່ານອະທິບາຍການຕັດສິນໃຈເຕັກນິກທີ່ຊັບຊ້ອນ ໃຫ້ຜູ້ບໍລິຫານທີ່ບໍ່ແມ່ນສາຍເຕັກນິກແນວໃດ?) “ການຕັດສິນໃຈ ແລະ ຕົວເລກທາງທຸລະກິດກ່ອນ, ກົນໄກເມື່ອຖືກຮ້ອງຂໍເທົ່ານັ້ນ; ໃຊ້ context diagram, ບໍ່ແມ່ນ container; ຄວາມສ່ຽງໃນຄຳສັບຂອງລາຍຮັບ-compliance-ຊື່ສຽງ; ແລະ ຂ້ອຍນຳສອງການຕັດສິນໃຈທີ່ຂ້ອຍຕ້ອງການຈາກເຂົາມາດ້ວຍ, ຂຽນເປັນທາງເລືອກພ້ອມປ້າຍລາຄາ — ຜູ້ບໍລິຫານຕັດສິນລະຫວ່າງທາງເລືອກ; ເຂົາບໍ່ອະນຸມັດຄວາມລຶກລັບ.”

10. “An engineer strongly disagrees with your design. What do you do?” (ວິສະວະກອນຄົນໜຶ່ງບໍ່ເຫັນດີກັບການອອກແບບຂອງທ່ານຢ່າງແຮງ. ທ່ານຈະເຮັດແນວໃດ?) “ກ່ອນອື່ນຂ້ອຍ steel-man ເຂົາອອກສຽງ — ເຂົາອາດຖືກ, ແລະ ການທົບທວນທີ່ປ່ຽນການອອກແບບຂອງຂ້ອຍ ຄືການທົບທວນທີ່ໄດ້ຜົນ. ຖ້າມັນສູສີກັນແທ້, ເກນເປັນຜູ້ຕັດສິນ (ຄວາມເໝາະສົມກັບ NFR, ທັກສະທີມ, ຕົ້ນທຶນການອອກ), ບໍ່ແມ່ນອາວຸໂສ — ແລະ ຂ້ອຍໃຫ້ຄວາມມັກຂອງຜູ້ລົງມືເປັນຝ່າຍຊະນະເມື່ອສະເໝີກັນ, ເພາະຄວາມມຸ່ງໝັ້ນຄືຂອງຖືກທີ່ລາຄານັ້ນ. ບໍ່ວ່າທາງໃດ ການຕັດສິນໃຈ ແລະ ທາງເລືອກທີ່ຖືກປະຕິເສດ ຈະລົງໃນ ADR, ເພື່ອວ່າພວກເຮົາຈະບໍ່ຖຽງເລື່ອງນີ້ສອງເທື່ອ.”

ຫຼັກສູດຫຍໍ້ໜຶ່ງໜ້າ

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

ແຫຼ່ງອ້າງອີງ

ປະກາດຮັບສະໝັກວຽກ ແລະ ນິຍາມບົດບາດ ທີ່ໃຊ້ໃນການ mapping ຂໍ້ກຳນົດ (ດຶງມາເດືອນສິງຫາ 2026): ແມ່ແບບຄຳບັນຍາຍວຽກ Cloud Architect ຂອງ KORE1 · ຄຳບັນຍາຍວຽກ Cloud Architect ຂອງ 4 Corner Resources · ໜ້າທີ່ຮັບຜິດຊອບຂອງ Solution Architect ໃນ Azure Well-Architected Framework ຂອງ Microsoft · ປະກາດ Pre-Sales Solutions Architect – AWS ຂອງ Arpio · ປະກາດ Solution Architect – Enterprise (ຜ່ານ Built In) ຂອງ Intel · ປະກາດ Cloud Domain Architect ຂອງ Halliburton. ການປະເມີນເວລາກຽມສອບ certification: ການສຳຫຼວດເວລາຮຽນ SAA-C03 ຂອງ CBT Nuggets ແລະ ຄຳແນະນຳການກຽມ SAP-C02 ຂອງ Whizlabs; ນິຍາມ certification ຈາກ Microsoft Learn (AZ-305) ແລະ AWS Well-Architected Framework. ເປັນເຫຼັ້ມຄູ່ຂອງ The Cloud Leader Course ໃນຊຸດ B4LCILC.