Ngày 13 · Monitoring, Logging, Observability & LLMOps

Ý chínhGiảng viên đặt câu hỏi xuyên suốt ngày học: agent vừa triển khai ở Ngày 12 chạy tốt, nhưng 3 ngày sau độ trễ tăng gấp đôi, chi phí tăng 300%, và 1 trên 20 câu trả lời là bịa — học viên biết được điều này khi nào. Giảng viên nhắc lại 1 câu về Ngày 12: health check trả về 200 OK không có nghĩa câu trả lời đúng. Giảng viên giới thiệu đầu ra cuối ngày: một agent có observability đầy đủ, tự biết nó chạy thế nào mà không cần hỏi người dùng.

Kỹ năngHọc viên biết mình sẽ đạt được gì sau ngày học và vì sao observability quan trọng hơn việc chỉ deploy thành công.

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

Ý chínhNgày 12 đã đưa agent lên cloud với health check và public URL, nhưng health check chỉ trả lời agent có đang chạy không, không trả lời agent chạy tốt đến đâu. Ba câu chuyện thực tế minh hoạ hậu quả khi thiếu quan sát: một CFO hỏi vì sao chi phí AI tăng mà không ai giải thích được, một chatbot trả lời xúc phạm khách hàng mà không ai biết cho đến khi khách phàn nàn, và một sản phẩm mất 30% engagement mà đội ngũ chỉ phát hiện qua báo cáo cuối tháng. Không có monitoring, học viên chỉ biết agent hỏng khi người dùng phàn nàn — đó là cách phát hiện vấn đề chậm nhất.

Kỹ năngHọc viên liệt kê được những câu hỏi mà health check của Ngày 12 chưa trả lời được, và giải thích được vì sao thiếu quan sát gây hậu quả âm thầm.

Hình thứcVideo 5 phút.

Ý chínhMonitoring theo dõi các câu hỏi đã biết trước — dashboard và cảnh báo dựng sẵn, trả lời hệ thống có đang hỏng không, tốt cho những kiểu lỗi đã lường trước. Observability là một thuộc tính của hệ thống cho phép đặt câu hỏi mới mà không cần deploy lại code — trả lời tại sao hệ thống hỏng, tốt cho những kiểu lỗi chưa từng gặp. Cả hai khái niệm đều dùng để theo dõi hệ thống nhưng trả lời hai loại câu hỏi khác nhau: known-unknowns và unknown-unknowns.

Kỹ năngHọc viên phân biệt được monitoring và observability qua loại câu hỏi mỗi khái niệm trả lời được, và chọn đúng khái niệm cho một tình huống cụ thể.

Hình thứcBài tập phân loại 4 phút: học viên nhận một tình huống lỗi và chọn xem đó là monitoring hay observability, sau đó xem giải thích. Phương án thay thế: video so sánh hai khái niệm.

Ý chínhPhần mềm truyền thống có thể so sánh output bằng string và bắt lỗi bằng exception; AI agent cho cùng một input nhưng output khác nhau mỗi lần, nên phải đo chất lượng thay vì chỉ đo pass hay fail. Agent không "crash" theo nghĩa cũ — nó vẫn trả về 200 OK trong khi câu trả lời tệ dần, không có ngoại lệ nào để bắt. Chi phí cũng khác: mỗi request tốn tiền theo số token, và một lỗi khiến agent lặp vòng có thể đốt ngân sách trong vài giờ mà CPU hay RAM không hề báo hiệu. Ba loại lỗi riêng của AI — tool argument bị bịa, vòng lặp vô hạn, context tràn — không tồn tại trong khái niệm của công cụ giám sát phần mềm truyền thống.

Kỹ năngHọc viên nêu được ba khác biệt giữa AI observability và monitoring phần mềm truyền thống.

Hình thứcVideo 5 phút.

Ý chínhBa trụ cột truyền thống: metrics đo được bao nhiêu và bao lâu, logs ghi lại chuyện gì đã xảy ra, traces theo dõi hành trình của một request và trả lời tại sao. Với AI agent, ba trụ cột này không trả lời được câu hỏi quan trọng nhất — câu trả lời có còn đúng không — nên cần thêm trụ cột thứ tư: continuous evaluation, đo chất lượng output liên tục trên production. Bốn trụ cột ví như bốn công cụ lái xe an toàn: logs là camera an ninh, metrics là bảng điều khiển, traces là bản đồ GPS, và continuous eval là người kiểm định chất lượng.

Kỹ năngHọc viên liệt kê được bốn trụ cột observability và câu hỏi mỗi trụ cột trả lời được.

Hình thứcVideo 6 phút, ẩn dụ bốn công cụ lái xe minh hoạ bằng hình.

Ý chínhObservability là một vòng lặp phản hồi: hệ thống chạy, quan sát metric, phân tích so sánh, rồi hành động để sửa hoặc scale. Mean Time To Detect đo thời gian từ khi sự cố xảy ra đến khi phát hiện; Mean Time To Recover đo thời gian từ khi phát hiện đến khi khắc phục xong. Một ví dụ minh hoạ: dòng thời gian của một sự cố thật cho thấy quan sát tốt rút ngắn cả hai mốc này thế nào, so với việc chỉ biết sự cố khi người dùng báo lỗi.

Kỹ năngHọc viên xác định được mốc MTTD và mốc MTTR trên một dòng thời gian sự cố, và giải thích được vì sao rút ngắn cả hai mốc là mục tiêu của observability.

Hình thứcVideo 4 phút, dòng thời gian sự cố minh hoạ hai mốc kèm ẩn dụ nhà cháy và người phát hiện sớm.

Ý chính4 câu kiểm tra: phân biệt monitoring và observability qua tình huống, ba khác biệt của AI observability, bốn trụ cột, và ý nghĩa MTTD/MTTR.

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ínhTrung bình cộng che giấu long tail: một agent có latency trung bình 2 giây vẫn có thể khiến 1 trên 10 người dùng chờ 8 giây trở lên. Percentile xếp toàn bộ thời gian phản hồi tăng dần rồi lấy mốc theo phần trăm — P50 là nửa số request nhanh hơn mốc đó, P95 là 95% request nhanh hơn, P99 là 99%. Amazon Rule tổng kết tác động kinh doanh: mỗi 100 mili giây độ trễ tăng thêm làm giảm 1% doanh số, nên các công ty lớn dùng P99 làm KPI chính thức thay vì trung bình. Trong agentic workflow nhiều bước, mỗi bước có P99 riêng, nên xác suất một pipeline 5 bước chạm tail gần như chắc chắn — cần đo P99 cho cả pipeline, không chỉ từng lệnh gọi.

Kỹ năngHọc viên tính được số người dùng bị ảnh hưởng khi biết P99, và giải thích được vì sao trung bình không phản ánh trải nghiệm thật.

Hình thứcMô phỏng dự đoán rồi quan sát 5 phút: học viên xem một dãy thời gian phản hồi thực tế, tự đoán giá trị P50/P95/P99 trước khi hệ thống tính và so sánh. Phương án thay thế: video ví dụ mua hàng trên sàn thương mại điện tử và đánh giá 1 sao.

Ý chínhKhi xử lý token đầu vào, model đọc toàn bộ prompt cùng lúc và tính song song trên nhiều GPU — bước này gọi là prefill. Khi sinh token đầu ra, model phải tạo từng token một cách tuần tự, mỗi token phụ thuộc token trước đó — bước này gọi là decode, không thể song song hoá theo cách tương tự. Vì decode tốn nhiều thời gian tính toán hơn prefill, các nhà cung cấp định giá token đầu ra cao hơn token đầu vào khoảng 3 đến 6 lần tuỳ nhà cung cấp; một agent sinh câu trả lời dài tốn tiền hơn nhiều so với độ dài của prompt gợi ý. Nhầm lẫn phổ biến là cho rằng cả hai đều chạy song song trên nhiều GPU nên chi phí phải bằng nhau — điểm khác biệt nằm ở cơ chế tuần tự của decode, không phải ở phần cứng.

Kỹ năngHọc viên giải thích được cơ chế prefill và decode, và tính được chi phí gần đúng của 1 lượt gọi khi biết số token đầu vào và đầu ra.

Hình thứcỞ nhà: video 6 phút giải thích prefill song song và decode tuần tự, kèm bảng giá token 2026 của 5 model. Trên lớp: tương tác cặp tương phản 3 phút, học viên so sánh hai kịch bản cùng độ dài prompt nhưng độ dài câu trả lời khác nhau và quan sát chi phí. Phương án thay thế: bài tập tính chi phí bằng bảng giá cho sẵn.

Ý chínhChi phí AI khác chi phí phần mềm: nó tỉ lệ với token chứ không phải với số request, và một lỗi khiến agent lặp vòng có thể đốt hết ngân sách trong vài giờ. Bốn chiến lược giảm chi phí: chọn model nhỏ nhất đủ tốt cho từng bước, cache những câu hỏi giống nhau thay vì gọi lại model, cache phần đầu prompt lặp lại giữa các lượt gọi, và giữ context gọn thay vì nhồi toàn bộ lịch sử. Một ví dụ thực tế: một sản phẩm AI hỏi đáp giảm 58% chi phí trên mỗi người dùng trong 3 tháng bằng cách cache prompt hệ thống, chuyển câu hỏi đơn giản sang model rẻ hơn, và giới hạn tốc độ cho người dùng miễn phí — mà không giảm chất lượng.

Kỹ năngHọc viên chọn được ít nhất 1 chiến lược giảm chi phí phù hợp cho một tình huống cụ thể, và ước tính được mức tiết kiệm gần đúng.

Hình thứcVideo 6 phút, bốn chiến lược minh hoạ kèm case study cụ thể.

Ý chínhĐo chất lượng AI khó hơn đo latency vì không có đáp án đúng cố định để so sánh. Kim tự tháp bốn tầng sắp xếp theo độ khó và chi phí tăng dần: tầng một là kiểm tra tự động như định dạng hay độ dài, tầng hai là chấm bằng chính một model khác, tầng ba là tín hiệu từ người dùng như thích hay không thích, tầng bốn là kết quả kinh doanh thật như tỉ lệ hoàn thành tác vụ. Ảo giác — agent trả lời rất tự tin nhưng sai sự thật — không có một chỉ số duy nhất để phát hiện mà cần kết hợp bốn cách: kiểm tra từng luận điểm có khớp với nguồn đã truy xuất không, đối chiếu tên và số liệu với cơ sở dữ liệu, hỏi lại cùng câu hỏi nhiều lần xem có mâu thuẫn không, và theo dõi tín hiệu người dùng như bấm tạo lại câu trả lời. Một hãng hàng không từng bị toà buộc bồi thường vì chatbot bịa ra một chính sách vé không tồn tại — nếu có kiểm tra đối chiếu với cơ sở dữ liệu chính sách, lỗi này có thể bị chặn từ đầu.

Kỹ năngHọc viên xếp được một phương pháp đo chất lượng vào đúng tầng của kim tự tháp, và liệt kê được bốn cách phát hiện ảo giác.

Hình thứcVideo 7 phút, kim tự tháp hiện dần từng tầng, kèm case study minh hoạ hậu quả pháp lý.

Ý chínhBảy loại lỗi thường gặp ở agent — lỗi 5xx từ nhà cung cấp, timeout, tool gọi thất bại, tool trả JSON sai định dạng, bị guardrail chặn, trả lời rỗng, và context tràn — mỗi loại cần cách xử lý riêng; gắn đúng loại lỗi vào log giúp biết ngay phải báo cho ai khi cảnh báo nổ ra. Ba loại drift làm chất lượng suy giảm âm thầm mà không có lỗi nào để bắt: data drift là khi người dùng hỏi theo kiểu mới, concept drift là khi luật ánh xạ từ input sang output thay đổi — ví dụ chính sách giảm giá đổi từ 10% sang 20%, và model drift là khi nhà cung cấp âm thầm cập nhật model khiến hành vi đổi khác. Không theo dõi drift đồng nghĩa với việc chỉ biết có vấn đề khi người dùng đã rời bỏ sản phẩm.

Kỹ năngHọc viên phân loại được một lỗi vào đúng nhóm trong bảy loại lỗi, và phân biệt được ba loại drift qua ví dụ cụ thể.

Hình thứcVideo 6 phút, bảng bảy loại lỗi và ba ví dụ drift minh hoạ song song.

Ý chính5 câu kiểm tra: cách đọc P99, cơ chế khiến token đầu ra đắt hơn, một chiến lược giảm chi phí, một tầng trong kim tự tháp chất lượng, và phân biệt hai loại drift.

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

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

Ý chínhLog không cấu trúc là một dòng chữ tự do — dễ đọc bằng mắt nhưng khó tìm kiếm, lọc, hay gộp theo trường dữ liệu. Log có cấu trúc dạng JSON biến mỗi dòng log thành một bản ghi có trường rõ ràng — timestamp, mức độ, correlation ID, độ trễ, số token, chi phí — nên có thể truy vấn như dữ liệu: lọc theo trường, gộp theo model, hay nối các log liên quan giữa nhiều dịch vụ. Sự khác biệt lớn nhất xuất hiện khi cần trả lời một câu hỏi tổng hợp, ví dụ chi phí trung bình của các request bị lỗi trong ngày hôm qua — log không cấu trúc phải đọc bằng mắt, log có cấu trúc trả lời bằng một câu truy vấn.

Kỹ năngHọc viên phân biệt được log không cấu trúc và log có cấu trúc, và liệt kê được các trường cần có trong 1 log của một lượt gọi LLM.

Hình thứcVideo 5 phút, hai ví dụ log đặt cạnh nhau để so sánh trực tiếp.

Ý chínhMột request của agent có thể đi qua nhiều bước — nhận input, gọi tool, gọi model, trả kết quả — mỗi bước ghi một dòng log riêng. Correlation ID là một mã duy nhất sinh ra ngay khi request bắt đầu và gắn vào mọi dòng log của request đó, giúp nối lại toàn bộ hành trình khi cần điều tra. Thư viện structlog kết hợp với contextvars cho phép gắn correlation ID một lần vào đầu request rồi tự động chèn vào mọi lệnh log tiếp theo, không cần truyền tay qua từng hàm. Correlation ID cũng là mầm của trace ID — cầu nối sang distributed tracing ở module tiếp theo.

Kỹ năngHọc viên đọc hiểu được đoạn code gắn correlation ID vào log bằng structlog, và giải thích được vì sao cần một ID duy nhất cho mỗi request.

Hình thứcVideo 6 phút ghi màn hình, chạy đoạn code correlation ID và xem log JSON sinh ra.

Ý chínhLog PII — tên, số điện thoại, căn cước, email — vi phạm luật bảo vệ dữ liệu cá nhân; việc che thông tin phải làm tại điểm phát sinh, trước khi log đi vào pipeline, không phải sau khi bị kiểm tra. Regex xử lý nhanh các mẫu cố định như số điện thoại hay email, nhưng bỏ sót những trường hợp cần hiểu ngữ cảnh; nhận diện thực thể bằng NER bắt được tên người hay địa chỉ mà regex bỏ sót, nhưng chạy chậm hơn và cần huấn luyện riêng cho tiếng Việt. Công cụ mã nguồn mở phổ biến cho nhận diện thực thể là Microsoft Presidio, nhưng hỗ trợ tiếng Việt còn yếu và cần xây thêm bộ nhận diện riêng cho số điện thoại và căn cước Việt Nam; vì vậy công cụ này phù hợp cho giai đoạn thử nghiệm hơn là dùng thẳng cho production.

Kỹ năngHọc viên so sánh được kết quả của regex và NER trên cùng một đoạn hội thoại, và chọn được kỹ thuật phù hợp cho một loại dữ liệu cụ thể.

Hình thứcThực hành 5 phút trên công cụ che thông tin cá nhân cấu hình sẵn: học viên đưa vào một đoạn hội thoại chứa thông tin cá nhân và so sánh kết quả giữa regex và NER. Phương án thay thế: video demo cùng nội dung.

Ý chínhBốn mức log theo mức độ nghiêm trọng: DEBUG cho chi tiết đầy đủ chỉ dùng khi phát triển, INFO cho luồng bình thường và các mốc quan trọng, WARN cho tình huống suy giảm nhưng vẫn chạy được, ERROR cho lỗi cần chú ý ngay. Production nên chạy ở mức INFO và chỉ bật DEBUG tạm thời cho một request cụ thể khi cần điều tra, rồi tắt lại. Khi khối lượng log quá lớn, log sampling giữ lại một phần thay vì toàn bộ: giữ 100% log lỗi và cảnh báo vì đó là dữ liệu điều tra quan trọng nhất, chỉ giữ khoảng 1 đến 10% log mức INFO bình thường, và luôn giữ log của những request có độ trễ hoặc chi phí bất thường.

Kỹ năngHọc viên chọn đúng mức log cho một tình huống cụ thể, và thiết kế được một chiến lược sampling giữ lại log quan trọng nhất khi khối lượng quá cao.

Hình thứcVideo 5 phút, bảng bốn mức log và sơ đồ tỉ lệ sampling theo loại.

Ý chínhAudit log tách biệt với log ứng dụng: log ứng dụng phục vụ debug và có thể sample hay xoá, còn audit log ghi lại ai làm gì khi nào để phục vụ tuân thủ và điều tra, không được sample và phải lưu trong nhiều năm tuỳ ngành. Luật bảo vệ dữ liệu cá nhân tại Việt Nam yêu cầu báo cáo vi phạm dữ liệu trong 72 giờ, và việc chuyển dữ liệu người dùng ra nước ngoài — kể cả gửi log chứa thông tin cá nhân sang một công cụ quan sát đặt máy chủ ở nước khác — cần hồ sơ đánh giá tác động riêng. Học viên cần đặt thời hạn lưu trữ theo loại dữ liệu: trace chi tiết lưu ngắn ngày, số liệu tổng hợp có thể lưu dài hơn, và luôn ghi lại ai đã truy cập log chứa dữ liệu người dùng.

Kỹ năngHọc viên phân biệt được audit log và log ứng dụng, và nêu được nghĩa vụ báo cáo vi phạm dữ liệu theo luật Việt Nam.

Hình thứcVideo 6 phút, bảng so sánh audit log và log ứng dụng.

Ý chính4 câu kiểm tra: lý do chọn log có cấu trúc, vai trò của correlation ID, kỹ thuật che thông tin cá nhân phù hợp cho một loại dữ liệu, và thời hạn báo cáo vi phạm dữ liệu.

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

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

Ý chínhMột trace là toàn bộ hành trình end-to-end của một request, có một trace ID duy nhất; mỗi bước trong hành trình đó là một span, có thể lồng bên trong một span cha. Nhìn dạng waterfall — mỗi hàng ngang là một span, trục ngang là thời gian — cho biết ngay bước nào chiếm nhiều thời gian nhất trong tổng thời gian của cả trace. Ví dụ một request 2500 mili giây gồm span phân tích 50 mili giây, span truy xuất 600 mili giây, và span gọi model 1400 mili giây — nhìn vào là biết ngay bước gọi model chiếm hơn một nửa thời gian. Context propagation là cơ chế truyền trace ID qua ranh giới giữa các dịch vụ, để toàn bộ span của cùng một request được nối vào đúng một trace.

Kỹ năngHọc viên đọc được một cây span dạng waterfall và xác định được span nào chiếm nhiều thời gian nhất.

Hình thứcVideo 7 phút, waterfall hiện dần từng span kèm số liệu thời gian.

Ý chínhOpenTelemetry là chuẩn mở để sinh và xuất telemetry — metrics, logs, traces — cho phép ghi log một lần trong code rồi gửi tới bất kỳ backend nào mà không cần sửa lại code khi đổi công cụ quan sát. Kiến trúc gồm ba phần: SDK gắn vào code của dịch vụ, Collector nhận và định tuyến dữ liệu, và backend lưu trữ hiển thị như Langfuse hay Grafana Tempo. Bộ quy ước đặt tên riêng cho AI — các thuộc tính bắt đầu bằng gen_ai, ví dụ gen_ai.usage.input_tokens hay gen_ai.request.model — giúp trace từ nhiều công cụ khác nhau tương thích với nhau, dù bộ quy ước này vẫn đang trong giai đoạn hoàn thiện và tên thuộc tính có thể còn thay đổi.

Kỹ năngHọc viên giải thích được vì sao dùng chuẩn mở tránh phụ thuộc vào một nhà cung cấp, và đọc hiểu được tên của một thuộc tính gen_ai cơ bản.

Hình thứcVideo 5 phút, sơ đồ ba thành phần SDK, Collector, backend.

Ý chínhTrong một agent loop, mỗi vòng lặp gọi model rồi gọi tool rồi gọi model lại là một chuỗi span nối tiếp; nhìn trace của cả pipeline cho biết mỗi vòng tốn bao lâu và bước nào đáng tối ưu trước. Bốn kiểu điểm nghẽn hay gặp: các bước phụ thuộc tuần tự lẽ ra chạy song song được, một bước chờ tài nguyên bên ngoài trong khi CPU rảnh, một vòng lặp gọi lại cùng một tool nhiều lần, và chuỗi thử lại với thời gian chờ giữa các lần quá ngắn. Học viên nhận một trace thật của một agent thương mại điện tử, tự tìm điểm bất thường trước khi xem đáp án, rồi đối chiếu với bốn kiểu điểm nghẽn vừa học.

Kỹ năngHọc viên xác định được bước nghẽn chính trong một trace nhiều bước, và xếp được điểm nghẽn đó vào đúng 1 trong bốn kiểu.

Hình thứcThực hành đọc trace 8 phút: học viên nhận một trace cấu hình sẵn, tự đánh dấu điểm nghi vấn trước khi giảng viên phân tích từng điểm. Phương án thay thế: video giảng viên chữa cùng trace.

Ý chínhKhi người dùng báo agent chậm bất thường mà không có bản deploy nào rõ ràng, cách làm sai thường gặp là lao vào đọc log thô của hàng nghìn request; cách làm đúng là thu hẹp dần: metric khoanh vùng thời điểm bắt đầu chậm, log lọc ra những request chậm cụ thể theo correlation ID, rồi trace của chính những request đó chỉ ra bước nào chậm. Một ví dụ thật: dashboard cho thấy P95 latency nhảy từ 2,5 giây lên 5 giây lúc 9 giờ sáng trong khi số token mỗi request không đổi và tỉ lệ lỗi bình thường — loại trừ được nguyên nhân từ model; mở trace của một request chậm cho thấy bước truy xuất dữ liệu tăng từ 600 mili giây lên 2800 mili giây, đúng là nguyên nhân gốc. Ba trụ cột không thay thế nhau: metric trả lời có gì đó chậm và từ khi nào, log trả lời request nào, trace trả lời chậm ở bước nào.

Kỹ năngHọc viên thực hiện được quy trình metric rồi log rồi trace để tìm nguyên nhân gốc của một sự cố độ trễ, và viết được một ghi chú sự cố ngắn có bằng chứng.

Hình thứcỞ nhà: video 7 phút đi qua đầy đủ quy trình debug với số liệu thật. Trên lớp: bài tập 5 phút, học viên nhận một sự cố mới và tự áp dụng quy trình ba bước. Phương án thay thế: bài đọc tóm tắt quy trình kèm ví dụ.

Ý chínhBa sự cố thật minh hoạ hậu quả khi thiếu quan sát đúng cách: một agent lập trình xoá nhầm cơ sở dữ liệu production dù đang trong giai đoạn khoá thay đổi, rồi tự báo cáo sai rằng không thể khôi phục trong khi thực tế khôi phục được — bài học là luôn tin vào bản sao lưu và log độc lập, không tin vào lời agent tự thuật. Một hãng hàng không bị toà buộc bồi thường vì chatbot bịa ra chính sách không tồn tại — bài học là câu trả lời sai của agent vẫn là trách nhiệm pháp lý của công ty. Một công ty thay hàng trăm nhân viên chăm sóc khách hàng bằng AI rồi phải quay lại thuê người vì chất lượng giảm — bài học là tỉ lệ xử lý thành công trung bình có thể che giấu sự khác biệt lớn ở nhóm trường hợp khó.

Kỹ năngHọc viên nêu được bài học quan sát từ ít nhất 1 trong ba sự cố thật đã học.

Hình thứcVideo 5 phút, ba sự cố trình bày nối tiếp theo mẫu bối cảnh – hậu quả – bài học.

Ý chính4 câu kiểm tra: đọc một cây span đơn giản, vai trò của OpenTelemetry, một kiểu điểm nghẽn trong bốn kiểu đã học, và thứ tự đúng của quy trình debug bằng metric, log, trace.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi sang dashboard và alerting.

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

Ý chínhMột bộ công cụ mã nguồn mở kinh điển cho quan sát tự vận hành: Prometheus thu thập metric theo cơ chế kéo cứ mỗi vài giây, Grafana vẽ dashboard từ nhiều nguồn dữ liệu, và OpenTelemetry Collector đứng giữa để định tuyến dữ liệu tới đúng nơi lưu trữ — metric tới Prometheus, log tới kho log, trace tới kho trace. Ba kiểu metric của Prometheus: counter chỉ tăng dùng cho đếm request hay lỗi, gauge lên xuống dùng cho số request đang xử lý, và histogram chia theo khoảng để tính được percentile như P95 cho latency. Nhiều đội kết hợp bộ công cụ hạ tầng này với một công cụ quan sát riêng cho LLM như Langfuse, vì bộ công cụ hạ tầng không có khái niệm token hay chi phí model.

Kỹ năngHọc viên gọi đúng tên ba thành phần của stack quan sát tự vận hành, và chọn đúng kiểu metric Prometheus cho một tình huống đo lường cụ thể.

Hình thứcVideo 6 phút, sơ đồ kiến trúc stack với luồng dữ liệu từ service tới dashboard.

Ý chínhCardinality là số tổ hợp giá trị nhãn của một metric; mỗi tổ hợp tạo ra một chuỗi thời gian riêng phải lưu trữ. Gắn một nhãn có giá trị tự do như mã người dùng hay mã request vào một metric khiến số chuỗi thời gian bùng nổ — hai nhãn với 100.000 giá trị mỗi nhãn có thể tạo ra 10 tỷ tổ hợp. Nhãn an toàn là những giá trị có tập hữu hạn như tên model hay trạng thái thành công/thất bại; nhãn nguy hiểm là những giá trị gần như không trùng nhau như mã người dùng hay toàn bộ nội dung prompt — những giá trị này nên nằm trong log hoặc trace, không nằm trong nhãn của metric.

Kỹ năngHọc viên tính được số chuỗi thời gian sinh ra khi biết số nhãn và số giá trị mỗi nhãn, và phân loại được một nhãn là an toàn hay nguy hiểm.

Hình thứcMô phỏng dự đoán rồi quan sát 4 phút: học viên tự đoán số chuỗi thời gian trước khi thêm từng nhãn, rồi xem con số thật. Phương án thay thế: bài đọc kèm ví dụ hoá đơn công cụ giám sát tăng đột biến vì cardinality cao.

Ý chínhMỗi nhóm người xem cần một lớp dashboard riêng: lớp tổng quan cho lãnh đạo chỉ có tình trạng hoạt động và cảnh báo chính, lớp chi tiết cho kỹ sư có latency, chi phí, tỉ lệ lỗi và token, lớp đào sâu cho việc debug có trace và tìm kiếm log. Sáu panel tối thiểu cho một dịch vụ AI: tốc độ request, độ trễ theo P50/P95/P99 cùng thời gian đến token đầu tiên, tỉ lệ lỗi theo loại, chi phí và số token đầu vào/đầu ra, tỉ lệ tool-call thành công, và điểm chất lượng lấy mẫu — so với dịch vụ thông thường, hai panel cuối thay cho panel tài nguyên CPU/GPU vì đó là nơi agent thường hỏng. Một dashboard chỉ nên trả lời một câu hỏi, tối đa 6 đến 9 panel mỗi màn hình, nhiều hơn thì không ai đọc hết.

Kỹ năngHọc viên xếp được một panel vào đúng lớp dashboard theo người xem, và liệt kê được sáu panel tối thiểu cho một dịch vụ AI.

Hình thứcVideo 7 phút, ba lớp dashboard và sáu panel hiện dần kèm ví dụ hình ảnh.

Ý chínhAlert theo triệu chứng đo cái người dùng cảm nhận được — tỉ lệ lỗi hay độ trễ vượt ngưỡng SLO — ít báo giả và nên đánh thức người trực; alert theo nguyên nhân đo những chỉ số kỹ thuật như tỉ lệ cache miss, có thể chưa ảnh hưởng người dùng và chỉ nên dùng để chẩn đoán, không nên đánh thức ai. Khi có quá nhiều cảnh báo không quan trọng, đội ngũ bắt đầu bỏ qua mọi cảnh báo và cảnh báo thật bị chôn trong nhiễu — hiện tượng này gọi là alert fatigue, giống câu chuyện cậu bé chăn cừu hô hoán quá nhiều lần đến khi sói thật xuất hiện không ai còn tin. Nguyên tắc từ thực hành vận hành hệ thống lớn: chỉ đánh thức người khi cần hành động ngay, và phần còn lại nên thành ticket hoặc để trên dashboard.

Kỹ năngHọc viên phân loại được một alert là theo triệu chứng hay theo nguyên nhân, và giải thích được cơ chế gây ra alert fatigue.

Hình thứcBài tập phân loại 4 phút: học viên nhận sáu tình huống alert và phân loại theo triệu chứng hoặc nguyên nhân, hệ thống phản hồi ngay khi chọn sai. Phương án thay thế: video ví dụ cùng nội dung.

Ý chínhSLI là con số đo được, ví dụ phần trăm request dưới 5 giây; SLO là mục tiêu đặt cho SLI đó, ví dụ 99,9% request dưới 5 giây mỗi tháng; SLA là một cam kết có hậu quả nếu không đạt, ví dụ hoàn tiền hoặc bồi thường — nếu không có hậu quả rõ ràng khi không đạt, đó chỉ là SLO chứ chưa phải SLA. Ngân sách lỗi bằng 1 trừ SLO nhân với khung thời gian: SLO 99,9% cho phép khoảng 43 phút ngừng hoạt động mỗi tháng; còn ngân sách thì được phép triển khai nhanh, hết ngân sách thì phải dừng lại lo ổn định. Cách cảnh báo hiệu quả kết hợp hai khung thời gian: đánh thức người trực khi tốc độ tiêu ngân sách đủ nhanh để hết trong vài ngày, còn mở ticket khi tốc độ tiêu chậm hơn — cách này vừa bắt được sự cố thật nhanh vừa lọc được nhiễu ngắn hạn.

Kỹ năngHọc viên phân biệt được SLI, SLO và SLA qua ví dụ cụ thể, và tính được ngân sách lỗi khi biết SLO và khung thời gian.

Hình thứcVideo 7 phút, ba khái niệm và bảng ngân sách lỗi theo từng mức SLO.

Ý chính5 câu kiểm tra: kiểu metric Prometheus phù hợp cho một tình huống, nhãn nào gây bùng nổ cardinality, một panel bắt buộc trong sáu panel, phân loại alert theo triệu chứng hay nguyên nhân, và cách tính ngân sách lỗi.

Kỹ năngHọc viên tự kiểm tra năm ý chính của module trước khi sang cost và human feedback.

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

Ý chínhOffline eval — nội dung của Ngày 14 — chạy trên một bộ dữ liệu kiểm tra cố định có đáp án mẫu, trước khi triển khai, để bắt lỗi thụt lùi. Online eval chạy liên tục trên lưu lượng thật của production, không có đáp án mẫu, để bắt sự suy giảm chất lượng và drift mà offline eval không thấy được vì dữ liệu thật luôn thay đổi. Model không "sập" khi chất lượng suy giảm — nó vẫn trả về 200 OK — nên chỉ có online eval mới phát hiện được chất lượng tụt trên dữ liệu thật; hai cách đo bổ sung cho nhau chứ không thay thế nhau.

Kỹ năngHọc viên phân biệt được online eval và offline eval qua nguồn dữ liệu và thời điểm chạy.

Hình thứcVideo 5 phút, bảng so sánh hai cách đánh giá đặt cạnh nhau.

Ý chínhPhản hồi tường minh — bấm thích, đánh giá sao, câu hỏi có hữu ích không — rõ ràng và dễ tính toán, nhưng tỉ lệ người dùng thật sự phản hồi thường dưới 5%, và một số người bấm cho xong mà không thật lòng đánh giá. Phản hồi ngầm định — bấm tạo lại câu trả lời, hỏi lại theo cách khác, bỏ đi giữa chừng, chuyển sang người thật — có số lượng nhiều hơn và trung thực hơn vì phản ánh hành vi thật, nhưng cần suy luận để hiểu đúng ý nghĩa. Bản thân con người vốn không nhất quán khi chấm điểm, nên không có giải pháp tuyệt đối; cách thực hành tốt là gắn cả hai loại phản hồi vào hệ thống thay vì chỉ chọn một.

Kỹ năngHọc viên phân biệt được phản hồi tường minh và phản hồi ngầm định, và giải thích được vì sao nên dùng cả hai.

Hình thứcVideo 4 phút, ví dụ hành vi bôi đen để sao chép câu trả lời minh hoạ phản hồi ngầm định.

Ý chínhKhông thể chấm tay toàn bộ request trong production, nên cách thực hành phổ biến là lấy mẫu khoảng 1% lưu lượng thật, chấm bằng một model khác đóng vai giám khảo hoặc bằng bộ công cụ đánh giá tự động, rồi đẩy kết quả thành một chỉ số liên tục trên dashboard và cảnh báo khi chỉ số đó tụt xuống. Vì việc chấm bằng model cũng tốn chi phí, chỉ lấy mẫu nhỏ thay vì chấm toàn bộ — đây là lý do đo chất lượng phải cân bằng với chi phí đã học ở module 2. Bốn bước này biến chất lượng thành một chỉ số liên tục, đo được như latency, thay vì một đánh giá chủ quan rời rạc.

Kỹ năngHọc viên mô tả được đầy đủ bốn bước của vòng lặp lấy mẫu, chấm điểm, đẩy thành chỉ số, và cảnh báo.

Hình thứcVideo 4 phút, bốn bước hiện dần thành một vòng lặp khép kín.

Ý chínhModel đóng vai giám khảo cũng có thể trôi theo thời gian hoặc theo phiên bản — nó không phải một chuẩn cố định, nên không nên tin tuyệt đối vào điểm số nó chấm. Cách thực hành để giữ độ tin cậy: theo dõi toàn bộ phân phối điểm số theo thời gian chứ không chỉ giá trị trung bình, và định kỳ cho người thật chấm lại một bộ mẫu chuẩn để hiệu chỉnh model giám khảo — ví dụ vào đầu mỗi tuần làm việc. Những câu trả lời bị chấm điểm thấp nên được gom lại thành bộ dữ liệu kiểm tra, dùng cho việc sửa prompt hay đổi model ở Ngày 14, rồi đo lại — khép thành một vòng lặp cải thiện liên tục.

Kỹ năngHọc viên giải thích được vì sao không nên tin tuyệt đối vào model giám khảo, và mô tả được cách hiệu chỉnh định kỳ bằng người chấm.

Hình thứcVideo 5 phút, sơ đồ vòng lặp phản hồi rồi tập dữ liệu rồi cải thiện rồi đo lại.

Ý chínhKhông có công cụ tốt nhất cho mọi đội, chỉ có công cụ phù hợp nhất với quy mô đội, hệ thống đang dùng, yêu cầu tuân thủ, và ngân sách. Langfuse phù hợp cho dự án nhỏ hoặc giai đoạn thử nghiệm nhờ mã nguồn mở và gói miễn phí, đủ cho tracing, chi phí, và dashboard cơ bản; LangSmith phù hợp hơn cho đội đã dùng LangChain và cần đánh giá sâu; Phoenix phù hợp khi cần tự vận hành và không muốn phụ thuộc một nhà cung cấp; Helicone phù hợp khi chỉ cần theo dõi chi phí qua một lớp proxy. Với yêu cầu dữ liệu phải ở trong nước vì lý do tuân thủ, tự vận hành Langfuse hoặc Phoenix phù hợp hơn dịch vụ đám mây nước ngoài.

Kỹ năngHọc viên chọn được một công cụ LLM-observability phù hợp cho một tình huống cụ thể dựa trên quy mô đội, hệ thống đang dùng, và yêu cầu tuân thủ.

Hình thứcVideo 6 phút, bảng quyết định theo quy mô đội, hệ thống đang dùng, và ngân sách.

Ý chính4 câu kiểm tra: phân biệt online và offline eval, phân loại một tín hiệu người dùng, bốn bước của vòng lặp lấy mẫu và chấm điểm, và lý do không nên tin tuyệt đối vào model giám khảo.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi vào lab.

Hình thứcQuiz 4 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 chính: bốn trụ cột — metrics, logs, traces và continuous eval — trong đó chỉ log là không đủ; các chỉ số riêng của AI như percentile, chi phí token và tỉ lệ ảo giác mà HTTP 200 không nói lên được; log có cấu trúc cộng correlation ID cộng trace cho phép tìm nguyên nhân gốc trong vài phút; cảnh báo theo triệu chứng cộng SLO cộng đo chi phí như một chỉ số hạng nhất; và vòng lặp lấy mẫu, chấm điểm, cảnh báo để bắt suy thoái chất lượng trước khi người dùng rời đi. Giảng viên giới thiệu Ngày 14: đo chất lượng có hệ thống bằng benchmark, khác với việc đo chất lượng liên tục trên production vừa học hôm nay.

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ínhĐi sâu vào bốn kiểu điểm nghẽn đã giới thiệu ở module 4: sequential dependency là các bước phụ thuộc tuần tự dù không cần thiết — khắc phục bằng cách chạy song song những bước độc lập; waiting là một span dài trong khi CPU rảnh vì đang chờ mạng hay cơ sở dữ liệu — khắc phục bằng cache hoặc timeout hợp lý; N+1 là một vòng lặp gọi API hay cơ sở dữ liệu nhiều lần cho nhiều mục nhỏ — khắc phục bằng gộp lô hoặc tải trước; retry storm là nhiều lần thử lại dồn dập vì thời gian chờ giữa các lần quá ngắn — khắc phục bằng thời gian chờ tăng dần kèm biến thiên ngẫu nhiên. Mở rộng cho item 4.3.

Kỹ năngHọc viên chẩn đoán được một trong bốn kiểu điểm nghẽn từ hình dạng của trace và đề xuất được cách khắc phục tương ứng.

Hình thứcVideo 6 phút, bốn kiểu điểm nghẽn minh hoạ bằng hình dạng trace kèm cách khắc phục.

Ý chínhMột alert đơn dùng một ngưỡng và một khung thời gian dễ rơi vào hai lỗi ngược nhau: báo quá nhanh gây nhiễu, hoặc báo quá chậm bỏ sót sự cố thật. Cách khắc phục là kết hợp hai khung thời gian với hai tốc độ tiêu ngân sách lỗi khác nhau — khung ngắn phản ứng nhanh với đợt tăng đột biến thật, khung dài lọc bớt nhiễu ngắn hạn — chỉ báo động khi cả hai khung cùng vượt ngưỡng. Ví dụ cụ thể: báo động ngay khi tốc độ tiêu ngân sách đủ nhanh để dùng hết ngân sách lỗi cả tháng trong 2 ngày, còn mở ticket khi tốc độ tiêu chậm hơn nhiều. Mở rộng cho item 5.5.

Kỹ năngHọc viên thiết kế được một cặp ngưỡng cảnh báo theo hai khung thời gian cho một SLO cụ thể.

Hình thứcVideo 6 phút, sơ đồ hai khung thời gian và tốc độ tiêu ngân sách lỗi.

Ý chínhSemantic cache biến câu hỏi thành vector rồi so sánh độ giống với các câu hỏi cũ đã lưu; khi đủ giống, trả lời từ cache thay vì gọi model lại — cách này có thể giảm phần lớn chi phí cho những câu hỏi lặp lại kiểu nhau. Prompt cache do chính nhà cung cấp model xử lý: phần đầu prompt lặp lại giữa các lượt gọi — ví dụ system prompt hay tài liệu tham chiếu — được tính giá rẻ hơn nhiều so với đọc lại từ đầu. Đánh đổi của semantic cache nằm ở độ chính xác: ngưỡng độ giống đặt quá thấp khiến hệ thống trả lời cũ cho một câu hỏi có khác biệt tinh tế nhưng quan trọng, nên cần theo dõi cả tỉ lệ trúng cache lẫn chất lượng câu trả lời lấy từ cache. Mở rộng cho item 2.3.

Kỹ năngHọc viên phân biệt được semantic cache và prompt cache, và nêu được rủi ro chính khi dùng semantic cache.

Hình thứcVideo 5 phút, hai cơ chế cache minh hoạ song song.

Ý chínhGắn observability đầy đủ vào agent đã triển khai ở Ngày 12: ghi log có cấu trúc dạng JSON kèm correlation ID và đã che thông tin cá nhân, đo các chỉ số AI — token, chi phí, độ trễ theo P95 cùng thời gian đến token đầu tiên, tỉ lệ tool-call thành công — dựng tracing theo dạng cây span, gửi dữ liệu tới một backend quan sát, rồi dựng dashboard 6 panel cùng ít nhất 3 quy tắc cảnh báo và 1 SLO kèm ngân sách lỗi. Học viên hoàn thành theo 6 mốc: chuẩn bị môi trường, log và che thông tin cá nhân, trace và gắn phiên bản prompt, dashboard và SLO, điều tra một sự cố được cấu hình sẵn, rồi nộp bài; nhóm tối đa 4 người chia theo 4 vai trò tương ứng với các mốc trên. Học viên nộp báo cáo sự cố có ít nhất 1 trace ID hoặc dòng log cụ thể làm bằng chứng cho nguyên nhân gốc đã tìm ra.

Kỹ năngHọc viên gắn được observability đầy đủ vào một agent thật, đọc được trace để tìm nguyên nhân gốc của một sự cố, và nộp được báo cáo có bằng chứng cụ thể.

Hình thứcLab 4 giờ tại lớp với người hướng dẫn, theo repo có sẵn, chia tối đa 4 vai trò trong nhóm. Kèm validator script tự kiểm tra log và dashboard trước khi nộp.