หลักสูตรสถาปนิกคลาวด์ (The Cloud Architect Course)

จากความรู้ศูนย์ สู่การออกแบบระบบคลาวด์ที่บริษัทกล้าเอาธุรกิจมาเดิมพัน

หลักสูตรนี้ทำงานอย่างไร

คุณไม่ได้กำลังฝึกเพื่อปฏิบัติการระบบคลาวด์ คุณกำลังฝึกเพื่อออกแบบมัน: รับโจทย์ธุรกิจที่ยุ่งเหยิง (“เราต้องขายให้ลูกค้าหนึ่งล้านคนโดยไม่ทำออเดอร์หายแม้แต่รายการเดียว”) แปลงมันเป็นแผนทางเทคนิคที่วาดออกมาแล้ว คิดต้นทุนแล้ว และปกป้องได้ด้วยเหตุผล จากนั้นโน้มน้าวทั้งวิศวกรที่จะสร้างมันและผู้บริหารที่จะจ่ายเงิน นั่นคืองานของ cloud architect (สถาปนิกคลาวด์ — ในประกาศงานยังใช้ชื่อ solutions architect, cloud solutions architect หรือ cloud domain architect) และมันเป็นงานฝีมือที่เรียนรู้ได้ โดยมีหลักสูตรที่ชัดเจน — เล่มนี้แหละ

หลักสูตรแบ่งเป็นห้าช่วง ช่วงที่ 1 (สัปดาห์ 1–6): องค์ประกอบพื้นฐาน ในฐานะการตัดสินใจ ทุกส่วนประกอบของคลาวด์ ถูกสอนใหม่ไม่ใช่ในฐานะข้อเท็จจริง แต่ในฐานะทางเลือกที่มี trade-off (การแลกเปลี่ยนได้อย่างเสียอย่าง) — เพราะหน่วยของงานของสถาปนิกคือการตัดสินใจ ช่วงที่ 2 (สัปดาห์ 7–14): อาณาเขตของการออกแบบ หกเสาหลักของ Well-Architected Framework — reliability, security, performance, cost, operations, sustainability — สอนลึกทีละเสา พร้อมแพตเทิร์นมาตรฐานและงานออกแบบตัวอย่าง ช่วงที่ 3 (สัปดาห์ 15–20): แค็ตตาล็อกแพตเทิร์น สถาปัตยกรรมราวหนึ่งโหลที่แก้ปัญหาจริงได้ 95% และ — สำคัญกว่านั้น — เมื่อไหร่ที่ไม่ควรใช้แต่ละตัว ช่วงที่ 4 (สัปดาห์ 21–26): การย้ายระบบและโลกจริง การพาบริษัทที่มีอยู่แล้วขึ้นคลาวด์ และข้อจำกัดต่าง ๆ (กฎหมาย ระบบเก่า การผูกติดผู้ให้บริการ) ที่ทำให้สถาปัตยกรรมจริงยากกว่าสถาปัตยกรรมบนไวต์บอร์ด ช่วงที่ 5 (เดือน 7–12): งานฝีมือ เอกสาร แผนภาพ การรีวิว การนำเสนอ และใบรับรองที่ทำให้คุณมีนายจ้างอยากได้ในฐานะสถาปนิก ปิดท้ายด้วยโปรเจกต์ออกแบบระดับพอร์ตโฟลิโอสามชิ้น

หลักสูตรนี้เหมาะกับใคร มันตั้งสมมติฐานว่าคุณไม่มีความรู้มาก่อน: ทุกสิ่งที่มันพึ่งพาถูกสอนซ้ำสั้น ๆ ก่อนถูกใช้งาน ถ้าคุณเรียนจบ The Cloud Engineer Course มาแล้ว (หรือทำงานคลาวด์ภาคปฏิบัติอยู่ทุกวันนี้) ช่วงที่ 1 จะคุ้นเคย — อ่านผ่าน ๆ ได้ แต่ทำแบบฝึกหัดของมันเสมอ เพราะมันจัดกรอบใหม่ให้สิ่งที่คุณรู้ในฐานะข้อเท็จจริง กลายเป็นสิ่งที่คุณต้องชั่งน้ำหนักในฐานะการตัดสินใจ และการจัดกรอบใหม่นั้นแหละคือการเปลี่ยนผ่านทั้งหมดจากวิศวกรสู่สถาปนิก

กติกาตลอดหลักสูตร: เรียนวันละหนึ่งชั่วโมง หกวันต่อสัปดาห์ — ความสม่ำเสมอชนะความหักโหม ทุกโมดูลจบด้วย ตารางคำศัพท์ (คำที่คุณต้องเป็นเจ้าของให้ได้), แบบฝึกหัด (งานออกแบบ ไม่ใช่การอ่าน — สถาปัตยกรรมเรียนรู้ด้วยการวาดและการตัดสินใจ) และ Milestone (หมุดหมาย — หลักฐานว่าคุณพร้อมไปต่อ; อย่าข้าม milestone ที่ยังไม่ผ่าน) และตั้งแต่สัปดาห์ที่ 1 ให้จด Design Journal (สมุดบันทึกการออกแบบ): ทุกสถาปัตยกรรมที่คุณวาด ทุก trade-off ที่คุณชี้ ทุกคำทำนายเรื่องต้นทุนหรือความล้มเหลวที่คุณทำ อีกสิบเดือนจากนี้มันจะกลายเป็นพอร์ตโฟลิโอสัมภาษณ์ของคุณ; ไม่มีอะไรทำให้กรรมการจ้างงานประทับใจเท่าสมุดบันทึกลงวันที่ที่มีสี่สิบงานออกแบบพร้อมโน้ตซื่อสัตย์ว่าคุณพลาดตรงไหน

สถาปนิกคลาวด์ทำอะไรกันแน่

นึกถึงสถาปนิกอาคาร เธอไม่ได้ก่ออิฐเอง — แต่เธอต้องรู้เป๊ะว่าอิฐทำอะไรได้และไม่ได้ ราคาเท่าไหร่ และอาคารพังอย่างไร เธอฟังลูกค้า (“บ้านครอบครัว แดดดี ภายใต้งบนี้ บนที่ดินรูปทรงลำบากแปลงนี้”) แล้วแปลงความอยากและข้อจำกัดให้เป็นแบบและสเปกที่แม่นยำพอให้ช่างก่อสร้างสร้างตามได้ และลูกค้าเซ็นอนุมัติได้ จากนั้นเธออยู่ต่อตลอดการก่อสร้าง คอยตอบคำถามและปรับแผนเมื่อพื้นดินกลายเป็นนุ่มกว่าที่ผลสำรวจบอก

สลับอิฐเป็น server แล้วนั่นคืองานนี้ สถาปนิกคลาวด์ใช้สัปดาห์ไปกับส่วนผสมของ: การฟังผู้มีส่วนได้ส่วนเสียฝั่งธุรกิจและสกัดความต้องการจริงจากความปรารถนาคลุมเครือ; การออกแบบ — เลือกส่วนประกอบ วาดแผนภาพ จดการตัดสินใจและเหตุผล; การรีวิวงานออกแบบของคนอื่นเทียบกับหกเสาหลัก; การประมาณว่างานออกแบบหนึ่งจะมีค่าใช้จ่ายต่อเดือนเท่าไหร่ และปกป้องตัวเลขนั้นต่อหน้าฝ่ายการเงิน; การวางแผนย้ายระบบเก่าขึ้นคลาวด์; การนำเสนอ — งานออกแบบเดียวกันที่อธิบายแบบหนึ่งให้วิศวกร และอีกแบบที่ต่างสิ้นเชิงให้ผู้บริหาร; และการเป็นพี่เลี้ยงวิศวกร เพื่อให้มาตรฐานอยู่รอดเมื่อปะทะกับเดดไลน์ ในหลายทีมยังมี pre-sales: นั่งข้างพนักงานขายต่อหน้าลูกค้ามุ่งหวัง แล้วสเก็ตช์โซลูชันที่ปิดดีลได้

สิ่งที่สถาปนิกไม่ใช่: คนเขียนโค้ดเก่งสุดในห้อง (มักไม่ใช่), คนพิมพ์เยอะสุด (พิมพ์น้อยสุด) หรืออัจฉริยะสันโดษที่ยื่นพิมพ์เขียวลงมา (วิธีเร็วสุดที่จะถูกเมิน) ผลผลิตจริงของสถาปนิกคือ การตัดสินใจที่ดี ที่ถูกเขียนบันทึกไว้ และคนอื่นเต็มใจสร้างตาม

ประกาศรับสมัครงานที่คุณกำลังฝึกเพื่อให้ตรงตาม

ในเดือนสิงหาคม 2569 เราได้รวบรวมประกาศงานและเทมเพลตตำแหน่ง Cloud/Solutions Architect จริง ๆ — เทมเพลต cloud architect ของ recruiter (KORE1), job description ของบริษัทจัดหางาน (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) เมื่อลอกกลิ่นอายบริษัทออก ข้อกำหนดสิบสองข้อชุดเดิมก็ปรากฏซ้ำแล้วซ้ำเล่า หลักสูตรนี้สร้างขึ้นตามรายการนั้น — นี่คือจุดที่แต่ละข้อถูกสอนเป๊ะ ๆ:

ใบรับรอง ตรวจสอบกับตลาดเดียวกัน: บันไดมาตรฐานคือ 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 โมดูล 14

ช่วงที่ 1 — องค์ประกอบพื้นฐาน ในฐานะการตัดสินใจ (สัปดาห์ 1–6)

ผู้จบหลักสูตร Cloud Engineer: อ่านคำอธิบายผ่าน ๆ ได้ แต่ทำแบบฝึกหัดทุกข้อ ข้อเท็จจริงชุดเดิม แต่คำถามชุดใหม่

โมดูล 1 (สัปดาห์ 1–2): คลาวด์คืออะไร และสถาปนิกคิดอย่างไร

คลาวด์ในหนึ่งย่อหน้า (บททบทวนสำหรับผู้เริ่มจากศูนย์) คลาวด์คือ คอมพิวเตอร์ของคนอื่น เช่าเป็นรายชั่วโมง บริหารจัดการด้วยซอฟต์แวร์ AWS, Microsoft Azure และ Google Cloud รันโกดังเต็มไปด้วย server (data center — ศูนย์ข้อมูล) จัดกลุ่มเป็น Region (รีเจียน) ตามภูมิศาสตร์ (เช่น “Asia Pacific (Bangkok)”); แต่ละ region มี Availability Zone (AZ) ที่แยกอิสระหลายแห่ง — อาคารแยกกันที่มีไฟฟ้าของตัวเอง ใกล้พอให้เชื่อมต่อเร็ว ไกลพอที่น้ำท่วมหรือไฟไหม้ครั้งเดียวจะไม่กวาดไปสองแห่ง คุณเช่าส่วนแบ่งของทั้งหมดนี้เป็นรายวินาที: เครื่องเปล่า (IaaS — คุณดูแลทุกอย่างบนนั้น), แพลตฟอร์มที่มีคนดูแลให้ (PaaS — คุณนำมาแค่แอปพลิเคชัน) หรือซอฟต์แวร์สำเร็จรูป (SaaS — คุณแค่ใช้) นั่นคือพื้นฐานรองรับทั้งหมด ทุกสิ่งที่สถาปนิกออกแบบถูกจัดวางอยู่บนมัน

คราวนี้ท่าไม้ตายของสถาปนิก: เปลี่ยนทุกข้อเท็จจริงให้เป็นคำถาม วิศวกรเรียนรู้ว่า “AZ คือ data center ที่แยกอิสระ” สถาปนิกถามทันทีว่า: “workload ตัวนี้สมควรได้กี่ AZ?” — เพราะสอง AZ แพงกว่าหนึ่ง สามแพงกว่าสอง และเว็บไซต์โบรชัวร์การตลาดไม่สมควรได้สิ่งที่ระบบชำระเงินสมควรได้ นี่คือแนวคิดแรกและสำคัญที่สุดของหลักสูตร:

สถาปัตยกรรมคือวินัยของการทำให้ trade-off ปรากฏชัดแจ้ง แทบไม่มีส่วนประกอบที่ผิด — มีแต่ส่วนประกอบที่ผิดสำหรับ workload ตัวนี้ งบนี้ ทีมนี้ เดดไลน์นี้

สามเหลี่ยม trade-off ทุกงานออกแบบต่อรองระหว่างสามมุม: เร็ว (ประสิทธิภาพ — เร็วสำหรับผู้ใช้ เร็วในการสร้าง), ถูก (บิลรายเดือนต่ำ แรงวิศวกรรมต่ำ) และ ทนทาน (รอดจากความล้มเหลว ขยายได้ ปลอดภัยอยู่เสมอ) คุณดันเข้าหามุมไหนก็ได้สองมุม; มุมที่สามเป็นผู้จ่าย ต้นแบบของสตาร์ตอัปควรเร็วและถูก — ความทนทานรอได้ บัญชีแยกประเภทหลักของธนาคารต้องทนทานและเร็ว — มันจะไม่ถูก เมื่อผู้มีส่วนได้ส่วนเสียบอกว่า “เราอยากได้ทั้งสามอย่าง” งานของคุณคือยิ้มแล้วถามว่าเขาอยากได้อันไหนที่สุด เพราะงานออกแบบเริ่มไม่ได้จนกว่าเขาจะตอบ วาดสามเหลี่ยมนี้ไว้บนหัวของทุกงานออกแบบที่คุณทำในหลักสูตรนี้ และทำเครื่องหมายว่า workload อยู่ตรงไหน มันจะช่วยคุณประหยัดการถกเถียงนับพันครั้ง

Requirements: วัตถุดิบของการออกแบบ สถาปนิกแยก functional requirement (ความต้องการเชิงหน้าที่ — ระบบทำอะไร — “ลูกค้าสั่งอาหารกลางวันได้”) ออกจาก non-functional requirement (NFR) (ความต้องการที่ไม่ใช่หน้าที่ — มันต้องทำได้ดีแค่ไหน — “ภายใน 2 วินาที รองรับนักเรียนพร้อมกัน 10,000 คน 99.9% ของเวลา ภายใต้ PDPA”) มือใหม่หมกมุ่นกับรายการแรก; สถาปนิกหาเงินเดือนจากรายการที่สอง เพราะ NFR คือสิ่งที่กำหนดสถาปัตยกรรมจริง ๆ คำถามวิเศษสองข้อที่สกัด NFR ออกจากผู้มีส่วนได้ส่วนเสียที่ไม่รู้ตัวว่าตัวเองมีมัน: “What happens to the business if this is down for an hour?” (ถ้าระบบนี้ล่มหนึ่งชั่วโมง ธุรกิจจะเป็นอย่างไร?) และ “What does success look like at ten times today’s size?” (ความสำเร็จหน้าตาเป็นอย่างไรที่สเกลสิบเท่าของวันนี้?)

คำศัพท์:

วิดีโอประจำโมดูลนี้ (ตรวจสอบลิงก์แล้ว):

ดูทัวร์ของ Fireship สองรอบ: รอบแรกตอนนี้เพื่อเห็นแผนที่ รอบสองตอนจบช่วงที่ 1 — คุณจะแปลกใจว่าตอนนี้วางตำแหน่งบริการต่าง ๆ ลงในงานออกแบบได้กี่ตัวแล้ว

แบบฝึกหัด: (1) เลือกแอปที่คุณใช้ทุกวันสามตัว (แอปธนาคาร แอปสั่งอาหาร แอปวิดีโอ) แล้วเขียน NFR สามอันดับแรกของแต่ละตัว พร้อมทำเครื่องหมายบนสามเหลี่ยม trade-off (2) สัมภาษณ์เพื่อนเรื่องไอเดียธุรกิจสิบนาที แล้วสกัด functional requirement ห้าข้อกับ non-functional ห้าข้อ — สังเกตว่า NFR โผล่มาก็ต่อเมื่อคุณถามคำถามวิเศษสองข้อ (3) เริ่ม Design Journal ด้วยรายการที่ 1: สามเหลี่ยม และหนึ่งย่อหน้าว่าทำไม “เราจะสละมุมไหน?” เป็นคำถามธุรกิจ ไม่ใช่คำถามเทคนิค

Milestone: เมื่อได้รับคำบรรยายระบบหนึ่งประโยคใด ๆ คุณสร้าง NFR ที่น่าจะเป็นและตำแหน่งบนสามเหลี่ยมได้ในห้านาที ออกเสียง โดยไม่เปิดโน้ต

โมดูล 2 (สัปดาห์ 3–4): Compute, storage, database, network — สี่การตัดสินใจ

ทุกงานออกแบบที่คุณจะวาดตลอดชีวิตคือสี่ทางเลือกนี้ ตัดสินใจอย่างจงใจ นี่คือแต่ละข้อที่ถูกสอนในฐานะการตัดสินใจ

การตัดสินใจที่ 1 — Compute: VM, container หรือ serverless? virtual machine (VM) (เครื่องเสมือน) คือส่วนแบ่งของ server ที่เช่ามาและทำตัวเหมือนคอมพิวเตอร์เต็มเครื่อง — ควบคุมได้มากสุด ดูแลมากสุด (คุณแพตช์เอง ขยายเอง และจ่ายเงินแม้มันว่างงาน) container (คอนเทนเนอร์) บรรจุแอปหนึ่งตัวพร้อมทุกสิ่งที่มันต้องใช้ให้รันเหมือนกันทุกที่; ตัวจัดวงดนตรี (Kubernetes) รันและซ่อมแซมพวกมันเป็นฝูง — ความหนาแน่นและความพกพาได้เยี่ยม แต่คุณได้รับแพลตฟอร์มซับซ้อนที่ต้องการคนมีทักษะมาด้วย Serverless (เซิร์ฟเวอร์เลส — AWS Lambda, Azure Functions) รันโค้ดของคุณเฉพาะเมื่อถูก trigger และคิดเงินต่อการเรียก — การดูแลใกล้ศูนย์และเหมาะเจาะกับทราฟฟิกพุ่งเป็นช่วง ๆ แต่มีข้อจำกัด (เพดานเวลารัน, cold start และการแต่งงานลึกขึ้นกับผู้ให้บริการรายเดียว) ตารางการตัดสินใจที่คุณควรเขียนซ้ำได้จากความจำ:

ข้อคิดระดับ senior: นี่คือทางเลือกราย workload ไม่ใช่ศาสนาประจำบริษัท ระบบจริง ๆ รันทั้งสามแบบเคียงข้างกัน อย่างถูกต้อง

การตัดสินใจที่ 2 — Storage: object, block หรือ file — และร้อนแค่ไหน? Object storage (Amazon S3) คือถังไร้ก้นบึ้งสำหรับไฟล์ — ถูก ทนทานเหลือเชื่อ (“สิบเอ็ดเลขเก้า”) คำตอบมาตรฐานของ “ไฟล์ไปอยู่ไหน?” Block storage (EBS) คือดิสก์เสมือนที่ยึดติดกับ VM File storage (EFS) คือไดรฟ์แชร์ที่หลายเครื่อง mount พร้อมกัน มิติพิเศษของสถาปนิกคือ อุณหภูมิ: ข้อมูล hot (ถูกเข้าถึงตลอด ตั้งราคาเพื่อความเร็ว) กับ tier แบบ cold/archive (Glacier — ราคาหลักสตางค์ แต่ใช้เวลาดึงเป็นนาทีถึงชั่วโมง) การออกแบบ lifecycle rule ให้ข้อมูลเก่าไหลไป tier เย็นคือชัยชนะด้านต้นทุนที่ถูกที่สุดในคลาวด์; การลืมทำคือความผิดพลาดที่พบบ่อยที่สุด

การตัดสินใจที่ 3 — Database: SQL หรือ NoSQL (และรส managed ตัวไหน)? database แบบ Relational/SQL (PostgreSQL, MySQL; แบบ managed คือ RDS/Aurora) เก็บข้อมูลในตารางเข้มงวดพร้อม consistency ที่รับประกัน — ค่าเริ่มต้นสำหรับทุกอย่างที่ความถูกต้องศักดิ์สิทธิ์: เงิน คำสั่งซื้อ สินค้าคงคลัง ผู้ใช้ database แบบ NoSQL (DynamoDB, MongoDB) แลกโครงสร้างเข้มงวดกับความยืดหยุ่นและการขยายแนวนอนแทบไร้ขีดจำกัด — ค่าเริ่มต้นสำหรับ session, แค็ตตาล็อก, ฟีด, telemetry ฮิวริสติกการตัดสินใจ: เริ่มด้วย SQL เว้นแต่คุณเอ่ยชื่อเหตุผลเจาะจงได้ว่าทำไมมันไม่เวิร์ก (สเกลสุดขั้ว, schema ยืดหยุ่น, การอ่านทั่วโลกระดับมิลลิวินาทีหลักเดียว) และในคลาวด์ “database” ควรหมายถึง “managed database” แทบเสมอ — ผู้ให้บริการจัดการ backup แพตช์ และ failover; ทีมที่รัน database เองบน VM ควรมีเหตุผลเป็นลายลักษณ์อักษร เพิ่มตัวผู้เชี่ยวชาญเฉพาะทางลงคลังศัพท์ของคุณ: cache (Redis — ข้อมูลร้อนในหน่วยความจำ อ่านระดับไมโครวินาที), warehouse (วิเคราะห์ข้อมูลที่สเกล — ช่วงที่ 3), queue (ไม่ใช่ database แต่บ่อยครั้งคือชิ้นที่ขาด — ช่วงที่ 3)

การตัดสินใจที่ 4 — Network: รูปทรงของโลกส่วนตัว VPC (Virtual Private Cloud) คือส่วนที่ล้อมรั้วไว้ของคุณในเครือข่ายผู้ให้บริการ ข้างในนั้น public subnet ถือสิ่งที่อินเทอร์เน็ตเข้าถึงได้ (load balancer) และ private subnet ถือทุกอย่างที่เหลือ — app server และ, เสมอ, database “database อยู่ใน private subnet” คือประโยคที่ถูกพูดซ้ำมากที่สุดในการรีวิวสถาปัตยกรรม; เหตุผล — ไม่มีอะไรโจมตีสิ่งที่ไม่มีเส้นทางจากอินเทอร์เน็ตได้ — คือครึ่งหนึ่งของความปลอดภัยเครือข่าย รอบ ๆ VPC: load balancer กระจายทราฟฟิกข้าม server และเลี่ยงเครื่องป่วย; DNS (Route 53) แปลงชื่อเป็นที่อยู่; CDN (CloudFront) แคชเนื้อหาในเมืองหลายร้อยแห่งให้เร็วทุกที่; API gateway คือเคาน์เตอร์ประชาสัมพันธ์แบบ managed สำหรับ API ของคุณ (การยืนยันตัวตน, rate limit, การเก็บ log) การเชื่อมกับโลกเก่า: VPN (อุโมงค์เข้ารหัสบนอินเทอร์เน็ต) หรือ Direct Connect (สายกายภาพส่วนตัว) — สายสะดือของทุกงานออกแบบ hybrid ในช่วงที่ 4

คำศัพท์:

วิดีโอประจำโมดูลนี้ (ตรวจสอบลิงก์แล้ว):

แบบฝึกหัด: (1) สำหรับ workload ห้าตัวนี้ เลือก compute, database และ storage แล้วเขียนเหตุผลอย่างละหนึ่งประโยค: เว็บสั่งอาหารกลางวันของโรงเรียน; บัญชีแยกประเภทธุรกรรมของธนาคาร; แอปแชร์รูปภาพ; ตัวสร้างรายงานรายคืนที่รัน 20 นาที; แอปแชตสำหรับผู้ใช้ 5 ล้านคน (2) หยิบทางเลือกหนึ่งของคุณมาแล้วแก้ต่างให้ทางเลือกตรงข้ามอย่างน่าเชื่อที่สุดเท่าที่ทำได้ — สถาปนิกที่ steel-man ทางเลือกอื่นไม่ได้ แปลว่ายังไม่เข้าใจ trade-off (3) ลงสมุด: ตารางการตัดสินใจ compute ของคุณ จากความจำ

Milestone: เมื่อได้ workload ใดก็ตามในหนึ่งประโยค คุณเอ่ยชื่อสี่การตัดสินใจของมันพร้อมเหตุผลได้ภายในสามนาที — และสำหรับอย่างน้อยหนึ่งการตัดสินใจ เอ่ยได้ว่าอะไรจะทำให้คุณเปลี่ยนใจ

โมดูล 3 (สัปดาห์ 5–6): การอ่านและวาดแผนภาพสถาปัตยกรรม

สถาปนิกที่วาดไม่เป็นคือที่ปรึกษาที่ได้แต่พูด แผนภาพคือภาษาทำงานของคุณ: โมดูลนี้ทำให้คุณอ่านมันคล่องและวาดมันได้

แผนภาพต้นแบบ — เรียนตัวนี้ก่อน three-tier architecture (สถาปัตยกรรมสามชั้น) คือ “โครงสร้างประโยค” ของแผนภาพคลาวด์; งานออกแบบส่วนใหญ่คือรูปแปรผันของมัน:

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

Tier 1 (presentation): สิ่งที่ผู้ใช้สัมผัส — เนื้อหา static จาก CDN, คำขอผ่าน load balancer Tier 2 (application): ฝูง server ที่สับเปลี่ยนแทนกันได้ซึ่งรันตรรกะของคุณ อยู่ใน private subnet ขยายอัตโนมัติ Tier 3 (data): database ลึกสุดและถูกปกป้องมากสุด พร้อม standby ใน AZ ที่สอง ทราฟฟิกไหลทางเดียว: ผู้ใช้ไม่มีวันแตะ app tier โดยตรง และ app tier เท่านั้นที่คุยกับ data tier ฝึกวาดจนมือทำเองโดยสมองไม่ต้องสั่ง — มันคือบทเปิดของ whiteboard interview ทุกที่บนโลก

ธรรมเนียมสัญกรณ์ที่ทำให้คุณดูเป็นมืออาชีพ (เพราะมันบังคับให้คุณคิดแบบมืออาชีพ): กล่องคือส่วนประกอบ — ติดป้ายแต่ละกล่องว่าคืออะไร และ ใช้บริการไหน (“App servers — EC2, auto-scaling group”) ลูกศรแสดงทิศทางที่คำขอไหล ติดป้ายโปรโตคอลเมื่อสำคัญ กรอบเส้นประแสดงขอบเขต — VPC, แต่ละ subnet, แต่ละ AZ (วาดขอบเขต AZ แล้ว multi-AZ จะมองเห็นได้แทนที่จะเป็นแค่คำอ้าง) ผู้ใช้/actor ยืนนอกระบบ ตัวเลขบนลูกศร (1, 2, 3…) ให้คุณเล่าเส้นทางการเดินทางของคำขอ และทุกแผนภาพมีชื่อเรื่อง วันที่ และคำอธิบายสัญลักษณ์ กฎที่ลึกกว่า: หนึ่งแผนภาพ หนึ่งผู้ชม หนึ่งคำถาม แผนภาพที่โชว์ทุกอย่างเท่ากับไม่โชว์อะไรเลย; คุณจะเรียนชุดระดับซูมมาตรฐาน (context → container → deployment) ในช่วงที่ 5

การอ่านแผนภาพของคนอื่น — เอกซเรย์ของสถาปนิก เมื่อได้รับแผนภาพ ให้รันสแกนนี้ออกเสียง: อินเทอร์เน็ตแตะระบบนี้ตรงไหน (ทุกจุดสัมผัสคือ attack surface)? ข้อมูลอยู่ไหน แล้วอยู่ใน private subnet หรือเปล่า? อะไรมีตัวสำรอง (ทนทาน) และอะไรคือ single point of failure — กล่องที่ไม่มีแฝด? ที่ทราฟฟิก 10× จะเจ็บตรงไหน? แต่ละกล่องราคาเดือนละเท่าไหร่? ห้าคำถาม สามสิบวินาที แล้วคุณก็อ่านแผนภาพแบบเดียวกับที่หมออ่านฟิล์มเอกซเรย์ เข้าไปดู AWS Architecture Center (https://aws.amazon.com/architecture/) แล้วรันสแกนนี้กับ reference architecture ที่เผยแพร่ไว้สามชิ้น

คำศัพท์:

แบบฝึกหัด: (1) วาดแผนภาพสามชั้นจากความจำ ห้าวันติด จนใช้เวลาไม่ถึงสี่นาทีพร้อมขอบเขตครบ (VPC, subnet, สอง AZ) (2) หยิบ workload ห้าตัวจากโมดูล 2 มาวาดทีละตัว — ยี่สิบนาทีต่อแผนภาพ บังคับใช้กฎสัญกรณ์ (3) หาแผนภาพสถาปัตยกรรมจริงที่ไหนก็ได้ในอินเทอร์เน็ต (AWS Architecture Center มีเป็นร้อย) แล้วเขียนสแกนเอกซเรย์ห้าคำถามลงสมุด (4) แบบฝึกเล่าเรื่อง: วางแผนภาพตรงหน้า เล่าการคลิกของผู้ใช้หนึ่งคนจากเบราว์เซอร์ถึง 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” โดยเรียกชื่อตรง ๆ เราจึงไล่เสาหลักทีละตัว และแต่ละตัวคุณเรียนสามสิ่ง: คำถามหลักของเสา, แพตเทิร์นมาตรฐานของมัน (คำตอบน่าเบื่อที่พิสูจน์แล้ว — สถาปนิกประกอบก่อนคิดค้น) และตัวอย่างลงมือทำบนโจทย์ต่อเนื่อง

โจทย์ต่อเนื่องของช่วงที่ 2 ทั้งหมด: ThaiTicket แพลตฟอร์มขายบัตรอีเวนต์สมมติในกรุงเทพฯ โหลดปกติ: ผู้เข้าชม 2,000 คน/ชั่วโมง แต่เมื่อบัตรศิลปินดังเปิดขายตอน 10:00 น. มันรับผู้เข้าชม 400,000 คนในสิบนาที การชำระเงินห้ามขายที่นั่งซ้ำ และข้อมูลส่วนบุคคลของลูกค้าไทยอยู่ใต้ PDPA เร็ว ถูก ทนทาน — ThaiTicket ต้องการทั้งสามและมีไม่ได้ นั่นแหละที่ทำให้มันเป็นคนไข้ฝึกหัดที่สมบูรณ์แบบ

ดูก่อนเข้าโมดูล 4 (ตรวจสอบลิงก์แล้ว):

และบุ๊กมาร์กตัว framework เอง — https://aws.amazon.com/architecture/well-architected/ และเอกสารฉบับเต็มที่ https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html — คุณจะใช้ชีวิตอยู่ในนั้นแปดสัปดาห์

โมดูล 4 (สัปดาห์ 7–8): Reliability — ออกแบบเผื่อวันที่ของพัง

คติของเสานี้: ทุกอย่างพังได้ ตลอดเวลา ดิสก์ตาย AZ น้ำท่วม deploy ผิดพลาด และ certificate ที่ไหนสักแห่งใกล้หมดอายุเสมอ reliability (ความน่าเชื่อถือ) ไม่ใช่การไร้ซึ่งความล้มเหลว — แต่คือการทำให้ความล้มเหลวไม่มีความหมาย: ออกแบบให้เมื่อ (ไม่ใช่ถ้า) ส่วนประกอบหนึ่งตาย ผู้ใช้ไม่มีวันสังเกต

คำถามหลัก (ถามกับทุกงานออกแบบ ตลอดไป): เมื่อแต่ละส่วนประกอบพังจะเกิดอะไรขึ้น — มี “แล้วยังไงต่อ” เสมอไหม? ระบบรับโหลด 10× อย่างไร? เรารู้ได้อย่างไรว่ามีอะไรพังก่อนลูกค้าบอก? RTO และ RPO ของเราคือเท่าไหร่ — และใครในฝั่งธุรกิจเป็นคนเซ็นรับ? เราทดสอบการกู้คืนครั้งสุดท้ายเมื่อไหร่?

RTO และ RPO — สองตัวเลขที่คือบทสนทนาเรื่องภัยพิบัติทั้งหมด Recovery Time Objective: เราล่มได้นานแค่ไหน? Recovery Point Objective: เรายอมเสียข้อมูลได้มากแค่ไหน (คือ backup ดีล่าสุดแก่ได้แค่ไหน)? RTO 4 ชั่วโมงกับ RPO 1 ชั่วโมงแปลว่า: กลับมาภายในสี่ชั่วโมง โดยเสียข้อมูลอย่างมากหนึ่งชั่วโมง สองตัวนี้เป็นการตัดสินใจทางธุรกิจที่ป้ายราคาโตแบบทวีคูณ — RPO 24 ชั่วโมงคือ backup รายคืน (ถูก); RPO ~ศูนย์คือ replication ต่อเนื่อง (แพง); RTO หลักนาทีแปลว่ามีโครงสร้างพื้นฐานอุ่นเครื่องรอเปล่า ๆ (แพงมาก) งานของสถาปนิกคือทำให้ธุรกิจเลือกตัวเลขอย่างรู้ตัว — และออกแบบให้ตรงกับตัวเลขนั้นเป๊ะ ไม่ใช่เกินเลยแบบโรแมนติก

แพตเทิร์นมาตรฐาน: redundancy (สองชุดของทุกอย่างที่สำคัญ — N+1) · multi-AZ (ตัวสำรองข้าม data center; load balancer และ failover ของ managed database ทำให้อัตโนมัติ) · auto-scaling (ความจุตามความต้องการ) · health check + self-healing (instance ที่ตายถูกตรวจพบและแทนที่โดยเครื่องจักร ไม่ใช่มนุษย์) · backup ที่ทดสอบแล้ว (backup ที่ไม่ทดสอบคือความหวัง ไม่ใช่แผน — จัดตารางซ้อมกู้คืน) · graceful degradation (เมื่อโหลดล้น ให้ปลดฟีเจอร์สำคัญน้อยสุดก่อน: ThaiTicket ยอมทิ้งพรีวิวผังที่นั่งแต่เก็บหน้าชำระเงินไว้) · queue เป็นโช้คอัพ (ช่วงที่ 3) · การเลี่ยง cascading failure (timeout, retry พร้อม backoff, circuit breaker — เพื่อไม่ให้ dependency ช้าตัวเดียวลากทั้งฝูงจมน้ำ)

ตัวอย่างลงมือทำ — งานออกแบบ reliability ของ ThaiTicket สอง AZ ใน region กรุงเทพฯ app tier แบบ stateless ใน auto-scaling group หลัง load balancer อุ่นเครื่องล่วงหน้าตามตารางก่อนเวลาเปิดขายที่ประกาศ (auto-scaling ตอบสนองในหลักนาที; การเปิดขาย 10:00 ต้องมีความจุตั้งแต่ 09:45) database เป็น Aurora, primary ใน AZ-a, standby แบบ synchronous ใน AZ-b, failover อัตโนมัติ ≈ ไม่ถึงนาที มี queue คั่นระหว่างคลิก “ซื้อ” กับการประมวลผลชำระเงิน เพื่อให้เมื่อฝั่งผู้ให้บริการชำระเงินอืด ออเดอร์เข้าคิวแทนที่เว็บจะล่ม Backup: ต่อเนื่อง กู้คืนแบบ point-in-time ซ้อมกู้คืนรายเดือน ตัวเลขที่ตกลงกับธุรกิจ: RTO 15 นาที, RPO ~ศูนย์สำหรับออเดอร์ (มันคือเงิน), RPO 24 ชั่วโมงสำหรับข้อมูลวิเคราะห์ (มันไม่ใช่) แบบฝึกลงสมุด: งานออกแบบนี้ทำให้เราเสียอะไรไปจากมุม “ถูก” ของสามเหลี่ยม?

คำศัพท์:

แบบฝึกหัด: (1) หยิบงานออกแบบเว็บสั่งอาหารกลางวันจากช่วงที่ 1 มาอัปเกรดให้รอดจาก: instance ตาย, เสีย AZ, database พัง และมื้อกลางวันพีก 10× — วาดก่อนและหลัง (2) เขียนบทสนทนา RTO/RPO สำหรับสามธุรกิจ (บล็อก, เว็บ e-commerce, ระบบเวชระเบียนโรงพยาบาล) เป็นบทพูดสั้น ๆ ระหว่างสถาปนิกกับเจ้าของ — ฝึกทำให้ต้นทุนมองเห็นได้ในบทสนทนา (3) ลงสมุด: ไล่รายการ SPOF ทุกจุดในงานออกแบบ ThaiTicket ข้างบน มีอย่างน้อยหนึ่งที่จงใจเหลือไว้ (คำใบ้: กี่ region?)

Milestone: คุณรันการซักถาม “ถ้าอันนี้พังจะเกิดอะไรขึ้น?” กับแผนภาพใดก็ได้ต่อเนื่องสิบนาทีโดยไม่มุกแห้ง และคุณอธิบาย RTO กับ RPO ให้เจ้าของกิจการที่ไม่ใช่สายเทคนิคฟังด้วยการเปรียบเทียบร้านค้าถูกน้ำท่วม ได้ในเก้าสิบวินาที

โมดูล 5 (สัปดาห์ 9–10): Security — ออกแบบระบบที่ทำร้ายได้ยาก

กรอบคิด: shared responsibility model (โมเดลความรับผิดชอบร่วม) ผู้ให้บริการดูแลความปลอดภัยของตัวคลาวด์เอง — อาคาร ฮาร์ดแวร์ hypervisor คุณดูแลทุกสิ่งที่คุณใส่เข้าไป — ข้อมูล ตัวตน การตั้งค่า โค้ด เหตุข้อมูลรั่วบนคลาวด์ที่โด่งดังแทบทุกกรณีคือการตั้งค่าผิดฝั่งลูกค้า (bucket สาธารณะ, key หลุด, role ที่สิทธิ์เกิน) นี่คือเหตุผลที่ความปลอดภัยเป็นปัญหาสถาปัตยกรรมก่อนจะเป็นปัญหาเครื่องมือ: ประกาศงานบอกว่า “integrate security into the design rather than bolting it on” และโมดูลนี้คือวิธีทำ

คำถามหลัก: ใครและอะไรเข้าถึงแต่ละส่วนประกอบได้ และทุกสิทธิ์เป็นขั้นต่ำที่จำเป็นหรือไม่? ข้อมูลถูกเข้ารหัสที่ไหน — at rest, in transit และใครถือกุญแจ? ขอบเขตเครือข่ายอยู่ตรงไหน และอะไรข้ามมันบ้าง? เราจะตรวจจับการเจาะระบบได้อย่างไร — และเล่าเรื่องย้อนหลังจาก log ได้ไหม? กฎหมายอะไรใช้กับข้อมูลนี้ และข้อมูลอาศัยอยู่ที่ไหนทางกายภาพ?

แพตเทิร์นมาตรฐาน: least privilege (ทุกคนและทุกโปรแกรมได้สิทธิ์ขั้นต่ำที่งานต้องการ — กฎทองคำที่ทุก IAM policy ถูกตัดสินเทียบ) · MFA ทุกที่ root ถูกเก็บล็อกไว้ · การเข้ารหัส at rest และ in transit เปิดเสมอ (ในคลาวด์มันคือช่องติ๊ก; ไม่มีข้อแก้ตัว) · network segmentation (การแบ่งส่วนเครือข่าย — public/private subnet, security group เป็น firewall รายเครื่อง; รัศมีความเสียหาย (blast radius) ของการเจาะถูกนิยามโดยกำแพงที่คุณวาดไว้ล่วงหน้า) · secret อยู่ใน vault ไม่อยู่ในโค้ดเด็ดขาด · zero trust (ตรวจสอบทุกคำขออย่างชัดแจ้ง — ตัวตน อุปกรณ์ บริบท — ไม่เชื่อใจสิ่งใดเพียงเพราะมันอยู่ “ข้างในเครือข่าย”; JD เอ่ยชื่อมัน คุณก็ต้องเอ่ยได้) · defense in depth (หลายชั้น เพื่อให้การควบคุมล้มเหลวหนึ่งตัวไม่ใช่จบเกม) · audit logging (บันทึกสไตล์ CloudTrail ว่าใครทำอะไร — แก้ไขไม่ได้ ถูกเฝ้าดู) · ความปลอดภัยเป็น guardrail ไม่ใช่ gate (เข้ารหัสกฎเป็นนโยบายอัตโนมัติที่ทำให้เส้นทางปลอดภัยเป็นเส้นทางง่าย แทนที่จะเป็นประชุมรีวิวที่ทำให้ความปลอดภัยกลายเป็นศัตรูของการส่งมอบ)

ตัวอย่างลงมือทำ — งานออกแบบ security ของ ThaiTicket ข้อมูลลูกค้า (ชื่อ อีเมล ข้อมูลอ้างอิงการชำระเงิน) จัดชั้นเป็นข้อมูลส่วนบุคคลตาม PDPA → เก็บแบบเข้ารหัสใน Aurora ที่ region กรุงเทพฯ (data residency — ถิ่นพำนักของข้อมูล) กุญแจอยู่ใน KMS เครือข่าย: มีแค่ load balancer ที่ public; app tier เป็น private; subnet ของ database รับการเชื่อมต่อเฉพาะจาก security group ของ app tier มนุษย์: SSO + MFA; วิศวกรได้สิทธิ์อ่านอย่างเดียวใน production เป็นค่าเริ่มต้น และขอสิทธิ์ยกระดับแบบจำกัดเวลาได้ (least privilege พร้อม audit trail) การจัดการข้อมูลบัตรจ่ายเงินมอบให้ผู้ให้บริการชำระเงินที่ผ่านการรับรอง เพื่อให้เลขบัตรดิบไม่มีวันแตะระบบเรา — การตัดสินใจเชิงออกแบบที่ปลดภาระ compliance ทั้งก้อน ซึ่งคือสถาปัตยกรรมความปลอดภัยในรูปที่ดีที่สุด CloudTrail เปิด แจ้งเตือนเมื่อมีการเข้าถึงผิดปกติ คำถามเหตุรั่วถูกตอบล่วงหน้า: PDPA มีหน้าที่แจ้งเหตุภายใน 72 ชั่วโมง — log และ runbook ต้องทำให้เราเล่าเรื่องได้เร็วกว่านั้น

คำศัพท์:

วิดีโอประจำโมดูลนี้ (ตรวจสอบลิงก์แล้ว): The AWS Shared Responsibility Model — Digital Cloud Training — ~4 นาที — https://www.youtube.com/watch?v=ESPBBEK-cvo

แบบฝึกหัด: (1) วาดแผนภาพ ThaiTicket แล้ววางเลเยอร์ความปลอดภัยทับ: ทำเครื่องหมายทุก trust boundary ทุกจุดเข้ารหัส ทุกที่ที่ credential อาศัยอยู่ นิสัยการวางเลเยอร์นี้ — แผนภาพเดิม เลนส์ความปลอดภัย — คือสิ่งที่การรีวิวขอจากคุณเป๊ะ ๆ (2) อ่าน post-mortem สาธารณะของเหตุรั่วจากการตั้งค่าคลาวด์ผิดหนึ่งกรณี (Capital One ปี 2562 (ค.ศ. 2019) คือกรณีคลาสสิกสำหรับสอน) แล้วเขียนลงสมุดว่าแพตเทิร์นข้อไหนข้างบนที่จะป้องกันมันได้ (3) เล่นบทบาทสมมติกับ AI: มันรับบทผู้ก่อตั้งสตาร์ตอัปที่พูดว่า “เดี๋ยวค่อยเพิ่มความปลอดภัยทีหลัง” — โน้มน้าวเขาออกจากความคิดนั้นด้วยเลขคณิตต้นทุนของการถูกเจาะ อย่างสุภาพ

Milestone: คุณหยิบแผนภาพช่วงที่ 1 ของคุณอันไหนก็ได้มาทำเลเยอร์ความปลอดภัยของมันได้ในยี่สิบนาที และอธิบาย least privilege, zero trust และ shared responsibility model ให้ผู้มีส่วนได้ส่วนเสียที่ไม่ใช่สายเทคนิคฟังได้โดยไม่มีศัพท์เทคนิค

โมดูล 6 (สัปดาห์ 11–12): Performance และ cost — ความเร็วกับเงิน สองเสาที่ควบคู่กัน

สองเสานี้ถูกสอนด้วยกันเพราะมันคือคันโยกเดียวกันที่ถูกดันคนละทิศ และสถาปนิกคือคนที่มือวางอยู่บนคันโยก

Performance efficiency — คำถามหลัก: ผู้ใช้จะรู้สึกถึงความช้าที่ไหนก่อน? อะไรถูกคำนวณซ้ำ ๆ ที่ควรคำนวณครั้งเดียวแล้ว cache ไว้? แต่ละส่วนประกอบเป็นเครื่องมือที่ถูกต้องไหม (SQL ที่ทำงานของ search engine คือบั๊กประสิทธิภาพของสถาปัตยกรรม ไม่ใช่ของโค้ด)? ประสิทธิภาพเปลี่ยนอย่างไรที่ 10× — และคอขวดแรกอยู่ไหน?

แพตเทิร์นด้าน performance: ชั้นของ caching — แพตเทิร์นประสิทธิภาพที่ให้ผลตอบแทนสูงสุดหนึ่งเดียว: cache ของเบราว์เซอร์ → CDN ที่ edge (เนื้อหา static เสิร์ฟจากเมืองใกล้ผู้ใช้; ดูดซับทราฟฟิกอ่านส่วนมหาศาลได้) → cache ระดับแอปพลิเคชัน (Redis หน้า database สำหรับการอ่านร้อน: ผังที่นั่ง, session, หน้าสินค้า) → query cache ของ database แต่ละชั้นตอบคำขอก่อนที่มันจะไปถึงแกนกลางราคาแพง; คำถามออกแบบคือเสมอ อะไร cache ได้ นานแค่ไหน และ invalidate อย่างไรเมื่อความจริงเปลี่ยน จากนั้น: read replica (สำเนา database ที่รับงานอ่าน เพื่อให้ primary เก็บแรงไว้เขียน) · asynchronous processing (อย่าให้ผู้ใช้รองานที่ทำทีหลังได้ — อีเมลใบเสร็จ, thumbnail, รายงาน) · เครื่องมือถูกงาน (ค้นหา → search engine; วิเคราะห์ → warehouse; lookup ร้อน → key-value store) · และ วัดก่อนเสมอ (งาน performance ที่ไม่มีการวัดคือไสยศาสตร์)

Cost optimization — คำถามหลัก: งานออกแบบนี้ราคาเดือนละเท่าไหร่ที่โหลดวันนี้ — และต่อหน่วย (ต่อออเดอร์ ต่อลูกค้า)? อะไรรันตอนตีสามทั้งที่ไม่จำเป็น? การใช้งานคงที่ส่วนไหนผูกมัดรับส่วนลดได้? ฝ่ายการเงินจะพูดว่าแนวโน้มเป็นอย่างไร?

แพตเทิร์นด้าน cost: rightsizing (ฝูงเครื่องส่วนใหญ่สเปกเกินอย่างเงียบ ๆ; หดให้พอดีกับความต้องการที่วัดได้คือเงินฟรี) · กลยุทธ์การจอง — เมนูราคา: on-demand (ราคาเต็ม อิสระเต็ม) สำหรับโหลดพุ่ง/ไม่รู้จัก, reserved instances / savings plans (ผูกมัด 1–3 ปี ลด 30–70%) สำหรับฐานที่คงที่, spot (ลดถึง 90% ถูกเรียกคืนได้ในเวลาสั้น) สำหรับงาน batch ที่ขัดจังหวะได้; ท่าของสถาปนิกคือวางเป็นชั้น: จองพื้น, auto-scale ตรงกลางด้วย on-demand, spot งาน batch · storage lifecycle (การจัด tier ของโมดูล 2 แบบอัตโนมัติ) · ปิดของ (environment ที่ไม่ใช่ production หลับกลางคืนและสุดสัปดาห์ ลดต้นทุนส่วนนั้นได้สองในสาม) · จับตา egress (ข้อมูลออกจากคลาวด์คิดเงิน; งานออกแบบที่คุยข้าม region พร่ำเพรื่อและการดาวน์โหลดสาธารณะก้อนใหญ่เซอร์ไพรส์ทุกคนมาแล้วหนึ่งครั้ง) · tagging และ showback (ทุกทรัพยากรติดป้าย owner/project เพื่อให้ทุกบาทมีเจ้าภาพ) · และเมตริกมงกุฎ unit economics (เศรษฐศาสตร์ต่อหน่วย): ไม่ใช่ “บิลคือ ฿800k/เดือน” แต่ “ต้นทุนต่อบัตรที่ขายคือ ฿1.90 และกำลังลดลง” บิลที่โตไม่เป็นไร; ต้นทุนต่อหน่วยที่โตคือกลิ่นไม่ดีของสถาปัตยกรรม วินัยนี้มีชื่อ — FinOps — และสถาปนิกนั่งอยู่ตรงกลางของมัน

ตัวอย่างลงมือทำ — ThaiTicket ผ่านทั้งสองเลนส์ Performance: CloudFront เสิร์ฟหน้าศิลปินและรูปผังที่นั่ง (คนมามุง 400,000 คนส่วนใหญ่ไม่เคยแตะ server เลย); Redis cache สถานะที่นั่งว่างด้วย TTL 2 วินาที — เก่าพอให้ถูก สดพอที่หน้าชำระเงิน (ซึ่งเช็กซ้ำกับ Aurora แหล่งความจริง) ป้องกันการขายซ้ำ; ใบเสร็จและตั๋วถูกสร้างแบบ asynchronous หลังชำระเงิน Cost: ฐานคงที่ 2,000 คน/ชั่วโมงรันบน savings plan (≈ลด 40%); ช่วงพุ่งตอนเปิดขายรัน on-demand เฉพาะชั่วโมงที่มันมีอยู่; งานวิเคราะห์รันบน spot ตอนกลางคืน; staging หลับนอกเวลางาน; ทุกทรัพยากรติด tag project:thaiticket ข้อเสนอถึง CFO อ่านว่า: “฿62,000/เดือนเป็นฐาน, ≈฿9,000 ต่ออีเวนต์เปิดขายใหญ่, ต้นทุนต่อบัตร ≈฿1.90 ลดลงตามปริมาณ” — และประโยคนั้นคือเสียงของสถาปนิกที่คล่องเรื่องต้นทุน

คำศัพท์:

วิดีโอประจำโมดูลนี้ (ตรวจสอบลิงก์แล้ว): 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)

โมดูล 7 (สัปดาห์ 13–14): Operational excellence, sustainability — และการรันทั้งหกเสาพร้อมกัน

Operational excellence คือเสาที่ถามว่า: มนุษย์รันเจ้าสิ่งนี้ได้จริง ๆ อย่างใจเย็นไหม? คำถามหลัก: การเปลี่ยนแปลงไปถึง production อย่างไร — ผ่าน pipeline อัตโนมัติที่ทดสอบแล้ว หรือผ่านมนุษย์ผู้กล้า? เรารู้ได้อย่างไรว่าระบบแข็งแรงตอนนี้เดี๋ยวนี้? เมื่อมันพังตอนตีสาม วิศวกร on-call ทำอะไรกันแน่? แพตเทิร์น: infrastructure as code (environment ถูกนิยามในข้อความที่ผ่านการรีวิวและควบคุมเวอร์ชัน — Terraform/CloudFormation — จึงทำซ้ำได้และตรวจสอบได้; สถาปัตยกรรมที่มีอยู่แค่ในรูปการคลิกคอนโซลคือนิทานพื้นบ้าน ไม่ใช่วิศวกรรม) · CI/CD pipeline พร้อมกลยุทธ์ deploy ที่ปลอดภัย (blue-green: ตั้งเวอร์ชันใหม่ข้างเวอร์ชันเก่าแล้วสลับ; canary: ให้เวอร์ชันใหม่รับทราฟฟิก 5% แล้วเฝ้าดู) · observability (log, metric, trace และ alert ที่ผูกกับอาการที่ผู้ใช้มองเห็น ไม่ใช่เรื่องจุกจิกของเครื่อง) · runbook (คู่มือลายลักษณ์อักษรว่าทำอะไรสำหรับแต่ละความล้มเหลวที่รู้จัก) · blameless post-mortem (หลังเหตุขัดข้อง: อะไรพัง ทำไม อะไรป้องกันการเกิดซ้ำ — ไม่มีผู้ร้าย ไม่งั้นคนเลิกพูดความจริง) บทบาทของสถาปนิก: ออกแบบเพื่อความสามารถในการปฏิบัติการ — ระบบที่ฉลาดขึ้นสองเท่าแต่สังเกตการณ์ได้ครึ่งเดียว คือระบบที่แย่ลง

Sustainability เสาที่หก ขอให้คุณเปลืองโลกกายภาพน้อยลง: rightsize (CPU ว่างงานเผาไฟฟ้าจริง), scale ตามความต้องการแทนการเผื่อพีกไว้ตลอด, ใช้ managed และ serverless (โครงสร้างพื้นฐานที่แชร์คือโครงสร้างพื้นฐานที่เต็มกว่า), จัด tier ให้ storage และลบของที่ตายแล้ว โชคดีที่ทางเลือกยั่งยืนกับทางเลือกประหยัดมักเป็นทางเลือกเดียวกัน — พูดทั้งสองอย่างในการรีวิวแล้วคุณจะชนะใจห้องสองต่อ

การรันทั้งหกเสาพร้อมกัน — Well-Architected review ครั้งแรกของคุณ ในการรีวิวจริง เสาหลักขัดแย้งกัน: reliability แบบ multi-region ตีกับ cost; การรีวิวความปลอดภัยเข้มตีกับความเร็วปฏิบัติการ; caching เพื่อ performance ตีกับความถูกต้องสดใหม่ของข้อมูล framework ไม่แก้ความขัดแย้งให้คุณ — มันบังคับให้ความขัดแย้งออกมาอยู่กลางแจ้ง ที่ซึ่งธุรกิจเลือกได้ นั่นคืออัจฉริยภาพทั้งหมดของมัน และเป็นของคุณที่จะหยิบใช้ ตัววิธีการรีวิว (ชุดคำถาม การจัดลำดับ findings รายงาน) สอนเต็มในช่วงที่ 5 โมดูล 12; สองสัปดาห์นี้คุณซ้อมทักษะดิบ: การซักถามงานออกแบบเดียวจากหกทิศในหนึ่งการนั่ง

คำศัพท์:

แบบฝึกหัด: (1) แบบฝึกหกเลนส์: หยิบแผนภาพที่ดีที่สุดของคุณมาใช้เวลาสิบนาทีต่อเสาเขียน findings — หกสิบนาที หนึ่งงานออกแบบ หกเลนส์; แบบฝึกนี้คือช่วงที่ 2 ฉบับย่อส่วน ทำซ้ำรายสัปดาห์จากนี้ไป (2) อ่านรายงานหลังเหตุขัดข้องของ AWS สองฉบับ (เผยแพร่บนหน้า status ของเขาหลังเหตุล่มใหญ่) แล้วชี้ว่าแพตเทิร์นของเสาไหนล้มเหลว (3) ลงสมุด: สำหรับ ThaiTicket เขียนสามความขัดแย้งระหว่างเสาที่คุณจะยกให้ธุรกิจเห็น แต่ละอันเป็นทางเลือกหนึ่งประโยค (“เรามี X หรือ Y ได้ที่งบนี้ — เอาอันไหน?”)

Milestone — จบช่วงที่ 2: การรีวิวจำลอง: AI สร้างสถาปัตยกรรมมีตำหนิของสตาร์ตอัปสินเชื่อออนไลน์ไทย; คุณต้องผลิต findings ลายลักษณ์อักษรครบหกเสา รวมอย่างน้อย: ช่องโหว่ reliability (database แบบ single-AZ ของเขา), ช่องโหว่ security (IAM กว้างเกิน), ช่องโหว่ cost (ทุกอย่าง on-demand), ช่องโหว่ operations (ไม่มี IaC) และบทสนทนา RTO/RPO ที่เขาไม่เคยมี — แต่ละ finding เขียนในรูปคำถามที่เพื่อนร่วมงานฟังได้โดยไม่สะดุ้ง เมื่อรายการ findings ของคุณอ่านแล้วเหมือนรุ่นพี่ใจดีมากกว่าผู้ตรวจสอบบัญชี ช่วงที่ 2 ก็เสร็จสิ้น

ช่วงที่ 3 — แค็ตตาล็อกแพตเทิร์น (สัปดาห์ 15–20)

สถาปนิกไม่คิดค้น; พวกเขาคัดเลือก ช่วงนี้คือแค็ตตาล็อกสถาปัตยกรรมมาตรฐานของคุณ — แต่ละตัวมี: มันคืออะไร ใช้เมื่อไหร่ ไม่ควรใช้เมื่อไหร่ และโปรไฟล์ต้นทุน/ความซับซ้อน คอลัมน์ “เมื่อไม่ควร” คือสัมภาระจริงของช่วงนี้: คอร์สไหนก็บอกคุณได้ว่า microservices คืออะไร; แต่การรู้ว่าเมื่อไหร่มันจะพังบริษัท คือสิ่งที่เขาจ้างคุณ ระหว่างเรียน ให้เข้าไปดู reference architecture จริงที่ https://aws.amazon.com/architecture/ เรื่อย ๆ — การส่องหาแพตเทิร์นในป่าจริงคือแบบฝึกที่ทำให้แค็ตตาล็อกติดหนึบ

โมดูล 8 (สัปดาห์ 15–17): แพตเทิร์นระดับแอปพลิเคชัน

Monolith กับ microservices — วิวาทะเสียงดังสุดของวงการ ยุติอย่างใจเย็น monolith (โมโนลิธ) คือแอปพลิเคชัน deploy ก้อนเดียวที่บรรจุทุกฟีเจอร์; microservices (ไมโครเซอร์วิส) แยกระบบเป็น service เล็ก ๆ จำนวนมากที่ deploy อิสระ แต่ละตัวเป็นเจ้าของข้อมูลตัวเอง คุยกันผ่าน API และ event ตารางฉบับซื่อสัตย์:

คำตัดสินของสถาปนิก: เริ่มแบบ monolith ที่แบ่งโมดูลภายในให้ดี; สกัด service ออกเมื่อ — และเมื่อเท่านั้น — ความเจ็บปวดด้านการขยายทีมหรือขยายโหลดมาถึงจริง พูดแบบนี้ในห้องสัมภาษณ์ พร้อมเหตุผล ทำเครื่องหมายคุณว่าเป็น senior; อุดมการณ์ไปทางไหนก็ตาม ทำเครื่องหมายคุณว่าเป็น junior

Event-driven architecture — queue กับ topic โช้คอัพของระบบ แทนที่ส่วนประกอบจะเรียกกันแล้วรอ (synchronous) ส่วนประกอบ publish event (“OrderPlaced”) เข้า queue (SQS — ผู้บริโภคหนึ่งรายรับแต่ละข้อความ ตามจังหวะของตัวเอง) หรือ topic (SNS — ผู้ subscribe ทุกรายได้สำเนา; fan-out) ผู้ผลิตไม่รู้และไม่สนว่าใครฟังอยู่ ใช้เมื่อ: ส่วนประกอบควรรอดพ้นเหตุล่มของกันและกัน (queue ถือข้อความไว้ขณะผู้บริโภคดับ — ความทนทานและ decoupling ในการซื้อครั้งเดียว); โหลดพุ่งเป็นช่วง (queue ดูดซับ spike; worker ระบายมันอย่างสม่ำเสมอ); เหตุการณ์เดียวจุดชนวนหลายปฏิกิริยา (สั่งซื้อแล้ว → ตัดเงิน, อีเมล, สต๊อก, วิเคราะห์ — สี่ subscriber ศูนย์ coupling) ห้ามใช้เมื่อ: ผู้ใช้ต้องการคำตอบเดี๋ยวนี้ (หน้าชำระเงิน confirm แบบ “เดี๋ยวค่อย” ไม่ได้); หรือทีมเล็กและการเรียก synchronous ง่าย ๆ ก็พอ — ทุก queue เพิ่ม delivery semantics (at-least-once แปลว่าผู้บริโภคต้อง idempotent — รันซ้ำสองครั้งได้อย่างปลอดภัย), การจัดการ dead-letter และภาระ monitoring ต้นทุน/ความซับซ้อน: ส่วนประกอบถูก แต่การดีบักแพงขึ้น — เรื่องราวของคำขอตอนนี้กระจัดกระจายข้าม service และ queue ซึ่งเป็นเหตุที่ observability (โมดูล 7) เลิกเป็นทางเลือกตรงนี้

Three-tier: เป็นของคุณอยู่แล้ว (โมดูล 3) ใช้กับ: เว็บแอปพลิเคชันส่วนกลางอันกว้างใหญ่ — มันคือแพตเทิร์นที่ตัวอื่นถูกวัดเทียบ ไม่เหมาะกับ: workload พุ่งจัดที่มีช่วงเงียบว่างงาน (serverless ถูกกว่า) หรือผลิตภัณฑ์หลายทีมขนาดมหึมาจริง ๆ (ดูข้างบน) โปรไฟล์: เป็นที่เข้าใจทุกหนแห่ง จ้างคนง่าย ต้นทุนปานกลาง

Serverless-first: ประกอบชิ้นส่วน managed — API Gateway → Lambda function → DynamoDB, S3 และ queue — โดยไม่เป็นเจ้าของ server เลย ใช้เมื่อ: ทราฟฟิกพุ่งหรือต่ำ (scale-to-zero แปลว่าต้นทุนตอนว่าง ~ศูนย์), ทีมเล็ก, ต้องออกตลาดเร็ว, กาวเชื่อม event-driven ห้ามใช้เมื่อ: งานประมวลผลยาวหรือเฉพาะทาง (ลิมิต runtime), เส้นทางที่ไวต่อ latency สุดขีด (cold start), โหลดคงที่มหาศาล (ราคาต่อการเรียกอาจแพงกว่า server ที่จองไว้ — ทำเลขคณิตที่สเกล) หรือเมื่อความพกพาข้ามคลาวด์เป็นข้อกำหนดจริง (นี่คือ lock-in ลึกสุดของทุกแพตเทิร์น — มักคุ้มค่า แต่ต้องพูดออกมาดัง ๆ) โปรไฟล์: ภาระปฏิบัติการต่ำสุดในแค็ตตาล็อก; ต้นทุนเยี่ยมยอดที่สเกลต่ำ/พุ่ง ต้องตรวจสอบที่สเกลคงที่สูง

คำศัพท์:

แบบฝึกหัด: (1) ออกแบบ flow คำสั่งซื้อของ ThaiTicket สองแบบ — three-tier แบบ synchronous แล้วก็ event-driven ด้วย SQS/SNS — และเขียนหนึ่งย่อหน้าว่าแต่ละเวอร์ชันทำอะไรระหว่างที่ผู้ให้บริการชำระเงินล่ม; ย่อหน้านั้นคือข้อโต้แย้งทั้งหมดของฝั่ง event (2) สำหรับสี่บริษัท (สตาร์ตอัป 3 คน, scale-up วิศวกร 50 คน, ธนาคาร, แอปโหวตรายการทีวีที่ใช้ 4 คืน/ปี) เลือกแพตเทิร์นและแก้ต่างให้มัน — แล้วเอ่ยชื่อทริกเกอร์ที่จะทำให้แต่ละบริษัทเปลี่ยนแพตเทิร์น (3) หาเรื่องเล่าจากบล็อกวิศวกรรมจริงหนึ่งเรื่องแนว “เราย้ายไป microservices แล้วเสียใจ” กับหนึ่งเรื่องสำเร็จ; ลงสมุดว่าต่างกันตรงไหน (แทบทุกครั้งคือขนาดทีมกับวุฒิภาวะของ domain)

Milestone: เมื่อได้คำบรรยายบริษัท คุณแนะนำแพตเทิร์นพร้อมทางลงของมันได้ — “เริ่มตรงนี้; เมื่อ X เกิด วิวัฒน์ไป Y” — ในห้านาที เส้นทางวิวัฒนาการ ไม่ใช่คำพิพากษา คือวิธีที่สถาปนิกพูดกันจริง ๆ

โมดูล 9 (สัปดาห์ 18–20): แพตเทิร์นด้านข้อมูล ระดับโลก และ hybrid

สถาปัตยกรรมข้อมูล — lake กับ warehouse database เชิงธุรกรรม (ช่วงที่ 1) รันธุรกิจ; ฝั่งวิเคราะห์อยากตั้งคำถามกับมันโดยไม่ทำให้มันช้าลง data warehouse (คลังข้อมูล — Redshift, Snowflake, BigQuery) เก็บข้อมูลที่มีโครงสร้าง ถูกทำความสะอาดแล้ว ปรับแต่งเพื่อการวิเคราะห์ SQL ที่เร็ว — ใช้เมื่อคำถามเป็นที่รู้จักและแดชบอร์ดต้องไว; แพงกว่าต่อ TB ต้องมีวินัยการโมเดลข้อมูลตั้งแต่ต้น data lake (ทะเลสาบข้อมูล — S3 + catalog + เอนจิน query อย่าง Athena) เก็บทุกอย่าง ดิบ ๆ ถูก ๆ — log, clickstream, รูปภาพ — และใส่โครงสร้างตอนอ่าน; ใช้เมื่ออยากเก็บทุกอย่างตอนนี้แล้วค่อยตัดสินใจเรื่องคำถามทีหลัง; แต่ถ้าไร้ธรรมาภิบาลมันจะเสื่อมเป็นมุกตลกของวงการ data swamp (บึงข้อมูล) ฉันทามติสมัยใหม่คือใช้ทั้งคู่ วางเป็นชั้น (“lakehouse”): ความจริงดิบใน lake, mart ที่คัดสรรใน warehouse ป้อนด้วย ETL/ELT pipeline กฎของสถาปนิก: ฝั่งวิเคราะห์ห้าม query database production เด็ดขาด (ใช้ replica หรือ pipeline ป้อนมัน) และทุกชุดข้อมูลมีเจ้าของ มีรายการใน catalog และมีนโยบาย retention — บรรทัดธรรมาภิบาลนั้นคือหนึ่งประโยคในงานออกแบบ และหนึ่งปีแห่งความเจ็บปวดถ้าคุณละไว้

Multi-region: active-passive กับ active-active เมื่อ region เดียวไม่พอ — เพราะธุรกิจต้องการ DR จากภัยพิบัติระดับ region หรือผู้ใช้กระจายข้ามทวีป — คุณเลือก:

ประโยคระดับห้องสัมภาษณ์: “Multi-AZ is table stakes; multi-region is a business case.” (multi-AZ คือเดิมพันขั้นต่ำ; multi-region คือ business case) ให้ธุรกิจประกาศ RTO/RPO ตีราคาทางเลือก แล้วปล่อยให้ตัวเลขเป็นผู้เลือก

Hybrid cloud ส่วนหนึ่ง on-prem ส่วนหนึ่งคลาวด์ เชื่อมด้วย VPN หรือ Direct Connect — สำหรับองค์กรที่ตั้งตัวแล้วส่วนใหญ่ ไม่ใช่แพตเทิร์นแต่เป็นความจริงยาวนับทศวรรษ: mainframe ที่ย้ายไม่ได้, ระบบโรงงานที่ติดพันธนาการ latency, ข้อมูลใต้กำกับที่ถูกปักหมุดไว้ on-premises และการ migrate (ช่วงที่ 4) ที่กำลังเดินผ่าน ใช้ในฐานะ: สะพานที่จงใจสร้าง พร้อมทิศทางการเดินทาง ห้ามยอมรับ: “hybrid” ในฐานะคำสวยของ “เราไม่เคยตัดสินใจ” โน้ตการออกแบบ: identity ต้องรวมเป็นหนึ่งก่อน (ล็อกอินเดียวข้ามสองโลก — สิ่งที่ JD องค์กรหมายถึงด้วยคำ “hybrid identity integration”); ระบุชื่อว่าระบบไหนคือ source of truth; จับตาต้นทุน egress ข้ามสาย; และคาดหวังว่าลิงก์เครือข่ายจะเป็น SPOF เว้นแต่มีสองเส้น ความซับซ้อน: ทุกอย่างคูณสองอาณาจักร — เหตุผลซื่อสัตย์ที่สถาปนิกผลักดันให้หดฝั่ง on-prem ลงเรื่อย ๆ

คำศัพท์:

แบบฝึกหัด: (1) ThaiTicket ไประดับภูมิภาค: ออกแบบการขยายไปสิงคโปร์สองแบบ — active-passive (กรุงเทพฯ เป็นหลัก) และ active-active — พร้อมตัวคูณต้นทุนและ RTO/RPO ของแต่ละแบบ; เขียนคำแนะนำหนึ่งหน้าและฟันธง (2) ผู้ค้าปลีกมีข้อมูลขาย 15 ปีใน SQL database ฝั่ง production และอยากได้ “AI-ready analytics”; สเก็ตช์งานออกแบบ lake + warehouse และเขียนสามประโยคธรรมาภิบาล (3) ส่องแพตเทิร์น: เลือก reference architecture สามชิ้นจาก https://aws.amazon.com/architecture/ แล้วเอ่ยชื่อทุกแพตเทิร์นในแค็ตตาล็อกที่ปรากฏในแต่ละชิ้น

Milestone — จบช่วงที่ 3: ด่านแค็ตตาล็อก: AI ยิงหกสถานการณ์รัว ๆ; แต่ละอันคุณเอ่ยชื่อแพตเทิร์น เหตุผล คำเตือนเมื่อไม่ควรใช้ และโปรไฟล์ต้นทุน/ความซับซ้อน — ไม่เกินห้านาทีต่อข้อ บทแลกเปลี่ยนแบบนี้เป๊ะ ๆ ที่ความเร็วนี้เป๊ะ ๆ คือหนึ่งในสามส่วนกลางของการสัมภาษณ์สถาปนิกจริง

ช่วงที่ 4 — การย้ายระบบและโลกจริง (สัปดาห์ 21–26)

งานออกแบบ greenfield คือส่วนน้อยของอาชีพ สถาปัตยกรรมส่วนใหญ่เกิดในบริษัทที่มีอยู่แล้ว — พร้อมห้อง server, ซอฟต์แวร์โบราณที่ธุรกิจพึ่งพา, สัญญา และกฎหมาย ช่วงนี้คือโลกใบนั้น และเป็นที่ที่ “lead migration and modernization initiatives” — หัวข้อในแทบทุก JD ที่เราศึกษา — ถูกสอน

โมดูล 10 (สัปดาห์ 21–23): Migration — พาบริษัทขึ้นคลาวด์

The 7 Rs — คลังศัพท์ร่วมของทุกบทสนทนา migration สำหรับแต่ละ workload ในอาณาจักรระบบ คุณเลือกหนึ่ง:

วิธีการ migration: assess → mobilize → migrate Assess (ประเมิน): ทำ inventory ทุกอย่าง (เครื่องมือ discovery บวกโบราณคดีของการไปถามคน) และให้คะแนนแต่ละ workload ตามคุณค่าธุรกิจกับความยากในการย้าย — ผลลัพธ์: application inventory ที่มี R กำกับทุกแถว และ business case (TCO ของการอยู่ต่อ vs การย้าย; ซื่อสัตย์ว่าบิลจะสูงขึ้นช่วงคาบเกี่ยวที่ทั้งสองอาณาจักรรันพร้อมกัน — ผู้นำที่ไม่ถูกเตือนเรื่อง migration bubble คือผู้นำที่ยกเลิก migration กลางคัน) Mobilize (เตรียมพร้อม): สร้าง landing zone — รากฐานคลาวด์ที่สร้างไว้ล่วงหน้าและมีธรรมาภิบาล ก่อน workload ตัวแรกจะลงจอด: โครงสร้างหลายบัญชี (แยกบัญชีต่อ environment และต่อทีม เพื่อให้รัศมีความเสียหายเล็ก), identity และ logging รวมศูนย์, ฮับเครือข่าย (VPC แบบ hub-and-spoke, Direct Connect กลับไป on-prem) และ guardrail — นโยบายอัตโนมัติที่ทำให้เส้นทางปลอดภัย ติด tag และ compliant เป็นค่าเริ่มต้น (AWS Control Tower คือชุดเริ่มต้นแบบ managed) JD บอกว่า “design the landing zone every workload inherits” — นี่แหละคือสิ่งนั้น การข้ามมันเพื่อ “เริ่มย้ายเลย” คือการสร้าง data center รกรุงรังใบเดิมขึ้นใหม่บนคลาวด์ในราคาแพงกว่า; มันคือลายเซ็นคลาสสิกของ migration ที่ล้มเหลว Migrate เป็นระลอก: จัดกลุ่ม workload เป็นระลอกละไม่กี่ตัว เรียงง่ายก่อน: ระลอกที่ 1 จงใจเลือกเดิมพันต่ำ (เรียนรู้เครื่องจักรตรงที่ความผิดพลาดราคาถูก) ระลอกหลัง ๆ พาอัญมณีมงกุฎไปพร้อม cutover ที่ซ้อมแล้ว แต่ละระลอกมีแผน rollback และช่วง hypercare ของการเฝ้าดูเข้มข้น สำหรับการย้าย database แต่ละตัว สองคำถามที่สำคัญคือตัวเลขของโมดูล 4 ในคราบปลอมตัว: cutover ยอมให้ downtime เท่าไหร่ (RTO) — และ replication ต่อเนื่องพร้อม switchover สั้น ๆ มีอยู่จริงเมื่อคำตอบคือ “แทบเป็นศูนย์”

คำศัพท์:

แบบฝึกหัด: (1) migration บนกระดาษ: AI สร้าง inventory บริษัทสมมติ 40 server (คุณจะเจอมันอีกครั้งในฐานะ Capstone 2); กำหนด R ให้ทุกแถวและแก้ต่างสิบการตัดสินใจที่ยากที่สุด (2) สเก็ตช์ landing zone: แผนภาพบัญชี, การไหลของ identity, เครือข่าย hub-and-spoke, guardrail ห้าข้อที่คุณจะบังคับใช้ตั้งแต่วันแรก (3) เขียนคำเตือน “migration bubble” สองย่อหน้าถึง CFO — การซ้อมส่งข่าวร้ายแต่เนิ่น ๆ คือคาร์ดิโอของสถาปนิก

Milestone: เมื่อได้ inventory ~20 workload พร้อมคำบรรยาย คุณผลิตตาราง R-ต่อ-workload ที่แก้ต่างได้, แผนสามระลอกพร้อมเหตุผล และสเก็ตช์ landing zone — ในการนั่งครั้งเดียว

โมดูล 11 (สัปดาห์ 24–26): ข้อจำกัด — กฎหมาย ระบบเก่า และ lock-in

Data residency และกฎหมายความเป็นส่วนตัว ในฐานะข้อมูลป้อนเข้าของสถาปัตยกรรม กฎหมายข้อมูลส่วนบุคคล — PDPA ของไทย, GDPR ของยุโรป และญาติ ๆ ทั่วโลก — มีรูปทรงร่วมที่สถาปนิกต้องรู้แม่นยำ: ข้อมูลส่วนบุคคลต้องมีฐานทางกฎหมาย (บ่อยครั้งคือความยินยอม); ปัจเจกมีสิทธิ (เข้าถึง แก้ไข ลบ — งานออกแบบของคุณต้องหาและลบข้อมูลของคนหนึ่งคนได้ ซึ่งยากถ้าคุณโปรยมันกระจายในสำเนาไร้ธรรมาภิบาล); เหตุรั่วมีหน้าที่แจ้งภายใน 72 ชั่วโมง (ระบบ logging ของคุณต้องทำให้เล่าเรื่องได้เร็วกว่านั้น); และกฎการโอนข้ามพรมแดนจำกัดว่าข้อมูลอาศัยอยู่ที่ไหนได้ทางกายภาพ — ซึ่งเป็นข้อจำกัดของการเลือก region, ข้อจำกัดของการออกแบบ replication (สำเนาวิเคราะห์ที่สิงคโปร์อาจเป็นเหตุการณ์ทางกฎหมาย) และเหตุผลที่ region ในประเทศมีอยู่ วิธีการของสถาปนิก ตามลำดับ: จัดชั้นข้อมูล (อะไรคือข้อมูลส่วนบุคคล?), ทำแผนที่การเดินทางของมัน (ทุกที่เก็บ ทุกสำเนา ทุกพรมแดนที่ข้าม — การไหลที่ไม่มีใครวาดคือที่อยู่ของการละเมิด) แล้วออกแบบการควบคุม: region ที่ตรงตาม residency, การเข้ารหัส, ตาราง retention และเส้นทางการลบที่ไปถึงการหมดอายุของ backup จริง ๆ พูดคำว่า “data protection by design” — มันคือวลีที่กฎหมายทั้งสองใช้ และมันคือชื่อตำแหน่งงานของคุณในหนึ่งประโยคแบบตรงตัวอักษร

Legacy integration (การเชื่อมระบบเก่า) ระบบบิลลิ่งบน mainframe ไม่ย้ายปีนี้แน่ ๆ และแอปคลาวด์เอี่ยมอ่องต้องคุยกับมัน แพตเทิร์น: anti-corruption layer — บริการแปลภาษาระหว่างใหม่กับเก่า เพื่อให้รูปทรงข้อมูลพิลึกของระบบ legacy ไม่รั่วเข้ามาทำเสียงานออกแบบใหม่ของคุณ; strangler fig — นำทราฟฟิกผ่าน façade แล้วลอกฟังก์ชันออกจากระบบ legacy ทีละชิ้น จนหลายปีให้หลังมันถูกปิดสวิตช์ได้ (ตั้งชื่อตามต้นไทรที่ค่อย ๆ โอบรัดต้นไม้เจ้าบ้าน; มันชนะการเขียนใหม่แบบ big-bang ซึ่งล้มเหลวในอัตราระดับตำนาน); สะพาน batch และจุดแตะ event สำหรับข้อมูลที่ต้องไหลข้ามโลก; และความเคารพต่อฟิสิกส์ latency ของการเรียก cloud-ถึง-on-prem แบบพร่ำเพรื่อ (Direct Connect ช่วยได้; ดีกว่านั้นคือออกแบบให้ความพร่ำเพรื่อหายไป) กฎ: จงกักเก็บ legacy อย่าไปติดมัน — ทุกส่วนประกอบใหม่ควรถูกสร้างราวกับระบบ legacy หายไปแล้ว

เศรษฐศาสตร์ vendor lock-in ทุก managed service แสนสะดวกทำให้การแต่งงานกับผู้ให้บริการรายเดียวลึกขึ้น; ความพกพา (abstraction ข้ามคลาวด์, ดูแลเองทุกอย่าง) เป็นทางเลือกจริงที่มีราคาจริงในรูปความซับซ้อนและความเร็วที่สละไป ทั้งคู่ไม่ใช่บาป — โหมดล้มเหลวไม่ใช่การเลือก lock-in แต่คือการไม่สังเกต เครื่องมือของสถาปนิกคือการประเมินต้นทุนขาออกเขียนลงในงานออกแบบ: “การใช้ DynamoDB ประหยัด ≈2 ปีวิศวกรตอนนี้; การย้ายทีหลัง ≈ การเขียน data layer ใหม่ 6 เดือน — เรายอมรับสิ่งนี้ และนี่คือขอบเขต interface ที่จะทำให้การเขียนใหม่หดลง” สามประโยค ตีราคาซื่อสัตย์ การตัดสินใจถูกบันทึก (ADR ของช่วงที่ 5) — นั่นคือการจัดการ lock-in แบบผู้ใหญ่ multi-cloud ในฐานะกลยุทธ์ (รัน workload เดียวกันแบบพกพาบนสองคลาวด์) มักเป็นคำตอบที่แพงที่สุดเท่าที่เป็นไปได้ และถูกซื้อโดยองค์กรที่สเกลหรือผู้กำกับดูแลเรียกร้องมันเท่านั้น; multi-cloud ในฐานะข้อเท็จจริง (ต่าง workload อยู่ต่างคลาวด์ตามประวัติศาสตร์หรือความเหมาะ) คือชีวิตปกติ

คำศัพท์:

แบบฝึกหัด: (1) ทำ data-flow map ของข้อมูลลูกค้า ThaiTicket: ทุกที่เก็บ ทุกสำเนา (อย่าลืม log, backup, pipeline วิเคราะห์, ไฟล์ export ของทีมซัพพอร์ต), ทุกพรมแดน; แล้วเขียนเส้นทางการลบ สัมผัสว่าแผนที่หาปัญหาที่แผนภาพซ่อนไว้ได้อย่างไร (2) ออกแบบแผน strangler-fig ให้ระบบสินค้าคงคลัง on-prem อายุ 20 ปี พร้อมเอ่ยชื่อสามชิ้นแรกที่จะลอก (3) เขียนย่อหน้า lock-in สไตล์ DynamoDB (ประโยชน์ตอนนี้, ต้นทุนขาออกทีหลัง, ยอมรับหรือบรรเทา) สำหรับสามบริการที่คุณจะใช้จริง

Milestone — จบช่วงที่ 4: ด่านข้อจำกัด: โจทย์ออกแบบหนึ่งข้อที่คลุกทั้งสามเรื่อง (“บริษัทประกันไทย, ข้อมูลลูกค้า, ระบบกรมธรรม์บน mainframe, บอร์ดกังวลเรื่องการพึ่งพา AWS”) — คุณผลิตแนวทางหนึ่งหน้าที่แตะ residency, integration และ lock-in แต่ละเรื่องพร้อมแพตเทิร์นที่เอ่ยชื่อได้และต้นทุนที่ซื่อสัตย์ เมื่อข้อจำกัดทำให้คุณตื่นเต้นกว่าที่ greenfield จะทำได้ — เพราะข้อจำกัดคือที่ที่สถาปนิกทำเงินได้เหนือกว่านักวาดแผนภาพ — ช่วงที่ 4 ก็เสร็จสิ้น

ช่วงที่ 5 — งานฝีมือของสถาปนิก (เดือน 7–12)

ทุกอย่างจนถึงตอนนี้ทำให้คุณออกแบบได้ ช่วงนี้ทำให้คุณทำงานเป็นสถาปนิกได้ — เอกสาร การรีวิว การนำเสนอ และหลักฐานต่าง ๆ ที่บทบาทนี้ประกอบขึ้นจากจริง ๆ บวกใบรับรองที่พาคุณผ่าน HR และ capstone สามชิ้นที่กลายเป็นพอร์ตโฟลิโอของคุณ

โมดูล 12 (เดือน 7–8): งานส่งมอบ — ADR, ชุดแผนภาพ และการรันรีวิว

Architecture Decision Records (ADRs) ADR คือเอกสารหนึ่งหน้าที่จับหนึ่งการตัดสินใจสำคัญ: เราเลือกอะไร ไม่เลือกอะไร และทำไม — เขียนตอนที่ตัดสินใจ ใส่หมายเลข และเก็บใน repository ของโปรเจกต์ตลอดไป ทำไม JD เอ่ยชื่อมัน: อีกสองปี จะมีคนถามว่า “ทำไมถึงเป็น 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 พอร์ตโฟลิโอสัมภาษณ์ที่มี ADR จริงนั้นหายากและทรงพลังอย่างร้ายกาจ

ชุดแผนภาพ — หนึ่งระบบ สามระดับซูม เอกสารสถาปัตยกรรมจริงคือชุด (โมเดล C4 ทำให้วินัยนี้แพร่หลาย): context diagram — ระบบเป็นกล่องเดียว พร้อมผู้ใช้และระบบภายนอกที่มันสัมผัส; มุมมองสำหรับผู้บริหาร/พนักงานใหม่ และเป็นอันที่คุณจะนำเสนอต่อผู้นำ container diagram — ซูมเข้า: ชิ้นส่วนหลักที่รันอยู่ (web app, 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 ฟรีในคอนโซลที่จัดโครงสร้างให้ทั้งกิจกรรม — https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html); แต่ละคำตอบ จด finding และจัดลำดับความสำคัญไปพร้อมกัน — ประเด็นความเสี่ยงสูงหยิบมือเดียว ไม่ใช่ข้อจุกจิกร้อยข้อ โทนการถามของคุณคือตัวการรีวิว: “help me understand what happens when the payment provider times out” (ช่วยเล่าให้ฟังหน่อยว่าเกิดอะไรขึ้นเมื่อผู้ให้บริการชำระเงิน timeout) เปิดประตูที่ “you don’t handle timeouts?” (คุณไม่ handle timeout เหรอ?) กระแทกปิด หลัง: รายงานสั้น — findings เด่น แต่ละอันมีความเสี่ยง แรงที่ใช้ และคำแนะนำ — และรายการปรับปรุงลงสู่ backlog จริงของทีมพร้อมเจ้าภาพ ไม่งั้นการรีวิวคือละคร ฝึก: รันรีวิวเต็มรูปแบบกับงานออกแบบ Capstone 1 ของคุณเอง; การหาตำหนิของตัวเองอย่างมีโครงสร้างคือทักษะที่ทบต้นเร็วที่สุดในหลักสูตรนี้

แบบฝึกหัด: (1) เขียน ADR ย้อนหลังให้ห้าการตัดสินใจใหญ่ในงานออกแบบช่วงที่ 2–3 ในสมุดของคุณ — คุณจะพบอย่างน้อยหนึ่งอันที่แก้ต่างไม่ได้อีกต่อไป ซึ่งนั่นแหละคือบทเรียน (2) ผลิตชุดแผนภาพสามระดับเต็มรูปแบบของ ThaiTicket (3) รันรีวิวจำลองข้างบน ผลิตรายงาน findings หนึ่งหน้า

Milestone: คนแปลกหน้า (หรือ AI ที่รับบทเป็น) หยิบแพ็ก ThaiTicket ของคุณ — สามแผนภาพ + ห้า ADR — แล้วตอบ “นี่คืออะไร รันอย่างไร และทำไมถึงถูกสร้างแบบนี้?” ได้ถูกต้องโดยไม่มีคุณอยู่ในห้อง แพ็กนั้นคืองานส่งมอบของอาชีพสถาปนิก

โมดูล 13 (เดือน 8–9): งานฝีมือด้านมนุษย์ — การนำเสนอ การคิดต้นทุน การรับแรงต้าน และการเป็นพี่เลี้ยง

การนำเสนอต่อผู้บริหาร vs วิศวกร — งานออกแบบเดียว สองภาษา ผู้บริหารซื้อผลลัพธ์; วิศวกรซื้อกลไก ต่อผู้บริหาร: นำด้วยการตัดสินใจและตัวเลข (“งานออกแบบนี้รองรับเป้าลูกค้าหนึ่งล้านคนที่ ฿1.90 ต่อออเดอร์ และนี่คือสองการตัดสินใจที่ผมต้องการจากคุณ”); สไลด์เดียว ใช้แผนภาพ context ความเสี่ยงถูกวางกรอบเป็นความเสี่ยงธุรกิจ (รายได้, compliance, ชื่อเสียง) และอย่าพูดคำว่า “Kubernetes” เมื่อคำว่า “แพลตฟอร์ม” ใช้แทนได้ เตรียมพร้อมสำหรับสามคำถามที่ผู้บริหารถามเสมอ: ราคาเท่าไหร่ อะไรพังได้ ทำไมไม่เอาตัวเลือกที่ถูกกว่า? ต่อวิศวกร: นำด้วยปัญหาและข้อจำกัดก่อนโซลูชัน (วิศวกรที่รู้สึกถึงปัญหาจะยอมรับโซลูชัน; วิศวกรที่ถูกยื่นคำพิพากษาจะล่าหาตำหนิโดยหลักการ), โชว์แผนภาพ container และ deployment, เอ่ยชื่อ trade-off และตัวเลือกที่ถูกปัดตกด้วยตัวเอง (ความน่าเชื่อถือมาจากสิ่งที่คุณยอมรับ) และเหลือพื้นที่จริงให้เปลี่ยนงานออกแบบ — คำถามในห้องคือการรีวิวฟรี นิสัยสถาปนิกที่แย่สุดคือเด็คเดียวสำหรับทั้งสองผู้ชม; นิสัยที่ดีสุดคือเขียน executive summary ก่อน เพราะถ้างานออกแบบรอดการบีบอัดเหลือห้าประโยคไม่ได้ มันยังไม่เสร็จ

การประมาณต้นทุนสำหรับข้อเสนอ วิธีการ: แยกงานออกแบบเป็นส่วนประกอบที่มีต้นทุน ~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 ไม่มีอะไรสร้างความน่าเชื่อถือระดับทศวรรษเร็วกว่านี้; ไม่มีอะไรทำลายมันเร็วกว่าการปกป้องศพ

การเป็นพี่เลี้ยงวิศวกร วลีใน JD คือ “mentor the engineers who build against your standards” และรูปแบบที่ใช้งานจริงคือ: design review office hours (ประตูที่เปิดประจำ เพื่อให้คำแนะนำเกิดก่อนโค้ด ไม่ใช่หลัง); การรีวิวงานออกแบบของพวกเขาอย่างเมตตา — คำถามก่อนคำพิพากษา และมีเหตุผลเบื้องหลังมาตรฐานเสมอ (guardrail ที่ถูกอธิบายได้พันธมิตร; guardrail ที่ถูกยัดเยียดได้ workaround); การมอบหมายการตัดสินใจจริงพร้อมตาข่ายนิรภัย (“คุณเป็นเจ้าของงานออกแบบ cache; นี่คือข้อจำกัด; ผมจะรีวิว และผมจะหนุนการตัดสินของคุณ”); และการสอนในที่สาธารณะ — ทุก ADR ทุกบทสรุปรีวิว ทุกเซสชัน brown-bag ขยายตัวคุณเกินชั่วโมงของตัวเอง ความจริงอาชีพแบบตรงไปตรงมา: สถาปนิกอัจฉริยะสันโดษมีเพดาน; สถาปนิกที่ปั้นวิศวกรห้าคนให้กลายเป็นเพื่อนร่วมงานที่ออกแบบเป็น คือคนที่ได้นำทีมงานสถาปัตยกรรม

แบบฝึกหัด: (1) นำเสนอ ThaiTicket สองครั้ง — เวอร์ชันผู้บริหาร 5 นาที กับเวอร์ชันวิศวกรรม 20 นาที — อัดเสียงทั้งคู่ แล้วฟังหาศัพท์เทคนิคที่รั่วเข้าไปในอันแรก (2) ผลิตข้อเสนอต้นทุนฉบับเต็ม (สมมติฐาน, ช่วง, ตัวขับ, ฉากทัศน์ 2×/10×) (3) ละครแรงต้านกับ AI: สามยก — การโจมตีต้นทุนจาก CFO, ความชอบ stack จากวิศวกรอาวุโส, เกมอำนาจแบบเพื่อน-CTO — จดลงสมุดว่าอะไรได้ผล (4) รีวิวงานออกแบบของ junior (ให้ AI สร้างฉบับมีตำหนิ) เป็นลายลักษณ์อักษร คำถามนำก่อน แล้วให้ AI ให้คะแนนโทนของคุณ

Milestone: ศึกสองรายการ: นำเสนอ pitch ผู้บริหารและรอดยี่สิบนาทีของ Q&A ผสมแบบดุแต่แฟร์ (แผง AI: หนึ่ง CFO หนึ่งวิศวกรขี้สงสัย) โดยไม่มีศัพท์ข้ามสาย ไม่มีท่าตั้งรับ และไม่มี trade-off สักอันที่ไม่ถูกจดบันทึก

โมดูล 14 (เดือน 9–12): ใบรับรองและ capstone สามชิ้น

เส้นทางใบรับรอง พร้อมไทม์ไลน์ซื่อสัตย์ ใบรับรองไม่ได้ทำให้คุณเป็นสถาปนิก — สิบสามโมดูลก่อนหน้าต่างหาก — แต่มันพาคุณไปถึงห้องสัมภาษณ์ และการเตรียมสอบเดินสายไฟบริการของผู้ให้บริการเข้าไปในนิ้วมือคุณ บันได ที่จังหวะวันละหนึ่งชั่วโมง: AWS Certified Solutions Architect – Associate (SAA-C03) — 2–3 เดือน; ใบรับรองสายสถาปนิกที่ถูกขอมากที่สุดในประกาศงาน และหลังช่วงที่ 1–3 เนื้อหาส่วนใหญ่จะรู้สึกเหมือนการทบทวนที่มีชื่อบริการแปะกำกับ; สอบตัวนี้ก่อน AWS Certified Solutions Architect – Professional (SAP-C02) — 4–8 เดือนหลัง Associate; อิงสถานการณ์ ยากจริง และเป็นบรรทัดเรซูเมที่แข็งแรงที่สุดหนึ่งเดียวในสายนี้; เนื้อหา 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 มากกว่าทักษะคลาวด์ ลำดับสำหรับหลักสูตรนี้: อ่าน SAA คู่ขนานเดือน 7–8 สอบราวเดือน 8; จากนั้นเลือก SA Pro (เส้นทางเทคนิคลึก) หรือ AZ-305 (เส้นทางความกว้าง) จนถึงเดือน 12 โดย SA Pro เสร็จภายในเดือน 14–16 ที่จังหวะซื่อสัตย์

Capstone สามชิ้น แต่ละชิ้นคือแพ็กระดับพอร์ตโฟลิโอที่สมบูรณ์: ชุดแผนภาพสามระดับ, ADR 5+ ฉบับ, ประมาณการต้นทุนพร้อมสมมติฐาน และ Well-Architected review ที่รันเองพร้อม findings ใช้เวลา 3–4 สัปดาห์ต่อชิ้น สามชิ้นงานนี้ บวกสมุดบันทึกของคุณ คือหลักฐานสัมภาษณ์ของ “end-to-end solution design”

Capstone 1 — greenfield: แพลตฟอร์ม e-commerce ไทยสำหรับผู้ใช้ 1 ล้านคน โจทย์: marketplace, ผู้ใช้ลงทะเบียน 1 ล้านคน, 50k พร้อมกันที่พีก flash-sale, mobile-first, เชื่อมชำระเงินแบบ PromptPay, ตรงตาม PDPA, availability 99.9%, ประหยัดงบแบบ seed-stage ต้องมี: การเลือกแพตเทิร์นพร้อมเส้นทางวิวัฒน์, กลยุทธ์ caching, บทสนทนา RTO/RPO เขียนเป็นบทพูด, ประมาณการ unit economics, data-flow map ของข้อมูลส่วนบุคคล

Capstone 2 — brownfield: การย้ายบริษัท on-prem 40 server โจทย์: บริษัทโลจิสติกส์ไทย; 40 server (ERP บน Oracle, แอปจัดการคลังสินค้าอายุ 12 ปี, file share, AD, แอปแผนกต่าง ๆ — ให้ AI สร้าง inventory ฉบับเต็มแล้วตรึงไว้); สัญญาเช่า data center หมดใน 14 เดือน; บอร์ดอยากออก ต้องมี: ตาราง 7-R ครบทุกแถว, แผนสามระลอกพร้อมเหตุผล dependency, งานออกแบบ landing zone, ไทม์ไลน์ต้นทุน migration bubble และบันทึกถึง CFO

Capstone 3 — โจทย์หิน: multi-region DR สำหรับ fintech โจทย์: บริษัทชำระเงินที่ถูกกำกับให้ RTO ≤ 15 นาที / RPO ≈ 0 สำหรับ ledger พร้อมข้อจำกัด data residency ของข้อมูลลูกค้า และการทดสอบ failover ต่อหน้าผู้กำกับดูแลปีละครั้ง ต้องมี: บทวิเคราะห์ active-passive vs active-active พร้อมต้นทุน, งานออกแบบ replication พร้อมแผนที่ residency, failover runbook และแผนการซ้อม

เกณฑ์ประเมินตนเอง (ใช้กับแต่ละ capstone อย่างซื่อสัตย์ ในสมุดบันทึก):

ได้ 4+ ทุกมิติในทั้งสาม capstone — แก้จนกว่าจะได้ — แล้วคุณก็เรียนจบหลักสูตรนี้

สิบคำถามสัมภาษณ์สถาปนิก (พร้อมคำตอบที่แข็งแรง)

ฝึกออกเสียง; ความแข็งแรงอยู่ที่โครงสร้างของแต่ละคำตอบ ซึ่งตอนนี้เป็นของคุณแล้ว

1. “Design a URL shortener / ticketing site / photo app for a million users.” (ออกแบบ URL shortener / เว็บขายบัตร / แอปรูปภาพ สำหรับผู้ใช้หนึ่งล้านคน) โครงที่แข็งแรง: requirements ก่อน ออกเสียง (“อ่านมากกว่าเขียนไหม? เป้า 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 ระดับมิลลิวินาทีหลักเดียว จากนั้นผมเลือกรส NoSQL ให้เข้ากับ access pattern และผมเขียน ADR ที่รวมสิ่งที่เราสละไป: join และ consistency semantics บางส่วน”

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) คำตัดสินของโมดูล 8 คำต่อคำ: เริ่ม modular-monolith; สกัดเมื่อความเจ็บปวดการขยายทีมหรือขยายโหลดมาถึงจริง; microservices คือเครื่องมือขยายทีมที่คิดภาษี distributed systems ได้คะแนนโบนัสถ้าพูดว่า “I’d rather run a good monolith than a bad distributed system” (ผมยอมรัน monolith ที่ดี มากกว่า distributed system ที่แย่)

5. “How do you handle a large cloud bill / cost optimization?” (คุณจัดการบิลคลาวด์ก้อนใหญ่ / cost optimization อย่างไร) “ความมองเห็นได้ก่อน — tagging และ showback; จากนั้นเก็บเกี่ยวตามลำดับแรงที่ใช้: ฆ่าทรัพยากรที่ตายแล้ว, rightsize จากการวัด, จัด tier ให้ storage, ตั้งเวลาหลับให้ non-prod, แล้วจองฐานที่คงที่ และผมรายงาน unit economics ไม่ใช่ยอดรวม — บิลที่โตพร้อมต้นทุนต่อออเดอร์ที่ลดลงคือความสำเร็จ ไม่ใช่ปัญหา”

6. “How would you migrate a legacy on-prem application?” (คุณจะย้ายแอป legacy จาก on-prem อย่างไร) “ประเมินก่อนย้าย — inventory, dependency และ R ต่อ workload จาก 7 Rs; สร้าง landing zone ก่อนระลอกแรก; ระลอกเรียงง่ายก่อนพร้อม cutover ที่ซ้อมแล้วและแผน rollback; และสำหรับ database อัญมณีมงกุฎ ใช้ cutover แบบ replication ที่ปรับขนาดตาม downtime ที่ธุรกิจเซ็นรับ อีกอย่าง: คำเตือน migration-bubble อย่างซื่อสัตย์ตั้งแต่ต้น”

7. “How do you secure a cloud architecture?” (คุณทำให้สถาปัตยกรรมคลาวด์ปลอดภัยอย่างไร) เดินไล่ชั้น: identity (least privilege, MFA, ไม่มี root รายวัน) → เครือข่าย (private subnet, segmentation, attack surface น้อยสุด) → ข้อมูล (เข้ารหัส at rest/in transit, classification, residency) → การตรวจจับ (audit log, alert) → “และโดยการออกแบบ ไม่ใช่แปะทีหลัง — การควบคุมความปลอดภัยที่ถูกที่สุดคือการตัดสินใจสถาปัตยกรรมที่กำจัดความเสี่ยงทั้งก้อน เช่นการไม่แตะข้อมูลบัตรดิบเลย”

8. “Tell me about a design decision you got wrong.” (เล่าการตัดสินใจออกแบบที่คุณเคยพลาดให้ฟังหน่อย) เขากำลังทดสอบอีโก้ ไม่ใช่ประวัติศาสตร์ โครง: ตัวอย่างจริง (จาก capstone) → สิ่งที่คุณเคยเชื่อ → สิ่งที่ความจริงบอก → post-mortem, ADR ที่ถูกอัปเดต, แพตเทิร์นที่ตอนนี้คุณคอยตรวจ สถาปนิกที่ผลิตคำตอบข้อนี้ไม่ได้ คือสถาปนิกที่ไม่เคยถูกรีวิว

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 ก่อนใครถาม และปั้นวิศวกรรอบตัวจนมาตรฐานของคุณอายุยืนกว่าการปรากฏตัวของคุณในห้อง สถาปัตยกรรมคืองานเทคนิคหายากที่ดีขึ้นเมื่อคุณแก่ตัวเข้าไปในมัน เพราะวัตถุดิบของมันคือวิจารณญาณ และวิจารณญาณทบต้น จดสมุดบันทึกต่อไป อีกสี่สิบงานออกแบบจากนี้ คุณจะไม่ต้องการหลักสูตรนี้อีก — คุณจะเป็นคนแก้ไขมันเอง

Sources

ประกาศงานและนิยามบทบาทที่ใช้ในตารางจับคู่ข้อกำหนด (สืบค้นเมื่อสิงหาคม 2569): KORE1 Cloud Architect job description template · 4 Corner Resources Cloud Architect job description · Solution Architect responsibilities in the Azure Well-Architected Framework ของ Microsoft · Pre-Sales Solutions Architect – AWS posting ของ Arpio · Solution Architect – Enterprise posting (via Built In) ของ Intel · Cloud Domain Architect posting ของ Halliburton ค่าประมาณเวลาเตรียมสอบใบรับรอง: CBT Nuggets’ SAA-C03 study-time survey และ Whizlabs’ SAP-C02 preparation guidance; นิยามใบรับรองจาก Microsoft Learn (AZ-305) และ AWS Well-Architected Framework เล่มคู่หูของ The Cloud Leader Course ในชุด B4LCILC