ຫຼັກສູດຜູ້ນຳດ້ານ Cloud (The Cloud Leader Course)

ຈາກຄວາມຮູ້ສູນ ສູ່ການນຳພາທີມວິສະວະກອນ cloud ຢ່າງຄ່ອງແຄ້ວ.

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

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

ຫຼັກສູດນີ້ມີສາມໄລຍະ. ໄລຍະທີ 1 (ອາທິດທີ 1–8): ເວົ້າພາສານີ້ໃຫ້ເປັນ. ທ່ານຈະຮຽນຮູ້ວ່າ cloud ແທ້ຈິງແລ້ວແມ່ນຫຍັງ ແລະ ຄຳສັບຂອງທຸກອົງປະກອບພື້ນຖານ, ເພື່ອໃຫ້ການປະຊຸມບໍ່ຟັງຄືສຽງລົບກວນອີກຕໍ່ໄປ. ໄລຍະທີ 2 (ອາທິດທີ 9–16): ຄິດຄືກັບຄົນໃນຫ້ອງປະຊຸມ. ສະຖາປັດຕະຍະກຳ (architecture), ຄວາມປອດໄພ, ແລະ ເງິນ — ສາມບົດສົນທະນາທີ່ທຸກທີມ cloud ມີທຸກອາທິດ, ແລະ ສາມບ່ອນທີ່ຜູ້ນຳຈະສ້າງຄຸນຄ່າ ຫຼື ຖືກເມີນເສີຍ. ໄລຍະທີ 3 (ເດືອນທີ 5–24): ນຳພາ. ໃບຢັ້ງຢືນ (certification), ການຈ້າງຄົນ, ການດຳເນີນກອງປະຊຸມຕັດສິນໃຈ, ແລະ ເສັ້ນທາງສອງປີແບບກົງໄປກົງມາ ສູ່ການຢືນຢູ່ໄດ້ຢ່າງໝັ້ນຄົງຕໍ່ໜ້າວິສະວະກອນອາວຸໂສ.

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

ໄລຍະທີ 1 — ເວົ້າພາສານີ້ໃຫ້ເປັນ (ອາທິດທີ 1–8)

Module 1 (ອາທິດທີ 1–2): Cloud ແທ້ຈິງແລ້ວແມ່ນຫຍັງ

ແນວຄິດຫຼັກ: Cloud (ຄລາວ — ລະບົບຄອມພິວເຕີທີ່ເຊົ່າຜ່ານອິນເຕີເນັດ) ຄື ຄອມພິວເຕີຂອງຄົນອື່ນ ທີ່ເຊົ່າເປັນຊົ່ວໂມງ ແລະ ຄຸ້ມຄອງດ້ວຍ software. ກ່ອນຍຸກ cloud, ບໍລິສັດຕ້ອງຊື້ server (ເຊີບເວີ — ຄອມພິວເຕີແມ່ຂ່າຍ) ຕົວຈິງ, ເອົາໄປວາງໄວ້ໃນຫ້ອງ, ແລະ ຈ້າງຄົນມາບົວລະບັດຮັກສາ — ຊ້າ, ແພງ, ບໍ່ຍືດຍຸ່ນ. AWS, Microsoft Azure, ແລະ Google Cloud ໄດ້ສ້າງສາງຂະໜາດໃຫຍ່ທີ່ບັນຈຸຄອມພິວເຕີຫຼາຍລ້ານໜ່ວຍ (data center — ສູນຂໍ້ມູນ) ແລ້ວເປີດໃຫ້ໃຜກໍໄດ້ເຊົ່າສ່ວນຍ່ອຍຂອງມັນເປັນວິນາທີ, ຈາກທຸກບ່ອນ, ຜ່ານໜ້າເວັບ ຫຼື ໂຄດແຖວດຽວ. ພຽງເທົ່ານັ້ນເອງ. ທຸກຢ່າງທີ່ເຫຼືອໃນຫຼັກສູດນີ້ ແມ່ນລາຍລະອຽດທີ່ຕໍ່ຍອດຈາກແນວຄິດດຽວນີ້.

ຜູ້ໃຫ້ບໍລິການລາຍໃຫຍ່ສາມເຈົ້າ, ນິຍາມໄວ້ດັ່ງນີ້:

ບັນຊີ AWS ຟຣີຂອງທ່ານ — ຕັ້ງມັນຂຶ້ນໃນອາທິດທີ 1. ເຂົ້າໄປທີ່ https://aws.amazon.com/free ແລ້ວກົດ “Create a Free Account” (ໜ້າສະໝັກໂດຍກົງແມ່ນ https://signin.aws.amazon.com/signup?request_type=register). ທ່ານຈະຕ້ອງມີອີເມວ, ເບີໂທລະສັບ, ແລະ ບັດເຄຣດິດ/ເດບິດ ເພື່ອຢັ້ງຢືນຕົວຕົນ — Free Tier (ຂັ້ນໃຊ້ຟຣີ) ໃຫ້ໂຄຕ້າລາຍເດືອນຂອງບໍລິການພື້ນຖານໂດຍບໍ່ເສຍຄ່າ (ລວມທັງ 750 ຊົ່ວໂມງ/ເດືອນ ຂອງ EC2 server ຂະໜາດນ້ອຍໃນປີທຳອິດ), ແລະ ບົດຝຶກຫັດຂອງຫຼັກສູດນີ້ຢູ່ພາຍໃນຂອບເຂດນັ້ນທັງໝົດ. ສອງນິໄສຄວາມປອດໄພຕັ້ງແຕ່ມື້ທຳອິດ: ເປີດໃຊ້ MFA (Module 6 ຈະອະທິບາຍ) ແລະ ຕັ້ງ billing alert (ການແຈ້ງເຕືອນຄ່າໃຊ້ຈ່າຍ) ທີ່ $5 (Module 7 ຈະອະທິບາຍວິທີ) ເພື່ອບໍ່ໃຫ້ຖືກເຮັດເສີຍໃຈຈັກເທື່ອ. ຫຼັງສະໝັກແລ້ວ ທ່ານເຂົ້າສູ່ລະບົບໄດ້ທີ່ https://console.aws.amazon.com — “console” ກໍຄືໜ້າເວັບຄວບຄຸມຂອງ AWS ນັ້ນເອງ.

ເປັນຫຍັງບໍລິສັດຈຶ່ງໃຊ້ cloud: ຄວາມໄວ (ໄດ້ server ໃໝ່ໃນ 60 ວິນາທີ ແທນທີ່ຈະລໍ 6 ອາທິດ), ຄວາມຍືດຍຸ່ນ (elasticity — ເຊົ່າ 100 server ສຳລັບມື້ຫຼຸດລາຄາໃຫຍ່ ແລ້ວສົ່ງຄືນ 90 ໜ່ວຍໃນມື້ຖັດໄປ), ບໍ່ມີຄ່າໃຊ້ຈ່າຍລ່ວງໜ້າ (ເປັນລາຍຈ່າຍດຳເນີນງານ ແທນລາຍຈ່າຍລົງທຶນ), ແລະ ການເຂົ້າເຖິງທົ່ວໂລກ (ວາງແອັບຂອງທ່ານໃກ້ລູກຄ້າຢູ່ບາງກອກ, ໂຕກຽວ, ແລະ ແຟຣງເຟີດ ໂດຍບໍ່ຕ້ອງກໍ່ສ້າງຫຍັງເລີຍ).

ສາມຊັ້ນຂອງບໍລິການ — ແບບຈຳລອງທາງຄວາມຄິດທີ່ມີປະໂຫຍດທີ່ສຸດໃນໂລກ cloud:

Region ແລະ Availability Zone: Region (ພາກພື້ນ) ຄືກຸ່ມ data center ຕາມພູມສາດ (ປະເທດໄທມີ AWS Region ຂອງຕົນເອງຕັ້ງແຕ່ເດືອນມັງກອນ 2025, ຢູ່ໃນ ແລະ ອ້ອມແອ້ມບາງກອກ). Availability Zone (AZ) ຄື data center ໜຶ່ງແຫ່ງ ຫຼື ຫຼາຍແຫ່ງທີ່ແຍກອິດສະຫຼະຈາກກັນ ພາຍໃນ region ດຽວກັນ. ແອັບທີ່ສຳຄັນຈະແລ່ນຢູ່ຢ່າງໜ້ອຍສອງ AZ, ເພື່ອວ່າຖ້າອາຄານໜຶ່ງລົ້ມເຫຼວ ລະບົບກໍບໍ່ລົ້ມຕາມ. ເມື່ອວິສະວະກອນເວົ້າວ່າ “we’re multi-AZ,” ເຂົາໝາຍຄວາມວ່າ “data center ໜຶ່ງແຫ່ງໄໝ້ໄດ້ ແຕ່ພວກເຮົາຍັງຢູ່ອອນລາຍ.”

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້ (ຟຣີທັງໝົດ, ລິ້ງກວດສອບແລ້ວ):

Fluency drill — ເວົ້າຈົນເປັນທຳມະຊາດ: “Is that workload on-prem or in the cloud?” (workload ນັ້ນຢູ່ on-prem ຫຼື ຢູ່ໃນ cloud?) · “Which region are we in — and are we multi-AZ?” (ພວກເຮົາຢູ່ region ໃດ — ແລະ ເປັນ multi-AZ ບໍ?) · “Is this an IaaS approach or is there a managed service that removes the maintenance?” (ນີ້ແມ່ນແນວທາງ IaaS ຫຼືວ່າມີ managed service ທີ່ຕັດພາລະບຳລຸງຮັກສາອອກໄດ້?)

ບົດຝຶກຫັດ: (1) ສ້າງບັນຊີ AWS ຟຣີຂອງທ່ານທີ່ https://aws.amazon.com/free — ຂັ້ນຕອນສະໝັກນັ້ນເອງສອນຄຳສັບໃຫ້ທ່ານຫຼາຍກວ່າການອ່ານໜຶ່ງບົດເຕັມໆ. (2) ເບິ່ງວິດີໂອສີ່ອັນໃນຕາຕະລາງຂ້າງເທິງ (ລວມກັນບໍ່ຮອດ 20 ນາທີ). (3) ໃນປຶ້ມບັນທຶກຂອງທ່ານ: ຂຽນຄຳອະທິບາຍ cloud ແບບສັ້ນກະທັດຮັດ ທີ່ທ່ານຈະເວົ້າໃຫ້ຜູ້ອຳນວຍການໂຮງຮຽນໄທຟັງໄດ້ໃນລົມຫາຍໃຈດຽວ.

Milestone: ທ່ານສາມາດອະທິບາຍ IaaS vs PaaS vs SaaS ດ້ວຍການປຽບທຽບຂອງທ່ານເອງ, ແລະ ອະທິບາຍໄດ້ວ່າເປັນຫຍັງການທີ່ AWS ເປີດ region ບາງກອກ ຈຶ່ງສຳຄັນຕໍ່ທະນາຄານໄທ (ຄຳຕອບ: latency + data residency — ເບິ່ງ Module 6).

Module 2 (ອາທິດທີ 3–4): ອົງປະກອບພື້ນຖານ — compute, storage, ແລະ database

Compute — ເຄື່ອງຈັກທີ່ແລ່ນໂຄດ. Virtual machine (VM/instance) (ເຄື່ອງຈັກເສມືອນ) ຄືສ່ວນແບ່ງໜຶ່ງຂອງ server ຕົວຈິງ ທີ່ປະພຶດຕົວຄືກັບຄອມພິວເຕີເຕັມໜ່ວຍ; ທ່ານເລືອກຂະໜາດ (CPU/RAM) ແລະ ຈ່າຍຕາມວິນາທີທີ່ມັນແລ່ນ. Container (ຄອນເທນເນີ) ຄືວິທີຫຸ້ມຫໍ່ແອັບພລິເຄຊັນໜຶ່ງອັນ ທີ່ເບົາກວ່າ ໄວກວ່າ ເພື່ອໃຫ້ມັນແລ່ນໄດ້ຄືກັນທຸກປະການໃນທຸກບ່ອນ; Docker ໃຊ້ຫຸ້ມຫໍ່ພວກມັນ ແລະ Kubernetes (K8s) ເປັນຜູ້ຄວບຄຸມວົງດົນຕີຂອງພວກມັນເປັນຝູງ — ເມື່ອໄດ້ຍິນ “K8s,” ໃຫ້ຄິດວ່າ “ລະບົບທີ່ແລ່ນ ແລະ ຮັກສາ container ຫຼາຍຮ້ອຍອັນຂອງເຮົາໂດຍອັດຕະໂນມັດ.” Serverless (ເຊີເວີເລສ — ແລ່ນໂຄດໂດຍບໍ່ຕ້ອງຄຸ້ມຄອງ server) (AWS Lambda) ໝາຍວ່າທ່ານອັບໂຫຼດພຽງ function ຂອງໂຄດ; cloud ຈະແລ່ນມັນເມື່ອຖືກກະຕຸ້ນ ແລະ ທ່ານຈ່າຍຕໍ່ຄັ້ງທີ່ເອີ້ນໃຊ້ — ບໍ່ມີ server ໃຫ້ຄຸ້ມຄອງເລີຍ. ຮູບແບບທີ່ຄວນສັງເກດ: VM → container → serverless ຄືແຖບເລື່ອນຈາກ “ຄວບຄຸມໄດ້ຫຼາຍ, ບຳລຸງຮັກສາຫຼາຍ” ໄປສູ່ “ຄວບຄຸມໄດ້ໜ້ອຍ, ບຳລຸງຮັກສາເກືອບສູນ.” ທີມທີ່ດີເລືອກຕາມແຕ່ລະ workload, ບໍ່ແມ່ນຕາມແຟຊັນ.

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

Database — ສອງຕະກູນ. Relational/SQL (MySQL, PostgreSQL; ແບບ managed ຄື Amazon RDS/Aurora): ຂໍ້ມູນໃນຕາຕະລາງທີ່ມີໂຄງສ້າງເຄັ່ງຄັດ; ຄ່າມາດຕະຖານສຳລັບເງິນ, ຄຳສັ່ງຊື້, ຜູ້ໃຊ້ — ທຸກຢ່າງທີ່ຄວາມຖືກຕ້ອງເປັນສິ່ງສັກສິດ. NoSQL (DynamoDB, MongoDB): ຍືດຍຸ່ນ, ຂະຫຍາຍໄດ້ມະຫາສານ; ຄ່າມາດຕະຖານສຳລັບຂໍ້ມູນຂະໜາດໃຫຍ່ ໄວ ຮູບຮ່າງງ່າຍກວ່າ (session, catalog, feed). “Managed database” ໝາຍວ່າຜູ້ໃຫ້ບໍລິການຈັດການ backup, patch, ແລະ failover ໃຫ້ — ທີມຄວນມີເຫດຜົນໜັກແໜ້ນແທ້ໆ ຈຶ່ງຈະແລ່ນ database ຂອງຕົນເອງ.

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້:

Fluency drill: “Should this run on VMs, containers, or serverless — and what’s the operational cost of each choice?” (ອັນນີ້ຄວນແລ່ນເທິງ VM, container, ຫຼື serverless — ແລະ ຕົ້ນທຶນດ້ານປະຕິບັດງານຂອງແຕ່ລະທາງເລືອກແມ່ນເທົ່າໃດ?) · “Is that data hot or can it go to a cheaper tier?” (ຂໍ້ມູນນັ້ນເປັນ hot ຫຼືວ່າຍ້າຍໄປ tier ທີ່ຖືກກວ່າໄດ້?) · “Why are we self-managing that database instead of using RDS?” (ເປັນຫຍັງພວກເຮົາຈຶ່ງຄຸ້ມຄອງ database ນັ້ນເອງ ແທນທີ່ຈະໃຊ້ RDS?)

ບົດຝຶກຫັດ: (1) ໃນບັນຊີຟຣີຂອງທ່ານ: ເປີດ EC2 instance ຂະໜາດນ້ອຍທີ່ສຸດ, ແລ້ວປິດຖິ້ມ (terminate). ອັບໂຫຼດໄຟລ໌ໜຶ່ງໄຟລ໌ຂຶ້ນ S3. ດຽວນີ້ທ່ານໄດ້ໃຊ້ IaaS ດ້ວຍຕົນເອງແລ້ວ. (2) ຂໍໃຫ້ AI assistant ທົດສອບທ່ານ: “Give me 10 scenarios; I’ll answer VM, container, or serverless, and you grade me.” (ໃຫ້ 10 ສະຖານະການ; ຂ້ອຍຈະຕອບ VM, container, ຫຼື serverless, ແລ້ວເຈົ້າໃຫ້ຄະແນນຂ້ອຍ.)

Milestone: ເມື່ອໄດ້ຍິນແອັບງ່າຍໆອັນໃດກໍຕາມ ທີ່ອະທິບາຍໃນປະໂຫຍກດຽວ (“ເວັບໄຊທີ່ນັກຮຽນສັ່ງອາຫານທ່ຽງ”), ທ່ານສາມາດບອກຊື່ສ່ວນປະກອບ compute, storage, ແລະ database ຂອງມັນອອກສຽງໄດ້ພາຍໃນ 60 ວິນາທີ.

Module 3 (ອາທິດທີ 5–6): ເຄືອຂ່າຍ, ແລະ ວິທີທີ່ຊິ້ນສ່ວນຕ່າງໆ ສື່ສານກັນ

VPC — ບ້ານສ່ວນຕົວຂອງທ່ານ. Virtual Private Cloud (ເຄືອຂ່າຍສ່ວນຕົວເສມືອນໃນ cloud) ຄືເຂດຮົ້ວກັ້ນຂອງທ່ານເອງ ພາຍໃນເຄືອຂ່າຍຂອງຜູ້ໃຫ້ບໍລິການ. ພາຍໃນມັນມີ subnet (ເຄືອຂ່າຍຍ່ອຍ) — ແບບ public (ເຂົ້າເຖິງໄດ້ຈາກອິນເຕີເນັດ, ເຊັ່ນ web server) ແລະ ແບບ private (ເຂົ້າເຖິງບໍ່ໄດ້, ເຊັ່ນ database). ປະໂຫຍກຄວາມປອດໄພທີ່ໄດ້ຍິນເລື້ອຍທີ່ສຸດ: “the database sits in a private subnet.” (database ຢູ່ໃນ private subnet.) ຖ້າທ່ານເຂົ້າໃຈວ່າເປັນຫຍັງ — ຜູ້ໂຈມຕີແຕະຕ້ອງສິ່ງທີ່ບໍ່ມີເສັ້ນທາງຈາກອິນເຕີເນັດບໍ່ໄດ້ — ທ່ານກໍເຂົ້າໃຈເຄິ່ງໜຶ່ງຂອງຄວາມປອດໄພເຄືອຂ່າຍແລ້ວ.

ຊັ້ນຈະລາຈອນ: load balancer (ຕົວແບ່ງເບົາການຈະລາຈອນ) ກະຈາຍ traffic ຂາເຂົ້າໄປຫາຫຼາຍ server (ແລະ ຄ່ອຍໆເອົາເຄື່ອງທີ່ບໍ່ສະບາຍອອກ); DNS (Route 53) ແປຊື່ຢ່າງ yourcompany.com ໃຫ້ເປັນທີ່ຢູ່; CDN (CloudFront) ເກັບສຳເນົາເນື້ອຫາຂອງທ່ານໄວ້ໃນຫຼາຍຮ້ອຍເມືອງ ເພື່ອໃຫ້ໂຫຼດໄວທຸກບ່ອນ; API ຄືປະຕູທີ່ software ອັນໜຶ່ງເປີດໃຫ້ software ອື່ນ — ເມື່ອວິສະວະກອນເວົ້າວ່າ “we’ll expose an API,” ເຂົາໝາຍວ່າ “ພວກເຮົາຈະໃຫ້ software ອື່ນມີວິທີໃຊ້ຂອງເຮົາແບບຄວບຄຸມໄດ້”; API gateway ຄືໂຕະຕ້ອນຮັບທີ່ຄຸ້ມຄອງປະຕູເຫຼົ່ານັ້ນ.

ການເຊື່ອມສອງໂລກ: VPN (ອຸໂມງເຂົ້າລະຫັດຜ່ານອິນເຕີເນັດ) ຫຼື Direct Connect (ສາຍສ່ວນຕົວທາງກາຍະພາບ) ເຊື່ອມຫ້ອງການ/ລະບົບ on-prem ຂອງບໍລິສັດ ເຂົ້າກັບ cloud ຂອງມັນ. Hybrid cloud = ແລ່ນທັງ on-prem ແລະ cloud ພ້ອມກັນ (ວິສາຫະກິດໄທສ່ວນໃຫຍ່ເປັນແບບນີ້); multi-cloud = ໃຊ້ຜູ້ໃຫ້ບໍລິການຫຼາຍກວ່າໜຶ່ງລາຍ.

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້: AWS Networking Basics — VPC & Subnets for Beginners — KodeKloud — https://www.youtube.com/watch?v=QM63dyA_4Pc (ເບິ່ງເຄິ່ງທຳອິດຕອນນີ້; ກັບມາເບິ່ງສ່ວນທີ່ເຫຼືອຫຼັງ Module 5).

Fluency drill: “Is the database in a private subnet?” (database ຢູ່ໃນ private subnet ບໍ?) · “What happens when one web server dies — is the load balancer health-checking?” (ຈະເກີດຫຍັງຂຶ້ນເມື່ອ web server ໜຶ່ງໜ່ວຍຕາຍ — load balancer ມີ health check ຢູ່ບໍ?) · “Are we exposing that as an API or is it internal only?” (ພວກເຮົາເປີດອັນນັ້ນເປັນ API ຫຼືວ່າໃຊ້ພາຍໃນເທົ່ານັ້ນ?)

ບົດຝຶກຫັດ: (1) ໃຫ້ AI ນຳພາທ່ານແຕ້ມ, ໃສ່ເຈ້ຍ, ເຄືອຂ່າຍຂອງແອັບສົ່ງອາຫານ: ຜູ້ໃຊ້ → CDN → load balancer → web server (public subnet) → database (private subnet). ແຕ້ມມັນສາມເທື່ອ ຈົນທ່ານແຕ້ມໄດ້ຈາກຄວາມຈຳ. (2) ຊອກຫາແຜນວາດສະຖາປັດຕະຍະກຳຂອງບໍລິສັດທ່ານ ຫຼື ຕົວຢ່າງໃດກໍໄດ້ ແລ້ວວົງມົນທຸກກ່ອງທີ່ຕອນນີ້ທ່ານບອກຊື່ໄດ້.

Milestone: ທ່ານສາມາດແຕ້ມແຜນວາດສາມຊັ້ນ (three-tier) ມາດຕະຖານນັ້ນເທິງກະດານຂາວ ແລະ ບັນຍາຍເສັ້ນທາງການຄລິກຂອງລູກຄ້າຄົນໜຶ່ງ ຜ່ານມັນໄດ້.

Module 4 (ອາທິດທີ 7–8): ທີມ cloud ເຮັດວຽກແນວໃດ — DevOps, IaC, ແລະ ການອ່ານບັນຍາກາດຫ້ອງປະຊຸມ

DevOps (ວັດທະນະທຳການເຮັດວຽກຮ່ວມກັນລະຫວ່າງຝ່າຍພັດທະນາ ແລະ ຝ່າຍປະຕິບັດງານ) ຄືວັດທະນະທຳຂອງການລວມ “ຄົນຂຽນ software” (Dev) ແລະ “ຄົນແລ່ນມັນ” (Ops) ເຂົ້າເປັນທີມດຽວ ທີ່ສົ່ງມອບການປ່ຽນແປງນ້ອຍໆ ເລື້ອຍໆ ຢ່າງປອດໄພ, ໂດຍມີລະບົບອັດຕະໂນມັດເປັນຜູ້ຮັບພາລະໜັກ. ຫົວໃຈເຕັ້ນຂອງມັນຄື CI/CD pipeline (ສາຍພານອັດຕະໂນມັດສຳລັບສ້າງ-ທົດສອບ-ນຳໃຊ້ໂຄດ): ທຸກການປ່ຽນແປງໂຄດ ຖືກ build, ທົດສອບ, ແລະ deploy ໂດຍອັດຕະໂນມັດ (Continuous Integration / Continuous Delivery). ເມື່ອທີມເວົ້າວ່າ “it’s in the pipeline,” ເຂົາໝາຍວ່າ ຫຸ່ນຍົນກຳລັງທົດສອບ ແລະ ສົ່ງມອບມັນຢູ່.

Infrastructure as Code (IaC) (ໂຄງລ່າງເປັນໂຄດ) — ແນວຄິດທີ່ປ່ຽນທຸກຢ່າງ: ແທນທີ່ຈະຄລິກໄປມາໃນ console ເພື່ອສ້າງ server, ວິສະວະກອນຂຽນ ໄຟລ໌ຂໍ້ຄວາມ ທີ່ປະກາດໂຄງລ່າງ (“server ສອງໜ່ວຍ, load balancer ໜຶ່ງອັນ, database ໜຶ່ງອັນ, ກົດ firewall ເຫຼົ່ານີ້”), ແລ້ວເຄື່ອງມື (Terraform, CloudFormation) ເຮັດໃຫ້ຄວາມເປັນຈິງກົງກັບໄຟລ໌. ເຫດຜົນທີ່ຜູ້ນຳຕ້ອງສົນໃຈ: ໄຟລ໌ເຫຼົ່ານັ້ນຢູ່ໃນ Git (ລະບົບຄວບຄຸມເວີຊັນ), ດັ່ງນັ້ນທຸກການປ່ຽນແປງໂຄງລ່າງ ຖືກກວດທານ, ຍ້ອນກັບໄດ້, ແລະ ກວດສອບຄືນໄດ້ — ຄວາມແຕກຕ່າງລະຫວ່າງໂຮງຊ່າງນ້ອຍ ກັບ ໂຮງງານ.

ພິທີກຳທີ່ທ່ານຈະໄດ້ນັ່ງຮ່ວມ: stand-up (ປະຊຸມຢືນປະຈຳວັນ 15 ນາທີ: ເຮັດຫຍັງແລ້ວ, ຈະເຮັດຫຍັງຕໍ່, ຕິດຫຍັງຢູ່ — ຟັງຫາສິ່ງກີດຂວາງ (blocker); ການເອົາມັນອອກຄືວຽກຂອງທ່ານ), sprint (ໜ່ວຍວຽກທີ່ວາງແຜນໄວ້ 1–2 ອາທິດ), retro (ປະຊຸມທົບທວນວ່າຈະປັບປຸງຫຍັງ), post-mortem/incident review (ຫຼັງລະບົບລົ້ມ: ການວິເຄາະແບບ ບໍ່ຫາຄົນຜິດ ວ່າຫຍັງພັງ ແລະ ຫຍັງຈະປ້ອງກັນມັນ — ສຸຂະພາບຂອງທີມສະແດງອອກຢູ່ບ່ອນວ່າ ການທົບທວນເຫຼົ່ານີ້ຊື່ສັດພຽງໃດ), on-call (ຮອບວຽນຂອງຄົນທີ່ຖືກປຸກຕອນຕີ 3; ຖ້າ on-call ທໍລະມານ, ຄົນເກັ່ງທີ່ສຸດຂອງທ່ານຈະລາອອກ — ຖາມເລື່ອງນີ້ທຸກເດືອນ).

ຕົວຊີ້ວັດສຸຂະພາບທີ່ສຳຄັນ: uptime/availability (“three nines” = 99.9% ≈ ລົ້ມ 8.8 ຊົ່ວໂມງ/ປີ; ແຕ່ລະ nine ທີ່ເພີ່ມ ຄູນຕົ້ນທຶນຂຶ້ນ), SLA (ຄຳສັນຍາຕໍ່ລູກຄ້າ, ພ້ອມຄ່າປັບ), SLO (ເປົ້າໝາຍພາຍໃນ), MTTR (ຄວາມໄວໃນການກູ້ຄືນ — ທີມທີ່ເຕີບໃຫຍ່ແລ້ວ ປັບປຸງການກູ້ຄືນ, ບໍ່ແມ່ນຄວາມຝັນລົມໆແລ້ງໆເລື່ອງບໍ່ມີວັນລົ້ມ), deployment frequency (ທີມສຸຂະພາບດີ ສົ່ງມອບການປ່ຽນແປງນ້ອຍໆເລື້ອຍໆ; ຄວາມຢ້ານທີ່ຈະ deploy ຄືສັນຍານບໍ່ດີ).

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້:

Fluency drill: “Is that change through the pipeline or was it manual?” (ການປ່ຽນແປງນັ້ນຜ່ານ pipeline ຫຼືເຮັດດ້ວຍມື?) · “What did the post-mortem conclude, and what’s the prevention item?” (post-mortem ສະຫຼຸບວ່າແນວໃດ, ແລະ ມາດຕະການປ້ອງກັນແມ່ນຫຍັງ?) · “What’s our MTTR trending like?” (ແນວໂນ້ມ MTTR ຂອງເຮົາເປັນແນວໃດ?) · “Is this in Terraform, or did someone click it into existence?” (ອັນນີ້ຢູ່ໃນ Terraform ຫຼືວ່າມີຄົນຄລິກສ້າງມັນຂຶ້ນມາ?) (ແບບຫຼັງເອີ້ນວ່າ “ClickOps,” ເວົ້າພ້ອມສີໜ້າບໍ່ພໍໃຈ).

ບົດຝຶກຫັດ: (1) ເບິ່ງການສົນທະນາບົດລາຍງານ post-mortem ຂອງເຫດການຈິງໜຶ່ງອັນ (ຫຼາຍອັນເປັນສາທາລະນະ — ບົດລາຍງານການລົ້ມຂອງ Cloudflare ແລະ AWS ມີຊື່ສຽງ) ແລ້ວສະຫຼຸບໃສ່ປຶ້ມບັນທຶກຂອງທ່ານໃນຫ້າປະໂຫຍກ. (2) ນັ່ງຮ່ວມ (ຫຼືເບິ່ງບັນທຶກຂອງ) stand-up ໃດກໍໄດ້ ແລ້ວຂຽນ blocker ສາມອັນທີ່ທ່ານໄດ້ຍິນ.

Milestone — ຈົບໄລຍະທີ 1: ທ່ານສາມາດນັ່ງຟັງກອງປະຊຸມວາງແຜນດ້ານເຕັກນິກ 30 ນາທີ ແລະ ຕິດຕາມໄດ້ ≥80% ຂອງມັນ, ແລະ ປຶ້ມບັນທຶກຂອງທ່ານພິສູດມັນ: ບັນທຶກຈາກກອງປະຊຸມຈິງ ຫຼື ຈຳລອງໜຶ່ງຄັ້ງ ໂດຍທຸກຄຳຫຍໍ້ຖືກຂະຫຍາຍຄວາມຢ່າງຖືກຕ້ອງ. ນີ້ຍັງເປັນເວລາທີ່ທ່ານຄວນນັດສອບເສັງ AWS Cloud Practitioner (CLF-C02) — ການກຽມຕົວແບບຕັ້ງໃຈ 2–4 ອາທິດ ຕໍ່ຍອດຈາກ module ເຫຼົ່ານີ້ ຄືມາດຕະຖານທີ່ເຜີຍແຜ່ກັນທົ່ວໄປ, ແລະ ການສອບຜ່ານມັນຄືຫຼັກຖານພາຍນອກອັນທຳອິດຂອງທ່ານ.

ໄລຍະທີ 2 — ຄິດຄືກັບຄົນໃນຫ້ອງປະຊຸມ (ອາທິດທີ 9–16)

Module 5 (ອາທິດທີ 9–10): ສະຖາປັດຕະຍະກຳ — ຕັດສິນແບບອອກແບບ ໂດຍບໍ່ຕ້ອງແຕ້ມມັນເອງ

ບົດບາດຂອງທ່ານໃນ design review ບໍ່ແມ່ນການອອກແບບ — ແມ່ນການສອບຖາມ. ກອບແນວຄິດທີ່ທັງອຸດສາຫະກຳໃຊ້ ຄື Well-Architected Framework ຂອງ AWS, ຫົກເສົາຫຼັກທີ່ທຸກການອອກແບບຄວນຕອບໄດ້: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability. ຮຽນສາມອັນທີ່ເປັນຕົວໜາໃຫ້ເລິກ; ເງິນ ແລະ ຄວາມສ່ຽງອາໄສຢູ່ບ່ອນນັ້ນ.

Reliability (ຄວາມເຊື່ອຖືໄດ້), ເວົ້າແບບງ່າຍໆ: ທຸກຢ່າງລົ້ມເຫຼວໃນທີ່ສຸດ, ດັ່ງນັ້ນລະບົບທີ່ດີຈຶ່ງສົມມຸດໄວ້ກ່ອນ. Redundancy (ຄວາມຊ້ຳຊ້ອນ — ບໍ່ມີຈຸດລົ້ມເຫຼວດ່ຽວ; ຂອງສຳຄັນມີສອງຊຸດ), multi-AZ (ຜ່ານການສູນເສຍ data center ໄປໄດ້), auto-scaling (ເພີ່ມ/ຫຼຸດເຄື່ອງອັດຕະໂນມັດຕາມຄວາມຕ້ອງການ), backup ທີ່ຖືກທົດສອບແລ້ວ (backup ທີ່ບໍ່ເຄີຍທົດສອບ ຄືຄວາມຫວັງ, ບໍ່ແມ່ນແຜນ), RTO/RPO (Recovery Time Objective: ເຮົາລົ້ມໄດ້ດົນປານໃດ; Recovery Point Objective: ເຮົາເສຍຂໍ້ມູນໄດ້ຫຼາຍປານໃດ — ສອງຕົວເລກນີ້ ຄື ບົດສົນທະນາເລື່ອງ disaster recovery, ແລະ ພວກມັນເປັນການຕັດສິນໃຈທາງທຸລະກິດ, ໝາຍຄວາມວ່າ ເປັນຂອງທ່ານ).

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

ເຈັດຄຳຖາມຂອງຜູ້ນຳ — ທ່ອງຈຳໄວ້; ພວກມັນເຮັດໃຫ້ທ່ານໜ້າຢຳເກງໃນທຸກ design review:

1. “What happens when this component fails?” (ຈະເກີດຫຍັງຂຶ້ນເມື່ອສ່ວນປະກອບນີ້ລົ້ມເຫຼວ?) (ຄຳວ່າ “ເມື່ອ” ມີສະເໝີ)
2. “What are the RTO and RPO, and who signed off on them?” (RTO ແລະ RPO ແມ່ນເທົ່າໃດ, ແລະ ໃຜເປັນຜູ້ອະນຸມັດ?)
3. “Where does this run — single AZ, multi-AZ, multi-region — and why?” (ອັນນີ້ແລ່ນຢູ່ໃສ — single AZ, multi-AZ, multi-region — ແລະ ເປັນຫຍັງ?)
4. “What will this cost per month at 10× today’s load?” (ອັນນີ້ຈະເສຍເດືອນລະເທົ່າໃດ ຖ້າວຽກໜັກ 10 ເທົ່າຂອງມື້ນີ້?)
5. “What’s the simplest version that meets the requirement?” (ສະບັບທີ່ງ່າຍທີ່ສຸດ ທີ່ຕອບສະໜອງເງື່ອນໄຂ ແມ່ນຫຍັງ?) (over-engineering ຄືພະຍາດຂອງມືໃໝ່; ຄວາມງ່າຍຄືຄຸນນະທຳຂອງມືອາວຸໂສ)
6. “What are we locked into, and what would leaving cost?” (ພວກເຮົາຖືກຜູກຕິດກັບຫຍັງ, ແລະ ການອອກຈາກມັນຈະເສຍເທົ່າໃດ?) (vendor lock-in ຄືລາຄາອັນໜຶ່ງ, ບາງເທື່ອກໍຄຸ້ມທີ່ຈະຈ່າຍ — ແຕ່ຕ້ອງຮູ້ຕົວ)
7. “Who else has built this before — are we inventing or assembling?” (ໃຜເຄີຍສ້າງອັນນີ້ມາກ່ອນແລ້ວ — ພວກເຮົາກຳລັງປະດິດ ຫຼື ປະກອບ?) (ນິຍົມຮູບແບບທີ່ໜ້າເບື່ອແຕ່ພິສູດແລ້ວ)

Fluency drill: ຝຶກຖາມຄຳຖາມ 1, 4, ແລະ 5 ດ້ວຍນ້ຳສຽງອົບອຸ່ນ — ພວກມັນຈະຖືກຮັບຮູ້ວ່າເປັນປັນຍາ ຫຼື ເປັນການໂຈມຕີ ຂຶ້ນກັບວິທີເວົ້າລ້ວນໆ. “Help me understand what happens if the cache goes down” (ຊ່ວຍໃຫ້ຂ້ອຍເຂົ້າໃຈແດ່ ວ່າຈະເກີດຫຍັງຂຶ້ນຖ້າ cache ລົ້ມ) ດີກວ່າ “did you think about failure?” (ເຈົ້າໄດ້ຄິດເລື່ອງຄວາມລົ້ມເຫຼວບໍ?)

ບົດຝຶກຫັດ: (1) ເອົາສະຖາປັດຕະຍະກຳຕົວຢ່າງສາມອັນ (ຂໍໃຫ້ AI ສ້າງ: ເວັບ e-commerce, backend ຂອງແອັບມືຖື, ແພລດຟອມວິເຄາະຂໍ້ມູນ) ແລ້ວໃຊ້ເຈັດຄຳຖາມທັງໝົດກັບແຕ່ລະອັນ, ຂຽນຄຳຕອບທີ່ທ່ານຄາດຫວັງ. (2) ອ່ານບົດສະຫຼຸບໜຶ່ງໜ້າຂອງເສົາຫຼັກ Well-Architected ທີ່ https://aws.amazon.com/architecture/well-architected/.

ວິດີໂອສຳລັບ module ນີ້:

Milestone: ໃນ design review ຈຳລອງ (ເຮັດກັບ AI ທີ່ສະແດງບົດເປັນວິສະວະກອນ), ທ່ານຖາມຄຳຖາມທີ່ມີເນື້ອໃນຫ້າຂໍ້ ແລະ ສະຫຼຸບຈຸດອ່ອນທີ່ສຸດຂອງການອອກແບບໄດ້ຢ່າງຖືກຕ້ອງໃນຕອນທ້າຍ.

Module 6 (ອາທິດທີ 11–12): ຄວາມປອດໄພ ແລະ ການປະຕິບັດຕາມກົດໝາຍ — ບົດສົນທະນາທີ່ອາດເຮັດໃຫ້ບໍລິສັດຈົບຊີວິດ

Shared responsibility model (ຮູບແບບຄວາມຮັບຜິດຊອບຮ່ວມ) — ສິ່ງທຳອິດທີ່ຕ້ອງເຂົ້າໃຈ: ຜູ້ໃຫ້ບໍລິການຮັກສາຄວາມປອດໄພຂອງຕົວ cloud ເອງ (ອາຄານ, ຮາດແວ, hypervisor); ທ່ານ ຮັກສາຄວາມປອດໄພຂອງສິ່ງທີ່ທ່ານເອົາໄປໃສ່ ໃນ ມັນ (ຂໍ້ມູນຂອງທ່ານ, ກົດການເຂົ້າເຖິງ, ການຕັ້ງຄ່າ). ການຮົ່ວໄຫຼສ່ວນໃຫຍ່ ແມ່ນການຕັ້ງຄ່າຜິດຂອງລູກຄ້າ — S3 bucket ທີ່ຖືກປະໄວ້ເປັນ public, access key ທີ່ຮົ່ວ — ບໍ່ແມ່ນຄວາມລົ້ມເຫຼວຂອງຜູ້ໃຫ້ບໍລິການ. ດັ່ງນັ້ນ “AWS ປອດໄພ” ກັບ “ພວກເຮົາປອດໄພເທິງ AWS” ຄືສອງປະໂຫຍກທີ່ຕ່າງກັນ.

ຄຳສັບຂອງການປ້ອງກັນ: IAM (Identity and Access Management — ໃຜເຮັດຫຍັງໄດ້; ສິ່ງທີ່ຖືກກວດສອບຫຼາຍທີ່ສຸດໃນ cloud), least privilege (ທຸກຄົນໄດ້ສິດເຂົ້າເຖິງຂັ້ນຕໍ່າສຸດທີ່ຈຳເປັນ — ກົດທອງ), MFA (ການຢັ້ງຢືນຕົວຕົນຫຼາຍປັດໄຈ — ປັດໄຈທີສອງໃນທຸກການເຂົ້າລະບົບຂອງມະນຸດ — ຕໍ່ລອງບໍ່ໄດ້), encryption at rest and in transit (ການເຂົ້າລະຫັດຂໍ້ມູນທັງຕອນເກັບ ແລະ ຕອນເດີນທາງ — ມາດຕະຖານຂັ້ນຕໍ່າ, ເປີດສະເໝີ), root account (ກະແຈແມ່ — ເກັບມ້ຽນໄວ້, ບໍ່ໃຊ້ປະຈຳວັນ), secrets management (ລະຫັດຜ່ານ/key ເກັບໃນຕູ້ນິລະໄພ, ບໍ່ຂຽນໃສ່ໂຄດເດັດຂາດ), zero trust (ກວດສອບທຸກຢ່າງ, ບໍ່ໄວ້ໃຈຕຳແໜ່ງເຄືອຂ່າຍໃດໂດຍປະລິຍາຍ), penetration test (ຈ້າງນັກໂຈມຕີມາພິສູດແນວປ້ອງກັນຂອງທ່ານ), ransomware (ເຫດຜົນທີ່ backup ແບບ offline ທີ່ຖືກທົດສອບແລ້ວ ເປັນມາດຕະການຄວາມປອດໄພ, ບໍ່ແມ່ນພຽງມາດຕະການ ops).

PDPA — ກົດໝາຍຂໍ້ມູນຂອງໄທ, ແລະ ຂໍ້ໄດ້ປຽບທາງຕະຫຼາດຂອງທ່ານ. Personal Data Protection Act ຄື GDPR ຂອງໄທ: ຕ້ອງມີການຍິນຍອມກ່ອນເກັບຂໍ້ມູນສ່ວນບຸກຄົນ, ໜ້າທີ່ ແຈ້ງເຫດຮົ່ວໄຫຼພາຍໃນ 72 ຊົ່ວໂມງ, ຕ້ອງມີ Data Protection Officer ສຳລັບຜູ້ປະມວນຜົນຂະໜາດໃຫຍ່, ແລະ ກົດເລື່ອງການສົ່ງຂໍ້ມູນຂ້າມຊາຍແດນ. ການບັງຄັບໃຊ້ກາຍເປັນເລື່ອງຈິງໃນປີ 2025 — ຄ່າປັບຄັ້ງທຳອິດເກີນ THB 21.5M, ລວມທັງໂຮງໝໍທີ່ຖືກປັບ ຍ້ອນຄຸ້ມຄອງ vendor ບໍ່ດີ. ສອງຜົນຕາມມາສຳລັບທ່ານ: (1) ທຸກວິສາຫະກິດໄທ ຕອນນີ້ມີບັນຫາການປະຕິບັດຕາມກົດໝາຍ ທີ່ບໍລິສັດຂອງທ່ານສາມາດຮັບເງິນເພື່ອຈັດການໃຫ້; (2) data residency (ການເກັບຂໍ້ມູນໄວ້ໃນປະເທດ) — ການຮັກສາຂໍ້ມູນໄທໄວ້ໃນແຜ່ນດິນໄທ — ຄືແຮງຂັບຕົວຈິງ ທີ່ດັນ workload ເຂົ້າສູ່ region ບາງກອກ. ວັກນີ້ຄືເຄິ່ງໜຶ່ງຂອງບົດຂາຍຂອງທ່ານໃນປະເທດໄທ; ຈື່ມັນໃຫ້ຂຶ້ນໃຈ.

ຄຳຖາມດ້ານຄວາມປອດໄພຂອງຜູ້ນຳ: “Who has access to production, and when did we last review the list?” (ໃຜເຂົ້າເຖິງ production ໄດ້, ແລະ ພວກເຮົາທົບທວນບັນຊີນັ້ນຄັ້ງສຸດທ້າຍເມື່ອໃດ?) · “Are we alerted on unusual access, or would we find out from the news?” (ພວກເຮົາໄດ້ຮັບການແຈ້ງເຕືອນເມື່ອມີການເຂົ້າເຖິງຜິດປົກກະຕິ ຫຼືວ່າຈະຮູ້ຈາກຂ່າວ?) · “When did we last restore a backup?” (ພວກເຮົາ ກູ້ຄືນ backup ຄັ້ງສຸດທ້າຍເມື່ອໃດ?) (ບໍ່ແມ່ນ “ພວກເຮົາມີ backup ບໍ”) · “If we lost this dataset, is it a PDPA-notifiable breach — and could we notify within 72 hours?” (ຖ້າພວກເຮົາເສຍຊຸດຂໍ້ມູນນີ້, ມັນເປັນເຫດຮົ່ວໄຫຼທີ່ຕ້ອງແຈ້ງຕາມ PDPA ບໍ — ແລະ ພວກເຮົາແຈ້ງພາຍໃນ 72 ຊົ່ວໂມງໄດ້ບໍ?) · “What did the last pen test find, and what’s still open?” (pen test ຄັ້ງລ່າສຸດພົບຫຍັງ, ແລະ ຫຍັງຍັງບໍ່ຖືກແກ້?)

ຄຳສັບ:

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

Fluency drill: “Is that bucket public? Why?” (bucket ນັ້ນເປັນ public ບໍ? ເປັນຫຍັງ?) · “Least privilege — does the intern really need prod access?” (least privilege — ນັກຝຶກງານຈຳເປັນຕ້ອງເຂົ້າ prod ແທ້ບໍ?) · “Where does the PDPA line sit in this design — what’s personal data here and where does it physically live?” (ເສັ້ນ PDPA ຢູ່ບ່ອນໃດໃນການອອກແບບນີ້ — ຫຍັງແມ່ນຂໍ້ມູນສ່ວນບຸກຄົນຢູ່ນີ້ ແລະ ມັນຢູ່ບ່ອນໃດທາງກາຍະພາບ?)

ບົດຝຶກຫັດ: (1) ອ່ານເລື່ອງການຮົ່ວໄຫຼຍ້ອນຕັ້ງຄ່າ cloud ຜິດ ທີ່ມີຊື່ສຽງໜຶ່ງເລື່ອງ (Capital One ປີ 2019 ຄືກໍລະນີຄລາສສິກ) ແລ້ວຂຽນສະບັບສາມປະໂຫຍກໃສ່ປຶ້ມບັນທຶກຂອງທ່ານ. (2) ໃຫ້ AI ຈຳລອງລູກຄ້າຖາມວ່າ “why should I trust you with my data?” (ເປັນຫຍັງຂ້ອຍຄວນໄວ້ໃຈເຈົ້າກັບຂໍ້ມູນຂອງຂ້ອຍ?) ແລ້ວຝຶກຕອບໂດຍໃຊ້ພາສາ shared responsibility + PDPA.

Milestone: ທ່ານສາມາດອະທິບາຍ shared responsibility model ແລະ ຄວາມໝາຍພາກປະຕິບັດຂອງ PDPA ໃຫ້ເຈົ້າຂອງທຸລະກິດໄທທີ່ບໍ່ແມ່ນສາຍເຕັກນິກຟັງໄດ້ ພາຍໃນສາມນາທີ — ເພາະຄຳອະທິບາຍນັ້ນ ຄື ກອງປະຊຸມຂາຍຂອງ MSP ນັ້ນເອງ.

Module 7 (ອາທິດທີ 13–14): ເລື່ອງເງິນ — ເສດຖະສາດ cloud ແລະ FinOps

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

ມິເຕີແລ່ນແນວໃດ: compute ຄິດເງິນຕໍ່ວິນາທີທີ່ມັນ ເປີດຢູ່ (ບໍ່ແມ່ນຕໍ່ການໃຊ້ — server ທີ່ວ່າງເປົ່າກໍຄິດເງິນເຕັມ; “ພວກເຮົາລືມປິດມັນ” ຄືການສູນເສຍແບບຄລາສສິກ), storage ຄິດຕໍ່ GB-ເດືອນ, ແລະ — ກັບດັກທີ່ໂດ່ງດັງ — egress (ຂໍ້ມູນຂາອອກ): ຂໍ້ມູນທີ່ໄຫຼ ອອກ ຈາກ cloud ເສຍເງິນ ໃນຂະນະທີ່ຂໍ້ມູນຂາເຂົ້າຟຣີ. ໃບບິນ egress ກ້ອນໃຫຍ່ ເຮັດເສີຍໃຈທຸກຄົນເທື່ອໜຶ່ງ; ຫຼັງ module ນີ້, ຈະບໍ່ແມ່ນທ່ານ.

ເມນູລາຄາ: on-demand (ລາຄາເຕັມ, ຍືດຍຸ່ນເຕັມທີ) · reserved instances / savings plans (ຜູກມັດ 1–3 ປີ ແລກກັບສ່ວນຫຼຸດ 30–70% — ຄັນໂຍກໃຫຍ່ທີ່ສຸດອັນດຽວ ສຳລັບ workload ທີ່ນິ້ງ) · spot instances (ຫຼຸດເຖິງ 90% ສຳລັບວຽກທີ່ຂັດຈັງຫວະໄດ້ ເຊັ່ນ batch job) · rightsizing (server ສ່ວນໃຫຍ່ຖືກຈັດຂະໜາດເກີນຕົວ; ການຫົດມັນລົງຄືເງິນຟຣີ) · storage tiering (Module 2) · auto-scaling ໃນຖານະເຄື່ອງມືປະຢັດ (ຈະຈ່າຍຄ່າຄວາມສາມາດຕອນທ່ຽງຄືນ ໃນລາຄາຕອນທ່ຽງວັນເຮັດຫຍັງ?).

FinOps (ວິໄນການບໍລິຫານການເງິນ cloud) ຄືການປະຕິບັດເພື່ອເຮັດໃຫ້ລາຍຈ່າຍ cloud ເບິ່ງເຫັນໄດ້, ຈັດສັນໄດ້, ແລະ ຖືກປັບປຸງຢ່າງຕໍ່ເນື່ອງ: tagging ທຸກຊັບພະຍາກອນ ດ້ວຍເຈົ້າຂອງ ແລະ ໂຄງການຂອງມັນ (ລາຍຈ່າຍທີ່ບໍ່ມີ tag ຄືລາຍຈ່າຍທີ່ບໍ່ມີໃຜຮັບຜິດຊອບ), showback/chargeback (ສະແດງໃບບິນຂອງແຕ່ລະທີມໃຫ້ເຂົາເຫັນ — ພຶດຕິກຳປ່ຽນທັນທີ), ງົບປະມານພ້ອມ alert (ຢ່າຄົ້ນພົບການໃຊ້ເກີນຈາກໃບແຈ້ງໜີ້ເດັດຂາດ), ແລະ unit economics (ເສດຖະສາດຕໍ່ຫົວໜ່ວຍ) — ຕົວຊີ້ວັດຂອງຜູ້ນຳ: ບໍ່ແມ່ນ “ໃບບິນຂອງເຮົາ ฿800k/ເດືອນ” ແຕ່ແມ່ນ “ຕົ້ນທຶນ ຕໍ່ທຸລະກຳຂອງລູກຄ້າ ຂອງເຮົາກຳລັງຫຼຸດລົງ.” ໃບຢັ້ງຢືນ FinOps Certified Practitioner ໃຊ້ເວລາປະມານສອງອາທິດ ແລະ ສຳລັບຜູ້ນຳສາຍທຸລະກິດ ມັນຄືໃບຢັ້ງຢືນທີ່ໃຫ້ຄວາມໜ້າເຊື່ອຖືສູງສຸດຕໍ່ຊົ່ວໂມງ ໃນໂລກ cloud ທັງໝົດ. ໄປເອົາມາ.

ຄຳຖາມເລື່ອງເງິນຂອງຜູ້ນຳ: “What’s our cost per [customer/transaction/tenant], and which direction is it moving?” (ຕົ້ນທຶນຕໍ່ [ລູກຄ້າ/ທຸລະກຳ/tenant] ຂອງເຮົາແມ່ນເທົ່າໃດ, ແລະ ມັນກຳລັງເຄື່ອນໄປທາງໃດ?) · “What percentage of our steady workload is on reservations?” (ຈັກເປີເຊັນຂອງ workload ນິ້ງໆຂອງເຮົາ ຢູ່ໃນ reservation?) · “What’s untagged?” (ຫຍັງແດ່ບໍ່ມີ tag?) · “What died but is still billing?” (ຫຍັງຕາຍແລ້ວແຕ່ຍັງຄິດເງິນຢູ່?) (ດິສກຳພ້າ ແລະ IP ວ່າງເປົ່າ — ທຸກບັນຊີມີ) · “What would this bill look like at 10× growth — does our architecture get cheaper or more expensive per unit?” (ໃບບິນນີ້ຈະເປັນແນວໃດ ຖ້າເຕີບໂຕ 10 ເທົ່າ — ສະຖາປັດຕະຍະກຳຂອງເຮົາ ຖືກລົງ ຫຼື ແພງຂຶ້ນຕໍ່ຫົວໜ່ວຍ?)

ຄຳສັບ:

ວິດີໂອສຳລັບ module ນີ້: What is FinOps? — FinOps Foundation (official) — 2 ນາທີ — https://www.youtube.com/watch?v=Y-c_xw9bHFw · ຈາກນັ້ນຮຽນຄອສຟຣີ “Introduction to FinOps” ທີ່ https://learn.finops.org.

ບົດຝຶກຫັດ: (1) ເປີດ AWS pricing calculator ແລ້ວຄິດໄລ່ລາຄາລະບົບຈິງຂະໜາດນ້ອຍ (server ສອງໜ່ວຍ, database ໜຶ່ງອັນ, storage 500GB, egress 1TB) — ການໄດ້ເຮັດມັນເທື່ອດຽວ ຈະປົດຄວາມລຶກລັບຂອງທຸກບົດສົນທະນາເລື່ອງຕົ້ນທຶນໃນອະນາຄົດ. (2) ຂໍໃຫ້ AI ສະແດງບົດເປັນວິສະວະກອນ ທີ່ປົກປ້ອງ server ຂະໜາດເກີນຕົວ; ຝຶກເຈລະຈາການ rightsizing ຢ່າງອ່ອນໂຍນ.

Milestone: ສອບເສັງ (ຫຼືນັດສອບ) FinOps Practitioner, ແລະ ໃນການທົບທວນຈຳລອງ, ຊອກຫາບັນຫາຕົ້ນທຶນສີ່ອັນ ໃນໃບບິນຕົວຢ່າງທີ່ AI ສ້າງໃຫ້ທ່ານ.

Module 8 (ອາທິດທີ 15–16): ຄ້າຍຝຶກຄວາມຄ່ອງແຄ້ວ — ປະກອບພາສາເຂົ້າກັນ

ສອງອາທິດນີ້ຄືການບູລະນາການລ້ວນໆ — ຄວາມແຕກຕ່າງລະຫວ່າງການຮູ້ຄຳສັບ ກັບ ການຄ່ອງແຄ້ວໃນຫ້ອງປະຊຸມ.

ບົດຝຶກປະຈຳວັນ (30 ນາທີ): ໃຫ້ AI ສ້າງບົດບັນທຶກກອງປະຊຸມທີ່ສົມຈິງ (design review, incident retro, ຫຼື cost review), ໂດຍຝັງຂໍ້ຜິດພາດທາງເຕັກນິກສອງອັນໄວ້ໂດຍເຈດຕະນາ. ວຽກຂອງທ່ານ: ສະຫຼຸບກອງປະຊຸມໃນຫ້າປະໂຫຍກ, ຈັບຂໍ້ຜິດພາດ, ແລະ ຂຽນສາມຄຳຖາມທີ່ທ່ານຄົງຈະໄດ້ຖາມ. ສະຫຼັບປະເພດກອງປະຊຸມທຸກມື້.

ກ້າມການແປຄວາມ (15 ນາທີ): ເອົາຄຳເວົ້າທາງເຕັກນິກມື້ລະໜຶ່ງອັນ ແລ້ວແປໃຫ້ສາມກຸ່ມຜູ້ຟັງ — CFO (ເງິນ), ລູກຄ້າ (ຄວາມສ່ຽງ/ຜົນປະໂຫຍດ), ແລະ ວິສະວະກອນຈູເນຍໃໝ່ (ການສອນ). ຕົວຢ່າງ: “ພວກເຮົາກຳລັງຍ້າຍ session store ຈາກ database ໄປ Redis” → CFO: “ຫຼຸດພາລະ database ຈຶ່ງເລື່ອນການອັບເກຣດມູນຄ່າ ฿2M ອອກໄປໄດ້” → ລູກຄ້າ: “ໜ້າເວັບໂຫຼດໄວຂຶ້ນຕອນຄົນຫຼາຍ” → ຈູເນຍ: “Redis ເກັບຂໍ້ມູນ hot ໄວ້ໃນ memory, ພວກເຮົາຈຶ່ງເຊົາທຸບ database ໃນທຸກຄລິກ.”

ຝຶກອ່ານ (15 ນາທີ): ບົດຄວາມ engineering blog ຈິງມື້ລະບົດ (AWS Architecture Blog, ຫຼື blog ວິສະວະກຳຂອງ Netflix/Grab — Grab ກ່ຽວຂ້ອງເປັນພິເສດ: ຂະໜາດລະດັບອາຊີຕາເວັນອອກສຽງໃຕ້, ຕະຫຼາດໃກ້ຄຽງໄທ). ຕອນນີ້ທ່ານຈະເຂົ້າໃຈ 70–80% ຂອງພວກມັນ. ຄົ້ນຫາສ່ວນທີ່ເຫຼືອ.

ຄູ່ຮ່ວມກຽມສອບຂອງໄລຍະນີ້: ຄອສເຕັມຟຣີທີ່ໂດ່ງດັງ — AWS Certified Cloud Practitioner (CLF-C02) 2026 ໂດຍ Andrew Brown ທາງ freeCodeCamp — https://www.youtube.com/watch?v=7HKot-brXFE (ສະບັບກ່ອນໜ້າຄວາມຍາວ 14 ຊົ່ວໂມງ, ໃຊ້ໄດ້ກັບລະຫັດສອບດຽວກັນ, ຢູ່ທີ່ https://www.youtube.com/watch?v=NhDYbskXRgc). ເບິ່ງທີ່ຄວາມໄວ 1.25× ຕະຫຼອດອາທິດທີ 13–16; ຫຼັງຈາກ Module 1–7 ສ່ວນໃຫຍ່ຂອງມັນຈະຮູ້ສຶກຄືການທວນຄືນ, ຊຶ່ງນັ້ນແຫຼະຄືສັນຍານວ່າທ່ານພ້ອມແລ້ວ.

Milestone — ຈົບໄລຍະທີ 2, ການສອບຈົບຊັ້ນຂອງທ່ານ: (1) ສອບຜ່ານ AWS Cloud Practitioner ຖ້າຍັງບໍ່ທັນຜ່ານ. (2) ດ່ານທົດສອບຈຳລອງ: AI ສະແດງບົດເປັນວິສະວະກອນອາວຸໂສ ພາທ່ານຍ່າງຜ່ານສະຖາປັດຕະຍະກຳທີ່ມີຂໍ້ບົກພ່ອງ ສຳລັບລູກຄ້າ e-commerce ໄທ; ທ່ານຕ້ອງພົບ database ທີ່ເປັນ single-AZ, S3 bucket ທີ່ເປັນ public, ການປະເມີນ egress ທີ່ຂາດຫາຍ, ແລະ ການພິຈາລະນາ PDPA ທີ່ບໍ່ມີ — ແລ້ວສົ່ງມອບຄຳຕິຊົມ ດ້ວຍນ້ຳສຽງທີ່ເຮັດໃຫ້ “ວິສະວະກອນ” ຮູ້ສຶກວ່າຖືກຊ່ວຍ, ບໍ່ແມ່ນຖືກຈັບຜິດ. ເມື່ອທ່ານເຮັດໄດ້, ທ່ານກໍເປັນຄົນທີ່ໜ້າຢຳເກງໃນການສົນທະນາແລ້ວ, ພຽງສິບຫົກອາທິດເທົ່ານັ້ນ.

ໄລຍະທີ 3 — ນຳພາ (ເດືອນທີ 5–24)

Module 9 (ເດືອນທີ 5–8): ໃບຢັ້ງຢືນຂັ້ນເລິກ ແລະ ພື້ນຖານທາງເຕັກນິກ

ຮຽນເນື້ອຫາ AWS Solutions Architect Associate (SAA-C03) — 2–3 ເດືອນ ຕາມຈັງຫວະໜຶ່ງຊົ່ວໂມງຕໍ່ມື້ຂອງທ່ານ. ທ່ານອາດຈະສອບ ຫຼື ບໍ່ສອບກໍໄດ້ (ໃນຖານະຜູ້ນຳ, ເນື້ອຫາ ຄືຄຸນຄ່າ; ກາໝາຍເປັນພຽງລະຄອນເສີມ), ແຕ່ນີ້ຄືບ່ອນທີ່ region, VPC, IAM, ແລະ ລາຄາ ຢຸດເປັນພຽງຄຳສັບ ແລ້ວກາຍເປັນລະບົບທີ່ເຊື່ອມໂຍງກັນໃນຫົວຂອງທ່ານ. ຄຽງຄູ່ກັນ, ຮັກສາບົດຝຶກປະຈຳວັນຂອງ Module 8 ໄວ້ເຄິ່ງໂດສ. ນີ້ຍັງເປັນຊ່ວງເວລາທີ່ຈະເພີ່ມ Azure fundamentals (ລະດັບ AZ-900) — ປະເທດໄທເປັນຕະຫຼາດວິສາຫະກິດທີ່ໜັກໄປທາງ Microsoft, ແລະ ຄວາມຮູ້ສອງພາສາ (AWS+Azure) ຂະຫຍາຍວົງສົນທະນາກັບລູກຄ້າຂອງທ່ານ.

Module 10 (ເດືອນທີ 5–12, ດຳເນີນຕໍ່ເນື່ອງ): ການຈ້າງ ແລະ ຄຸ້ມຄອງວິສະວະກອນ

ການຈ້າງເມື່ອທ່ານຕັດສິນທັກສະເອງບໍ່ໄດ້ເຕັມທີ: ໂຄງສ້າງຊະນະສັນຊາດຕະຍານ. ໃຊ້ວົງຈອນທີ່ຄົງເສັ້ນຄົງວາ: ການສົນທະນາຄັດກອງທີ່ທ່ານນຳເອງ (ແຮງຈູງໃຈ, ການສື່ສານ, ວິທີເຂົາອະທິບາຍໂຄງການເກົ່າ ໃຫ້ຄົນທີ່ບໍ່ແມ່ນວິສະວະກອນຟັງ — ຖ້າເຂົາເຮັດບໍ່ໄດ້, ເຂົາກໍຈະລົ້ມເຫຼວກັບລູກຄ້າຂອງທ່ານເຊັ່ນກັນ) + ການສຳພາດເຕັກນິກ ດຳເນີນໂດຍ bar-raiser ຂອງທ່ານ (ຜູ້ຊ່ວຍເຕັກນິກໝາຍເລກສອງຂອງທ່ານ ຫຼື ຜູ້ຮັບເໝົາອາວຸໂສທີ່ຈ້າງມາ) + ການໂທຫາຜູ້ອ້າງອີງ ບ່ອນທີ່ທ່ານຖາມພຽງໜຶ່ງຄຳຖາມທີ່ສຳຄັນແທ້: “would you hire this person again for this role?” (ທ່ານຈະຈ້າງຄົນນີ້ອີກຄັ້ງ ສຳລັບຕຳແໜ່ງນີ້ບໍ?) ລະວັງສອງແບບຢ່າງແຫ່ງຄວາມລົ້ມເຫຼວ: ນັກເວົ້າຄ່ອງທີ່ບໍ່ມີຄວາມເລິກ (bar-raiser ຂອງທ່ານຈະຈັບໄດ້) ແລະ ຜູ້ຊ່ຽວຊານເລິກແຕ່ມິດງຽບ (ມັກເປັນຄຳໃນທີມໄທ, ບ່ອນທີ່ຄວາມຖ່ອມຕົນເປັນວັດທະນະທຳ — ຢ່າໃຫ້ຄວາມມັນວາວໃນການສຳພາດ ມີນ້ຳໜັກກວ່າຫຼັກຖານຂອງຜົນງານຈິງ).

ຜູ້ຊ່ວຍເຕັກນິກໝາຍເລກສອງ — ການຕັດສິນໃຈສຳຄັນທີ່ສຸດຂອງກິດຈະການ: ຈ້າງເຂົາກ່ອນໝູ່, ຈ່າຍດ້ວຍຫຸ້ນທີ່ມີຄວາມໝາຍ (10–20% ຖ້າເປັນ co-founder ແທ້ໆ), ແລະ ກຳນົດຂໍ້ຕົກລົງຢ່າງຈະແຈ້ງ: ເຂົາຖືມາດຕະຖານເຕັກນິກ ແລະ ເປັນເຈົ້າຂອງການຕັດສິນໃຈດ້ານສະຖາປັດຕະຍະກຳ; ທ່ານເປັນເຈົ້າຂອງລູກຄ້າ, ເງິນ, ບູລິມະສິດ, ແລະ ຄົນ; ຄວາມເຫັນຕ່າງລະຫວ່າງທ່ານທັງສອງ ເກີດຂຶ້ນເປັນການສ່ວນຕົວ ແລະ ແກ້ໄຂໃຫ້ຈົບກ່ອນທີມຈະເຫັນ.

ພິທີກຳທີ່ເຮັດໃຫ້ວິສະວະກອນຢູ່ຕໍ່: 1:1 ທຸກອາທິດ ຫຼື ສອງອາທິດຕໍ່ຄັ້ງ ທີ່ເປັນເລື່ອງຂອງ ເຂົາ (ອາຊີບ, ຄວາມຝືດ, ພະລັງງານ — ບໍ່ແມ່ນລາຍງານສະຖານະ); ເສັ້ນທາງເຕີບໂຕເປັນລາຍລັກອັກສອນ ຕໍ່ຄົນ (ໃນຕະຫຼາດຂາດແຄນຄົນເກັ່ງ 70k/ປີ ຂອງໄທ, ງົບການເຕີບໂຕ ແລະ certification ຮັກສາຄົນໄດ້ດີກວ່າເງິນເດືອນຢ່າງດຽວ — ຈ່າຍໃຫ້ທຸກ cert, ພ້ອມໂບນັດ vesting 12 ເດືອນ ເມື່ອສຳເລັດ); ຍ້ອງຍໍໃນທີ່ແຈ້ງ, ຕັກເຕືອນໃນທີ່ລັບ; ແລະ ປົກປ້ອງເວລາສະມາທິຂອງເຂົາຢ່າງເດັດດ່ຽວ — ຜູ້ນຳທີ່ຍົກເລີກກອງປະຊຸມກາງ sprint ຄືວິລະບຸລຸດ.

ເວທີຕັດສິນໃຈ — ວິທີທີ່ທ່ານຕັດສິນເລື່ອງເຕັກນິກ ທີ່ທ່ານປະເມີນເອງບໍ່ໄດ້ເຕັມທີ: ສຳລັບທຸກການຕັດສິນໃຈໃຫຍ່, ຮຽກຮ້ອງ decision doc (ເອກະສານການຕັດສິນໃຈ) ໜຶ່ງໜ້າ ຈາກວິສະວະກອນຜູ້ສະເໜີ: ບັນຫາ, ທາງເລືອກ 2–3 ທາງ, ຕົ້ນທຶນ, ຄວາມສ່ຽງ, ຂໍ້ແນະນຳ. ຈາກນັ້ນດຳເນີນກອງປະຊຸມ ດ້ວຍເຈັດຄຳຖາມຂອງທ່ານຈາກ Module 5. ທ່ານບໍ່ແມ່ນສະຖາປະນິກທີ່ສະຫຼາດທີ່ສຸດໃນຫ້ອງ ແລະ ບໍ່ຈຳເປັນຕ້ອງເປັນຈັກເທື່ອ — ທ່ານຄືຄົນທີ່ເຮັດໃຫ້ທາງເລືອກທີ່ ຖືກໂຕ້ແຍ້ງມາດີທີ່ສຸດ ຊະນະ, ຕາມກຳນົດເວລາ, ໂດຍການແລກປ່ຽນເລື່ອງເງິນ ແລະ ຄວາມສ່ຽງຖືກເຮັດໃຫ້ຈະແຈ້ງ. ວິສະວະກອນນັບຖືສິ່ງນີ້ຢ່າງເລິກເຊິ່ງ ເມື່ອມັນຖືກເຮັດຢ່າງຊື່ສັດ; ຈົດໄວ້ວ່າໃຜທຳນາຍຫຍັງ (Decision Journal ຂອງທ່ານອີກແລ້ວ) ແລະ ທົບທວນຄຳທຳນາຍທຸກໄຕມາດ — ມັນປັບຄວາມແມ່ນຢຳທັງຂອງທ່ານ ແລະ ຂອງເຂົາ.

Module 11 (ເດືອນທີ 6–24): ເສັ້ນໂຄ້ງຄວາມໜ້າເຊື່ອຖື, ຢ່າງກົງໄປກົງມາ

ປະສົບການທີ່ຕີພິມ ຈາກວັນນະຄະດີການນຳພາດ້ານວິສະວະກຳ ບັນຈົບກັນທີ່ເສັ້ນເວລານີ້, ແລະ ການທຳທ່າວ່າບໍ່ແມ່ນ ຄືວິທີທີ່ຜູ້ກໍ່ຕັ້ງສາຍບໍ່ແມ່ນເຕັກນິກລົ້ມເຫຼວ: ~90 ວັນ ເພື່ອດຳເນີນຈັງຫວະທຸລະກິດຢ່າງມີຄວາມສາມາດ · ~6 ເດືອນ ສູ່ປະສິດທິຜົນຂັ້ນພື້ນຖານ (ປະຊຸມຄ່ອງແຄ້ວ, ຕັດສິນໃຈມີໂຄງສ້າງ, ທີມໝັ້ນຄົງ) · 12–18 ເດືອນ ກ່ອນສັນຊາດຕະຍານທາງເຕັກນິກຂອງທ່ານ ຈະມີຄ່າດ້ວຍຕົວມັນເອງ · ~2 ປີ ກ່ອນທ່ານຈະຢືນຢູ່ໄດ້ຢ່າງແທ້ຈິງ ຕໍ່ໜ້າວິສະວະກອນອາວຸໂສ ໃນເລື່ອງການແລກປ່ຽນທາງສະຖາປັດຕະຍະກຳ. ວິທີບັນເທົາໃນຂະນະທີ່ເສັ້ນໂຄ້ງໄຕ່ຂຶ້ນ: ຢືມຄວາມໜ້າເຊື່ອຖື (ໝາຍເລກສອງຂອງທ່ານ ນຳສະເໜີເຄິ່ງເຕັກນິກຂອງກອງປະຊຸມຂາຍ — ລູກຄ້າຕ້ອງເຫັນທີມສຳຮອງຢູ່ແລ້ວ), ຢ່າຕົວະເດັດຂາດ (ຕົວທຳລາຍຄວາມໜ້າເຊື່ອຖືທີ່ໄວທີ່ສຸດ; “I don’t know — walk me through it” (ຂ້ອຍບໍ່ຮູ້ — ພາຂ້ອຍຜ່ານມັນແດ່) ຄືປະໂຫຍກຂອງຜູ້ນຳ), ແລະ ປ່ອຍໃຫ້ຄຳຖາມຂອງທ່ານເປັນຜູ້ເວົ້າແທນ: ຜູ້ນຳທີ່ຖາມ “what’s our RPO and who signed off on it?” (RPO ຂອງເຮົາແມ່ນເທົ່າໃດ ແລະ ໃຜອະນຸມັດ?) ຟັງຄືມີແຜ່ນເປັນສາມສິບປີ, ແລະ ຫຼັງຫຼັກສູດນີ້, ທ່ານຈະໝາຍຄວາມຕາມນັ້ນແທ້.

Module 12 (ຕໍ່ເນື່ອງ): ຊັ້ນຕະຫຼາດໄທ

ນຳເອົາລາຍລະອຽດຈາກ TSI Part 5 ມາເປັນຄວາມຮູ້ປະຕິບັດງານ: PDPA ໃນຖານະທັງໜ້າທີ່ຕາມກົດໝາຍ ແລະ ຜະລິດຕະພັນ (§Module 6); ບັນໄດຄູ່ຮ່ວມທຸລະກິດ (AWS Select ຕ້ອງການພະນັກງານມີ cert ຈຳນວນໜຶ່ງ + 3 ດີລທີ່ launch ແລ້ວ; Microsoft Solutions Partner ຕ້ອງການຄະແນນຄວາມສາມາດ 70/100 — certification ຂອງທີມທ່ານ ຄືຊັບສິນການຂາຍໂດຍກົງ, ອີກເຫດຜົນໜຶ່ງທີ່ຄວນອອກທຶນໃຫ້); ການສົ່ງເສີມ BOI ສຳລັບການຖືຫຸ້ນຕ່າງຊາດ 100% ຂອງບໍລິສັດ; ຂັ້ນເງິນເດືອນບາງກອກ (ຈູເນຍ ฿50–75k → architect ฿180–280k/ເດືອນ) ເພື່ອຕັ້ງລາຄາປະມູນ ແລະ ຂໍ້ສະເໜີຈ້າງໄດ້ຖືກຕ້ອງ; ແລະ ເລກຄະນິດການຂາຍຂອງຊ່ວງເວລານີ້ — ການລົງທຶນ data center ທີ່ອະນຸມັດແລ້ວກວ່າ $27B, ຄຳສັ່ງ cloud-first ຂອງລັດຖະບານ, ແລະ ຊ່ອງວ່າງທັກສະ 70,000 ຄົນ/ປີ ທີ່ທີມງານມີ cert ຂອງທ່ານມີໄວ້ເພື່ອຕື່ມເຕັມ.

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

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

ເອກະສານປະກອບຂອງ “The Thailand Strategic Investment (TSI),” Part 5. ການປະເມີນເວລາກຽມສອບ certification ແລະ ເສັ້ນເວລາການນຳພາ ອ້າງອີງຈາກແຫຼ່ງທີ່ອ້າງໄວ້ໃນນັ້ນ (CBT Nuggets, StudyTech, FinOps Foundation, First Round Review, The Pragmatic Engineer).