Ngày 12 · Hạ tầng Cloud & Deployment

Ý chínhGiảng viên đặt tình huống xuyên suốt ngày học: bạn demo cho sếp thấy agent chạy trên laptop, sếp hỏi khi nào 100 người dùng được và liệu nó có ngốn hết ngân sách không. Đối chiếu với hiện trạng sau 11 ngày: agent chạy ở localhost, khoá API nằm trong file .env, chỉ một người dùng là chính mình, không có health check, tắt laptop là agent dừng. Giới thiệu bốn đầu ra của ngày — đóng gói được, bảo vệ được, mở rộng được, deploy được — và nhấn mạnh ngày học không đòi hỏi nền DevOps, chỉ cần một máy tính cài được Docker.

Kỹ năngHọc viên biết mình sẽ đạt được gì sau ngày học và nhận ra khoảng cách giữa "chạy được trên máy tôi" và "dùng được cho 100 người".

Hình thứcVideo giảng viên, 3 phút, giọng dẫn dắt.

Ý chínhBa tầng dịch vụ cloud theo mức tự quản giảm dần: thuê máy ảo, thuê nền tảng, dùng phần mềm có sẵn. Sáu lớp của một ứng dụng AI theo đường đi của request: client, gateway và xác thực, dịch vụ backend (phiên hội thoại, RAG, tool, worker chạy nền), tầng model, tầng dữ liệu (vector DB, DB quan hệ, cache, hàng đợi) và hạ tầng cloud (compute, CI/CD, giám sát). Ba nhà cung cấp lớn cung cấp dịch vụ tương đương dưới tên gọi khác nhau; Railway và Render là nền tảng đơn giản hơn để bắt đầu. Sáu lớp là bản đồ tổng quát để định vị, không phải thứ tự phải làm.

Kỹ năngHọc viên đặt được từng thành phần agent mình đã xây vào đúng lớp, và gọi tên được dịch vụ tương ứng ở ít nhất một nhà cung cấp.

Hình thứcVideo 6 phút, sáu lớp hiện dần theo đường đi của một request từ người dùng đến model và quay về. Kèm bảng tra cứu tên dịch vụ tương đương giữa ba nhà cung cấp lớn và hai nền tảng đơn giản, một trang, cập nhật định kỳ. Phương án thay thế: một trang đọc kèm sơ đồ.

Ý chínhTình huống mở đầu: gửi code cho bạn cùng nhóm hoặc cho giảng viên thì không chạy được vì máy họ thiếu thư viện hoặc lệch phiên bản, mà gửi cả laptop đi thì không khả thi. Năm khác biệt giữa dev và production: thư viện (cài tay bằng pip so với đóng gói cùng container), cấu hình (file .env trên máy so với biến môi trường và trình quản lý secret — khi có 10 máy thì không thể chép .env lên từng máy), mạng (localhost:8000 so với HTTPS, tên miền, bộ cân bằng tải), người dùng (một so với nhiều người đồng thời), và sự cố (khởi động lại bằng tay so với tự khởi động lại kèm health check). Nguyên tắc dev/prod parity: ba môi trường dev, staging, production càng giống nhau càng ít lỗi khi deploy.

Kỹ năngHọc viên nêu được năm khác biệt và chỉ ra trong agent hiện tại của mình chỗ nào đang vi phạm từng khác biệt.

Hình thứcVideo 5 phút, bảng hai cột hiện dần từng dòng, mỗi dòng kèm một tình huống thất bại khi bỏ qua.

Ý chínhMột ứng dụng CRUD trả lời trong dưới 1 giây; agent khác về bản chất ở ba điểm. Vòng lặp suy luận chạy 10–60 giây, có khi vài phút, vượt timeout mặc định 29–60 giây của gateway và proxy. Agent có memory hội thoại và lịch sử tool, mâu thuẫn với nguyên tắc stateless cần để mở rộng. Mỗi lượt gọi gửi lại cả lịch sử nên chi phí tăng siêu tuyến tính theo token. Hệ quả: dùng lại cùng bộ máy ship của phần mềm truyền thống — CI/CD, container, cân bằng tải — nhưng định nghĩa lại cách kiểm thử (eval gate thay vì so khớp chính xác), hoá đơn (token thay vì giờ CPU) và dependency (model nằm trên máy của nhà cung cấp, có thể bị khai tử hoặc bị giới hạn thông lượng theo gói).

Kỹ năngHọc viên nêu được ba tính chất và dự đoán được tính chất nào gây ra lỗi 504, tính chất nào làm hoá đơn tăng bất ngờ.

Hình thứcVideo 7 phút. Bảng sáu tiêu chí CRUD so với agent (kiểm thử, chi phí, độ trễ, state, dependency, đơn vị mở rộng) hiện dần; đoạn timeout dùng ẩn dụ gọi điện thoại phải đợi đầu dây kia bắt máy. Kèm bảng timeout mặc định của các nền tảng phổ biến, một trang, cập nhật định kỳ.

Ý chính3 câu kiểm tra: RAG và tool nằm ở lớp nào trong sáu lớp; cấu hình khác nhau thế nào giữa dev và production; ba tính chất của agent.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module.

Hình thứcQuiz 3 câu, chấm ngay, có giải thích khi sai.

Ý chínhHọc viên đọc một ứng dụng FastAPI mẫu khoảng 60 dòng đang chạy tốt ở localhost và tìm những chỗ sẽ gây sự cố khi đưa lên production: khoá API và chuỗi kết nối DB ghi thẳng trong code; in cả khoá ra log khi khởi động; không có endpoint kiểm tra sức khoẻ; cổng cố định 8000 thay vì đọc từ biến môi trường; không giới hạn origin được phép gọi. Nhầm lẫn phổ biến là cho rằng chương trình chạy đúng thì đã đủ; ứng dụng mẫu trả lời đúng mọi câu hỏi nhưng vẫn không thể vận hành cho người khác.

Kỹ năngHọc viên tự phát hiện được ít nhất 4 trong 5 lỗi và giải thích được hậu quả của từng lỗi.

Hình thứcTương tác: học viên đánh dấu các dòng có vấn đề trong code hiển thị trên màn hình, mỗi dòng đánh dấu đúng hiện ngay hậu quả tương ứng, ví dụ log in khoá ra terminal. 4 phút. Phương án thay thế: video 3 phút chỉ từng lỗi.

Ý chínhNguyên tắc đầu tiên của 12-factor: mọi cấu hình đọc từ biến môi trường, không hardcode. Secret bắt buộc không có giá trị mặc định để ứng dụng dừng ngay khi thiếu khoá thay vì chạy với khoá giả — thà dừng sớm còn hơn chạy sai. Ba môi trường và cách quản lý secret tăng dần: file .env ở local, biến môi trường trên nền tảng ở staging, trình quản lý secret có xoay vòng và nhật ký truy cập ở production; dữ liệu ở staging là dữ liệu giả cùng schema, không phải dữ liệu thật. Khoá lỡ đẩy lên kho mã công khai có thể bị quét và khai thác trong vài giờ; cách xử lý duy nhất là thu hồi và tạo khoá mới ngay, đồng thời thêm bước quét secret vào CI.

Kỹ năngHọc viên tách được cấu hình ra một module Settings đọc từ môi trường, và nêu được vì sao secret không được có giá trị mặc định.

Hình thứcVideo 5 phút ghi màn hình: chuyển một file có khoá hardcode sang Settings đọc từ môi trường, cố tình bỏ khoá để thấy ứng dụng dừng ngay khi khởi động. Kèm bảng so sánh local, staging, production theo 6 tiêu chí — mục đích, dữ liệu, secret, số instance, cách deploy, cách rollback — một trang.

Ý chínhHạ tầng cần biết agent còn sống và đã sẵn sàng nhận request hay chưa. Endpoint /health (liveness) trả về trạng thái, thời gian chạy, phiên bản; hạ tầng gọi định kỳ, khác 200 thì khởi động lại container. Endpoint /ready (readiness) kiểm tra thêm phụ thuộc như Redis; thất bại thì chỉ ngắt traffic khỏi instance đó chứ không khởi động lại — nhầm hai loại này sẽ tạo vòng lặp khởi động vô ích. Mã 4xx là lỗi phía client, 5xx là lỗi phía mình — nhìn mã là biết lỗi thuộc về ai. Log ghi dạng key-value hoặc JSON để công cụ phân tích đọc được, thay cho print dòng chữ tự do; mỗi dòng log mang tên sự kiện, độ dài request, địa chỉ client, và không bao giờ mang secret.

Kỹ năngHọc viên viết được /health và /ready đúng vai trò, phân biệt được 4xx và 5xx, và nêu được hai việc làm được với log JSON mà print không làm được.

Hình thứcVideo 6 phút ghi màn hình: gọi /health thấy uptime tăng dần, tắt Redis thấy /ready đổi trạng thái còn /health vẫn 200; so sánh một dòng print và một dòng log JSON của cùng sự kiện.

Ý chínhKhi deploy bản mới hoặc khi hạ tầng thu hồi instance, tiến trình nhận tín hiệu dừng. SIGKILL tắt ngay lập tức: request đang xử lý dở bị cắt, dữ liệu đang ghi có thể hỏng. SIGTERM cho phép tắt êm: ngừng nhận request mới, xử lý nốt request đang dở, trả kết quả, rồi mới thoát. Với agent, một lượt xử lý có thể kéo dài, nên thời gian chờ tắt phải lớn hơn lượt dài nhất. Cặp tương phản: cùng một request đang chạy, một tiến trình nhận SIGKILL và một tiến trình nhận SIGTERM.

Kỹ năngHọc viên cài được hàm xử lý SIGTERM cho FastAPI và giải thích được vì sao request dở vẫn được trả về.

Hình thứcTương tác mô phỏng 4 phút: học viên gửi một request mất 5 giây rồi bấm "dừng tiến trình" theo hai cách, dự đoán trước rồi quan sát request được trả về hay bị cắt; sau đó chỉnh thời gian chờ tắt ngắn hơn lượt xử lý để thấy request vẫn bị cắt. Cần người hướng dẫn giải thích tín hiệu của hệ điều hành. Phương án thay thế: video demo 3 phút.

Ý chính3 câu kiểm tra: vì sao secret không có giá trị mặc định; /health khác /ready thế nào; điều gì xảy ra với request đang dở khi tiến trình nhận SIGTERM.

Kỹ năngHọc viên tự kiểm tra ba ý chính trước khi vào khối lab đầu tiên.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhBa thế hệ hạ tầng qua câu chuyện một sàn thương mại điện tử: máy chủ vật lý chịu tải ngày thường nhưng quá tải ngày khuyến mãi, nâng cấp phải tắt máy cắm phần cứng nên gián đoạn dịch vụ; máy ảo cho phép chạy nhiều hệ điều hành trên một máy nhưng mỗi máy ảo mang cả hệ điều hành nên nặng hàng GB và khởi động chậm; container đóng gói mã nguồn, thư viện và runtime thành một đơn vị dùng chung nhân hệ điều hành nên nhẹ, khởi động trong vài giây và nhân bản được hàng chục bản khi tải tăng. Hình dung: đóng gói cả chiếc laptop thành một khối, mang đi đâu cũng chạy y hệt. Image là bản thiết kế bất động, container là bản thiết kế đang chạy — như file cài hệ điều hành và hệ điều hành đang chạy. Docker chỉ là một công cụ tạo và chạy container, không phải chính khái niệm container.

Kỹ năngHọc viên giải thích được vì sao container nhẹ hơn máy ảo, và phân biệt được image với container bằng một ví dụ của mình.

Hình thứcVideo 7 phút, dạng kể chuyện với sơ đồ ba thế hệ xếp chồng lớp — phần cứng, hệ điều hành, ứng dụng; đoạn image và container dùng hình bản thiết kế và ngôi nhà.

Ý chínhMột Dockerfile tối thiểu chỉ có sáu lệnh: FROM chọn image gốc, WORKDIR đặt thư mục làm việc, COPY đưa mã nguồn vào, RUN cài thư viện, EXPOSE khai báo cổng, CMD lệnh khởi chạy. Mỗi lệnh tạo một layer xếp chồng lên image gốc. Vòng làm việc: build tạo image có tag; run tạo container từ image với ánh xạ cổng — số bên trái là cổng trên máy mình tự chọn, số bên phải là cổng ứng dụng khai báo; push đẩy image lên registry; pull kéo về máy khác chạy mà không cần mã nguồn hay trình biên dịch. Registry là kho image công khai giống như kho mã nguồn. Các lệnh quan sát: liệt kê container, xem log, vào trong container bằng exec.

Kỹ năngHọc viên viết được Dockerfile cho agent FastAPI của mình, build và chạy được ở local, và giải thích được từng số trong tuỳ chọn ánh xạ cổng.

Hình thứcVideo 7 phút ghi màn hình: viết Dockerfile từ trống, build thấy từng layer chạy, run và mở trình duyệt, push lên registry rồi pull về chạy trên một máy trống. Kèm bảng tra cứu 12 lệnh Docker và Docker Compose hay dùng, một trang.

Ý chínhDocker dùng lại layer chưa đổi từ lần build trước; layer nào đổi thì mọi layer sau nó phải chạy lại. Vì thế lệnh ít thay đổi đặt lên trên, lệnh hay thay đổi đặt xuống dưới: chép file khai báo thư viện và cài thư viện trước, chép mã nguồn sau. Nhầm lẫn phổ biến là chép toàn bộ thư mục rồi mới cài thư viện, khiến mỗi lần sửa một ký tự trong code lại cài lại toàn bộ thư viện. Mở rộng: gộp các lệnh RUN liên quan thành một để giảm số layer; file .dockerignore loại .git, .env và thư mục môi trường ảo khỏi image.

Kỹ năngHọc viên dự đoán đúng layer nào được dùng lại sau khi sửa code, và sắp xếp lại Dockerfile để build lại chỉ mất vài giây.

Hình thứcTương tác mô phỏng 3 phút: học viên sửa một ký tự trong main.py rồi bấm build với hai Dockerfile có thứ tự COPY và RUN khác nhau, dự đoán trước rồi quan sát layer nào báo dùng lại và thời gian build. Phương án thay thế: video 2 phút so sánh hai lần build.

Ý chínhImage một giai đoạn mang cả trình biên dịch và toàn bộ thư viện build nên nặng khoảng 1 GB; multi-stage build tách giai đoạn build và giai đoạn chạy, chỉ chép kết quả sang image chạy nên còn dưới 500 MB, thậm chí vài chục MB. Chọn image gốc: bản đầy đủ khoảng 1 GB; bản slim khoảng 150 MB là mặc định tốt cho Python; distroless gọn nhất nhưng không có shell để gỡ lỗi; alpine tránh dùng cho AI vì thư viện tính toán phải biên dịch lại từ nguồn, chậm gấp hàng chục lần. Container mặc định chạy bằng root: kẻ tấn công vào được sẽ có sẵn mã nguồn, trình biên dịch và toàn quyền sửa ứng dụng; tạo user thường và chuyển sang user đó cắt đứt chuỗi này. Cặp tương phản: vào trong hai container từ cùng một mã nguồn, một bản root có mọi thứ và sửa được câu trả lời của agent, một bản non-root chỉ có file chạy nên không làm gì được. Ghim phiên bản image gốc thay vì dùng tag latest; quét lỗ hổng image trước khi deploy.

Kỹ năngHọc viên viết được Dockerfile hai giai đoạn với user thường, chọn được image gốc phù hợp, và giải thích được chuỗi sự kiện từ một lỗ hổng trong code đến quyền cao trên máy chủ.

Hình thứcỞ nhà: video 8 phút ghi màn hình, build hai bản và so kích thước, vào trong từng container để thấy dấu nhắc root và user thường, đóng vai kẻ tấn công sửa mã trong bản root. Trên lớp: tương tác 4 phút, học viên thử cùng thao tác sửa mã trong hai container mô phỏng sẵn và quan sát kết quả trên trình duyệt. Phương án thay thế: slide kèm hai ảnh chụp màn hình đối chiếu.

Ý chínhMột agent thật gồm nhiều dịch vụ: agent, vector store, Redis cho phiên và giới hạn tần suất, reverse proxy. Docker Compose khai báo tất cả trong một file và khởi chạy bằng một lệnh; các dịch vụ gọi nhau bằng tên, agent chờ dịch vụ phụ thuộc báo khoẻ mới khởi động, dữ liệu bền lưu ở volume — như ổ đĩa ngoài cắm vào container, còn lại khi container mất. Nguyên tắc tách image khỏi cấu hình: một image dùng cho mọi môi trường, khác nhau chỉ ở biến môi trường truyền vào lúc chạy. Nhầm lẫn phổ biến là build một image riêng cho mỗi máy hoặc mỗi khoá API.

Kỹ năngHọc viên viết được docker-compose.yml cho agent kèm Redis, và giải thích được vì sao chỉ cần một image cho cả ba môi trường.

Hình thứcVideo 6 phút ghi màn hình: thêm dịch vụ vào file compose, khởi chạy, tắt Redis để thấy agent chờ, đổi biến môi trường và chạy lại cùng một image.

Ý chính4 câu kiểm tra: vì sao container nhẹ hơn máy ảo; số nào trong ánh xạ cổng do mình chọn; layer nào chạy lại khi sửa code; vì sao không chạy container bằng root.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhGateway là điểm vào duy nhất của mọi request, đứng trước agent như một bức tường. Vòng đời: request đến, kiểm tra xác thực — sai trả 401; kiểm tra tần suất — vượt trả 429; kiểm tra đầu vào và ngân sách còn lại; rồi mới chuyển vào agent. Từ chối sớm ở gateway đồng nghĩa với không tốn token cho request xấu. Sáu chức năng thường gặp: xác thực, giới hạn tần suất, định tuyến và cân bằng tải, biến đổi request, ghi log và trace, cache câu trả lời cho câu hỏi lặp lại. Với MVP, một middleware trong FastAPI là đủ; dịch vụ gateway quản lý là bước sau.

Kỹ năngHọc viên vẽ được vòng đời request qua gateway và nói được mã lỗi trả về ở từng bước từ chối.

Hình thứcVideo 6 phút, sơ đồ bốn trạm kiểm tra hiện dần, mỗi trạm một request mẫu bị chặn kèm mã lỗi.

Ý chínhBa mẫu theo độ phức tạp tăng dần: khoá API trong header — đơn giản, đủ cho MVP và giao tiếp giữa các dịch vụ, khoá được băm rồi lưu, gateway so khớp; JWT — token có hạn, không cần lưu phiên, dùng cho ứng dụng hướng người dùng, thường gồm access token ngắn hạn và refresh token dài hạn; OAuth 2.1 với PKCE — uỷ quyền, bắt buộc khi host MCP server từ xa. CORS chỉ là kiểm soát của trình duyệt đối với origin gọi vào, không thay thế xác thực. Khoá không bao giờ được đưa xuống trình duyệt: ứng dụng "phía client" vẫn cần một backend trung gian giữ khoá và gọi model. Kèm quy tắc khi khoá lộ: thu hồi ngay, tạo khoá mới, kiểm tra .env đã nằm trong .gitignore.

Kỹ năngHọc viên chọn được mẫu xác thực phù hợp cho từng tình huống và giải thích được vì sao bật CORS chưa phải là bảo mật.

Hình thứcVideo 6 phút, ba mẫu trình bày theo bậc; sơ đồ trình duyệt, backend trung gian, nhà cung cấp model để thấy khoá nằm ở đâu.

Ý chínhGiới hạn tần suất chặn một người dùng hoặc một khoá gọi quá nhiều trong một khoảng thời gian. Ba thuật toán: cửa sổ cố định đếm theo phút đồng hồ và đặt lại ở giây 00, nên với hạn mức 10 lượt mỗi phút, một người có thể gửi 20 lượt trong 2 giây quanh mốc đặt lại; cửa sổ trượt đếm trong 60 giây gần nhất nên không có kẽ hở đó; xô token cho phép bùng nổ ngắn rồi nạp lại dần. Hạn mức thường đặt theo gói người dùng. Cặp tương phản: cùng một loạt request bùng nổ đi qua cửa sổ cố định và cửa sổ trượt.

Kỹ năngHọc viên dự đoán được số request lọt qua ở mỗi thuật toán và chọn được thuật toán cho agent của mình.

Hình thứcTương tác mô phỏng 4 phút: học viên chọn thuật toán và hạn mức, bắn một loạt 20 request trong 2 giây quanh mốc phút, dự đoán trước rồi quan sát số request nhận 200 và số nhận 429 trên dòng thời gian. Kèm trang tóm tắt ba thuật toán dạng bảng tra cứu. Phương án thay thế: video 3 phút.

Ý chínhHai sự cố có thật: bốn agent gọi nhau lặp vô hạn trong 11 ngày, có log nhưng không có giới hạn cứng; một ứng dụng tăng từ 100 nghìn lên 900 nghìn người dùng trong vài ngày với hoá đơn hạ tầng tăng theo. Ngân sách hàng tháng ở bảng điều khiển của nhà cung cấp chỉ là thông báo, không chặn chi tiêu. Cách chặn thật là kiểm soát trước khi gọi: đếm token đầu vào, ước tính chi phí lượt gọi với đầu ra tối đa, so với ngân sách còn lại của người dùng hoặc của tháng, từ chối nếu vượt, và gắn nhãn mọi lượt gọi để tính chi phí theo người dùng và tính năng. Giới hạn tần suất và giới hạn ngân sách khác nhau: một người gọi ít lần nhưng mỗi lần rất dài vẫn lọt qua tần suất mà phải bị ngân sách chặn; ngược lại, nhiều lần gọi ngắn bị tần suất chặn dù ngân sách còn nhiều.

Kỹ năngHọc viên viết được hàm guard ước tính chi phí trước khi gọi model, và nêu được một tình huống mỗi cơ chế chặn mà cơ chế kia cho qua.

Hình thứcỞ nhà: video 5 phút, kể hai sự cố rồi đọc từng dòng hàm guard khoảng 10 dòng. Trên lớp: tương tác 3 phút, học viên bật hoặc tắt guard rồi cho một agent chạy vòng lặp gọi lại chính nó, quan sát hoá đơn mô phỏng tăng và điểm dừng. Phương án thay thế: video minh hoạ hoá đơn hai kịch bản.

Ý chính3 câu kiểm tra: mã lỗi khi vượt tần suất; vì sao khoá không được đưa xuống trình duyệt; một tình huống giới hạn ngân sách chặn mà giới hạn tần suất cho qua.

Kỹ năngHọc viên tự kiểm tra ba ý chính trước khối lab về bảo mật.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhNguyên tắc: agent không giữ phiên hội thoại trong bộ nhớ tiến trình mà lưu ra kho ngoài như Redis hoặc Postgres, để bất kỳ instance nào cũng phục vụ được bất kỳ người dùng nào, và khi instance chết hoặc bị thu hồi thì không mất gì. Ví dụ tương phản: bấm nút tạo một ảnh — mỗi request độc lập, xong là xong; hội thoại nhiều lượt với agent — lượt sau cần lịch sử lượt trước. Agent thuộc loại thứ hai nhưng vẫn phải stateless bằng cách đưa state ra ngoài, không phải bỏ nguyên tắc. Phiên dính vào một instance chỉ là nỗ lực tốt nhất của bộ cân bằng tải, không đáng tin. Khi máy chủ khởi động lại mà state nằm trong tiến trình, agent trở về trắng trơn.

Kỹ năngHọc viên chuyển được lịch sử hội thoại từ dict trong tiến trình sang Redis, và giải thích được vì sao dữ liệu trong volume của container chưa phải là giải pháp.

Hình thứcVideo 6 phút, sơ đồ hai kịch bản — state trong từng instance và state ở kho chung — chạy cùng một chuỗi request qua ba instance.

Ý chínhHọc viên gửi 100 request với cùng một mã người dùng vào cụm ba instance sau bộ cân bằng tải và theo dõi độ dài lịch sử hội thoại trả về. Khi lịch sử lưu trong dict của từng tiến trình, con số nhảy lung tung vì mỗi instance chỉ nhớ phần mình nhận; khi lưu ở Redis, con số tăng đều bất kể request rơi vào instance nào. Bước hai: tắt một instance giữa chừng và quan sát lịch sử còn hay mất ở hai kịch bản.

Kỹ năngHọc viên quan sát trực tiếp hậu quả của state sai chỗ và tự rút ra điều kiện để scale ngang.

Hình thứcTương tác mô phỏng 4 phút trên dữ liệu cấu hình sẵn: chọn nơi lưu state, gửi loạt request, xem bảng độ dài lịch sử theo từng instance; dự đoán trước rồi quan sát. Phương án thay thế: video 3 phút ghi kết quả hai kịch bản.

Ý chínhScale dọc là tăng RAM, CPU cho một máy — đơn giản, thường dùng để sửa lỗi khẩn cấp, nhưng phải khởi động lại và có trần phần cứng. Scale ngang là thêm instance sau bộ cân bằng tải — không gián đoạn, gần như không trần, nhưng đòi hỏi stateless. Agent chủ yếu chờ model và tool nên nặng I/O chứ không nặng CPU: một instance có thể đầy request đang chờ mà CPU vẫn thấp, vì thế phải viết bất đồng bộ và tự động mở rộng theo số request đang chờ thay vì theo CPU. Mở rộng theo nhu cầu có độ trễ dựng máy, nên trước giờ cao điểm đã biết trước thì chuẩn bị sẵn một số instance. Luôn đặt trần số instance: một lỗi làm CPU đầy có thể khiến hệ thống tự mở hàng trăm instance và hoá đơn tăng vọt. Kèm ví dụ tự động mở rộng từ 2 lên 20 instance khi CPU vượt 70%.

Kỹ năngHọc viên chọn được scale dọc hay ngang cho từng tình huống, nêu được tín hiệu đúng để tự động mở rộng agent, và giải thích được vì sao phải có trần.

Hình thứcỞ nhà: video 6 phút, biểu đồ số instance theo tải trong một ngày. Trên lớp: tương tác 3 phút, học viên gửi 100 request đồng thời vào 1 instance rồi vào 3 instance và so sánh độ trễ trung vị cùng số request lỗi; bật trần 3 instance rồi bỏ trần để thấy số instance và chi phí mô phỏng thay đổi. Phương án thay thế: video minh hoạ hai biểu đồ độ trễ.

Ý chínhBa loại probe: liveness hỏi "còn sống không", thất bại thì khởi động lại; readiness hỏi "sẵn sàng nhận request chưa", thất bại thì rút khỏi bộ cân bằng tải; startup dành cho ứng dụng khởi động chậm. Gộp hai endpoint làm một và cho nó kiểm tra Redis thì khi Redis mất kết nối 30 giây, cả cụm bị khởi động lại vòng vô ích thay vì chỉ tạm ngưng nhận traffic. Deploy không gián đoạn bốn bước: khởi động bản mới, chờ health pass, chuyển traffic, rút cạn và tắt bản cũ bằng SIGTERM. Ba chiến lược: thay dần từng instance; hai môi trường song song rồi đổi đường dẫn; phát hành cho một phần nhỏ người dùng chọn ngẫu nhiên — ngẫu nhiên để không bỏ sót nhóm dùng đúng tính năng có lỗi. Rollback phải làm được trong dưới 2 phút, gồm cả rollback prompt và phiên bản model chứ không chỉ code.

Kỹ năngHọc viên cấu hình được liveness và readiness đúng vai trò, mô tả được bốn bước deploy không gián đoạn, và nêu được vì sao nhóm phát hành thử phải ngẫu nhiên.

Hình thứcVideo 6 phút, hoạt hình bốn bước với hai instance, sau đó tình huống Redis mất kết nối chạy trên hai cấu hình probe.

Ý chínhBốn mẫu thường dùng khi dịch vụ phía sau lỗi: thử lại với thời gian chờ tăng dần 1, 2, 4 giây rồi dừng — nhưng chỉ với hành động thử lại được, vì gửi email hay trừ tài khoản mà thử lại mù là làm hai lần; ngắt mạch tạm thời khi lỗi liên tiếp để các phần khác không phải chờ timeout; timeout kèm phương án dự phòng; khoá idempotency cho mọi hành động có tác dụng phụ. Ba chỉ số: SLI là thước đo (tỉ lệ thành công, độ trễ P99), SLO là mục tiêu nội bộ, SLA là cam kết với khách hàng — SLA phải thấp hơn SLO vì bộ kiểm thử nội bộ không bao phủ hết thực tế. Kiểm tra độ bền bằng cách tự phá: tắt một instance, tiêm 2 giây trễ giữa các dịch vụ, tắt Redis, và xem hệ thống có tự hồi phục hay ít nhất báo lỗi rõ ràng không.

Kỹ năngHọc viên chọn được mẫu chịu lỗi phù hợp cho một lỗi cụ thể, và giải thích được vì sao SLA thấp hơn SLO.

Hình thứcVideo 6 phút, mỗi mẫu một hoạt hình ngắn; bảng ba chỉ số, mỗi chỉ số một dòng.

Ý chính4 câu kiểm tra: điều kiện để scale ngang; tín hiệu tự động mở rộng phù hợp với agent; readiness thất bại thì hạ tầng làm gì; hành động nào không được thử lại mù.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module.

Hình thứcQuiz 4 câu, chấm ngay.

Ý chínhVòng lặp agent, tool và khoá API thực sự chạy ở đâu quyết định bảo mật, chi phí và quyền riêng tư. Đa số agent production chạy phía server: vòng lặp và khoá nằm ở backend, client chỉ là lớp mỏng gửi tin. Giao diện chạy trong trình duyệt vẫn phải gọi qua backend trung gian giữ khoá. Model nhỏ chạy trên thiết bị hoặc trong trình duyệt mới thật sự không cần khoá, không cần mạng, không tốn chi phí gọi model, đổi lại năng lực hạn chế; kiến trúc lai để model nhỏ lo việc thường và chuyển lên model lớn khi khó. Điện thoại đời mới tăng RAM lên 8–12 GB là để chuẩn bị cho làn sóng này.

Kỹ năngHọc viên xác định được vị trí chạy phù hợp cho agent của mình và nói được khoá API nằm ở đâu trong từng lựa chọn.

Hình thứcVideo 4 phút, bảng năm vị trí theo bốn cột: vòng lặp chạy ở đâu, khoá ở đâu, ai trả chi phí, năng lực.

Ý chínhBốn tầng theo mức tự quản giảm dần: tự quản Kubernetes — toàn quyền, phức tạp; container phục vụ tự mở rộng như Cloud Run, Fargate — timeout từ 60 phút đến không giới hạn, hợp agent; nền tảng đơn giản như Railway, Render — deploy dưới 10 phút, nơi bắt đầu; runtime agent quản lý trọn gói — không phải viết Dockerfile hay lo mở rộng, đổi lại phụ thuộc nhà cung cấp và tốn kém khi tải tăng. Với agent, trục quan trọng nhất khi so sánh là thời gian tối đa một request được chạy, không phải giá: hàm serverless giới hạn 5–15 phút và mất state giữa các lần gọi nên không hợp agent chạy lâu. Nguyên tắc: càng ít phải lo hạ tầng thì chi phí đơn vị càng cao; bắt đầu ở tầng đơn giản, chuyển tầng khi tải thật đòi hỏi. Ba mức lo: tự mua máy thì lo cả điện và mạng, thuê máy ảo thì chỉ lo phần mềm, dùng runtime quản lý thì chỉ quyết định logic.

Kỹ năngHọc viên chọn được tầng nền tảng cho một tình huống cho trước, và giải thích được vì sao timeout là trục so sánh chính với agent.

Hình thứcVideo 6 phút, bốn tầng xếp bậc thang, trục timeout hiện lên như thước đo ngang. Kèm bảng so sánh nền tảng — thời gian chạy tối đa, thu về 0 khi rảnh, hỗ trợ GPU, mức phù hợp agent — dạng PDF, sản xuất tách riêng để cập nhật định kỳ.

Ý chínhNăm bước: kết nối kho mã, nền tảng tự nhận Dockerfile, đặt biến môi trường trên giao diện, bấm deploy, nhận địa chỉ công khai có HTTPS. Điều kiện bắt buộc: ứng dụng đọc cổng từ biến môi trường PORT và lắng nghe trên 0.0.0.0; khai báo đường dẫn health check để nền tảng tự khởi động lại khi lỗi. Bốn lỗi hay gặp: không đọc PORT; sai địa chỉ Redis; health check quá thời gian vì khởi động chậm; image build trên máy chip ARM không chạy trên máy chủ x86. Sau khi có địa chỉ, kiểm tra từ máy khác bằng một lệnh gọi có khoá API và một lệnh gọi không có khoá.

Kỹ năngHọc viên deploy được agent của mình lên một nền tảng, có địa chỉ công khai gọi được từ máy khác, và chẩn đoán được lỗi deploy đầu tiên gặp phải.

Hình thứcỞ nhà: video 6 phút ghi màn hình toàn bộ năm bước, cố tình quên đọc PORT để thấy lỗi và sửa. Trên lớp: học viên tự thực hiện trong lab với người hướng dẫn. Kèm bảng tra cứu lỗi deploy thường gặp và cách sửa, một trang. Phương án thay thế: gộp hẳn vào mốc cuối của lab, không cần phần trên lớp riêng.

Ý chínhDeploy bằng tay sẽ quên bước. Pipeline tự động chạy khi có commit: kiểm tra định dạng và test, build image, quét lỗ hổng image, chạy bộ đánh giá agent, chỉ deploy khi mọi bước xanh. Phần mềm thường chỉ cần test pass; agent còn cần cổng đánh giá vì agent sai vẫn trả lời bình thường chứ không báo lỗi đỏ như code sai — gate deploy theo điểm đánh giá trên bộ câu hỏi chuẩn. Prompt và phiên bản model là artifact deploy, quản lý phiên bản tách khỏi code để rollback độc lập. Kèm workflow GitHub Actions tối thiểu khoảng 15 dòng.

Kỹ năngHọc viên vẽ được pipeline năm bước cho agent và giải thích được vì sao cần cổng đánh giá ngoài test thường.

Hình thứcVideo 6 phút, pipeline hiện dần từng bước, dừng ở bước đánh giá để so sánh test pass và điểm đánh giá tụt. Kèm file workflow mẫu để học viên chép về.

Ý chínhHọc viên mô tả dự án của mình; trợ lý AI hỏi lần lượt về số người dùng dự kiến, yêu cầu nhanh hay chậm, dữ liệu có cần giữ trong nội bộ không, ngân sách và đội ngũ vận hành; sau đó cùng chốt tầng nền tảng, nơi chạy vòng lặp agent, và ba việc phải làm trước khi có người dùng thật. Kết quả là một trang phương án A và B kèm lý do, dùng làm tài liệu nộp cùng lab.

Kỹ năngHọc viên ra được một quyết định deploy có lý do cho chính dự án của mình thay vì chọn theo tên nền tảng.

Hình thứcHội thoại với trợ lý AI theo kịch bản 5 bước, 5 phút, có gợi ý khi cần. Phương án thay thế: biểu mẫu 5 câu tự điền.

Ý chính3 câu kiểm tra: trục so sánh chính giữa các nền tảng với agent; vì sao hàm serverless không hợp agent chạy lâu; bước nào trong pipeline chỉ có ở agent.

Kỹ năngHọc viên tự kiểm tra trước khi vào khối lab cuối.

Hình thứcQuiz 3 câu, chấm ngay.

Ý chínhGiảng viên trả lời câu hỏi mở đầu bằng năm điểm: dùng cùng bộ máy ship của phần mềm truyền thống nhưng định nghĩa lại cách kiểm thử, hoá đơn và dependency; container hai giai đoạn, slim, non-root, dưới 500 MB; state đưa ra ngoài để thêm instance tuỳ ý; bảo vệ trước khi có người dùng thật bằng xác thực, giới hạn tần suất và kiểm soát ngân sách vì ngân sách của nhà cung cấp không tự chặn; chọn nền tảng theo timeout. Giới thiệu Ngày 13: agent đã deploy được ba ngày, độ trễ tăng gấp đôi, chi phí tăng gấp ba — bạn không biết cho đến khi người dùng phàn nàn.

Kỹ năngHọc viên tóm tắt được năm điểm chính bằng ngôn ngữ của mình.

Hình thứcVideo giảng viên, 3 phút.

Ý chínhMột sợi chỉ đỏ: giữ GPU luôn bận và không tính lại KV cache. Gom nhiều request thành một lô như đi xe khách thay vì mỗi người một xe; gom liên tục như thang cuốn thay vì thang máy đợi đủ người; quản KV cache theo khối như hệ điều hành quản bộ nhớ, ví như bãi đỗ xe không cần năm chỗ liền nhau; cache phần đầu prompt chung nên câu hỏi gửi lần hai vừa nhanh vừa ít tốn; model nháp nhỏ đề xuất vài token để model lớn xác minh song song. Giải thích vì sao đặt phần tĩnh lên đầu prompt lại giảm chi phí. Mở rộng cho item 1.3 và 5.3.

Kỹ năngHọc viên giải thích được vì sao cùng câu hỏi gửi lần hai lại nhanh hơn, và thiết kế prompt để tận dụng cache.

Hình thứcVideo 8 phút, mỗi kỹ thuật một ẩn dụ đời thường kèm hoạt hình ngắn.

Ý chínhMCP server cũng là một dịch vụ phải deploy khi nhiều client dùng chung. Hai kênh: stdio chạy cùng máy với agent, lấy khoá từ môi trường, hợp giai đoạn phát triển; Streamable HTTP là một endpoint độc lập phục vụ nhiều client, phải host và bảo vệ như API thật, bắt buộc OAuth 2.1 với PKCE. Mở rộng theo từng MCP server khi một tool được gọi nhiều. Mở rộng cho item 4.2.

Kỹ năngHọc viên chọn được kênh phù hợp và nêu được yêu cầu xác thực khi host MCP từ xa.

Hình thứcVideo 6 phút, sơ đồ hai kênh đối chiếu.

Ý chínhSáu hình dạng agent — chatbot đồng bộ, việc định kỳ, xử lý lô, tự trị chạy mãi, copilot nhúng, theo sự kiện — mỗi hình dạng một cách deploy và một yêu cầu về độ bền của state. Thử lại mù với hành động có tác dụng phụ là làm hai lần; khoá idempotency và cái bẫy riêng của agent khi model không sinh lại tham số y hệt. Thực thi bền bỉ ghi lại quyết định của model để không gọi lại khi khôi phục sau sự cố. Bước không hoàn tác đặt cuối chuỗi và có người duyệt. Sandbox cho agent chạy code, kiểm soát kết nối ra ngoài, mỗi agent một danh tính riêng. Mở rộng cho item 5.5.

Kỹ năngHọc viên nhận ra agent của mình thuộc hình dạng nào và nêu được rủi ro khi thử lại một hành động có tác dụng phụ.

Hình thứcVideo 8 phút, bảng sáu hình dạng và ba hoạt hình ngắn.

Ý chínhKinh nghiệm vận hành qua các tình huống có thật: hai dịch vụ đặt ở hai khu vực địa lý khác nhau làm độ trễ tăng mà tưởng lỗi thuật toán; DNS của bên thứ ba trục trặc làm hệ thống chậm dù mạng hai đầu đều tốt, nên cần DNS dự phòng và cơ chế tự chuyển; phân quyền quá chặt khiến một sự cố chỉ cần sửa một biến môi trường phải chờ đến đầu tuần vì người có quyền vắng mặt — cần người dự phòng và tài liệu hướng dẫn; tự host thì phải tự lo bảo mật, thuê dịch vụ thì có đội bảo mật và cam kết đền bù. Mở rộng cho item 6.2.

Kỹ năngHọc viên liệt kê được ba yếu tố vận hành hay bị bỏ quên khi so sánh phương án deploy.

Hình thứcVideo 6 phút, có phần chia sẻ kinh nghiệm thực tế của giảng viên.

Ý chínhNăm mốc kiểm tra theo thứ tự các module: tách cấu hình theo 12-factor, thêm /health và log JSON; viết Dockerfile hai giai đoạn với user thường, image dưới 500 MB, docker-compose kèm Redis; xác thực bằng khoá API, giới hạn tần suất cửa sổ trượt, kiểm soát ngân sách theo tháng; lưu lịch sử hội thoại ở Redis, thêm /ready, xử lý SIGTERM, chạy ba bản agent sau Nginx; deploy lên Railway hoặc Render và nộp địa chỉ công khai. Mỗi mốc có bộ test tự động chấm, làm được đến đâu có điểm đến đó; kèm 10 câu phản ánh yêu cầu ghi số đo thật, như kích thước hai image và lỗi deploy đầu tiên. Phần thưởng: tự viết workflow GitHub Actions để mỗi lần push tự test, tự build, chỉ deploy khi xanh. Không cần khoá API thật vì lab dùng model giả lập.

Kỹ năngHọc viên có một agent chạy trên địa chỉ công khai, có health check, có khoá API, có kiểm soát ngân sách, và giải thích được từng phần code mình viết.

Hình thứcLab 4 giờ tại lớp với người hướng dẫn, theo repo có sẵn với năm mốc kiểm tra và bộ test tự động; kèm model giả lập, cấu hình Railway và Render mẫu, và phiếu phản ánh 10 câu.