Khóa học Kiến trúc sư Cloud (The Cloud Architect Course)

Từ chỗ chưa biết gì đến thiết kế được những hệ thống cloud mà một công ty dám đặt cược cả doanh nghiệp vào đó.

Khóa học này vận hành như thế nào

Bạn không rèn luyện để vận hành các hệ thống cloud. Bạn rèn luyện để thiết kế chúng: nhận lấy một bài toán kinh doanh bừa bộn (“chúng tôi cần bán cho một triệu khách hàng và không bao giờ mất một đơn hàng”), biến nó thành một bản kế hoạch kỹ thuật được vẽ ra, được định giá, có thể bảo vệ được, rồi thuyết phục cả những kỹ sư sẽ xây nó lẫn những lãnh đạo sẽ trả tiền cho nó. Đó là công việc của một cloud architect (kiến trúc sư cloud — cũng được đăng tuyển dưới tên solutions architect, cloud solutions architect, hay cloud domain architect), và nó là một nghề thủ công học được với một giáo trình rõ ràng — chính là giáo trình này.

Khóa học gồm năm giai đoạn. Giai đoạn 1 (Tuần 1–6): Các khối xây dựng, dưới dạng quyết định. Mọi thành phần cloud, được dạy lại không phải như một sự kiện mà như một lựa chọn kèm đánh đổi — vì đơn vị công việc của kiến trúc sư là quyết định. Giai đoạn 2 (Tuần 7–14): Các miền thiết kế. Sáu trụ cột của Well-Architected Framework — độ tin cậy, bảo mật, hiệu năng, chi phí, vận hành, tính bền vững — mỗi trụ được dạy sâu cùng các mẫu hình chuẩn của nó và một bản thiết kế mẫu. Giai đoạn 3 (Tuần 15–20): Danh mục mẫu hình. Khoảng một tá kiến trúc giải quyết 95% các bài toán thực tế, và — quan trọng hơn — khi nào không nên dùng mỗi cái. Giai đoạn 4 (Tuần 21–26): Migration và thế giới thực. Di chuyển các công ty đang tồn tại lên cloud, và những ràng buộc (luật pháp, hệ thống cũ, lock-in) khiến kiến trúc thực tế khó hơn kiến trúc trên bảng trắng. Giai đoạn 5 (Tháng 7–12): Nghề. Các tài liệu, sơ đồ, buổi review, bài thuyết trình và chứng chỉ khiến bạn tuyển được với vai trò kiến trúc sư, chốt lại bằng ba dự án thiết kế cấp portfolio.

Khóa học này dành cho ai. Nó giả định không có kiến thức trước: mọi thứ nó dựa vào đều được dạy lại ngắn gọn trước khi được dùng. Nếu bạn đã hoàn thành Khóa học Kỹ sư Cloud (The Cloud Engineer Course) (hoặc bạn đang làm việc thực hành với cloud hôm nay), Giai đoạn 1 sẽ quen thuộc — hãy lướt qua nó, nhưng vẫn làm các bài tập của nó, vì nó tái đóng khung những điều bạn biết như sự kiện thành những điều bạn phải cân nhắc như quyết định, và chính sự tái đóng khung đó là toàn bộ cú chuyển mình từ kỹ sư sang kiến trúc sư.

Quy tắc cho toàn khóa học: học một giờ mỗi ngày, sáu ngày mỗi tuần — sự đều đặn thắng sự dồn dập. Mỗi module kết thúc bằng một bảng Từ vựng (những từ bạn phải làm chủ), các Bài tập (công việc thiết kế, không phải đọc — kiến trúc học được bằng cách vẽ và quyết định), và một Milestone (cột mốc — bằng chứng bạn sẵn sàng đi tiếp; đừng nhảy qua một cột mốc chưa đạt). Và ngay từ Tuần 1, hãy duy trì một Design Journal (nhật ký thiết kế): mỗi kiến trúc bạn vẽ, mỗi đánh đổi bạn gọi tên, mỗi dự đoán bạn đưa ra về chi phí hay sự cố. Mười tháng nữa nó trở thành portfolio phỏng vấn của bạn; không gì gây ấn tượng với một hội đồng tuyển dụng bằng một cuốn sổ có ngày tháng với bốn mươi bản thiết kế kèm những ghi chú trung thực về những gì bạn đã sai.

Kiến trúc sư cloud thực sự làm gì

Hãy nghĩ về một kiến trúc sư xây dựng. Cô ấy không xếp gạch — nhưng cô ấy phải biết chính xác gạch làm được và không làm được gì, chúng giá bao nhiêu, và các tòa nhà đổ như thế nào. Cô ấy lắng nghe một khách hàng (“một ngôi nhà gia đình, nhiều nắng, trong ngân sách này, trên mảnh đất khó này”), và biến những mong muốn cùng ràng buộc thành bản vẽ và thông số kỹ thuật đủ chính xác để thợ xây xây theo và khách hàng ký duyệt. Rồi cô ở lại suốt quá trình thi công, trả lời các câu hỏi và điều chỉnh bản kế hoạch khi nền đất hóa ra mềm hơn kết quả khảo sát.

Đổi gạch thành server và đó chính là công việc. Một kiến trúc sư cloud dành cả tuần cho một hỗn hợp gồm: lắng nghe các bên liên quan phía kinh doanh và trích xuất yêu cầu thật từ những mong ước mơ hồ; thiết kế — chọn thành phần, vẽ sơ đồ, viết ra các quyết định và lý do; review thiết kế của người khác dựa trên sáu trụ cột; ước tính một thiết kế sẽ tốn bao nhiêu mỗi tháng và bảo vệ con số đó trước bộ phận tài chính; lập kế hoạch migration (di trú) các hệ thống cũ lên cloud; thuyết trình — cùng một thiết kế được giải thích một kiểu cho kỹ sư và một kiểu hoàn toàn khác cho lãnh đạo; và cố vấn (mentoring) các kỹ sư để các chuẩn mực sống sót qua va chạm với deadline. Ở nhiều đội còn có cả pre-sales (tiền bán hàng): ngồi cạnh một nhân viên bán hàng trước một khách hàng tiềm năng, phác họa giải pháp thắng được hợp đồng.

Điều một kiến trúc sư không phải là: người viết code giỏi nhất phòng (thường không phải), người gõ phím nhiều nhất (gõ ít nhất), hay một thiên tài đơn độc ban phát bản thiết kế từ trên cao (cách nhanh nhất để bị phớt lờ). Sản phẩm thực sự của kiến trúc sư là những quyết định tốt, được viết ra, mà người khác tự nguyện xây theo.

Bản mô tả công việc mà bạn đang rèn luyện để đáp ứng

Vào tháng 8 năm 2026, chúng tôi thu thập các tin tuyển dụng và mẫu mô tả công việc Cloud/Solutions Architect thực tế — một mẫu cloud-architect của nhà tuyển dụng (KORE1), một bản mô tả công việc của công ty nhân sự (4 Corner Resources), định nghĩa của chính Microsoft về vai trò kiến trúc sư trong Azure Well-Architected Framework, một tin tuyển Solutions Architect pre-sales (Arpio, mảng khôi phục thảm họa AWS), một tin tuyển Solution Architect doanh nghiệp (Intel, qua Built In), và một tin tuyển Cloud Domain Architect doanh nghiệp (Halliburton, ưu tiên Azure). Bỏ đi hương vị công ty thì cùng mười hai yêu cầu ấy xuất hiện lặp đi lặp lại. Khóa học này được xây theo danh sách đó — đây chính xác là nơi mỗi yêu cầu được dạy:

Chứng chỉ, được kiểm chứng trên cùng thị trường đó: bậc thang tiêu chuẩn là AWS Certified Solutions Architect – Associate (SAA-C03) — chứng chỉ đơn lẻ được yêu cầu nhiều nhất, thường cần 2–3 tháng ôn — tiếp theo là AWS Certified Solutions Architect – Professional (SAP-C02), thường thêm 4–8 tháng nữa; các công ty nặng về Azure đòi hỏi AZ-305 (Azure Solutions Architect Expert); các doanh nghiệp lớn đôi khi thêm TOGAF cho phương pháp kiến trúc doanh nghiệp. Kế hoạch đầy đủ nằm ở Giai đoạn 5, Module 14.

GIAI ĐOẠN 1 — CÁC KHỐI XÂY DỰNG, DƯỚI DẠNG QUYẾT ĐỊNH (Tuần 1–6)

Học viên tốt nghiệp Khóa học Kỹ sư Cloud: lướt qua phần giải thích, nhưng làm mọi bài tập. Sự kiện thì giống nhau; câu hỏi thì mới.

Module 1 (Tuần 1–2): Cloud là gì, và kiến trúc sư tư duy như thế nào

Cloud trong một đoạn văn (phần ôn cho người chưa biết gì). Cloud là máy tính của người khác, thuê theo giờ, được quản lý bằng phần mềm. AWS, Microsoft Azure và Google Cloud vận hành những nhà kho chứa server (data center — trung tâm dữ liệu) được nhóm thành các Region (vùng) theo địa lý (ví dụ “Asia Pacific (Bangkok)”); mỗi region chứa vài Availability Zone (AZ — vùng khả dụng) tách biệt — những tòa nhà riêng với nguồn điện độc lập, đủ gần để kết nối nhanh, đủ xa để một trận lụt hay hỏa hoạn không quét sạch được hai cái. Bạn thuê các lát cắt của tất cả những thứ này theo từng giây: máy thô (IaaS — bạn quản lý mọi thứ trên đó), nền tảng được quản lý (PaaS — bạn chỉ mang ứng dụng của mình), hoặc phần mềm hoàn chỉnh (SaaS — bạn chỉ việc dùng). Đó là toàn bộ tầng nền. Mọi thứ một kiến trúc sư thiết kế đều được sắp xếp bên trên nó.

Bây giờ, nước đi của kiến trúc sư: biến mọi sự kiện thành một câu hỏi. Một kỹ sư học “một AZ là một trung tâm dữ liệu tách biệt.” Một kiến trúc sư lập tức hỏi: “Workload này xứng đáng bao nhiêu AZ?” — vì hai AZ tốn hơn một, ba tốn hơn hai, và một trang brochure marketing không xứng đáng với những gì một hệ thống thanh toán xứng đáng. Đây là ý tưởng đầu tiên và quan trọng nhất của khóa học:

Kiến trúc là bộ môn làm cho các đánh đổi trở nên tường minh. Gần như không có thành phần nào sai — chỉ có những thành phần sai cho workload này, ngân sách này, đội ngũ này, deadline này.

Tam giác đánh đổi. Mọi thiết kế đều thương lượng giữa ba góc: nhanh (hiệu năng — nhanh cho người dùng, nhanh để xây), rẻ (hóa đơn tháng thấp, công sức kỹ thuật thấp), và bền bỉ (sống sót qua sự cố, mở rộng được, giữ được an toàn). Bạn có thể đẩy về bất kỳ hai góc nào; góc thứ ba trả giá cho điều đó. Bản mẫu thử của một startup nên nhanh và rẻ — sự bền bỉ có thể đợi. Sổ cái lõi của một ngân hàng phải bền bỉ và nhanh — nó sẽ không rẻ. Khi một bên liên quan nói “chúng tôi muốn cả ba”, việc của bạn là mỉm cười và hỏi họ muốn cái nào nhất, vì bản thiết kế không thể bắt đầu cho đến khi họ trả lời. Hãy vẽ tam giác này ở đầu mỗi bản thiết kế bạn làm trong khóa học này, và đánh dấu workload nằm ở đâu. Nó sẽ giúp bạn tránh được một nghìn cuộc tranh cãi.

Yêu cầu: nguyên liệu thô của thiết kế. Kiến trúc sư tách functional requirements (yêu cầu chức năng — hệ thống làm gì: “khách hàng có thể đặt cơm trưa”) khỏi non-functional requirements (NFR — yêu cầu phi chức năng) (nó phải làm điều đó tốt đến đâu — “dưới 2 giây, cho 10.000 học sinh đồng thời, 99,9% thời gian, trong khuôn khổ PDPA”). Người mới ám ảnh với danh sách thứ nhất; kiến trúc sư kiếm được lương nhờ danh sách thứ hai, vì NFR mới là thứ thực sự quyết định kiến trúc. Hai câu hỏi thần kỳ trích xuất NFR từ những bên liên quan không biết mình có chúng: “What happens to the business if this is down for an hour?” (Điều gì xảy ra với doanh nghiệp nếu cái này sập trong một giờ?) và “What does success look like at ten times today’s size?” (Thành công trông như thế nào ở quy mô gấp mười hôm nay?)

Từ vựng:

Video cho module này (liên kết đã kiểm chứng):

Xem chuyến tham quan của Fireship hai lần: một lần ngay bây giờ để có tấm bản đồ, một lần vào cuối Giai đoạn 1 — bạn sẽ ngạc nhiên vì mình giờ đã đặt được bao nhiêu dịch vụ vào một bản thiết kế.

Bài tập: (1) Chọn ba ứng dụng bạn dùng hằng ngày (một ứng dụng ngân hàng, một ứng dụng giao đồ ăn, một ứng dụng video) và, với mỗi cái, viết ba NFR hàng đầu của nó và đánh dấu nó trên tam giác đánh đổi. (2) Phỏng vấn một người bạn về một ý tưởng kinh doanh trong mười phút và trích xuất năm yêu cầu chức năng cùng năm yêu cầu phi chức năng — để ý rằng các NFR chỉ lộ ra khi bạn hỏi hai câu hỏi thần kỳ. (3) Bắt đầu Design Journal của bạn với mục #1: tam giác, và một đoạn văn về vì sao “chúng ta hy sinh góc nào?” là một câu hỏi kinh doanh, không phải một câu hỏi kỹ thuật.

Milestone: với bất kỳ mô tả hệ thống một câu nào, bạn có thể đưa ra các NFR khả dĩ của nó và vị trí của nó trên tam giác trong năm phút, thành tiếng, không cần ghi chú.

Module 2 (Tuần 3–4): Compute, lưu trữ, cơ sở dữ liệu, mạng — bốn quyết định

Mọi bản thiết kế bạn sẽ từng vẽ đều là bốn lựa chọn này, được đưa ra một cách chủ đích. Đây là từng cái, được dạy như một quyết định.

Quyết định 1 — Compute: VM, container, hay serverless? Một virtual machine (VM — máy ảo) là một lát thuê của một server hoạt động như một máy tính hoàn chỉnh — quyền kiểm soát tối đa, việc bảo trì tối đa (bạn vá nó, bạn mở rộng nó, bạn trả tiền cả khi nó nhàn rỗi). Một container đóng gói một ứng dụng cùng mọi thứ nó cần để nó chạy giống hệt nhau ở mọi nơi; một bộ điều phối (Kubernetes) chạy và chữa lành các hạm đội container — mật độ và tính di động tuyệt vời, nhưng bạn đã nhận nuôi một nền tảng phức tạp cần người có kỹ năng. Serverless (AWS Lambda, Azure Functions) chỉ chạy code của bạn khi được kích hoạt và tính tiền theo mỗi lần gọi — gần như không phải bảo trì và hoàn hảo cho lưu lượng tăng vọt thất thường, nhưng có giới hạn (trần thời gian thực thi, cold start, và một cuộc hôn nhân sâu đậm hơn với một nhà cung cấp). Bảng quyết định mà bạn nên tái tạo được từ trí nhớ:

Cái nhìn sâu của người senior: đây là lựa chọn theo từng workload, không phải tôn giáo của cả công ty. Các hệ thống thực tế chạy cả ba cạnh nhau, một cách đúng đắn.

Quyết định 2 — Lưu trữ: object, block, hay file — và nóng đến đâu? Object storage (lưu trữ đối tượng — Amazon S3) là một chiếc xô không đáy cho file — rẻ, bền đến phi lý (“mười một số chín”), câu trả lời mặc định cho “file để đâu?” Block storage (lưu trữ khối — EBS) là ổ đĩa ảo bắt vít vào một VM. File storage (lưu trữ tệp — EFS) là một ổ dùng chung mà nhiều máy cùng gắn kết một lúc. Chiều bổ sung của kiến trúc sư là nhiệt độ: dữ liệu nóng (truy cập liên tục, định giá cho tốc độ) so với các bậc lạnh/lưu trữ dài hạn (Glacier — vài xu, nhưng vài phút đến vài giờ để lấy lại). Thiết kế các lifecycle rule để dữ liệu cũ trôi dần xuống các bậc lạnh là chiến thắng chi phí rẻ nhất trong cloud; quên làm điều đó là lỗi phổ biến nhất.

Quyết định 3 — Cơ sở dữ liệu: SQL hay NoSQL (và hương vị được quản lý nào)? Cơ sở dữ liệu relational/SQL (quan hệ — PostgreSQL, MySQL; được quản lý dưới dạng RDS/Aurora) giữ dữ liệu trong các bảng chặt chẽ với tính nhất quán được bảo đảm — mặc định cho bất cứ thứ gì mà tính chính xác là thiêng liêng: tiền bạc, đơn hàng, tồn kho, người dùng. Cơ sở dữ liệu NoSQL (DynamoDB, MongoDB) đánh đổi cấu trúc chặt chẽ lấy sự linh hoạt và khả năng mở rộng ngang gần như vô hạn — mặc định cho session, danh mục, bảng tin, telemetry. Quy tắc quyết định: bắt đầu với SQL trừ khi bạn nêu đích danh được lý do cụ thể nó không dùng được (quy mô cực lớn, schema linh hoạt, đọc toàn cầu ở mức mili giây một chữ số). Và trong cloud, “cơ sở dữ liệu” gần như luôn phải nghĩa là “cơ sở dữ liệu được quản lý” — nhà cung cấp lo sao lưu, vá lỗi và failover; một đội tự chạy cơ sở dữ liệu trên VM nên có một lý do được viết ra. Thêm các chuyên gia vào vốn từ của bạn: cache (Redis — dữ liệu nóng trong bộ nhớ, đọc ở mức micro giây), warehouse (kho dữ liệu — phân tích ở quy mô lớn — Giai đoạn 3), queue (hàng đợi — không phải cơ sở dữ liệu, nhưng thường là mảnh ghép còn thiếu — Giai đoạn 3).

Quyết định 4 — Mạng: hình dạng của thế giới riêng. Một VPC (Virtual Private Cloud) là khu vực được rào chắn của bạn trong mạng của nhà cung cấp. Bên trong nó, public subnet chứa những thứ internet được phép chạm tới (load balancer), và private subnet chứa mọi thứ còn lại — server ứng dụng và, luôn luôn, cơ sở dữ liệu. “Cơ sở dữ liệu nằm trong một private subnet” là câu được lặp lại nhiều nhất trong các buổi review kiến trúc; lập luận — không gì tấn công được thứ không có đường dẫn từ internet — là một nửa của bảo mật mạng. Xung quanh VPC: một load balancer trải lưu lượng qua các server và định tuyến vòng qua những cái ốm yếu; DNS (Route 53) biến tên thành địa chỉ; một CDN (CloudFront) lưu đệm nội dung tại hàng trăm thành phố để nó nhanh ở mọi nơi; một API gateway là quầy lễ tân được quản lý cho các API của bạn (xác thực, giới hạn tần suất, ghi log). Kết nối với thế giới cũ: VPN (đường hầm mã hóa qua internet) hoặc Direct Connect (một đường truyền vật lý riêng) — những cuống rốn của mọi thiết kế hybrid ở Giai đoạn 4.

Từ vựng:

Video cho module này (liên kết đã kiểm chứng):

Bài tập: (1) Với mỗi workload trong năm workload sau, chọn compute, cơ sở dữ liệu và lưu trữ, và viết một câu biện minh cho mỗi cái: một trang đặt cơm trưa cho trường học; sổ cái giao dịch của một ngân hàng; một ứng dụng chia sẻ ảnh; một trình tạo báo cáo hằng đêm chạy 20 phút; một ứng dụng chat cho 5 triệu người dùng. (2) Lấy một trong các lựa chọn của bạn và biện luận cho lựa chọn ngược lại một cách thuyết phục nhất có thể — kiến trúc sư không thể “steel-man” phương án thay thế là người chưa hiểu sự đánh đổi. (3) Nhật ký: bảng quyết định compute của bạn, từ trí nhớ.

Milestone: với bất kỳ workload nào trong một câu, bạn có thể nêu tên bốn quyết định của nó kèm biện minh trong dưới ba phút — và với ít nhất một quyết định, nêu được điều gì sẽ khiến bạn đổi ý.

Module 3 (Tuần 5–6): Đọc và vẽ sơ đồ kiến trúc

Một kiến trúc sư không biết vẽ là một nhà tư vấn chỉ biết nói. Sơ đồ là ngôn ngữ làm việc của bạn: module này làm cho bạn đọc chúng trôi chảy và vẽ chúng thành thạo.

Sơ đồ kinh điển — học cái này trước tiên. Three-tier architecture (kiến trúc ba tầng) là “cấu trúc câu” của các sơ đồ cloud; đa số các thiết kế là biến thể của nó:

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

Tầng 1 (presentation — trình diện): thứ người dùng chạm vào — nội dung tĩnh từ CDN, các request đi qua load balancer. Tầng 2 (application — ứng dụng): hạm đội các server thay thế được cho nhau chạy logic của bạn, trong các private subnet, được mở rộng tự động. Tầng 3 (data — dữ liệu): cơ sở dữ liệu, sâu nhất và được bảo vệ nhất, với một bản standby ở AZ thứ hai. Lưu lượng chảy một chiều: người dùng không bao giờ chạm trực tiếp vào tầng ứng dụng, chỉ mình tầng ứng dụng nói chuyện với tầng dữ liệu. Luyện vẽ cái này cho đến khi bàn tay bạn tự làm mà không cần bộ não — nó là màn mở đầu phỏng vấn bảng trắng ở mọi nơi trên trái đất.

Các quy ước ký hiệu khiến bạn trông chuyên nghiệp (vì chúng khiến bạn tư duy chuyên nghiệp): hộp là thành phần — dán nhãn mỗi cái với nó là gì và dịch vụ nào (“App servers — EC2, auto-scaling group”). Mũi tên chỉ hướng một request chảy, dán nhãn giao thức khi điều đó quan trọng. Các đường bao nét đứt chỉ ranh giới — VPC, mỗi subnet, mỗi AZ (vẽ ranh giới AZ và multi-AZ trở nên nhìn thấy được thay vì chỉ được tuyên bố). Một người dùng/tác nhân đứng ngoài hệ thống. Các con số trên mũi tên (1, 2, 3…) cho phép bạn thuật lại hành trình của một request. Và mỗi sơ đồ mang một tiêu đề, một ngày tháng, và một chú giải. Quy tắc sâu hơn: một sơ đồ, một khán giả, một câu hỏi. Một sơ đồ cho thấy mọi thứ thì không cho thấy gì cả; bạn sẽ học bộ mức thu phóng tiêu chuẩn (context → container → deployment) ở Giai đoạn 5.

Đọc sơ đồ của người khác — tia X của kiến trúc sư. Khi được đưa một sơ đồ, hãy chạy bài quét này thành tiếng: Internet chạm vào hệ thống này ở đâu (mỗi điểm chạm là bề mặt tấn công)? Dữ liệu ở đâu, và nó có nằm trong private subnet không? Cái gì được nhân đôi (bền bỉ) và cái gì là single point of failure (điểm hỏng đơn lẻ) — một chiếc hộp không có bản sinh đôi? Đâu sẽ là chỗ đau ở mức lưu lượng 10×? Mỗi chiếc hộp tốn bao nhiêu mỗi tháng? Năm câu hỏi, ba mươi giây, và bạn đã đọc sơ đồ theo cách một bác sĩ đọc phim X-quang. Duyệt AWS Architecture Center (https://aws.amazon.com/architecture/) và chạy bài quét trên ba kiến trúc tham chiếu đã công bố.

Từ vựng:

Bài tập: (1) Vẽ sơ đồ ba tầng từ trí nhớ, năm ngày liên tiếp, cho đến khi mất dưới bốn phút với mọi ranh giới (VPC, subnet, hai AZ) được vẽ. (2) Lấy năm workload của Module 2 và vẽ từng cái — hai mươi phút mỗi sơ đồ, các quy tắc ký hiệu được thực thi. (3) Tìm bất kỳ sơ đồ kiến trúc thật nào trên mạng (AWS Architecture Center có hàng trăm), và viết bài quét X-quang năm-câu-hỏi của nó vào nhật ký. (4) Bài luyện thuật lại: sơ đồ trước mặt, thuật lại một cú nhấp của người dùng từ trình duyệt đến cơ sở dữ liệu và quay về, thành tiếng, đánh số các mũi tên khi bạn đi.

Milestone — kết thúc Giai đoạn 1: trên một bảng trắng (hoặc giấy, chụp lại cho nhật ký), bạn có thể vẽ một thiết kế ba tầng đúng, ký hiệu chuẩn, cho một workload một-câu mới lạ trong dưới mười lăm phút, thuật lại một request đi qua nó, và trả lời “cái gì hỏng nếu hộp này chết?” cho mọi chiếc hộp. Màn vẽ-cộng-chất-vấn này chính xác là nửa đầu của một buổi phỏng vấn kiến trúc sư thực thụ — từ đây trở đi, mọi thứ là chiều sâu.

GIAI ĐOẠN 2 — CÁC MIỀN THIẾT KẾ (Tuần 7–14)

Tấm bản đồ cho giai đoạn này là AWS Well-Architected Framework — danh sách kiểm tra chung của cả ngành về ý nghĩa của “được thiết kế đúng đắn”, được tổ chức thành sáu trụ cột: vận hành xuất sắc, bảo mật, độ tin cậy, hiệu quả hiệu năng, tối ưu chi phí, tính bền vững. (Azure có một framework gần như giống hệt; học sâu một cái là bạn đã học cả hai.) Các bản mô tả công việc đòi hỏi đích danh những kiến trúc sư có thể “run Well-Architected reviews” (điều hành các buổi Well-Architected review), nên chúng ta đi qua từng trụ cột một, và với mỗi trụ bạn học ba thứ: các câu hỏi then chốt của trụ cột, các mẫu hình chuẩn của nó (những câu trả lời nhàm chán nhưng đã được chứng minh — kiến trúc sư lắp ráp trước khi phát minh), và một ví dụ mẫu trên một kịch bản xuyên suốt.

Kịch bản xuyên suốt cho toàn bộ Giai đoạn 2: ThaiTicket, một nền tảng bán vé sự kiện hư cấu ở Bangkok. Tải bình thường: 2.000 lượt truy cập/giờ. Nhưng khi vé của một nghệ sĩ nổi tiếng mở bán lúc 10 giờ sáng, nó hứng 400.000 lượt truy cập trong mười phút, khâu thanh toán không được bán trùng ghế, và dữ liệu cá nhân của khách hàng Thái nằm trong phạm vi PDPA. Nhanh, rẻ, bền bỉ — ThaiTicket cần cả ba và không thể có cả ba, đó chính là điều khiến nó thành bệnh nhân thực hành hoàn hảo.

Xem trước Module 4 (liên kết đã kiểm chứng):

Và bookmark chính framework — https://aws.amazon.com/architecture/well-architected/ và tài liệu đầy đủ tại https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html — bạn sẽ sống trong đó tám tuần.

Module 4 (Tuần 7–8): Độ tin cậy — thiết kế cho cái ngày mọi thứ hỏng

Tín điều của trụ cột này: mọi thứ hỏng, mọi lúc. Ổ đĩa chết, AZ ngập lụt, các đợt deploy trục trặc, và một certificate ở đâu đó luôn sắp hết hạn. Độ tin cậy không phải là sự vắng mặt của hỏng hóc — nó là sự vô nghĩa của hỏng hóc: thiết kế sao cho khi (không phải nếu) một thành phần chết, người dùng không bao giờ nhận ra.

Các câu hỏi then chốt (hỏi những câu này với mọi thiết kế, mãi mãi): Điều gì xảy ra khi mỗi thành phần hỏng — luôn có một “rồi sao nữa” chứ? Hệ thống xử lý tải 10× như thế nào? Làm sao chúng ta biết có gì đó hỏng trước khi khách hàng báo? RTO và RPO của chúng ta là bao nhiêu — và ai trong doanh nghiệp đã ký duyệt chúng? Lần cuối chúng ta kiểm chứng một cuộc khôi phục là khi nào?

RTO và RPO — hai con số chính là cuộc trò chuyện về thảm họa. Recovery Time Objective (mục tiêu thời gian khôi phục): chúng ta được phép sập bao lâu? Recovery Point Objective (mục tiêu điểm khôi phục): chúng ta được phép mất bao nhiêu dữ liệu (tức là, bản backup tốt gần nhất được phép cũ đến đâu)? RTO 4 giờ và RPO 1 giờ nghĩa là: trở lại trong vòng bốn giờ, mất nhiều nhất một giờ dữ liệu. Đây là các quyết định kinh doanh với bảng giá tăng theo cấp số nhân — RPO 24 giờ là một bản sao lưu hằng đêm (rẻ); RPO ~0 là sao chép liên tục (đắt); RTO tính bằng phút nghĩa là hạ tầng ấm chạy chờ sẵn (rất đắt). Việc của kiến trúc sư là làm cho doanh nghiệp chọn các con số một cách có hiểu biết — và thiết kế chính xác theo chúng, chứ không lãng mạn vượt quá chúng.

Các mẫu hình chuẩn: redundancy (dự phòng — hai bản của mọi thứ quan trọng — N+1) · multi-AZ (các bản sao trải qua các trung tâm dữ liệu; load balancer và failover của cơ sở dữ liệu được quản lý làm nó tự động) · auto-scaling (công suất đi theo nhu cầu) · health check + tự chữa lành (instance chết được phát hiện và thay thế bởi máy móc, không phải con người) · backup, đã kiểm chứng (một bản backup chưa kiểm chứng là một niềm hy vọng, không phải một kế hoạch — hãy lên lịch các buổi diễn tập khôi phục) · graceful degradation (suy giảm có kiểm soát — khi quá tải, buông các tính năng ít quan trọng nhất trước: ThaiTicket có thể bỏ bản xem trước sơ đồ ghế và giữ lại khâu checkout) · queue làm giảm xóc (Giai đoạn 3) · tránh hỏng hóc dây chuyền (timeout, retry với backoff, circuit breaker — để một phụ thuộc chậm chạp không dìm chết cả hạm đội).

Ví dụ mẫu — thiết kế độ tin cậy cho ThaiTicket. Hai AZ trong region Bangkok. Tầng ứng dụng stateless trong một auto-scaling group sau một load balancer, được làm ấm trước theo lịch trước các giờ mở bán đã công bố (auto-scaling phản ứng trong vài phút; một đợt mở bán lúc 10:00 cần công suất lúc 09:45). Cơ sở dữ liệu Aurora, primary ở AZ-a, standby đồng bộ ở AZ-b, failover tự động ≈ dưới một phút. Một queue giữa các cú nhấp “mua” và khâu xử lý thanh toán để một sự chậm chạp của nhà cung cấp thanh toán xếp hàng các đơn thay vì làm sập trang. Backup: liên tục, khôi phục theo thời điểm, diễn tập khôi phục hằng tháng. Các con số đã thống nhất với doanh nghiệp: RTO 15 phút, RPO ~0 cho đơn hàng (đó là tiền), RPO 24 giờ cho dữ liệu phân tích (thì không). Bài tập nhật ký: cái này đã lấy đi của chúng ta gì từ góc “rẻ” của tam giác?

Từ vựng:

Bài tập: (1) Lấy thiết kế đặt-cơm-trưa của Giai đoạn 1 và nâng cấp nó để sống sót qua: một instance chết, mất một AZ, một sự cố cơ sở dữ liệu, và một giờ cao điểm ăn trưa 10× — vẽ bản trước và sau. (2) Viết cuộc trò chuyện RTO/RPO cho ba doanh nghiệp (một blog, một trang thương mại điện tử, một hệ thống hồ sơ bệnh viện) dưới dạng một đoạn hội thoại ngắn giữa kiến trúc sư và chủ doanh nghiệp — luyện cách làm cho chi phí hiện hình trong hội thoại. (3) Nhật ký: liệt kê mọi SPOF trong thiết kế ThaiTicket ở trên. Có ít nhất một cái được để lại một cách chủ ý. (Gợi ý: bao nhiêu region?)

Milestone: bạn có thể chạy màn chất vấn “điều gì xảy ra khi cái này hỏng?” trên bất kỳ sơ đồ nào trong mười phút liên tục mà không cạn lời, và bạn có thể giải thích RTO vs RPO cho một chủ doanh nghiệp không chuyên kỹ thuật bằng phép so sánh cửa-hàng-bị-ngập trong chín mươi giây.

Module 5 (Tuần 9–10): Bảo mật — thiết kế những hệ thống khó bị tổn thương

Khung nhìn: shared responsibility model (mô hình trách nhiệm chia sẻ). Nhà cung cấp bảo vệ bản thân cloud — tòa nhà, phần cứng, hypervisor. Bạn bảo vệ mọi thứ bạn đặt vào đó — dữ liệu, danh tính, cấu hình, code. Gần như mọi vụ rò rỉ cloud nổi tiếng đều là một cấu hình sai phía khách hàng (một bucket public, một key bị lộ, một role được cấp quyền quá tay), đó là lý do bảo mật là một bài toán kiến trúc trước khi là một bài toán công cụ: các bản mô tả công việc nói “integrate security into the design rather than bolting it on” (tích hợp bảo mật vào thiết kế thay vì gắn thêm sau), và module này là cách làm điều đó.

Các câu hỏi then chốt: Ai và cái gì có thể truy cập mỗi thành phần, và mọi quyền hạn có phải là mức tối thiểu cần thiết không? Dữ liệu được mã hóa ở đâu — khi lưu trữ, khi truyền, và ai giữ khóa? Các ranh giới mạng ở đâu, và cái gì băng qua chúng? Chúng ta sẽ phát hiện một vụ xâm nhập bằng cách nào — và có kể lại được câu chuyện sau đó từ log không? Luật nào áp dụng cho dữ liệu này, và dữ liệu sống ở đâu về mặt vật lý?

Các mẫu hình chuẩn: least privilege (đặc quyền tối thiểu — mỗi con người và chương trình nhận mức truy cập tối thiểu mà công việc của nó cần — quy tắc vàng mà mọi IAM policy bị phán xét theo) · MFA ở khắp nơi, root cất kỹ · mã hóa khi lưu trữ và khi truyền, luôn bật (trong cloud nó là một ô đánh dấu; không có lý do bào chữa nào) · phân đoạn mạng (public/private subnet, security group làm tường lửa theo-từng-server; bán kính sát thương của một vụ xâm nhập được định nghĩa bởi những bức tường bạn đã vẽ từ trước) · bí mật trong két, không bao giờ trong code · zero trust (kiểm chứng mọi request một cách tường minh — danh tính, thiết bị, ngữ cảnh — không tin gì chỉ vì nó “ở bên trong mạng”; các JD gọi tên nó, bạn cũng phải thế) · defense in depth (phòng thủ theo chiều sâu — nhiều lớp, để một biện pháp thất bại không phải là hết trận) · audit logging (nhật ký kiểm toán kiểu CloudTrail về ai đã làm gì — bất biến, được giám sát) · bảo mật như guardrail, không phải cổng chặn (mã hóa các quy tắc thành chính sách tự động làm cho con đường an toàn thành con đường dễ đi, thay vì một cuộc họp review biến bảo mật thành kẻ thù của tiến độ).

Ví dụ mẫu — thiết kế bảo mật cho ThaiTicket. Dữ liệu khách hàng (tên, email, tham chiếu thanh toán) được phân loại là dữ liệu cá nhân theo PDPA → lưu mã hóa trong Aurora ở region Bangkok (data residency — lưu trú dữ liệu), khóa trong KMS. Mạng: chỉ load balancer là public; tầng ứng dụng private; subnet cơ sở dữ liệu chỉ chấp nhận kết nối duy nhất từ security group của tầng ứng dụng. Con người: SSO + MFA; kỹ sư mặc định nhận quyền chỉ-đọc trên production và quyền nâng cao có giới hạn thời gian khi yêu cầu (least privilege kèm dấu vết kiểm toán). Việc xử lý thẻ thanh toán được ủy thác cho một nhà cung cấp thanh toán được chứng nhận để số thẻ thô không bao giờ chạm vào hệ thống của chúng ta — một quyết định thiết kế gỡ bỏ cả một gánh nặng tuân thủ, đó chính là kiến trúc bảo mật ở dạng đẹp nhất. CloudTrail bật, cảnh báo về truy cập bất thường. Câu hỏi về xâm nhập được trả lời trước: PDPA có nghĩa vụ thông báo trong 72 giờ — log và runbook phải cho phép chúng ta kể lại câu chuyện trong thời gian ngắn hơn thế.

Từ vựng:

Video cho module này (liên kết đã kiểm chứng): The AWS Shared Responsibility Model — Digital Cloud Training — ~4 phút — https://www.youtube.com/watch?v=ESPBBEK-cvo

Bài tập: (1) Vẽ sơ đồ ThaiTicket và phủ lớp bảo mật lên nó: đánh dấu mọi ranh giới tin cậy, mọi điểm mã hóa, mọi nơi thông tin xác thực sinh sống. Thói quen phủ lớp này — cùng một sơ đồ, lăng kính bảo mật — chính xác là điều một buổi review đòi hỏi ở bạn. (2) Đọc một bản post-mortem công khai về một vụ rò rỉ do cấu hình cloud sai (Capital One 2019 là bài giảng kinh điển) và viết vào nhật ký mẫu hình nào ở trên lẽ ra đã ngăn được nó. (3) Nhập vai với một AI: nó đóng một nhà sáng lập startup nói “bảo mật để sau” — thuyết phục họ từ bỏ ý định đó bằng phép tính chi-phí-của-một-vụ-rò-rỉ, một cách tử tế.

Milestone: bạn có thể lấy bất kỳ sơ đồ Giai đoạn 1 nào của mình và tạo ra lớp phủ bảo mật của nó trong hai mươi phút, và giải thích least privilege, zero trust và shared responsibility model cho một bên liên quan không chuyên kỹ thuật mà không dùng biệt ngữ.

Module 6 (Tuần 11–12): Hiệu năng và chi phí — tốc độ và tiền bạc, cặp trụ cột song sinh

Hai trụ cột này được dạy cùng nhau vì chúng là cùng một cần gạt bị đẩy theo hai hướng ngược nhau, và kiến trúc sư là người đặt tay trên cần gạt.

Hiệu quả hiệu năng — các câu hỏi then chốt: Người dùng sẽ cảm thấy chậm ở đâu trước tiên? Cái gì được tính toán lặp đi lặp lại mà lẽ ra có thể tính một lần rồi cache? Mỗi thành phần có phải là công cụ đúng không (SQL làm việc của một máy tìm kiếm là một lỗi hiệu năng của kiến trúc, không phải của code)? Hiệu năng thay đổi thế nào ở mức 10× — và nút thắt cổ chai đầu tiên ở đâu?

Các mẫu hình hiệu năng: các lớp cache — mẫu hình hiệu năng đòn bẩy cao nhất: cache trình duyệt → CDN ở biên (nội dung tĩnh phục vụ từ một thành phố gần người dùng; có thể hấp thụ phần lớn áp đảo của lưu lượng đọc) → cache ứng dụng (Redis đứng trước cơ sở dữ liệu cho các lượt đọc nóng: sơ đồ ghế, session, trang sản phẩm) → cache truy vấn cơ sở dữ liệu. Mỗi lớp trả lời các request trước khi chúng chạm tới phần lõi đắt đỏ; các câu hỏi thiết kế luôn là cái gì được phép cache, trong bao lâu, và nó được vô hiệu hóa thế nào khi sự thật thay đổi. Tiếp theo: read replica (các bản sao của cơ sở dữ liệu phục vụ lượt đọc để bản primary chuyên tâm ghi) · xử lý bất đồng bộ (đừng bắt người dùng chờ những việc có thể làm sau — email biên nhận, ảnh thu nhỏ, báo cáo) · đúng công cụ cho đúng việc (tìm kiếm → một máy tìm kiếm; phân tích → một warehouse; tra cứu nóng → một kho key-value) · và đo trước đã (làm hiệu năng mà không đo lường là mê tín).

Tối ưu chi phí — các câu hỏi then chốt: Thiết kế này tốn bao nhiêu mỗi tháng ở tải hôm nay — và trên mỗi đơn vị (mỗi đơn hàng, mỗi khách hàng)? Cái gì đang chạy lúc 3 giờ sáng mà không cần thiết? Mức sử dụng ổn định nào có thể cam kết để được chiết khấu? Bộ phận tài chính sẽ nói xu hướng là gì?

Các mẫu hình chi phí: rightsizing (đa số các hạm đội bị cấp thừa một cách âm thầm; thu nhỏ về đúng nhu cầu đo được là tiền nhặt được) · chiến lược đặt trước — thực đơn giá: on-demand (giá đầy đủ, tự do đầy đủ) cho tải tăng vọt/chưa rõ, reserved instances / savings plans (cam kết 1–3 năm, giảm 30–70%) cho phần nền ổn định, spot (giảm đến 90%, có thể bị thu hồi trong thời gian ngắn) cho công việc batch chịu được gián đoạn; nước đi của kiến trúc sư là xếp lớp chúng: đặt trước phần sàn, auto-scale phần giữa bằng on-demand, spot cho batch · vòng đời lưu trữ (phân bậc của Module 2, tự động hóa) · tắt mọi thứ đi (các môi trường phi production ngủ đêm và cuối tuần có thể cắt hai phần ba chi phí của chúng) · canh chừng egress (dữ liệu rời khỏi cloud bị tính tiền; các thiết kế xuyên region lắm lời và các lượt tải công khai lớn khiến ai cũng bất ngờ một lần) · tagging và showback (mọi tài nguyên dán nhãn chủ sở hữu/dự án để mỗi baht đều truy được trách nhiệm) · và chỉ số vương miện, unit economics (kinh tế học đơn vị): không phải “hóa đơn là ฿800k/tháng” mà là “chi phí trên mỗi vé bán ra là ฿1,90 và đang giảm.” Hóa đơn tăng thì không sao; chi phí đơn vị tăng là một mùi kiến trúc. Bộ môn này có một cái tên — FinOps — và kiến trúc sư ngồi giữa nó.

Ví dụ mẫu — ThaiTicket, cả hai lăng kính. Hiệu năng: CloudFront phục vụ các trang nghệ sĩ và ảnh sơ đồ ghế (400.000 người hiếu kỳ phần lớn không bao giờ chạm tới các server); Redis cache tình trạng ghế trống với TTL 2 giây — đủ cũ để rẻ, đủ mới để khâu checkout (thứ kiểm tra lại với Aurora, nguồn sự thật) ngăn việc bán trùng; biên nhận và vé được tạo bất đồng bộ sau thanh toán. Chi phí: phần nền ổn định 2.000 lượt truy cập/giờ chạy trên một savings plan (≈40% giảm); các cơn sốt mở bán chạy on-demand trong đúng cái giờ chúng tồn tại; các job phân tích chạy trên spot vào ban đêm; staging ngủ ngoài giờ làm việc; mọi tài nguyên gắn tag project:thaiticket. Bản đề xuất cho CFO viết: “฿62.000/tháng cho phần nền, ≈฿9.000 cho mỗi sự kiện mở bán lớn, chi phí trên mỗi vé ≈฿1,90 giảm dần theo sản lượng” — và chính câu đó là âm thanh của một kiến trúc sư trôi chảy về chi phí.

Từ vựng:

Video cho module này (liên kết đã kiểm chứng): What is FinOps? — FinOps Foundation (official) — ~2 phút — https://www.youtube.com/watch?v=Y-c_xw9bHFw

Bài tập: (1) Định giá phần nền của ThaiTicket trong AWS pricing calculator (tìm kiếm “AWS pricing calculator” — bài tập liệt kê từng hạng mục của một thiết kế thật một lần sẽ giải mã mọi cuộc trò chuyện chi phí tương lai); so sánh tổng của bạn với con số ฿62.000 ở trên và giải thích mọi khoảng chênh. (2) Thêm lớp phủ caching cho hai sơ đồ Giai đoạn 1 của bạn: đánh dấu mỗi cache, TTL của nó, và câu chuyện vô hiệu hóa của nó. (3) Một AI đóng vai một kỹ sư muốn mọi thứ on-demand “cho đơn giản” — thương lượng chiến lược đặt trước, với các con số.

Milestone: với bất kỳ thiết kế nào bạn đã vẽ, bạn có thể nêu ba dòng chi phí lớn nhất của nó và nút thắt cổ chai đầu tiên khả dĩ — và đề xuất một thay đổi cải thiện cả hai cùng lúc (gần như luôn có một cái; caching thường là nó).

Module 7 (Tuần 13–14): Vận hành xuất sắc, tính bền vững — và chạy cả sáu trụ cột cùng nhau

Vận hành xuất sắc là trụ cột đặt câu hỏi: con người có thực sự vận hành được thứ này, một cách bình tĩnh không? Các câu hỏi then chốt: Một thay đổi đến production bằng cách nào — qua một pipeline tự động, đã kiểm thử, hay qua một con người anh hùng? Làm sao chúng ta biết hệ thống khỏe mạnh ngay lúc này? Khi nó hỏng lúc 3 giờ sáng, kỹ sư on-call thực sự làm gì? Các mẫu hình: infrastructure as code (môi trường được định nghĩa trong văn bản được review, có quản lý phiên bản — Terraform/CloudFormation — nên nó tái tạo được và kiểm toán được; một kiến trúc chỉ tồn tại dưới dạng các cú nhấp trong console là truyện dân gian, không phải kỹ thuật) · các pipeline CI/CD với chiến lược triển khai an toàn (blue-green: dựng phiên bản mới cạnh bản cũ và chuyển; canary: cho phiên bản mới 5% lưu lượng và quan sát) · observability (khả năng quan sát — log, metric, trace, và các cảnh báo gắn với triệu chứng người dùng thấy được, không phải chuyện vặt của máy móc) · runbook (bản viết phải-làm-gì cho mỗi kiểu hỏng đã biết) · post-mortem không đổ lỗi (sau sự cố: cái gì hỏng, vì sao, cái gì ngăn lặp lại — không có kẻ xấu, nếu không mọi người ngừng nói sự thật). Phần của kiến trúc sư: thiết kế cho tính vận hành được — một hệ thống thông minh gấp đôi mà dễ quan sát bằng nửa là một hệ thống tệ hơn.

Tính bền vững, trụ cột thứ sáu, yêu cầu bạn lãng phí thế giới vật lý ít hơn: rightsize (CPU nhàn rỗi đốt điện thật), mở rộng theo nhu cầu thay vì cấp phát theo đỉnh, dùng dịch vụ được quản lý và serverless (hạ tầng chia sẻ là hạ tầng được lấp đầy hơn), phân bậc lưu trữ, và xóa những gì đã chết. Thật tiện, lựa chọn bền vững và lựa chọn rẻ thường là cùng một lựa chọn — nói cả hai trong các buổi review và bạn sẽ thuyết phục cả phòng hai lần.

Chạy các trụ cột cùng nhau — buổi Well-Architected review đầu tiên của bạn. Trong các buổi review thực tế, các trụ cột xung đột: độ tin cậy multi-region đánh nhau với chi phí; review bảo mật nghiêm ngặt đánh nhau với tốc độ vận hành; caching hiệu năng đánh nhau với tính đúng đắn của độ tươi dữ liệu. Framework không giải quyết xung đột thay bạn — nó ép chúng ra chỗ sáng, nơi doanh nghiệp có thể lựa chọn. Đó là toàn bộ thiên tài của nó, và là của bạn để vận dụng. Bản thân phương pháp review (các bộ câu hỏi, xếp ưu tiên phát hiện, bản báo cáo) được dạy đầy đủ ở Giai đoạn 5, Module 12; hai tuần này bạn tập dượt kỹ năng thô: chất vấn một thiết kế từ sáu hướng trong một lần ngồi.

Từ vựng:

Bài tập: (1) Bài luyện sáu lăng kính: lấy sơ đồ tốt nhất của bạn và dành mười phút cho mỗi trụ cột để viết các phát hiện — sáu mươi phút, một thiết kế, sáu lăng kính; bài luyện này chính là Giai đoạn 2 thu nhỏ, lặp lại nó hằng tuần từ giờ. (2) Đọc hai báo cáo hậu-sự-cố của AWS (được công bố trên các trang trạng thái của họ sau các vụ sập lớn) và nhận diện mẫu hình của trụ cột nào đã thất bại. (3) Nhật ký: với ThaiTicket, viết ba xung-đột-trụ-cột bạn sẽ nêu lên cho doanh nghiệp, mỗi cái là một lựa chọn một câu (“Chúng ta có thể có X hoặc Y ở ngân sách này — chọn cái nào?”).

Milestone — kết thúc Giai đoạn 2: buổi review giả lập: một AI tạo ra một kiến trúc đầy lỗi cho một startup cho vay trực tuyến Thái; bạn phải tạo ra các phát hiện viết ra trên cả sáu trụ cột, bao gồm ít nhất: một khoảng trống độ tin cậy (cơ sở dữ liệu single-AZ của họ), một khoảng trống bảo mật (IAM quá rộng), một khoảng trống chi phí (mọi thứ on-demand), một khoảng trống vận hành (không có IaC), và cuộc trò chuyện RTO/RPO họ chưa từng có — mỗi phát hiện được diễn đạt như một câu hỏi mà một đồng nghiệp có thể nghe mà không nhăn mặt. Khi danh sách phát hiện của bạn đọc lên giống một đồng nghiệp senior tận tình hơn là một kiểm toán viên, Giai đoạn 2 hoàn tất.

GIAI ĐOẠN 3 — DANH MỤC MẪU HÌNH (Tuần 15–20)

Kiến trúc sư không phát minh; họ lựa chọn. Giai đoạn này là danh mục các kiến trúc chuẩn của bạn — với mỗi cái: nó là gì, khi nào dùng, khi nào không, và hồ sơ chi phí/độ phức tạp của nó. Các cột “khi nào không” là trọng tải thực sự của giai đoạn: khóa học nào cũng nói được cho bạn microservices là gì; biết khi nào chúng sẽ đánh sập một công ty mới là thứ bạn được trả tiền. Trong khi học, hãy tiếp tục duyệt các kiến trúc tham chiếu thực tế tại https://aws.amazon.com/architecture/ — nhận diện mẫu hình ngoài tự nhiên là bài tập khiến danh mục dính lại.

Module 8 (Tuần 15–17): Các mẫu hình ứng dụng

Monolith vs. microservices — cuộc cãi vã ồn ào nhất của ngành, được phân xử một cách bình thản. Một monolith (khối nguyên) là một ứng dụng triển khai duy nhất chứa mọi tính năng; microservices chia hệ thống thành nhiều dịch vụ nhỏ, triển khai độc lập, mỗi cái sở hữu dữ liệu của mình, nói chuyện qua API và sự kiện. Bảng trung thực:

Phán quyết của kiến trúc sư: bắt đầu bằng monolith, mô-đun hóa bên trong; tách dịch vụ ra khi — và chỉ khi — một cơn đau về mở rộng đội ngũ hoặc mở rộng tải thực sự xuất hiện. Nói điều này trong phỏng vấn, kèm lý do, đánh dấu bạn là senior; giáo điều theo bất kỳ hướng nào đánh dấu bạn là junior.

Event-driven architecture (kiến trúc hướng sự kiện) — queue và topic, những bộ giảm xóc. Thay vì các thành phần gọi nhau và chờ đợi (đồng bộ), các thành phần công bố event (sự kiện — “OrderPlaced”) vào một queue (hàng đợi — SQS — một consumer lấy mỗi thông điệp, theo nhịp của riêng nó) hoặc một topic (SNS — mọi subscriber nhận một bản sao; fan-out). Bên sản xuất không biết và không quan tâm ai đang nghe. Dùng khi: các thành phần nên sống sót qua sự cố của nhau (queue giữ thông điệp trong khi một consumer sập — sự bền bỉ và sự tách rời trong một lần mua); tải tăng vọt (queue hấp thụ cơn sốt; các worker rút cạn nó đều đặn); một sự kiện kích hoạt nhiều phản ứng (đơn hàng được đặt → trừ tiền, email, tồn kho, phân tích — bốn subscriber, không chút ràng buộc nào). KHÔNG dùng khi: người dùng cần câu trả lời ngay bây giờ (checkout không thể xác nhận “rồi sẽ có”); hoặc đội nhỏ và một lời gọi đồng bộ đơn giản là đủ — mỗi queue thêm ngữ nghĩa giao nhận (at-least-once nghĩa là các consumer phải idempotent — an toàn khi chạy hai lần), xử lý dead-letter, và một gánh nặng giám sát. Chi phí/độ phức tạp: các thành phần rẻ, gỡ lỗi đắt hơn — câu chuyện của một request giờ đây rải rác qua các dịch vụ và queue, đó là lý do observability (Module 7) từ đây ngừng là tùy chọn.

Three-tier: đã là của bạn (Module 3). Dùng cho: dải giữa rộng lớn của các ứng dụng web — nó là mẫu hình mà các mẫu khác được đo theo. Không dùng cho: các workload tăng vọt dữ dội với những quãng trũng nhàn rỗi (serverless rẻ hơn) hoặc các sản phẩm đa-đội thực sự khổng lồ (xem ở trên). Hồ sơ: được hiểu rõ ở mọi nơi, dễ tuyển người, chi phí trung bình.

Serverless-first: ghép các mảnh được quản lý — API Gateway → các Lambda function → DynamoDB, S3 và các queue — không sở hữu server nào cả. Dùng khi: lưu lượng tăng vọt hoặc thấp (scale-to-zero nghĩa là chi phí nhàn rỗi ~0), đội nhỏ, ra thị trường nhanh, chất keo hướng sự kiện. KHÔNG dùng khi: compute chạy dài hoặc chuyên biệt (giới hạn runtime), các đường đi siêu nhạy độ trễ (cold start), tải ổn định khổng lồ (giá theo-mỗi-lần-gọi có thể vượt server đặt trước — hãy làm phép tính ở quy mô), hoặc khi tính di động giữa các cloud là một yêu cầu thực sự (đây là mức lock-in sâu nhất trong mọi mẫu hình — thường đáng giá, nhưng phải nói ra thành tiếng). Hồ sơ: gánh nặng vận hành thấp nhất trong danh mục; chi phí tuyệt hảo ở quy mô thấp/tăng vọt, cần kiểm tra ở quy mô ổn định cao.

Từ vựng:

Bài tập: (1) Thiết kế luồng đặt hàng của ThaiTicket hai lần — ba tầng đồng bộ, rồi hướng sự kiện với SQS/SNS — và viết một đoạn văn về việc mỗi phiên bản làm gì trong một sự cố của nhà cung cấp thanh toán; đoạn văn đó là toàn bộ lập luận cho events. (2) Với bốn công ty (startup 3 người, scale-up 50 kỹ sư, một ngân hàng, một ứng dụng bình chọn truyền hình dùng 4 đêm/năm), chọn một mẫu hình và bảo vệ nó — rồi nêu tên cú hích sẽ khiến mỗi công ty đổi mẫu hình. (3) Tìm một câu chuyện blog kỹ thuật thực tế “chúng tôi chuyển sang microservices và hối hận” và một câu chuyện thành công; ghi nhật ký điểm khác biệt (gần như luôn là kích cỡ đội và độ chín của miền).

Milestone: với một bản mô tả công ty, bạn có thể đề xuất một mẫu hình kèm lối thoát của nó — “bắt đầu ở đây; khi X xảy ra, tiến hóa sang Y” — trong năm phút. Các lộ trình tiến hóa, không phải các bản án, mới là cách kiến trúc sư thực sự nói chuyện.

Module 9 (Tuần 18–20): Các mẫu hình dữ liệu, toàn cầu và hybrid

Kiến trúc dữ liệu — lake vs. warehouse. Các cơ sở dữ liệu giao dịch (Giai đoạn 1) vận hành doanh nghiệp; mảng phân tích muốn đặt câu hỏi với nó mà không làm nó chậm đi. Một data warehouse (kho dữ liệu — Redshift, Snowflake, BigQuery) lưu dữ liệu có cấu trúc, đã làm sạch, tối ưu cho phân tích SQL nhanh — dùng khi các câu hỏi đã biết trước và các dashboard phải nhanh; tốn hơn mỗi TB, cần kỷ luật mô hình hóa từ đầu. Một data lake (hồ dữ liệu — S3 + catalog + các engine truy vấn như Athena) lưu mọi thứ, thô, rẻ — log, clickstream, hình ảnh — và áp cấu trúc lúc đọc; dùng khi bạn muốn giữ mọi thứ ngay bây giờ và quyết định câu hỏi sau; nhưng không được quản trị thì nó suy biến thành trò đùa của ngành, cái data swamp (đầm lầy dữ liệu). Sự đồng thuận hiện đại là cả hai, xếp lớp (“lakehouse”): sự thật thô trong lake, các mart tuyển chọn trong warehouse, được nuôi bởi các pipeline ETL/ELT. Các quy tắc của kiến trúc sư: mảng phân tích không bao giờ truy vấn cơ sở dữ liệu production (replica hoặc pipeline nuôi nó), và mỗi bộ dữ liệu có một chủ sở hữu, một mục catalog, và một chính sách lưu giữ — dòng quản trị đó là một câu trong bản thiết kế của bạn và là một năm đau khổ nếu bạn bỏ sót.

Multi-region: active-passive vs. active-active. Khi một region là không đủ — vì doanh nghiệp đòi hỏi DR trước các thảm họa cấp region, hoặc người dùng trải dài các châu lục — bạn chọn:

Câu nói cấp-phỏng-vấn: “Multi-AZ is table stakes; multi-region is a business case.” (Multi-AZ là điều kiện tối thiểu; multi-region là một bài toán kinh doanh.) Hãy để doanh nghiệp tuyên bố RTO/RPO, định giá các phương án, và để các con số lựa chọn.

Hybrid cloud. Một phần on-prem, một phần cloud, nối bằng VPN hoặc Direct Connect — với đa số doanh nghiệp lâu đời, không phải một mẫu hình mà là một thực tại kéo dài cả thập kỷ: những mainframe không thể di dời, các hệ thống nhà máy bị trói bởi độ trễ, dữ liệu bị quản chế ghim tại chỗ, và một cuộc migration (Giai đoạn 4) đang đi ngang qua. Dùng như: một cây cầu có chủ đích với một hướng di chuyển. KHÔNG chấp nhận: “hybrid” như một uyển ngữ cho “chúng tôi chưa bao giờ quyết định.” Ghi chú thiết kế: danh tính phải được hợp nhất trước tiên (một lần đăng nhập xuyên cả hai thế giới — thứ mà các JD doanh nghiệp muốn nói bằng “hybrid identity integration”); nêu đích danh hệ thống nào là nguồn sự thật; canh chừng chi phí egress-qua-đường-truyền; và dự liệu rằng đường mạng sẽ là một SPOF trừ khi được nhân đôi. Độ phức tạp: hai cơ ngơi với đủ thứ của mỗi bên — lý do trung thực khiến kiến trúc sư thúc đẩy thu nhỏ phía on-prem một cách đều đặn.

Từ vựng:

Bài tập: (1) ThaiTicket vươn ra khu vực: thiết kế cuộc mở rộng sang Singapore hai lần — active-passive (Bangkok là primary) và active-active — với bội số chi phí và RTO/RPO cho mỗi cái; viết bản khuyến nghị một trang và ra một quyết định. (2) Một nhà bán lẻ có 15 năm dữ liệu bán hàng trong một cơ sở dữ liệu SQL production và muốn “phân tích sẵn sàng cho AI”; phác họa thiết kế lake + warehouse và viết ba câu quản trị. (3) Nhận diện mẫu hình: chọn ba kiến trúc tham chiếu từ https://aws.amazon.com/architecture/ và nêu tên mọi mẫu hình danh mục có mặt trong mỗi cái.

Milestone — kết thúc Giai đoạn 3: màn thử thách danh mục: một AI đưa bạn sáu kịch bản dồn dập; với mỗi cái bạn nêu tên mẫu hình, lý do, lời cảnh báo khi-KHÔNG, và hồ sơ chi phí/độ phức tạp — dưới năm phút mỗi cái. Chính cuộc trao đổi này, ở chính tốc độ này, là một phần ba giữa của một buổi phỏng vấn kiến trúc sư thực thụ.

GIAI ĐOẠN 4 — MIGRATION VÀ THẾ GIỚI THỰC (Tuần 21–26)

Thiết kế greenfield là phần thiểu số của công việc. Đa số kiến trúc diễn ra trong các công ty đã tồn tại sẵn — với những phòng server, phần mềm cổ xưa mà doanh nghiệp phụ thuộc vào, các hợp đồng, và luật pháp. Giai đoạn này là thế giới đó, và là nơi “lead migration and modernization initiatives” (dẫn dắt các sáng kiến migration và hiện đại hóa) — một gạch đầu dòng trong gần như mọi JD chúng tôi nghiên cứu — được dạy.

Module 10 (Tuần 21–23): Migration — đưa một công ty lên cloud

7 chữ R — vốn từ chung của mọi cuộc trò chuyện migration. Với mỗi workload trong cơ ngơi, bạn chọn một:

Phương pháp migration: assess → mobilize → migrate (đánh giá → chuẩn bị → di trú). Assess: kiểm kê mọi thứ (công cụ khám phá cộng với ngành khảo cổ của việc hỏi con người), và chấm điểm mỗi workload theo giá trị kinh doanh và độ khó migration — đầu ra: một bản kiểm kê ứng dụng với một chữ R mỗi hàng, và một business case (TCO của việc ở lại vs. chuyển đi; hãy trung thực rằng hóa đơn tăng lên trong giai đoạn chồng lấn khi cả hai cơ ngơi cùng chạy — lãnh đạo không được cảnh báo về cái bong bóng migration sẽ trở thành lãnh đạo hủy migration giữa chừng). Mobilize: xây landing zone — nền móng cloud được quản trị, dựng sẵn trước khi workload đầu tiên hạ cánh: cấu trúc đa tài khoản (tài khoản riêng cho mỗi môi trường và đội, để bán kính sát thương giữ được nhỏ), danh tính và logging tập trung, hub mạng (các VPC hub-and-spoke, đường Direct Connect về on-prem), và guardrails — các chính sách tự động khiến con đường an toàn, có tag, tuân thủ trở thành mặc định (AWS Control Tower là bộ khởi đầu được quản lý). Các JD nói “design the landing zone every workload inherits” (thiết kế landing zone mà mọi workload thừa hưởng) — chính là cái này. Bỏ qua nó để “cứ bắt đầu migrate đi” là tái tạo cái trung tâm dữ liệu bừa bộn trong cloud với chi phí cao hơn; đó là chữ ký kinh điển của migration thất bại. Migrate theo đợt (wave): nhóm các workload thành từng đợt vài cái, xếp dễ-trước: Đợt 1 cố ý chọn rủi ro thấp (học bộ máy ở nơi sai lầm còn rẻ), các đợt sau đưa những viên ngọc quý đi với các cuộc cutover đã tập dượt, mỗi đợt có một kế hoạch rollback và một giai đoạn hypercare — thời kỳ canh chừng tăng cường. Với mỗi cú chuyển cơ sở dữ liệu, hai câu hỏi quan trọng chính là các con số của Module 4 trá hình: cuộc cutover được phép mất bao nhiêu downtime (RTO) — và sao chép liên tục với một cú chuyển ngắn tồn tại cho trường hợp câu trả lời là “gần như không.”

Từ vựng:

Bài tập: (1) Cuộc migration trên giấy: một AI tạo ra bản kiểm kê một công ty hư cấu 40 server (bạn sẽ gặp lại nó ở Capstone 2); gán một chữ R cho mỗi hàng và bảo vệ mười quyết định khó nhất. (2) Phác họa một landing zone: sơ đồ tài khoản, luồng danh tính, mạng hub-and-spoke, năm guardrail bạn sẽ cưỡng chế từ ngày đầu. (3) Viết lời cảnh báo “migration bubble” hai đoạn văn cho một CFO — luyện báo-tin-xấu-sớm là bài thể dục tim mạch của kiến trúc sư.

Milestone: với một bản kiểm kê ~20 workload kèm mô tả, bạn tạo ra một bảng R-mỗi-workload bảo vệ được, một kế hoạch ba đợt kèm lý do, và một bản phác landing zone — trong một lần ngồi.

Module 11 (Tuần 24–26): Các ràng buộc — luật pháp, hệ thống cũ, và lock-in

Data residency và luật riêng tư như các đầu vào kiến trúc. Các luật dữ liệu cá nhân — PDPA của Thái Lan, GDPR của châu Âu, và họ hàng của chúng trên toàn thế giới — chia sẻ một hình dạng mà kiến trúc sư phải thuộc lòng: dữ liệu cá nhân cần một cơ sở hợp pháp (thường là sự đồng ý); các cá nhân có quyền (truy cập, sửa chữa, xóa bỏ — thiết kế của bạn phải tìm được và xóa được dữ liệu của một người, điều rất khó nếu bạn đã rải nó qua các bản sao không được quản trị); các vụ rò rỉ mang nghĩa vụ thông báo trong 72 giờ (hệ thống logging của bạn phải cho phép kể lại câu chuyện trong thời gian ngắn hơn); và các quy tắc chuyển xuyên biên giới ràng buộc nơi dữ liệu được phép sống về mặt vật lý — đó là một ràng buộc chọn region, một ràng buộc thiết kế sao chép (bản sao phân tích ở Singapore kia có thể là một sự kiện pháp lý), và một lý do các region trong nước tồn tại. Phương pháp của kiến trúc sư, theo thứ tự: phân loại dữ liệu (cái gì là cá nhân?), vẽ bản đồ các hành trình của nó (mọi kho, mọi bản sao, mọi biên giới bị băng qua — những dòng chảy không ai vẽ là nơi các vi phạm sinh sống), rồi thiết kế các biện pháp kiểm soát: các region tuân thủ residency, mã hóa, lịch lưu giữ, và một đường xóa thực sự chạm đến kỳ hết hạn của các bản backup. Hãy nói “data protection by design” (bảo vệ dữ liệu ngay từ thiết kế) — đó là cụm từ cả hai luật dùng, và nó đúng nghĩa đen là chức danh của bạn trong một câu.

Tích hợp hệ thống cũ (legacy). Hệ thống hóa đơn trên mainframe sẽ không di dời trong năm nay, và ứng dụng cloud bóng bẩy phải nói chuyện với nó. Các mẫu hình: một anti-corruption layer (lớp chống nhiễm bẩn) — một dịch vụ phiên dịch giữa mới và cũ, để các hình dạng dữ liệu kỳ quặc của hệ thống cũ không rò rỉ vào và làm hỏng thiết kế mới của bạn; strangler fig (cây đa bóp nghẹt) — định tuyến lưu lượng qua một mặt tiền, rồi bóc từng chức năng khỏi hệ thống cũ từng cái một cho đến khi, nhiều năm sau, nó có thể được tắt đi (đặt tên theo loài đa dần dần bao trùm cây chủ; nó thắng các cuộc viết lại big-bang, thứ thất bại với tỷ lệ huyền thoại); các cầu batch và vòi sự kiện cho dữ liệu phải chảy giữa hai thế giới; và sự tôn trọng vật lý độ trễ của các lời gọi cloud-đến-on-prem lắm lời (Direct Connect giúp ích; tốt hơn nữa, thiết kế để loại sự lắm lời đó ra). Quy tắc: khoanh vùng hệ thống cũ, đừng nhiễm nó — mỗi thành phần mới nên được xây như thể hệ thống cũ đã biến mất rồi.

Kinh tế học vendor lock-in. Mỗi dịch vụ được quản lý tiện lợi làm sâu thêm cuộc hôn nhân của bạn với một nhà cung cấp; tính di động (các lớp trừu tượng đa-cloud, tự-quản-mọi-thứ) là một lựa chọn thật có giá thật bằng độ phức tạp và tốc độ bị từ bỏ. Không cái nào là tội lỗi — chế độ thất bại không phải là chọn lock-in, mà là không nhận ra. Công cụ của kiến trúc sư là một ước tính chi phí thoát được viết vào bản thiết kế: “Dùng DynamoDB tiết kiệm ≈2 năm-kỹ-sư ngay bây giờ; chuyển đổi về sau ≈ một cuộc viết lại 6 tháng của tầng dữ liệu — chúng ta chấp nhận điều này, và đây là ranh giới interface sẽ thu nhỏ cuộc viết lại.” Ba câu, định giá trung thực, quyết định được ghi lại (các ADR của Giai đoạn 5) — đó là quản lý lock-in trưởng thành. Multi-cloud như một chiến lược (chạy cùng một workload di động trên hai cloud) thường là câu trả lời đắt nhất có thể và được mua bởi chính xác những tổ chức mà quy mô hoặc cơ quan quản lý của họ đòi hỏi nó; multi-cloud như một thực tế (các workload khác nhau trên các cloud khác nhau do lịch sử hoặc do độ phù hợp) là cuộc sống bình thường.

Từ vựng:

Bài tập: (1) Vẽ bản đồ dòng dữ liệu khách hàng của ThaiTicket: mọi kho, mọi bản sao (đừng quên log, backup, pipeline phân tích, các bản xuất của đội hỗ trợ), mọi biên giới; rồi viết đường xóa. Cảm nhận cách tấm bản đồ tìm ra những vấn đề mà sơ đồ che giấu. (2) Thiết kế kế hoạch strangler-fig cho một hệ thống tồn kho on-prem 20 năm tuổi, nêu tên ba lần bóc đầu tiên. (3) Viết đoạn văn lock-in kiểu DynamoDB (lợi ích bây giờ, chi phí thoát về sau, chấp nhận hay giảm nhẹ) cho ba dịch vụ bạn sẽ thực sự dùng.

Milestone — kết thúc Giai đoạn 4: màn thử thách ràng buộc: một đề bài thiết kế cài đủ cả ba (“công ty bảo hiểm Thái, dữ liệu khách hàng, hệ thống hợp đồng trên mainframe, hội đồng quản trị lo lắng về sự phụ thuộc AWS”) — bạn tạo ra một hướng tiếp cận một trang chạm đến residency, tích hợp và lock-in, mỗi cái với một mẫu hình được nêu tên và một chi phí trung thực. Khi các ràng buộc làm bạn phấn khích hơn cả greenfield — vì ràng buộc là nơi kiến trúc sư kiếm nhiều hơn những người-vẽ-sơ-đồ — Giai đoạn 4 hoàn tất.

GIAI ĐOẠN 5 — NGHỀ CỦA KIẾN TRÚC SƯ (Tháng 7–12)

Mọi thứ đến giờ làm cho bạn có khả năng thiết kế. Giai đoạn này làm cho bạn có khả năng làm việc như một kiến trúc sư — các tài liệu, buổi review, bài thuyết trình và bằng chứng mà vai trò này thực sự được cấu thành từ đó, cộng với các chứng chỉ đưa bạn qua cửa HR, và ba capstone trở thành portfolio của bạn.

Module 12 (Tháng 7–8): Các sản phẩm bàn giao — ADR, bộ sơ đồ, và điều hành review

Architecture Decision Records (ADR — hồ sơ quyết định kiến trúc). Một ADR là một tài liệu một trang ghi lại một quyết định quan trọng: chúng ta đã chọn gì, đã không chọn gì, và vì sao — được viết ngay khi quyết định được đưa ra, được đánh số, và được giữ trong repository của dự án mãi mãi. Vì sao các JD gọi tên chúng: hai năm nữa, ai đó sẽ hỏi “trời ạ vì sao cái này lại là DynamoDB?” và ADR trả lời trong ba mươi giây — với bối cảnh, các ràng buộc, và những phương án thay thế đã được cân nhắc trung thực. Các đội có ADR không xử lại vụ án nào; các đội không có thì cãi vòng quanh hằng năm. Mẫu — học thuộc nó:

# 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.

Viết một ADR cho mỗi quyết định quan trọng trong mọi capstone. Một portfolio phỏng vấn chứa các ADR thật là thứ hiếm hoi và hiệu quả đến tàn khốc.

Bộ sơ đồ — một hệ thống, ba mức thu phóng. Tài liệu kiến trúc thực thụ là một bộ (mô hình C4 đã phổ biến hóa kỷ luật này): context diagram (sơ đồ bối cảnh) — hệ thống là một chiếc hộp, với người dùng và các hệ thống bên ngoài nó chạm tới; góc nhìn cho lãnh đạo/người mới, và là cái bạn sẽ trình bày cho ban điều hành. Container diagram (sơ đồ container) — phóng to: các mảnh đang chạy chính (web app, API, cơ sở dữ liệu, queue, cache) và cách chúng nói chuyện; góc nhìn kỹ thuật hằng ngày, đại khái là các bản vẽ Giai đoạn 1–3 của bạn. Deployment diagram (sơ đồ triển khai) — tất cả chạy ở đâu về mặt vật lý: region, các AZ, VPC, subnet, các nhóm scaling; góc nhìn cho review, bảo mật và vận hành. Một hệ thống, ba khán giả, ba sơ đồ — được giữ cập nhật, có ngày tháng, trong hệ thống quản lý phiên bản cạnh các ADR. Một sơ đồ không tìm được hoặc không tin được là một sơ đồ không tồn tại.

Điều hành một buổi Well-Architected review. Bạn đã biết sáu trụ cột (Giai đoạn 2); đây là bản thân cuộc họp. Trước: chọn workload và phạm vi, cập nhật bộ sơ đồ, mời những người vận hành thứ đó (không chỉ những người thiết kế nó), và đặt tông giọng — đây là một buổi kiểm tra sức khỏe vì lợi ích của đội, không phải một cuộc kiểm toán cho hồ sơ của ai. Trong (nửa ngày): đi qua các trụ cột với các bộ câu hỏi của framework (AWS công bố chúng, kèm một Well-Architected Tool miễn phí trong console cấu trúc hóa toàn bộ bài tập — https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html); với mỗi câu trả lời, ghi lại phát hiện, và xếp ưu tiên ngay khi đi — một nhúm vấn đề rủi ro cao, không phải một trăm lời bắt bẻ. Tông giọng đặt câu hỏi của bạn chính là buổi review: “help me understand what happens when the payment provider times out” (giúp tôi hiểu điều gì xảy ra khi nhà cung cấp thanh toán hết giờ chờ) mở những cánh cửa mà “you don’t handle timeouts?” (các anh không xử lý timeout à?) đóng sập. Sau: một bản báo cáo ngắn — các phát hiện hàng đầu, mỗi cái với rủi ro, công sức và một khuyến nghị — và các hạng mục cải thiện đáp xuống backlog thật của đội với người phụ trách, nếu không buổi review chỉ là sân khấu. Thực hành: chạy một buổi review đầy đủ trên chính thiết kế Capstone 1 của bạn; tìm ra khuyết điểm của chính mình một cách có cấu trúc là kỹ năng lãi-kép-nhanh-nhất trong khóa học này.

Bài tập: (1) Viết bù ADR cho năm quyết định lớn trong các thiết kế nhật ký Giai đoạn 2–3 của bạn — bạn sẽ tìm thấy ít nhất một cái mình không còn biện minh được, và đó chính là bài học. (2) Tạo bộ ba-sơ-đồ đầy đủ cho ThaiTicket. (3) Chạy buổi review giả lập ở trên, tạo bản báo cáo phát hiện một trang.

Milestone: một người lạ (hoặc một AI đóng vai) có thể cầm lấy tập hồ sơ ThaiTicket của bạn — ba sơ đồ + năm ADR — và trả lời đúng “đây là gì, nó chạy thế nào, và vì sao nó được xây như vậy?” mà không có bạn trong phòng. Tập hồ sơ đó chính là sản phẩm bàn giao của nghề kiến trúc sư.

Module 13 (Tháng 8–9): Nghề con người — thuyết trình, định giá, đối mặt phản bác, và cố vấn

Thuyết trình cho lãnh đạo vs. kỹ sư — một thiết kế, hai ngôn ngữ. Lãnh đạo mua kết quả; kỹ sư mua cơ chế. Với lãnh đạo: mở đầu bằng quyết định và con số (“Thiết kế này đáp ứng mục tiêu một triệu khách hàng ở mức ฿1,90 mỗi đơn, và đây là hai quyết định tôi cần từ các vị”); một slide, sơ đồ context, các rủi ro đóng khung như rủi ro kinh doanh (doanh thu, tuân thủ, danh tiếng), và đừng bao giờ nói “Kubernetes” khi “nền tảng” là đủ. Chuẩn bị cho ba câu hỏi lãnh đạo luôn hỏi: cái này tốn bao nhiêu, cái gì có thể hỏng, vì sao không chọn phương án rẻ hơn? Với kỹ sư: mở đầu bằng bài toán và các ràng buộc trước giải pháp (kỹ sư cảm được bài toán sẽ chấp nhận giải pháp; kỹ sư bị trao một bản án sẽ săn khuyết điểm theo nguyên tắc), cho xem sơ đồ container và deployment, tự mình nêu tên các đánh đổi và những phương án bị loại (uy tín đến từ những gì bạn thừa nhận), và chừa chỗ thật để thay đổi thiết kế — các câu hỏi trong phòng là review miễn phí. Thói quen kiến trúc sư tệ nhất là một bộ slide cho cả hai khán giả; thói quen tốt nhất là viết bản tóm tắt cho lãnh đạo trước tiên, vì nếu thiết kế không sống sót qua sự nén xuống năm câu, nó chưa hoàn thành.

Ước tính chi phí cho một bản đề xuất. Phương pháp: phân rã thiết kế thành ~10 thành phần mang chi phí; định giá từng cái ở mức tải kỳ vọng trong pricing calculator; viết các giả định của bạn ra giấy (request/ngày, tăng trưởng dữ liệu, egress — các giả định chính là bản ước tính; khi chúng thay đổi, con số di chuyển theo với một lương tâm trong sạch); áp chiến lược đặt trước cho các phần ổn định; thêm các kịch bản tăng trưởng (hôm nay, 2×, 10× — lãnh đạo nhớ con số 10×); và trình bày dưới dạng một khoảng kèm các động lực (“฿55–70k/tháng, chủ yếu do egress — đây là cần gạt”), không bao giờ là một con số đơn chính-xác-giả-tạo. Bao gồm cả migration bubble nếu có. Ước tính thấp đi để được phê duyệt là tội kinh điển của kiến trúc sư non tay; dự án sẽ nhớ.

Đối mặt phản bác. Bạn sẽ bị ép về chi phí (“đắt quá” → quay về tam giác: “chúng ta có thể cắt ฿30k bằng cách chấp nhận single-AZ — đây là phép toán về sự cố; quyền quyết định là của anh, và tôi sẽ ghi lại” — làm cho sự đánh đổi tường minh và được ghi lại biến đa số phản bác thành hoặc sự đồng thuận hoặc một rủi ro được chấp nhận có hiểu biết, cả hai đều ổn); về khẩu vị (“kỹ sư thích một stack khác” → steel-man nó thành tiếng, rồi đưa nó về tiêu chí, không phải sở thích: độ khớp NFR, kỹ năng đội, hệ sinh thái, chi phí thoát — và khi thực sự sít sao, hãy để sở thích của kỹ sư thực thi thắng, mua được sự cam kết với giá rẻ); và về quyền uy (“bạn của CTO bảo dùng X” → đừng bao giờ đấu ý kiến bằng ý kiến; hỏi xin các tiêu chí, chạy X qua cùng một cuộc đánh giá công khai như mọi thứ khác, để ma trận trả lời một cách lịch sự). Và khi bạn sai — bạn sẽ thiết kế thứ gì đó thất bại; kiến trúc sư nào cũng vậy — nước đi là post-mortem không đổ lỗi áp lên chính mình, công khai, với ADR được cập nhật. Không gì xây uy tín thập-kỷ nhanh hơn; không gì phá hủy nó nhanh hơn việc bảo vệ một xác chết.

Cố vấn kỹ sư. Cụm từ trong JD là “mentor the engineers who build against your standards” (cố vấn các kỹ sư xây theo chuẩn mực của bạn), và các hình thức thực tế là: giờ tiếp chuyện design review (một cánh cửa thường trực, để sự dẫn dắt diễn ra trước code, không phải sau); review thiết kế của họ một cách tử tế — câu hỏi trước phán quyết, và luôn kèm cái vì sao đằng sau chuẩn mực (một guardrail được giải thích chiêu mộ một đồng minh; một guardrail bị áp đặt chiêu mộ một đường vòng); ủy quyền các quyết định thật kèm lưới an toàn (“bạn sở hữu thiết kế cache; đây là các ràng buộc; tôi sẽ review, và tôi sẽ đứng sau quyết định của bạn”); và dạy công khai — mỗi ADR, mỗi bản viết review, mỗi buổi brown-bag nhân bạn lên vượt quá số giờ của chính bạn. Sự thật nghề nghiệp thẳng thừng: một kiến trúc sư thiên tài đơn độc sẽ chạm trần; một kiến trúc sư đã nuôi năm kỹ sư thành đồng nghiệp biết thiết kế sẽ điều hành cả nghiệp vụ.

Bài tập: (1) Thuyết trình ThaiTicket hai lần — bản 5 phút cho lãnh đạo và bản 20 phút cho kỹ thuật — ghi âm cả hai, và nghe xem biệt ngữ có rò rỉ vào bản đầu không. (2) Tạo bản đề xuất chi phí viết đầy đủ (giả định, khoảng, động lực, kịch bản 2×/10×). (3) Sân khấu phản bác với một AI: ba hiệp — đòn tấn công chi phí từ một CFO, sở thích stack từ một kỹ sư senior, màn quyền uy bạn-của-CTO — ghi nhật ký cái gì hiệu quả. (4) Review thiết kế của một junior (một AI có thể tạo một bản đầy lỗi) bằng văn bản, câu-hỏi-trước, và để AI chấm điểm tông giọng của bạn.

Milestone: trận đấu kép: trình bày bản pitch cho lãnh đạo và sống sót qua hai mươi phút hỏi-đáp hỗn hợp thù-địch-nhưng-công-bằng (hội đồng AI: một CFO, một kỹ sư hoài nghi) mà không lẫn biệt ngữ, không phòng thủ, và không một đánh đổi nào chưa được viết ra.

Module 14 (Tháng 9–12): Chứng chỉ và ba capstone

Lộ trình chứng chỉ, với các mốc thời gian trung thực. Chứng chỉ không làm bạn thành kiến trúc sư — mười ba module trước đó mới làm — nhưng chúng mang lại cho bạn các buổi phỏng vấn, và việc ôn thi cho chúng khắc các dịch vụ của nhà cung cấp vào ngón tay bạn. Bậc thang, ở nhịp một-giờ-mỗi-ngày: AWS Certified Solutions Architect – Associate (SAA-C03) — 2–3 tháng; chứng chỉ kiến trúc sư được yêu cầu nhiều nhất trong các tin tuyển dụng, và sau Giai đoạn 1–3, phần lớn nó sẽ có cảm giác như ôn lại kèm tên dịch vụ gắn vào; thi nó trước. AWS Certified Solutions Architect – Professional (SAP-C02) — 4–8 tháng sau Associate; dựa trên tình huống, thực sự khó, và là dòng résumé mạnh nhất trong lĩnh vực này; phần migration và multi-account của Giai đoạn 4 là một nửa giáo trình của nó. Azure AZ-305 (Azure Solutions Architect Expert) — thêm vào nếu thị trường của bạn nặng về Microsoft (đa số thị trường doanh nghiệp ít nhất là song ngữ); dự trù 2–3 tháng với kiến thức AWS chuyển giao được với chiết khấu lớn (bắt đầu tại https://learn.microsoft.com/en-us/credentials/certifications/azure-solutions-architect/). TOGAF Foundation — tùy chọn, 2–4 tuần; một số doanh nghiệp lớn đòi hỏi nó; nó chứng nhận phương pháp kiến trúc doanh nghiệp và vốn từ chứ không phải kỹ năng cloud. Trình tự cho khóa học này: ôn SAA song song với Tháng 7–8, thi vào ~Tháng 8; sau đó hoặc SA Pro (con đường kỹ thuật sâu) hoặc AZ-305 (con đường chiều rộng) đến hết Tháng 12, với SA Pro hoàn thành vào Tháng 14–16 theo nhịp trung thực.

Ba capstone. Mỗi cái là một tập hồ sơ hoàn chỉnh, cấp portfolio: bộ sơ đồ ba mức, 5+ ADR, ước tính chi phí kèm giả định, và một buổi Well-Architected review tự-điều-hành kèm các phát hiện. Dành 3–4 tuần cho mỗi cái. Ba sản phẩm này, cộng với nhật ký của bạn, chính là bằng chứng phỏng vấn của bạn cho “end-to-end solution design” (thiết kế giải pháp đầu-cuối).

Capstone 1 — greenfield: một nền tảng thương mại điện tử Thái cho 1 triệu người dùng. Đề bài: marketplace, 1 triệu người dùng đăng ký, 50k đồng thời ở đỉnh flash-sale, ưu tiên di động, tích hợp thanh toán kiểu PromptPay, tuân thủ PDPA, khả dụng 99,9%, tiết kiệm ngân sách kiểu vòng hạt giống. Phải bao gồm: lựa chọn mẫu hình kèm lộ trình tiến hóa, chiến lược caching, cuộc trò chuyện RTO/RPO viết dưới dạng hội thoại, ước tính unit economics, bản đồ dòng dữ liệu cho dữ liệu cá nhân.

Capstone 2 — brownfield: di trú một công ty on-prem 40 server. Đề bài: một công ty logistics Thái; 40 server (ERP trên Oracle, ứng dụng quản lý kho 12 năm tuổi, các file share, AD, các ứng dụng phòng ban linh tinh — tạo bản kiểm kê đầy đủ với một AI và đóng băng nó); hợp đồng thuê trung tâm dữ liệu hết hạn sau 14 tháng; hội đồng quản trị muốn thoát ra. Phải bao gồm: bảng kiểm kê 7-R đầy đủ, kế hoạch ba đợt với lý do về phụ thuộc, thiết kế landing zone, dòng thời gian chi phí migration-bubble, và bản ghi nhớ cho CFO.

Capstone 3 — bài khó: DR multi-region cho một fintech. Đề bài: một công ty thanh toán bị quản chế ở mức RTO ≤ 15 phút / RPO ≈ 0 cho sổ cái, với các ràng buộc data-residency về dữ liệu khách hàng và một cuộc kiểm tra failover hằng năm có cơ quan quản lý chứng kiến. Phải bao gồm: phân tích active-passive vs. active-active kèm chi phí, thiết kế sao chép kèm bản đồ residency, runbook failover, và kế hoạch diễn tập.

Thang tự đánh giá (áp cho mỗi capstone, một cách trung thực, trong nhật ký của bạn):

Chấm mọi chiều 4+ trên cả ba capstone — sửa cho đến khi đạt — và bạn đã hoàn thành khóa học.

Mười câu hỏi phỏng vấn kiến trúc sư (kèm câu trả lời mạnh)

Luyện những câu này thành tiếng; sức mạnh nằm ở cấu trúc của mỗi câu trả lời, thứ giờ đây bạn đã sở hữu.

1. “Design a URL shortener / ticketing site / photo app for a million users.” (Thiết kế một trình rút gọn URL / trang bán vé / ứng dụng ảnh cho một triệu người dùng.) Khuôn hình mạnh: yêu cầu trước tiên, thành tiếng (“Đọc áp đảo ghi? Mục tiêu khả dụng? Ngân sách?”) → định vị trên tam giác → bộ khung ba tầng hoặc serverless-first với multi-AZ, cache, CDN → tự nêu tên các đánh đổi không cần ai nhắc → kết thúc bằng bậc độ lớn chi phí và lộ trình tiến hóa 10×. Người phỏng vấn chấm đậu những câu hỏi bạn hỏi, không phải những chiếc hộp bạn vẽ.

2. “When would you choose NoSQL over a relational database?” (Khi nào bạn chọn NoSQL thay vì cơ sở dữ liệu quan hệ?) “Tôi mặc định SQL — các bảo đảm về tính đúng đắn và kỹ năng phổ quát — cho đến khi một lý do được nêu đích danh lấn át: mở rộng ngang cực đại, schema linh hoạt, hoặc truy cập key-value ở mức mili giây một chữ số. Khi đó tôi chọn hương vị NoSQL khớp với mẫu truy cập, và tôi viết ADR bao gồm cả những gì chúng ta từ bỏ: các phép join, và một phần ngữ nghĩa nhất quán.”

3. “Explain RTO and RPO, and how they drive design.” (Giải thích RTO và RPO, và cách chúng dẫn dắt thiết kế.) Định nghĩa cả hai một cách sắc gọn → “chúng là các quyết định kinh doanh với bảng giá tăng theo cấp số nhân” → bậc thang: backup hằng đêm → sao chép liên tục → standby ấm → active-active, với chi phí tăng ở mỗi nấc → “việc của tôi là làm cho doanh nghiệp chọn một cách có hiểu biết, rồi thiết kế chính xác theo con số — và diễn tập nó, vì một failover chưa kiểm chứng là một niềm hy vọng.”

4. “Monolith or microservices?” (Monolith hay microservices?) Phán quyết của Module 8, nguyên văn: bắt đầu bằng modular-monolith; tách ra khi cơn đau mở rộng đội ngũ hoặc mở rộng tải thực sự xuất hiện; microservices là một công cụ mở rộng đội ngũ có thu thuế hệ-thống-phân-tán. Điểm cộng cho câu “I’d rather run a good monolith than a bad distributed system” (Tôi thà vận hành một monolith tốt còn hơn một hệ thống phân tán tồi).

5. “How do you handle a large cloud bill / cost optimization?” (Bạn xử lý một hóa đơn cloud lớn / tối ưu chi phí như thế nào?) “Sự hữu hình trước tiên — tagging và showback; rồi vụ gặt theo thứ tự công sức: giết tài nguyên chết, rightsize từ số đo, phân bậc lưu trữ, lập lịch ngủ cho non-prod, rồi đặt trước phần nền ổn định. Và tôi báo cáo unit economics, không phải tổng số — một hóa đơn tăng với chi-phí-mỗi-đơn giảm là thành công, không phải vấn đề.”

6. “How would you migrate a legacy on-prem application?” (Bạn sẽ di trú một ứng dụng on-prem cũ như thế nào?) “Đánh giá trước khi chuyển — kiểm kê, các phụ thuộc, và một chữ R mỗi workload từ 7 chữ R; xây landing zone trước đợt một; các đợt dễ-trước với những cuộc cutover đã tập dượt và kế hoạch rollback; và với cơ sở dữ liệu ngọc quý, cutover dựa trên sao chép được đo theo mức downtime doanh nghiệp đã ký. Thêm nữa: lời cảnh báo migration-bubble trung thực ngay từ đầu.”

7. “How do you secure a cloud architecture?” (Bạn bảo mật một kiến trúc cloud như thế nào?) Đi qua các lớp: danh tính (least privilege, MFA, không dùng root hằng ngày) → mạng (private subnet, phân đoạn, bề mặt tấn công tối thiểu) → dữ liệu (mã hóa khi lưu trữ/khi truyền, phân loại, residency) → phát hiện (nhật ký kiểm toán, cảnh báo) → “và ngay từ thiết kế, không gắn thêm sau — biện pháp bảo mật rẻ nhất là quyết định kiến trúc gỡ bỏ hoàn toàn rủi ro, như không bao giờ chạm vào dữ liệu thẻ thô.”

8. “Tell me about a design decision you got wrong.” (Kể cho tôi về một quyết định thiết kế bạn đã sai.) Họ đang kiểm tra cái tôi, không phải lịch sử. Khuôn hình: ví dụ thật (từ capstone) → bạn đã tin gì → thực tế đã nói gì → bản post-mortem, ADR được cập nhật, mẫu hình bạn giờ luôn kiểm tra. Một kiến trúc sư không đưa ra được câu trả lời này là một kiến trúc sư chưa từng được review.

9. “How do you explain a complex technical decision to a non-technical executive?” (Bạn giải thích một quyết định kỹ thuật phức tạp cho một lãnh đạo không chuyên kỹ thuật như thế nào?) “Quyết định và con số kinh doanh trước, cơ chế chỉ khi được hỏi; sơ đồ context, không phải container; rủi ro theo ngôn ngữ doanh-thu-tuân-thủ-danh-tiếng; và tôi mang theo hai quyết định tôi cần từ họ, viết dưới dạng các lựa chọn kèm bảng giá — lãnh đạo quyết định giữa các phương án; họ không phê duyệt những điều bí ẩn.”

10. “An engineer strongly disagrees with your design. What do you do?” (Một kỹ sư phản đối mạnh mẽ thiết kế của bạn. Bạn làm gì?) “Trước tiên tôi steel-man họ thành tiếng — họ có thể đúng, và cuộc review làm thay đổi thiết kế của tôi là cuộc review đang hoạt động. Nếu thực sự sít sao, tiêu chí quyết định (độ khớp NFR, kỹ năng đội, chi phí thoát), không phải thâm niên — và tôi để sở thích của người thực thi thắng khi hòa, vì sự cam kết là món hời ở cái giá đó. Dù thế nào, quyết định và phương án bị loại đều vào ADR, để chúng tôi không bao giờ cãi lại lần hai.”

Giáo trình một trang

Lời kết từ người thầy của bạn. Sau hai mươi sáu tuần, bạn có thể thiết kế; sau mười hai tháng, bạn có thể hành nghề — có một sự khác biệt, và đó là sự khác biệt mà khóa học này được xây để khép lại. Những thói quen giờ đây chính là sự nghiệp: vẽ trước khi tranh luận, viết ADR ngay ngày bạn quyết định, định giá những gì bạn đề xuất, gọi tên sự đánh đổi trước khi ai kịp hỏi, và nuôi lớn những kỹ sư quanh bạn cho đến khi chuẩn mực của bạn sống lâu hơn sự hiện diện của bạn trong phòng. Kiến trúc là nghề kỹ thuật hiếm hoi trở nên tốt hơn khi bạn già đi cùng nó, vì nguyên liệu thô của nó là phán đoán, và phán đoán sinh lãi kép. Hãy tiếp tục cuốn nhật ký. Bốn mươi bản thiết kế nữa, bạn sẽ không cần khóa học này — bạn sẽ đang sửa lại nó.

Nguồn tham khảo

Các bản mô tả công việc và định nghĩa vai trò dùng cho bảng ánh xạ yêu cầu (thu thập tháng 8 năm 2026): mẫu KORE1 Cloud Architect job description template · bản 4 Corner Resources Cloud Architect job description · Solution Architect responsibilities in the Azure Well-Architected Framework của Microsoft · tin tuyển Pre-Sales Solutions Architect – AWS của Arpio · tin tuyển Solution Architect – Enterprise (qua Built In) của Intel · tin tuyển Cloud Domain Architect của Halliburton. Ước tính thời gian ôn chứng chỉ: khảo sát thời gian học SAA-C03 của CBT Nuggets và hướng dẫn ôn SAP-C02 của Whizlabs; định nghĩa chứng chỉ từ Microsoft Learn (AZ-305) và AWS Well-Architected Framework. Một tập sách đồng hành của The Cloud Leader Course trong bộ B4LCILC.