Khóa học Lãnh đạo Cloud (The Cloud Leader Course)

Từ chỗ chưa biết gì đến việc lãnh đạo trôi chảy một đội ngũ kỹ sư cloud.

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

Bạn không học để trở thành một kỹ sư cloud. Bạn học để lãnh đạo các kỹ sư cloud: theo kịp mọi cuộc trò chuyện trong phòng họp, đặt những câu hỏi thực sự quan trọng, ra quyết định đúng đắn về tiền bạc, rủi ro và con người, và giành được sự tôn trọng của các chuyên gia mà không cần giả vờ mình là một người trong số họ. Đó là một kỹ năng khác — hoàn toàn có thể học được — và chính là kỹ năng mà khóa học này truyền dạy.

Khóa học gồm ba giai đoạn. Giai đoạn 1 (Tuần 1–8): Nói được ngôn ngữ. Bạn học cloud (điện toán đám mây) thực chất là gì và từ vựng của mọi khối xây dựng cốt lõi, để các cuộc họp không còn nghe như tiếng ồn. Giai đoạn 2 (Tuần 9–16): Tư duy như cả phòng họp. Kiến trúc, bảo mật và tiền bạc — ba cuộc trò chuyện mà mọi đội cloud đều có hằng tuần, và cũng là ba nơi mà một người lãnh đạo hoặc tạo ra giá trị, hoặc bị phớt lờ. Giai đoạn 3 (Tháng 5–24): Lãnh đạo. Chứng chỉ, tuyển dụng, điều hành các cuộc họp ra quyết định, và con đường hai năm trung thực để có thể đứng vững trước các kỹ sư senior.

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 Fluency Drill (bài luyện nói trôi chảy — những câu bạn nói thành tiếng cho đến khi chúng trở nên tự nhiên) và một Milestone (cột mốc — bằng chứng cho thấy bạn đã sẵn sàng đi tiếp). Hãy làm chúng; chỉ đọc thôi thì tạo ra sự nhận biết, chứ không tạo ra sự trôi chảy. Và ngay từ Tuần 1, hãy duy trì một Decision Journal (nhật ký quyết định): mỗi khi học một khái niệm, viết một câu về việc nó ảnh hưởng đến tiền bạc, rủi ro hay con người ra sao — vì chính công việc “phiên dịch” đó là toàn bộ vai trò của bạn.

GIAI ĐOẠN 1 — NÓI ĐƯỢC NGÔN NGỮ (Tuần 1–8)

Module 1 (Tuần 1–2): Cloud thực chất là gì

Ý tưởng lớn: 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. Trước khi có cloud, một công ty phải mua server (máy chủ) vật lý, đặt chúng trong một căn phòng, và trả tiền cho người bảo trì — chậm chạp, tốn kém, thiếu linh hoạt. AWS, Microsoft Azure và Google Cloud đã xây những nhà kho chứa hàng triệu máy tính (data center — trung tâm dữ liệu) và cho phép bất kỳ ai thuê từng “lát” của chúng theo từng giây, từ bất cứ đâu, thông qua một trang web hoặc một dòng lệnh. Chỉ vậy thôi. Mọi thứ còn lại trong khóa học này đều là chi tiết xây trên một ý tưởng duy nhất đó.

Ba nhà cung cấp lớn nhất, định nghĩa rõ ràng:

Tài khoản AWS miễn phí của bạn — hãy thiết lập ngay trong Tuần 1. Truy cập https://aws.amazon.com/free và nhấn “Create a Free Account” (trang đăng ký trực tiếp là https://signin.aws.amazon.com/signup?request_type=register). Bạn cần một địa chỉ email, một số điện thoại và một thẻ tín dụng/ghi nợ để xác minh danh tính — Free Tier (gói miễn phí) cho bạn hạn mức hằng tháng miễn phí với các dịch vụ cơ bản (bao gồm 750 giờ/tháng cho một server EC2 nhỏ trong năm đầu tiên), và toàn bộ bài tập của khóa học này nằm gọn trong hạn mức đó. Hai thói quen an toàn ngay từ ngày đầu: bật MFA (Module 6 sẽ giải thích) và đặt billing alert (cảnh báo chi phí) ở mức 5 USD (Module 7 hướng dẫn cách làm) để bạn không bao giờ bị bất ngờ. Sau khi đăng ký, bạn đăng nhập tại https://console.aws.amazon.com — “console” đơn giản là trang web điều khiển của AWS.

Vì sao các công ty dùng cloud: tốc độ (một server mới trong 60 giây thay vì 6 tuần), tính co giãn — elasticity (thuê 100 server cho ngày sale lớn, trả lại 90 chiếc vào hôm sau), không cần chi phí đầu tư ban đầu (chi phí vận hành thay vì chi phí vốn), và tầm với toàn cầu (đặt ứng dụng gần khách hàng của bạn ở Bangkok, Tokyo và Frankfurt mà không phải xây gì cả).

Ba tầng dịch vụ — mô hình tư duy hữu ích nhất trong cloud:

Region và Availability Zone: một Region (vùng) là một cụm trung tâm dữ liệu theo địa lý (Thái Lan có AWS Region riêng từ tháng 1 năm 2025, ở trong và quanh Bangkok). Một Availability Zone (AZ — vùng khả dụng) là một hoặc nhiều trung tâm dữ liệu tách biệt bên trong một region. Những ứng dụng quan trọng chạy trên ít nhất hai AZ, để sự cố của một tòa nhà không kéo sập chúng. Khi các kỹ sư nói “chúng ta chạy multi-AZ”, ý họ là “một trung tâm dữ liệu có thể cháy rụi mà chúng ta vẫn hoạt động.”

Từ vựng:

Video cho module này (tất cả miễn phí, liên kết đã kiểm chứng):

Fluency drill — nói cho đến khi tự nhiên: “Is that workload on-prem or in the cloud?” (Workload đó đang chạy on-prem hay trên cloud?) · “Which region are we in — and are we multi-AZ?” (Chúng ta đang ở region nào — và có chạy multi-AZ không?) · “Is this an IaaS approach or is there a managed service that removes the maintenance?” (Đây là cách tiếp cận IaaS, hay có một managed service nào giúp loại bỏ việc bảo trì?)

Bài tập: (1) Tạo tài khoản AWS miễn phí tại https://aws.amazon.com/free — bản thân quy trình đăng ký dạy bạn nhiều từ vựng hơn cả một chương sách. (2) Xem bốn video trong bảng trên (tổng cộng dưới 20 phút). (3) Trong nhật ký của bạn: viết bài “thuyết trình thang máy” giải thích cloud mà bạn sẽ nói với một hiệu trưởng trường học Thái Lan trong một hơi.

Milestone: bạn có thể giải thích IaaS vs PaaS vs SaaS bằng phép so sánh của riêng mình, và giải thích vì sao việc AWS mở region Bangkok lại quan trọng với các ngân hàng Thái (đáp án: latency + data residency — xem Module 6).

Module 2 (Tuần 3–4): Các khối xây dựng — compute, lưu trữ và cơ sở dữ liệu

Compute (năng lực tính toán) — những cỗ máy chạy code. Một virtual machine (VM/instance — máy ảo) là một “lát” của server vật lý hoạt động như một máy tính hoàn chỉnh; bạn chọn kích cỡ (CPU/RAM) và trả tiền theo từng giây nó chạy. Một container là cách đóng gói một ứng dụng nhẹ hơn, nhanh hơn để nó chạy giống hệt nhau ở mọi nơi; Docker đóng gói chúng và Kubernetes (K8s) điều phối cả hạm đội container — khi nghe “K8s”, hãy nghĩ “hệ thống tự động chạy và tự chữa lành hàng trăm container của chúng ta”. Serverless (không cần quản lý server — AWS Lambda) nghĩa là bạn chỉ tải lên một hàm code; cloud chạy nó khi được kích hoạt và bạn trả tiền theo mỗi lần gọi — hoàn toàn không có server nào phải quản lý. Quy luật cần chú ý: VM → container → serverless là một thanh trượt từ “nhiều quyền kiểm soát hơn, nhiều việc bảo trì hơn” đến “ít quyền kiểm soát hơn, gần như không phải bảo trì”. Đội giỏi chọn theo từng workload, không chọn theo mốt.

Lưu trữ — ba hình dạng. Object storage (lưu trữ đối tượng — Amazon S3): một chiếc “xô” không đáy cho file — hình ảnh, video, bản sao lưu, bộ dữ liệu; rẻ, độ bền “mười một số chín”, câu trả lời mặc định cho “chúng ta để file ở đâu?” Block storage (lưu trữ khối — EBS): ổ cứng ảo gắn vào một VM. File storage (lưu trữ tệp — EFS): một ổ đĩa dùng chung mà nhiều máy cùng gắn kết một lúc. Rồi đến tier (bậc lưu trữ): nóng (truy cập thường xuyên, đắt) và lạnh/lưu trữ dài hạn (Glacier — rẻ, chậm) — chuyển dữ liệu cũ xuống bậc lạnh là một trong những chiến thắng chi phí dễ nhất mà bất kỳ đội nào cũng có thể thực hiện.

Cơ sở dữ liệu — hai họ. Relational/SQL (quan hệ — MySQL, PostgreSQL; được quản lý dưới dạng Amazon RDS/Aurora): dữ liệu trong các bảng có cấu trúc chặt chẽ; lựa chọn mặc định cho tiền bạc, đơn hàng, người dùng — bất cứ thứ gì mà tính chính xác là bất khả xâm phạm. NoSQL (DynamoDB, MongoDB): linh hoạt, mở rộng cực lớn; lựa chọn mặc định cho dữ liệu khổng lồ, nhanh, cấu trúc đơn giản hơn (session, danh mục, bảng tin). “Managed database” (cơ sở dữ liệu được quản lý) nghĩa là nhà cung cấp lo việc sao lưu, vá lỗi và failover — đội của bạn cần một lý do thật mạnh mới nên tự vận hành cơ sở dữ liệu riêng.

Từ vựng:

Video cho module này:

Fluency drill: “Should this run on VMs, containers, or serverless — and what’s the operational cost of each choice?” (Cái này nên chạy trên VM, container hay serverless — và chi phí vận hành của mỗi lựa chọn là gì?) · “Is that data hot or can it go to a cheaper tier?” (Dữ liệu đó có “nóng” không, hay có thể chuyển xuống bậc rẻ hơn?) · “Why are we self-managing that database instead of using RDS?” (Tại sao chúng ta tự quản lý cơ sở dữ liệu đó thay vì dùng RDS?)

Bài tập: (1) Trong tài khoản miễn phí của bạn: khởi chạy instance EC2 nhỏ nhất, rồi terminate (chấm dứt) nó. Tải một file lên S3. Bạn vừa đích thân sử dụng IaaS. (2) Nhờ một trợ lý AI kiểm tra bạn: “Cho tôi 10 tình huống; tôi sẽ trả lời VM, container hay serverless, và bạn chấm điểm.”

Milestone: với bất kỳ ứng dụng đơn giản nào được mô tả trong một câu (“một website nơi học sinh đặt cơm trưa”), bạn có thể nêu tên các thành phần compute, lưu trữ và cơ sở dữ liệu của nó thành tiếng trong 60 giây.

Module 3 (Tuần 5–6): Mạng, và cách các mảnh ghép nói chuyện với nhau

VPC — khu phố riêng của bạn. Một Virtual Private Cloud (đám mây riêng ảo) là khu vực được rào chắn riêng của bạn bên trong mạng của nhà cung cấp. Bên trong nó là các subnet (mạng con) — loại public (truy cập được từ internet, ví dụ web server) và loại private (không truy cập được, ví dụ cơ sở dữ liệu). Câu nói về bảo mật phổ biến nhất mà bạn sẽ nghe: “cơ sở dữ liệu nằm trong private subnet.” Nếu bạn hiểu vì sao — kẻ tấn công không thể chạm vào thứ không có đường dẫn nào từ internet — bạn đã hiểu một nửa về bảo mật mạng.

Tầng lưu lượng: một load balancer (bộ cân bằng tải) phân phối lưu lượng truy cập đến trên nhiều server (và lặng lẽ loại bỏ những chiếc “ốm yếu”); DNS (Route 53) dịch những cái tên như yourcompany.com thành địa chỉ; một CDN (CloudFront) lưu bản sao nội dung của bạn tại hàng trăm thành phố để nó tải nhanh ở mọi nơi; một API là cánh cửa mà một phần mềm mở ra cho phần mềm khác — khi kỹ sư nói “we’ll expose an API”, ý họ là “chúng ta sẽ cho phần mềm khác một cách có kiểm soát để dùng phần mềm của mình”; một API gateway là quầy lễ tân quản lý những cánh cửa đó.

Kết nối các thế giới: VPN (đường hầm mã hóa qua internet) hoặc Direct Connect (đường truyền vật lý riêng) nối văn phòng/hệ thống on-prem của công ty với cloud của họ. Hybrid cloud (đám mây lai) = chạy cả on-prem lẫn cloud (đa số doanh nghiệp Thái); multi-cloud = dùng nhiều hơn một nhà cung cấp.

Từ vựng:

Video cho module này: AWS Networking Basics — VPC & Subnets for Beginners — KodeKloud — https://www.youtube.com/watch?v=QM63dyA_4Pc (xem nửa đầu ngay bây giờ; quay lại xem phần còn lại sau Module 5).

Fluency drill: “Is the database in a private subnet?” (Cơ sở dữ liệu có nằm trong private subnet không?) · “What happens when one web server dies — is the load balancer health-checking?” (Điều gì xảy ra khi một web server chết — load balancer có đang kiểm tra sức khỏe không?) · “Are we exposing that as an API or is it internal only?” (Chúng ta mở cái đó ra thành API hay chỉ dùng nội bộ?)

Bài tập: (1) Nhờ một AI hướng dẫn bạn vẽ, trên giấy, mạng của một ứng dụng giao đồ ăn: người dùng → CDN → load balancer → web server (public subnet) → cơ sở dữ liệu (private subnet). Vẽ ba lần cho đến khi bạn vẽ được từ trí nhớ. (2) Tìm sơ đồ kiến trúc của công ty bạn hoặc bất kỳ sơ đồ mẫu nào và khoanh tròn mọi ô mà giờ đây bạn gọi được tên.

Milestone: bạn có thể phác thảo sơ đồ ba tầng tiêu chuẩn đó lên bảng trắng và thuật lại hành trình một cú nhấp chuột của khách hàng đi qua nó.

Module 4 (Tuần 7–8): Cách các đội cloud làm việc — DevOps, IaC, và đọc vị phòng họp

DevOps là văn hóa hợp nhất “những người viết phần mềm” (Dev) và “những người vận hành nó” (Ops) thành một đội duy nhất, phát hành những thay đổi nhỏ một cách thường xuyên và an toàn, với tự động hóa gánh phần việc nặng. Nhịp tim của nó là CI/CD pipeline (đường ống tích hợp/triển khai liên tục): mỗi thay đổi code được tự động build, kiểm thử và triển khai (Continuous Integration / Continuous Delivery). Khi một đội nói “it’s in the pipeline”, ý họ là con robot đang kiểm thử và phát hành nó.

Infrastructure as Code (IaC — hạ tầng dưới dạng code) — ý tưởng đã thay đổi tất cả: thay vì nhấp chuột loanh quanh trong console để tạo server, kỹ sư viết các file văn bản khai báo hạ tầng (“hai server, một load balancer, một cơ sở dữ liệu, những quy tắc tường lửa này”), và một công cụ (Terraform, CloudFormation) làm cho thực tế khớp với file. Vì sao lãnh đạo quan tâm: các file đó sống trong Git (hệ thống quản lý phiên bản), nên mọi thay đổi hạ tầng đều được review, có thể đảo ngược và có thể kiểm toán — sự khác biệt giữa một xưởng thủ công và một nhà máy.

Những nghi thức bạn sẽ ngồi dự: stand-up (15 phút mỗi ngày: đã xong gì, tiếp theo là gì, đang vướng gì — hãy lắng nghe các blocker; gỡ chúng là việc của bạn), sprint (một đơn vị công việc có kế hoạch kéo dài 1–2 tuần), retro (cần cải thiện gì), post-mortem/incident review (sau một sự cố ngừng hoạt động: phân tích không đổ lỗi về cái gì đã hỏng và cái gì sẽ ngăn nó lặp lại — sức khỏe của một đội thể hiện ở chỗ những buổi này có trung thực hay không), on-call (vòng xoay trực — ai bị đánh thức lúc 3 giờ sáng; nếu on-call khổ sở, những người giỏi nhất của bạn sẽ ra đi — hãy hỏi về nó hằng tháng).

Các chỉ số sức khỏe quan trọng: uptime/availability (thời gian hoạt động/tính khả dụng — “ba số chín” = 99,9% ≈ 8,8 giờ ngừng hoạt động/năm; mỗi số chín thêm vào nhân chi phí lên nhiều lần), SLA (lời hứa với khách hàng, kèm điều khoản phạt), SLO (mục tiêu nội bộ), MTTR (bạn phục hồi nhanh đến đâu — các đội trưởng thành tối ưu khả năng phục hồi, chứ không theo đuổi ảo tưởng không-bao-giờ-hỏng), deployment frequency (tần suất triển khai — đội khỏe mạnh phát hành thay đổi nhỏ thường xuyên; nỗi sợ deploy là một dấu hiệu xấu).

Từ vựng:

Video cho module này:

Fluency drill: “Is that change through the pipeline or was it manual?” (Thay đổi đó đi qua pipeline hay làm thủ công?) · “What did the post-mortem conclude, and what’s the prevention item?” (Post-mortem kết luận gì, và hạng mục phòng ngừa là gì?) · “What’s our MTTR trending like?” (MTTR của chúng ta đang có xu hướng thế nào?) · “Is this in Terraform, or did someone click it into existence?” (Cái này có trong Terraform không, hay ai đó đã nhấp chuột tạo ra nó?) (kiểu sau được gọi là “ClickOps”, nói kèm một cái cau mày).

Bài tập: (1) Xem một bản viết post-mortem sự cố thực tế được thảo luận (nhiều bản công khai — các báo cáo sự cố của Cloudflare và AWS rất nổi tiếng) và tóm tắt vào nhật ký trong năm câu. (2) Ngồi dự (hoặc xem bản ghi hình) một buổi stand-up bất kỳ và viết ra ba blocker bạn nghe được.

Milestone — kết thúc Giai đoạn 1: bạn có thể ngồi suốt một cuộc họp lập kế hoạch kỹ thuật 30 phút và theo kịp ≥80% nội dung, và nhật ký của bạn chứng minh điều đó: ghi chú từ một cuộc họp thật hoặc mô phỏng với mọi từ viết tắt được mở rộng chính xác. Đây cũng là lúc bạn nên đặt lịch thi AWS Cloud Practitioner (CLF-C02) — 2–4 tuần ôn tập tập trung trên nền các module này là chuẩn được công bố, và việc thi đậu là bằng chứng bên ngoài đầu tiên của bạn.

GIAI ĐOẠN 2 — TƯ DUY NHƯ CẢ PHÒNG HỌP (Tuần 9–16)

Module 5 (Tuần 9–10): Kiến trúc — đánh giá các bản thiết kế mà không cần tự vẽ chúng

Vai trò của bạn trong một buổi design review không phải là thiết kế — mà là chất vấn. Khung tham chiếu mà cả ngành sử dụng là Well-Architected Framework của AWS, sáu trụ cột mà mọi bản thiết kế phải trả lời được: 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. Hãy học sâu ba trụ cột in đậm; đó là nơi tiền bạc và rủi ro trú ngụ.

Độ tin cậy, nói bằng ngôn ngữ thường: mọi thứ rồi sẽ hỏng, nên hệ thống tốt mặc định điều đó. Redundancy (dự phòng — không có điểm hỏng đơn lẻ nào; mọi thứ quan trọng đều có hai bản), multi-AZ (sống sót khi mất một trung tâm dữ liệu), auto-scaling (tự động thêm/bớt máy theo nhu cầu), backup được kiểm chứng (một bản sao lưu chưa từng thử khôi phục là một niềm hy vọng, không phải một kế hoạch), RTO/RPO (Recovery Time Objective: chúng ta có thể ngừng hoạt động bao lâu; Recovery Point Objective: chúng ta có thể mất bao nhiêu dữ liệu — hai con số này chính là cuộc trò chuyện về khôi phục thảm họa, và chúng là quyết định kinh doanh, tức là của bạn).

Tam giác đánh đổi: nhanh, rẻ, bền bỉ — chọn hai. Mọi cuộc tranh luận kiến trúc mà bạn sẽ phân xử đều quy về việc doanh nghiệp cần đứng ở đâu trên tam giác đó cho workload này. Một hệ thống thanh toán và một trang marketing không xứng đáng nhận cùng một câu trả lời.

Bảy câu hỏi của người lãnh đạo — hãy học thuộc; chúng khiến bạn “nguy hiểm” trong mọi buổi design review:

1. “What happens when this component fails?” (Điều gì xảy ra khi thành phần này hỏng?) (luôn luôn là “khi nào”, không phải “nếu”)
2. “What are the RTO and RPO, and who signed off on them?” (RTO và RPO là bao nhiêu, và ai đã phê duyệt chúng?)
3. “Where does this run — single AZ, multi-AZ, multi-region — and why?” (Cái này chạy ở đâu — một AZ, multi-AZ, multi-region — và vì sao?)
4. “What will this cost per month at 10× today’s load?” (Cái này tốn bao nhiêu mỗi tháng khi tải gấp 10 lần hôm nay?)
5. “What’s the simplest version that meets the requirement?” (Phiên bản đơn giản nhất vẫn đáp ứng yêu cầu là gì?) (over-engineering — thiết kế thừa — là căn bệnh của người non tay; sự đơn giản là đức hạnh của người senior)
6. “What are we locked into, and what would leaving cost?” (Chúng ta đang bị khóa vào cái gì, và rời đi sẽ tốn bao nhiêu?) (vendor lock-in — sự phụ thuộc nhà cung cấp — là một cái giá, đôi khi đáng trả — miễn là trả một cách có ý thức)
7. “Who else has built this before — are we inventing or assembling?” (Ai đã từng xây cái này trước đây — chúng ta đang phát minh hay đang lắp ráp?) (hãy ưu tiên những mẫu hình nhàm chán nhưng đã được chứng minh)

Fluency drill: luyện cách đặt câu hỏi 1, 4 và 5 với giọng điệu ấm áp — chúng được đón nhận như sự thông thái hay như đòn tấn công phụ thuộc hoàn toàn vào cách truyền đạt. “Help me understand what happens if the cache goes down” (Giúp tôi hiểu điều gì xảy ra nếu cache sập) hay hơn hẳn “did you think about failure?” (anh đã nghĩ đến chuyện hỏng hóc chưa?).

Bài tập: (1) Lấy ba kiến trúc mẫu (nhờ một AI tạo ra: một trang thương mại điện tử, một backend cho ứng dụng di động, một nền tảng phân tích dữ liệu) và áp cả bảy câu hỏi vào từng cái, viết ra những câu trả lời bạn kỳ vọng. (2) Đọc bản tóm tắt một trang về các trụ cột Well-Architected tại https://aws.amazon.com/architecture/well-architected/.

Video cho module này:

Milestone: trong một buổi design review mô phỏng (làm với một AI đóng vai kỹ sư), bạn đặt được năm câu hỏi có chất lượng và tóm tắt chính xác điểm yếu nhất của bản thiết kế ở cuối buổi.

Module 6 (Tuần 11–12): Bảo mật và tuân thủ — cuộc trò chuyện có thể kết liễu cả công ty

Shared responsibility model (mô hình trách nhiệm chia sẻ) — điều đầu tiên cần hiểu: nhà cung cấp bảo vệ bản thân cloud (tòa nhà, phần cứng, hypervisor); còn bạn bảo vệ những gì bạn đặt vào trong nó (dữ liệu, quy tắc truy cập, cấu hình của bạn). Đa số các vụ rò rỉ là do khách hàng cấu hình sai — một S3 bucket bị để public, một access key bị lộ — chứ không phải do nhà cung cấp thất bại. Vì thế “AWS an toàn” và “chúng ta an toàn trên AWS” là hai câu khác nhau.

Từ vựng của phòng thủ: IAM (Identity and Access Management — quản lý danh tính và quyền truy cập: ai được làm gì; thứ bị kiểm toán nhiều nhất trong cloud), least privilege (đặc quyền tối thiểu — mọi người chỉ nhận đúng mức truy cập cần thiết — quy tắc vàng), MFA (xác thực đa yếu tố trên mọi lần đăng nhập của con người — không thể thương lượng), encryption at rest and in transit (mã hóa khi lưu trữ và khi truyền — dữ liệu được xáo trộn trên đĩa và trên đường truyền — điều tối thiểu bắt buộc, luôn bật), root account (chìa khóa vạn năng — cất kỹ, không bao giờ dùng hằng ngày), secrets management (quản lý bí mật — mật khẩu/khóa nằm trong két, không bao giờ nằm trong code), zero trust (kiểm chứng mọi thứ, mặc định không tin bất kỳ vị trí mạng nào), penetration test (thuê “kẻ tấn công” kiểm chứng hàng phòng thủ của bạn), ransomware (mã độc tống tiền — lý do các bản backup được kiểm chứng, lưu ngoại tuyến là một biện pháp bảo mật, không chỉ là biện pháp vận hành).

PDPA — luật dữ liệu của Thái Lan, và lợi thế thị trường của bạn. Personal Data Protection Act là GDPR của Thái Lan: bắt buộc có sự đồng ý khi thu thập dữ liệu cá nhân, nghĩa vụ thông báo rò rỉ trong 72 giờ, yêu cầu Data Protection Officer cho các đơn vị xử lý dữ liệu quy mô lớn, và các quy định về chuyển dữ liệu xuyên biên giới. Việc thực thi trở nên nghiêm túc từ năm 2025 — hơn 21,5 triệu THB tiền phạt đợt đầu, trong đó có một bệnh viện bị phạt vì giám sát lỏng lẻo một nhà cung cấp bên ngoài. Hai hệ quả cho bạn: (1) mọi doanh nghiệp Thái giờ đây đều có một bài toán tuân thủ mà công ty bạn có thể được trả tiền để quản lý; (2) data residency (lưu trú dữ liệu — giữ dữ liệu Thái trên đất Thái) là một động lực thực sự đẩy các workload vào các region ở Bangkok. Đoạn văn này là một nửa bài chào hàng của bạn tại Thái Lan; hãy nắm nó thật vững.

Các câu hỏi bảo mật của người lãnh đạo: “Who has access to production, and when did we last review the list?” (Ai có quyền truy cập production, và lần cuối chúng ta rà soát danh sách đó là khi nào?) · “Are we alerted on unusual access, or would we find out from the news?” (Chúng ta có được cảnh báo khi có truy cập bất thường không, hay sẽ biết tin qua báo chí?) · “When did we last restore a backup?” (Lần cuối chúng ta thực sự khôi phục từ backup là khi nào?) (chứ không phải “chúng ta có backup không”) · “If we lost this dataset, is it a PDPA-notifiable breach — and could we notify within 72 hours?” (Nếu mất bộ dữ liệu này, đó có phải vụ rò rỉ buộc thông báo theo PDPA không — và chúng ta có kịp thông báo trong 72 giờ?) · “What did the last pen test find, and what’s still open?” (Đợt pen test gần nhất phát hiện gì, và những gì còn chưa xử lý?)

Từ vựng:

Video cho module này: The AWS Shared Responsibility Model — Digital Cloud Training — 4 phút — https://www.youtube.com/watch?v=ESPBBEK-cvo

Fluency drill: “Is that bucket public? Why?” (Bucket đó có đang public không? Vì sao?) · “Least privilege — does the intern really need prod access?” (Least privilege — thực tập sinh có thật sự cần quyền truy cập prod không?) · “Where does the PDPA line sit in this design — what’s personal data here and where does it physically live?” (Ranh giới PDPA nằm ở đâu trong thiết kế này — cái gì ở đây là dữ liệu cá nhân và nó nằm ở đâu về mặt vật lý?)

Bài tập: (1) Đọc một câu chuyện rò rỉ nổi tiếng do cấu hình cloud sai (vụ Capital One 2019 là kinh điển) và viết phiên bản ba câu vào nhật ký. (2) Nhờ một AI mô phỏng khách hàng hỏi “vì sao tôi nên tin giao dữ liệu cho anh?” và luyện câu trả lời bằng ngôn ngữ shared responsibility + PDPA.

Milestone: bạn có thể giải thích shared responsibility model và ý nghĩa thực tiễn của PDPA cho một chủ doanh nghiệp Thái không thuộc giới kỹ thuật trong dưới ba phút — vì lời giải thích đó chính là buổi chào hàng dịch vụ MSP.

Module 7 (Tuần 13–14): Tiền bạc — kinh tế học cloud và FinOps

Đây là nơi một lãnh đạo không-phải-kỹ-sư tạo ra giá trị nhanh nhất, vì đa số kỹ sư chưa từng được dạy về nó và mức lãng phí là khổng lồ — các khảo sát nhất quán cho thấy khoảng một phần ba chi tiêu cloud bị lãng phí.

Đồng hồ tính tiền chạy thế nào: compute được tính theo từng giây nó bật (không phải theo mức sử dụng — một server nhàn rỗi vẫn bị tính đủ; “quên tắt” là kiểu lãng phí kinh điển), lưu trữ tính theo GB-tháng, và — cái bẫy nổi tiếng — egress (dữ liệu đi ra): dữ liệu chảy ra khỏi cloud thì tốn tiền trong khi dữ liệu đi vào miễn phí. Hóa đơn egress khổng lồ khiến ai cũng bất ngờ một lần; sau module này, bạn thì không.

Thực đơn giá: on-demand (giá đầy đủ, linh hoạt tối đa) · reserved instances / savings plans (cam kết 1–3 năm để được giảm 30–70% — đòn bẩy lớn nhất cho workload ổn định) · spot instances (giảm đến 90% cho công việc chịu được gián đoạn như batch job) · rightsizing (đa số server bị cấp thừa tài nguyên; thu nhỏ chúng là tiền nhặt được) · phân bậc lưu trữ (Module 2) · auto-scaling như một công cụ chi phí (sao lại trả tiền cho công suất lúc nửa đêm với giá giờ cao điểm?).

FinOps là thực hành làm cho chi tiêu cloud trở nên hữu hình, được phân bổ và tối ưu liên tục: tagging (gắn thẻ) mọi tài nguyên với chủ sở hữu và dự án của nó (chi tiêu không gắn thẻ là chi tiêu không ai chịu trách nhiệm), showback/chargeback (cho mỗi đội thấy hóa đơn của mình — hành vi thay đổi ngay lập tức), ngân sách kèm alert (đừng bao giờ phát hiện bội chi từ hóa đơn), và unit economics (kinh tế học đơn vị) — chỉ số của người lãnh đạo: không phải “hóa đơn của chúng ta là ฿800k/tháng” mà là “chi phí trên mỗi giao dịch của khách hàng đang giảm.” Chứng chỉ FinOps Certified Practitioner mất khoảng hai tuần và, đối với một lãnh đạo phía kinh doanh, là tấm chứng chỉ có độ-tin-cậy-trên-mỗi-giờ-học cao nhất trong toàn bộ thế giới cloud. Hãy lấy nó.

Các câu hỏi tiền bạc của người lãnh đạo: “What’s our cost per [customer/transaction/tenant], and which direction is it moving?” (Chi phí trên mỗi [khách hàng/giao dịch/tenant] của chúng ta là bao nhiêu, và đang đi theo hướng nào?) · “What percentage of our steady workload is on reservations?” (Bao nhiêu phần trăm workload ổn định của chúng ta đang chạy trên reservation?) · “What’s untagged?” (Cái gì đang chưa được gắn thẻ?) · “What died but is still billing?” (Cái gì đã chết mà vẫn đang tính tiền?) (đĩa mồ côi và IP nhàn rỗi — tài khoản nào cũng có) · “What would this bill look like at 10× growth — does our architecture get cheaper or more expensive per unit?” (Hóa đơn này sẽ ra sao khi tăng trưởng gấp 10 lần — kiến trúc của chúng ta rẻ đi hay đắt lên trên mỗi đơn vị?)

Từ vựng:

Video cho module này: What is FinOps? — FinOps Foundation (official) — 2 phút — https://www.youtube.com/watch?v=Y-c_xw9bHFw · sau đó là khóa học miễn phí “Introduction to FinOps” tại https://learn.finops.org.

Bài tập: (1) Mở AWS pricing calculator và tính giá một hệ thống nhỏ có thật (hai server, một cơ sở dữ liệu, 500GB lưu trữ, 1TB egress) — làm việc đó một lần sẽ “giải thiêng” mọi cuộc trò chuyện về chi phí sau này. (2) Nhờ một AI đóng vai kỹ sư đang bảo vệ một server quá khổ; luyện cách thương lượng rightsizing một cách tử tế.

Milestone: thi (hoặc đặt lịch thi) FinOps Practitioner, và trong một buổi review mô phỏng, tìm ra bốn vấn đề chi phí trong một hóa đơn mẫu do AI tạo cho bạn.

Module 8 (Tuần 15–16): Trại huấn luyện trôi chảy — ghép ngôn ngữ lại với nhau

Hai tuần này là tích hợp thuần túy — sự khác biệt giữa biết từ vựng và trôi chảy trong các cuộc họp.

Bài luyện hằng ngày (30 phút): nhờ một AI tạo một biên bản họp thực tế (design review, incident retro, hoặc cost review), với hai lỗi kỹ thuật được cố tình cài vào. Nhiệm vụ của bạn: tóm tắt cuộc họp trong năm câu, bắt được các lỗi, và viết ra ba câu hỏi bạn sẽ đặt. Luân phiên các loại họp mỗi ngày.

Cơ bắp phiên dịch (15 phút): mỗi ngày lấy một phát biểu kỹ thuật và dịch nó cho ba đối tượng — CFO (tiền bạc), khách hàng (rủi ro/lợi ích), và một kỹ sư junior mới (giảng dạy). Ví dụ: “Chúng ta chuyển session store từ cơ sở dữ liệu sang Redis” → CFO: “giảm tải cơ sở dữ liệu nên hoãn được đợt nâng cấp ฿2M” → khách hàng: “trang tải nhanh hơn lúc cao điểm” → junior: “Redis giữ dữ liệu nóng trong bộ nhớ, nên ta thôi ‘đập’ vào cơ sở dữ liệu với mỗi cú nhấp chuột.”

Luyện đọc (15 phút): mỗi ngày một bài blog kỹ thuật thực thụ (AWS Architecture Blog, hoặc blog kỹ thuật của Netflix/Grab — Grab đặc biệt phù hợp: quy mô Đông Nam Á, thị trường sát với Thái Lan). Giờ đây bạn sẽ hiểu 70–80% nội dung. Tra cứu phần còn lại.

Người bạn đồng hành ôn thi cho giai đoạn này: khóa học đầy đủ miễn phí nổi tiếng — AWS Certified Cloud Practitioner (CLF-C02) 2026 của Andrew Brown trên freeCodeCamp — https://www.youtube.com/watch?v=7HKot-brXFE (ấn bản 14 giờ trước đó, cũng hợp lệ cho cùng mã đề thi, ở tại https://www.youtube.com/watch?v=NhDYbskXRgc). Xem ở tốc độ 1.25× trong các Tuần 13–16; sau các Module 1–7, phần lớn nội dung sẽ giống như ôn tập — và đó chính xác là dấu hiệu bạn đã sẵn sàng.

Milestone — kết thúc Giai đoạn 2, kỳ thi tốt nghiệp của bạn: (1) Đậu AWS Cloud Practitioner nếu bạn chưa đậu. (2) “Trận đấu thử” mô phỏng: một AI đóng vai kỹ sư senior dẫn bạn đi qua một kiến trúc có lỗi cho một khách hàng thương mại điện tử Thái; bạn phải tìm ra cơ sở dữ liệu chạy single-AZ, cái S3 bucket bị public, ước tính egress bị thiếu, và sự vắng bóng của cân nhắc PDPA — rồi đưa phản hồi với giọng điệu khiến “người kỹ sư” cảm thấy được giúp đỡ, chứ không phải bị bắt lỗi. Khi làm được điều đó, bạn đã “nguy hiểm” trong giao tiếp — chỉ sau mười sáu tuần.

GIAI ĐOẠN 3 — LÃNH ĐẠO (Tháng 5–24)

Module 9 (Tháng 5–8): Chứng chỉ chuyên sâu và sàn kỹ thuật

Học qua tài liệu AWS Solutions Architect Associate (SAA-C03) — 2–3 tháng với nhịp độ một giờ mỗi ngày của bạn. Bạn có thể thi hoặc không (với tư cách lãnh đạo, tài liệu mới là giá trị; tấm huy hiệu chỉ là màn trình diễn tùy chọn), nhưng đây là nơi region, VPC, IAM và định giá thôi là từ vựng rời rạc và trở thành một hệ thống kết nối trong đầu bạn. Song song, duy trì các bài luyện hằng ngày của Module 8 ở nửa liều. Đây cũng là khoảng thời gian để bổ sung kiến thức nền tảng Azure (trình độ AZ-900) — Thái Lan là thị trường doanh nghiệp nặng về Microsoft, và khả năng “song ngữ” (AWS+Azure) mở rộng các cuộc trò chuyện với khách hàng của bạn.

Module 10 (Tháng 5–12, chạy liên tục): Tuyển dụng và quản lý kỹ sư

Tuyển dụng khi bạn chưa thể tự đánh giá đầy đủ kỹ năng: cấu trúc thắng bản năng. Dùng một vòng lặp nhất quán: một buổi trò chuyện sàng lọc do bạn dẫn dắt (động lực, khả năng giao tiếp, cách họ giải thích một dự án cũ cho người không phải kỹ sư — nếu họ không làm được, họ cũng sẽ thất bại với khách hàng của bạn) + một buổi phỏng vấn kỹ thuật do bar-raiser của bạn thực hiện (“người giữ chuẩn” — nhân vật kỹ thuật số 2 của bạn hoặc một chuyên gia senior thuê ngoài) + một cuộc gọi tham khảo nơi bạn hỏi đúng một câu hỏi quan trọng: “would you hire this person again for this role?” (anh/chị có tuyển lại người này cho đúng vai trò này không?). Hãy cảnh giác với hai kiểu thất bại điển hình: người nói năng lưu loát nhưng không có chiều sâu (bar-raiser của bạn sẽ bắt được họ) và chuyên gia sâu sắc nhưng ít nói (thường là vàng ròng trong các đội Thái, nơi sự khiêm tốn thuộc về văn hóa — đừng để sự bóng bẩy khi phỏng vấn lấn át bằng chứng về công việc thực).

Nhân vật kỹ thuật số 2 — quyết định quan trọng nhất của cả liên doanh: tuyển họ đầu tiên, trả bằng cổ phần có ý nghĩa (10–20% nếu là đồng sáng lập thực thụ), và định nghĩa thỏa thuận một cách tường minh: họ giữ chuẩn mực kỹ thuật và sở hữu các quyết định kiến trúc; bạn sở hữu khách hàng, tiền bạc, thứ tự ưu tiên và con người; bất đồng giữa hai người diễn ra kín đáo và được giải quyết trước khi đội nhìn thấy.

Những nghi thức khiến kỹ sư ở lại: các buổi 1:1 hằng tuần hoặc hai tuần một lần nói về chính họ (sự nghiệp, va chạm, năng lượng — không phải báo cáo tiến độ); một lộ trình phát triển bằng văn bản cho từng người (trong thị trường thiếu hụt 70k nhân lực/năm của Thái Lan, cơ hội phát triển và ngân sách chứng chỉ giữ người tốt hơn lương đơn thuần — trả tiền cho mọi chứng chỉ, kèm thưởng vesting 12 tháng khi hoàn thành); khen công khai, góp ý riêng tư; và bảo vệ quyết liệt thời gian tập trung của họ — một lãnh đạo hủy cuộc họp giữa sprint là một người hùng.

Diễn đàn quyết định — cách bạn ra các quyết định kỹ thuật mà bạn chưa thể tự thẩm định đầy đủ: với bất kỳ quyết định lớn nào, yêu cầu một decision doc (tài liệu quyết định) dài một trang từ kỹ sư đề xuất: vấn đề, 2–3 phương án, chi phí, rủi ro, khuyến nghị. Rồi điều hành cuộc họp bằng bảy câu hỏi của bạn từ Module 5. Bạn không phải kiến trúc sư giỏi nhất trong phòng và không bao giờ cần phải thế — bạn là người khiến phương án được lập luận tốt nhất chiến thắng, đúng hạn, với các đánh đổi về tiền bạc và rủi ro được nêu tường minh. Các kỹ sư tôn trọng sâu sắc điều này khi nó được làm trung thực; hãy ghi lại ai dự đoán điều gì (lại là Decision Journal của bạn) và xem lại các dự đoán mỗi quý — việc đó hiệu chỉnh cả bạn lẫn họ.

Module 11 (Tháng 6–24): Đường cong uy tín, một cách trung thực

Kinh nghiệm được công bố từ các tài liệu về lãnh đạo kỹ thuật hội tụ về mốc thời gian này, và giả vờ khác đi chính là cách các nhà sáng lập phi kỹ thuật thất bại: ~90 ngày để vận hành nhịp kinh doanh một cách thành thạo · ~6 tháng để đạt mức hiệu quả cơ bản (họp hành trôi chảy, quyết định có cấu trúc, đội ngũ ổn định) · 12–18 tháng trước khi trực giác kỹ thuật của bạn tự thân có giá trị đáng kể · ~2 năm trước khi bạn thực sự đứng vững trước các kỹ sư senior trong các cuộc bàn về đánh đổi kiến trúc. Các biện pháp giảm nhẹ trong khi đường cong đi lên: mượn uy tín (nhân vật số 2 của bạn trình bày nửa kỹ thuật của các buổi gặp bán hàng — đằng nào khách hàng cũng cần thấy đội ngũ dự bị), không bao giờ nói liều (kẻ giết uy tín nhanh nhất; “I don’t know — walk me through it” (Tôi chưa biết — hãy dẫn tôi đi qua nó) là một câu nói của người lãnh đạo), và để các câu hỏi của bạn lên tiếng thay bạn: một lãnh đạo hỏi “what’s our RPO and who signed off on it?” (RPO của chúng ta là bao nhiêu và ai đã phê duyệt?) nghe như mang ba mươi năm sẹo trận mạc — và sau khóa học này, bạn sẽ hỏi câu đó với hiểu biết thật.

Module 12 (Liên tục): Lớp kiến thức thị trường Thái Lan

Gấp các nội dung cụ thể từ TSI Phần 5 vào thành kiến thức vận hành: PDPA vừa là nghĩa vụ tuân thủ vừa là sản phẩm (§Module 6); các bậc thang đối tác (AWS Select cần một số nhân sự có chứng chỉ + 3 thương vụ đã triển khai; Microsoft Solutions Partner cần điểm năng lực 70/100 — chứng chỉ của đội bạn đúng nghĩa là tài sản bán hàng, thêm một lý do nữa để tài trợ cho chúng); ưu đãi BOI cho quyền sở hữu nước ngoài 100% của công ty; các dải lương Bangkok (junior ฿50–75k → architect ฿180–280k/tháng) để bạn định giá thầu và đưa ra offer chính xác; và bài toán bán hàng của thời điểm này — hơn 27 tỷ USD đầu tư trung tâm dữ liệu đã được phê duyệt, một chỉ thị cloud-first của chính phủ, và khoảng trống kỹ năng 70.000 người/năm mà đội ngũ có chứng chỉ của bạn tồn tại để lấp đầy.

Giáo trình một trang

Đôi lời khép lại từ người thầy của bạn. Mười sáu tuần nữa, bạn sẽ theo kịp mọi cuộc trò chuyện trong phòng họp. Đó không phải vạch đích — đó là tấm giấy phép để bắt đầu. Đường cong hai năm đến óc phán đoán kỹ thuật thực thụ không phải một bức tường; nó là một con hào: mỗi tuần bạn hoàn thành trên đường cong đó là một tuần mà các nhà sáng lập phi kỹ thuật của đối thủ đã không làm. Học mỗi ngày, ghi nhật ký mọi quyết định, không bao giờ nói liều, và tuyển những người giỏi hơn bạn rồi khiến họ vui vì đã đến. Đó là toàn bộ công việc.

Tài liệu đồng hành với “The Thailand Strategic Investment (TSI)”, Phần 5. Các ước tính thời gian ôn thi chứng chỉ và mốc thời gian lãnh đạo được rút từ các nguồn trích dẫn ở đó (CBT Nuggets, StudyTech, FinOps Foundation, First Round Review, The Pragmatic Engineer).