Ngày 10 · Data Pipeline & Data Observability

Ý chínhGiảng viên đặt câu hỏi xuyên suốt ngày học bằng một tình huống cụ thể: dữ liệu trong hệ thống công ty đột nhiên sai, agent bắt đầu trả lời sai theo — và câu hỏi không phải "làm sao dữ liệu không bao giờ sai" mà là "bạn biết trước hay đợi người dùng báo". Giảng viên giới thiệu bốn đầu ra học viên sẽ đạt được trong ngày — đọc đúng tầng lỗi, viết được bộ luật dữ liệu, quan sát được pipeline, và quyết định đúng mức xử lý.

Kỹ năngHọc viên biết mình sẽ đạt được gì sau ngày học và vì sao câu hỏi "biết trước hay đợi báo" là trọng tâm.

Hình thứcVideo giảng viên, 3 phút, mở bằng tình huống thật.

Ý chínhTrong phần lớn dự án AI thực tế, khoảng 60–80% thời gian là công việc về dữ liệu, không phải xây model hay agent; một agent xuất sắc vẫn trả lời sai nếu kho tri thức được nạp dữ liệu không sạch. Data cascade mô tả cách một quyết định nhỏ hợp lý tại nguồn — ví dụ đổi cách ghi ngày — trôi qua từng bước thu thập, biến đổi, và đưa vào agent mà không bước nào báo lỗi, rồi chỉ lộ ra ở bước cuối cùng khi agent trả lời sai. Vì dữ liệu không có cơ chế báo lỗi tức thời như code, cách thoát khỏi cascade không phải là kêu gọi cẩn thận hơn mà là gắn điểm đo sớm hơn ở từng bước. Học viên cũng học cách đọc năm triệu chứng phổ biến của agent — trả lời đúng nhưng cũ, lẫn hai phiên bản tài liệu, tự bịa nhưng nghe hợp lý, chỉ sai với một loại nguồn, đột biến sau khi triển khai — để suy ra tầng dữ liệu nào đang hỏng trước khi sửa prompt hay đổi model.

Kỹ năngHọc viên giải thích được vì sao lỗi dữ liệu trôi xa hơn lỗi code trước khi bị phát hiện, và từ một triệu chứng của agent suy luận ra đúng tầng dữ liệu khả nghi.

Hình thứcVideo 7 phút — sơ đồ cascade dựng dần bốn bước, năm cặp triệu chứng-tầng hiện lần lượt.

Ý chínhMột nhóm muốn ứng dụng đo một chỉ số sức khoẻ mỗi ngày một lần, nhưng chỉ tìm được nguồn dữ liệu đo mỗi 5 phút một lần — câu hỏi là dùng dữ liệu đó thế nào cho đúng. Cách trả lời phổ biến nhưng sai là lấy trung bình cộng toàn bộ các lần đo trong ngày: trung bình cộng làm mất chính đặc tính dao động mà chỉ số này cần thể hiện, trong khi người theo dõi thực tế cần biết dao động, không cần một con số phẳng. Cách đúng là bám theo hành vi người dùng thật — lấy đúng một điểm đo mỗi ngày ở cùng một khung giờ, chấp nhận một khoảng dung sai xung quanh mốc đó vì người dùng không phải lúc nào cũng đo đúng giờ. Chọn sai cách lấy mẫu ngay từ bước này khiến toàn bộ dữ liệu thu thập sau đó phải bỏ đi và làm lại — quyết định lấy mẫu luôn phải bám theo cách sản phẩm thực sự được dùng, không phải theo dữ liệu nguồn sẵn có.

Kỹ năngHọc viên dự đoán được hệ quả của việc lấy trung bình một chỉ số dao động, và chọn được cách lấy mẫu bám đúng hành vi người dùng thay vì dữ liệu nguồn sẵn có.

Hình thứcTương tác mô phỏng 5 phút trên dữ liệu cấu hình sẵn: học viên dự đoán kết quả của cách lấy trung bình so với cách lấy đúng một điểm mỗi ngày, trước khi xem biểu đồ dao động thật. Phương án thay thế: video so sánh hai cách xử lý cùng một tập dữ liệu đo tần suất cao.

Ý chínhETL và ELT đều gồm đúng ba việc — lấy dữ liệu ra khỏi nguồn, biến đổi, và nạp vào kho — khác nhau chỉ ở thứ tự transform diễn ra trước hay sau khi nạp. Chọn ETL khi không được phép giữ dữ liệu thô, ví dụ log có thông tin cá nhân buộc phải che trước khi lưu theo luật; chọn ELT khi chưa chắc chắn sau này sẽ transform kiểu gì, ví dụ tài liệu chính sách mà vài tháng sau có thể muốn cắt đoạn theo cách khác — giữ dữ liệu thô là giữ quyền đổi ý. Trong thực tế nhiều đội dùng cách kết hợp: nạp thô trước cho phần lớn dữ liệu, nhưng ETL riêng phần nhạy cảm hoặc phần cần tính lại nhiều đặc trưng dẫn xuất tốn kém nếu phải làm lại mỗi lần huấn luyện. Câu hỏi quyết định là: bạn có được phép giữ dữ liệu thô không — nếu không thì ETL là lựa chọn duy nhất.

Kỹ năngHọc viên chọn được ETL hay ELT cho một tình huống cụ thể và giải thích được lý do bằng đúng một câu hỏi quyết định.

Hình thứcVideo 6 phút — hai luồng ETL/ELT dựng song song, kèm hai ví dụ đối lập.

Ý chínhBatch xử lý theo lô chạy theo lịch — mỗi giờ, mỗi đêm — đơn giản, rẻ, dễ chạy lại nếu sai, nhưng dữ liệu có thể trễ vài giờ trước khi agent thấy; streaming xử lý ngay khi sự kiện tới, độ trễ tính bằng mili giây nhưng đắt hơn và khó gỡ lỗi hơn nhiều. Batch phù hợp cho dữ liệu huấn luyện và báo cáo định kỳ; streaming cần thiết khi độ trễ ảnh hưởng trực tiếp đến quyết định, ví dụ phát hiện gian lận giao dịch thẻ. Câu hỏi quyết định không phải "realtime có tốt hơn không" mà là: nếu dữ liệu trễ 6 tiếng, agent trả lời sai tới mức nào — trả lời được câu đó mới chọn được kiến trúc phù hợp.

Kỹ năngHọc viên chọn được batch hay streaming cho một luồng dữ liệu cụ thể dựa trên mức độ ảnh hưởng của độ trễ.

Hình thứcVideo 5 phút — hai luồng minh hoạ tốc độ xử lý đối lập.

Ý chínhHọc viên áp hai quyết định vừa học — transform trước hay sau, xử lý theo lô hay theo sự kiện — lên bốn tình huống: che thông tin cá nhân trong log trước khi lưu, đồng bộ đêm một file chính sách, một sự kiện cần lên bảng điều khiển ngay lập tức, và một file tổng hợp hàng tháng. Với mỗi tình huống, học viên chọn một ô trong ma trận hai trục rồi viết một dòng lý do theo bốn tiêu chí: độ trễ, khả năng kiểm soát dữ liệu nhạy cảm, chi phí vận hành, và khả năng gỡ lỗi. Bài tập không có một đáp án tuyệt đối cho mọi tình huống — mục tiêu là học viên nêu rõ mình đang đánh đổi cái gì, không phải chọn đúng ô.

Kỹ năngHọc viên phân loại được một tình huống dữ liệu mới vào đúng góc phần tư và nêu được đánh đổi đằng sau lựa chọn.

Hình thứcTương tác kéo bốn thẻ tình huống vào ma trận hai trục, 4 phút, có gợi ý khi lựa chọn khác đáp án mẫu nhưng lý do hợp lý vẫn được chấp nhận. Phương án thay thế: quiz bốn tình huống dạng trắc nghiệm.

Ý chính3 câu kiểm tra: vì sao data cascade khó phát hiện, câu hỏi quyết định giữa ETL và ELT, câu hỏi quyết định giữa batch và streaming.

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ínhBốn nhóm nguồn phổ biến hỏng theo cách khác nhau: cơ sở dữ liệu quan hệ có thể timeout, đổi schema, hoặc kéo về không dòng nào; API bên thứ ba trả lỗi giới hạn tần suất, hết hạn xác thực, hoặc lệch khi phân trang; tệp PDF và HTML có thể đọc sai chữ, lỗi bảng mã, hoặc thiếu metadata; webhook và luồng sự kiện có thể dồn ứ hoặc trùng lặp. Mỗi nhóm cần một cách đo tương ứng — độ mới và số dòng cho cơ sở dữ liệu, khối lượng và tiến độ checkpoint cho API, tỉ lệ dòng bị gắn cờ xem lại cho tệp, độ sâu hàng đợi và số bản ghi vào hàng lỗi cho luồng sự kiện. Một mẫu ghi hữu ích cho mọi nguồn: nguồn nào, cách lấy, cách kiểm tra, ai chịu trách nhiệm — nguồn nào không điền nổi cột người chịu trách nhiệm là nguồn sẽ gây sự cố.

Kỹ năngHọc viên chọn đúng cách đo cho một nguồn dữ liệu mới dựa trên kiểu hỏng đặc trưng của nó.

Hình thứcVideo 5 phút — bảng bốn nguồn hiện dần kèm ví dụ hỏng.

Ý chínhKhi phân trang bằng offset, hệ thống trả lời theo kiểu "cho tôi từ dòng thứ N trở đi" — nếu một bản ghi mới bị chèn vào đầu danh sách trong lúc đang đọc, mọi thứ dịch xuống một ô và trang tiếp theo đọc trùng bản ghi cũ trong khi bỏ sót bản ghi mới, mà không có lỗi nào bắn ra. Phân trang bằng cursor ghi nhớ đúng mốc đã dừng — ví dụ một mã định danh — và luôn xin phần sau mốc đó, nên chèn bao nhiêu bản ghi cũng không làm lệch. Vì dữ liệu vẫn đang thay đổi trong lúc pipeline đọc, đây là một trong những lựa chọn dễ bị đánh giá thấp nhất: hai cách trông tương đương khi thử với dữ liệu tĩnh, nhưng khác hẳn khi nguồn đang sống.

Kỹ năngHọc viên dự đoán đúng kết quả đọc dữ liệu khi có bản ghi chèn giữa, cho cả hai cách phân trang, và giải thích được vì sao cursor an toàn hơn.

Hình thứcTương tác mô phỏng 5 phút trên dữ liệu cấu hình sẵn: học viên dự đoán trang hai sẽ chứa gì trước khi bấm chạy, cho cả offset và cursor, rồi so với kết quả thật. Phương án thay thế: video so sánh hai cách phân trang trên cùng một tình huống chèn dữ liệu.

Ý chínhKhi một API bên thứ ba trả lỗi giới hạn tần suất, cách xử lý đúng là chờ tăng dần theo cấp số nhân giữa các lần thử lại — 1 giây, 2 giây, 4 giây — thay vì thử lại ngay lập tức; nếu bên thứ ba trả kèm thời gian chờ đề xuất thì đọc và tuân theo trước khi tự đoán. Vấn đề nảy sinh khi nhiều tiến trình cùng chờ đúng một khoảng thời gian: cả ba đập vào API cùng một khoảnh khắc và bị chặn lần nữa; thêm một khoảng ngẫu nhiên nhỏ vào mỗi lần chờ giúp rải các lần thử ra, để API có chỗ thở. Thử lại vô hạn không giới hạn số lần và không tăng dần thời gian chờ là sai lầm kinh điển: pipeline tự tấn công chính API nguồn, và bên đó chặn lại là đúng.

Kỹ năngHọc viên dự đoán được điều gì xảy ra khi ba tiến trình thử lại cùng lúc có và không có khoảng ngẫu nhiên, và giải thích được vì sao cần giới hạn số lần thử lại.

Hình thứcTương tác mô phỏng 4 phút: học viên dự đoán ba tiến trình có đụng độ không trước khi bật khoảng ngẫu nhiên, rồi quan sát biểu đồ thời điểm thử lại thay đổi. Phương án thay thế: video minh hoạ hai kịch bản có và không có khoảng ngẫu nhiên.

Ý chínhHai khái niệm dễ nhầm khi xử lý tệp: giá trị băm nội dung trả lời câu hỏi "tệp có đổi không" để quyết định có cần xử lý lại hay không, còn phiên bản logic — ví dụ tên tệp gắn số hiệu — trả lời câu khác hẳn là "đây là bản nào" để agent lọc đúng phiên bản khi trả lời; thiếu cái đầu khiến lần chạy nào cũng xử lý lại toàn bộ, thiếu cái sau khiến agent không phân biệt được bản cũ và bản mới. Công nghệ đọc chữ từ ảnh scan luôn đi kèm một điểm tin cậy; điểm thấp cần được gắn cờ cho người xem lại trước khi công bố, không phải sau khi người dùng phàn nàn. Cắt đoạn theo tiêu đề thay vì theo số ký tự cố định giúp tránh tình trạng agent trích dẫn được nhưng cắt ngang một điều khoản, khiến câu trả lời có trích nguồn mà vẫn sai nghĩa.

Kỹ năngHọc viên phân biệt được vai trò của giá trị băm nội dung và phiên bản logic, và giải thích được vì sao điểm tin cậy thấp cần được xử lý trước khi công bố.

Hình thứcVideo 6 phút — hai khái niệm đối chiếu song song kèm ví dụ tên tệp thật.

Ý chínhKhi nguồn phát sự kiện nhanh hơn tốc độ xử lý, hàng đợi phình lên — đây là triệu chứng, không phải nguyên nhân, và câu hỏi đúng là tại sao bên xử lý chậm lại, không phải làm sao giảm độ dài hàng đợi. Cơ chế áp lực ngược báo ngược cho bên phát khi hàng đợi gần đầy để bên đó chậm lại; không có cơ chế này, hàng đợi phình tới khi hết bộ nhớ và mất dữ liệu. Một bản ghi thử lại nhiều lần vẫn lỗi cần được tách sang một hàng riêng dành cho bản ghi lỗi, thay vì chặn cả hàng đợi phía sau; hàng chờ này là điểm để quan sát, không phải nơi vứt bỏ — bản ghi lỗi vẫn nằm đó để xem lại, thay vì biến mất im lặng.

Kỹ năngHọc viên đọc được độ dài hàng đợi tăng bất thường như một tín hiệu cần điều tra bên xử lý, và giải thích được vai trò của hàng chờ bản ghi lỗi.

Hình thứcVideo 5 phút — sơ đồ luồng dựng dần: nguồn phát, hàng đợi, bên xử lý, hàng chờ lỗi.

Ý chính3 câu kiểm tra: nghi ngờ đầu tiên khi pipeline báo thành công nhưng dữ liệu không mới, vì sao cursor an toàn hơn offset, và tăng số tiến trình xử lý có phải là cách sửa gốc khi hàng đợi phình hay không.

Kỹ năngHọc viên tự kiểm tra ba ý chính của module trước khi sang phần làm sạch dữ liệu.

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

Ý chínhMỗi bản ghi đi qua bước kiểm tra schema và quy tắc rồi rẽ vào một trong ba hướng: sửa được — ví dụ cắt khoảng trắng thừa, chuẩn hoá định dạng ngày, chuẩn hoá unicode — thì đi thẳng vào kho; nghi ngờ nhưng có thể cứu được — ví dụ thiếu ngày nhưng có nội dung, hoặc điểm tin cậy đọc chữ thấp — thì chờ người có chuyên môn duyệt; không cứu được — ví dụ nội dung rỗng sau khi cắt khoảng trắng, hoặc trùng khoá chính — thì tách sang khu vực riêng. Mọi bản ghi bị loại hoặc gắn cờ phải được ghi lại kèm mã lần chạy vào một bảng riêng; xoá mà không ghi lại nghĩa là mất dữ liệu mà không ai biết. Nguyên tắc bao trùm: transform là code cộng với một bộ quy tắc được viết ra, không phải sửa tay trong vài phút trước khi trình diễn — sửa tay thì lần chạy sau lỗi lại y nguyên.

Kỹ năngHọc viên phân loại được một bản ghi lỗi vào đúng một trong ba hướng xử lý và giải thích được vì sao phải ghi lại bản ghi bị loại.

Hình thứcVideo 6 phút — một bảng dữ liệu thô biến đổi thành bảng sạch từng bước, ba hướng xử lý tô màu khác nhau.

Ý chínhNăm lỗi phổ biến xuất hiện ở hầu hết mọi nguồn dữ liệu: giá trị thiếu dưới nhiều hình dạng khác nhau — rỗng, chữ "chưa có", hoặc số không giả làm giá trị thiếu; giá trị bất thường đủ sức kéo lệch cả một phép tính tổng hợp; bản ghi trùng lặp do cùng một nội dung được nạp nhiều lần; định dạng không nhất quán, ví dụ hai cách viết ngày khác nhau trong cùng một cột; và lỗi bảng mã, nơi tiếng Việt có dấu thường là chỗ lộ ra đầu tiên. Một cạm bẫy hay gặp khi mới bắt đầu là ba đội khác nhau dùng ba cách biểu diễn "chưa có giá trị" — rỗng, số không, và giá trị thiếu thật sự — cho cùng một ý nghĩa, khiến phép tính tổng hợp sai mà không ai phát hiện; quy ước này phải thống nhất và viết rõ, không để mỗi người tự chọn. Với giá trị thiếu, quyết định bỏ, điền giá trị mặc định, hay gắn cờ chờ xem lại phải được ghi rõ trong một bộ quy tắc dùng chung.

Kỹ năngHọc viên nhận diện được năm kiểu lỗi phổ biến trong một tập dữ liệu mới và giải thích được vì sao ba cách biểu diễn "chưa có giá trị" cần được thống nhất giữa các đội.

Hình thứcVideo 5 phút — năm kiểu lỗi minh hoạ bằng ví dụ ngắn, kèm ví dụ ba đội hiểu khác nhau về "chưa có giá trị".

Ý chínhNăm khía cạnh đầu tiên máy tự kiểm tra được chỉ bằng cách nhìn vào chính bảng dữ liệu: đúng kiểu và đúng khoảng giá trị, tỉ lệ thiếu và số dòng, tỉ lệ trùng lặp, đối chiếu chéo giữa các hệ thống, và tuổi của bản ghi so với thời điểm cập nhật gần nhất. Khía cạnh thứ sáu — đúng với thực tế hay không — không có cách nào tự kiểm tra được chỉ bằng chính bảng dữ liệu, mà cần một nguồn đối chiếu bên ngoài: người nắm nghiệp vụ, hệ thống gốc, hoặc chứng từ thực tế. Điểm dễ nhầm nhất trong sáu khía cạnh là giữa khía cạnh đầu và khía cạnh cuối: một giá trị số tiền dương và đúng kiểu dữ liệu là hợp lệ về mặt kiểm tra tự động, nhưng có thể vẫn không đúng với thực tế nếu người nhập sai; kiểm tra tự động chỉ bắt được loại lỗi đầu, còn loại lỗi sau cần đi hỏi.

Kỹ năngHọc viên phân biệt được kiểm tra tự động bắt được gì và không bắt được gì, và chọn đúng khía cạnh cần một nguồn đối chiếu bên ngoài.

Hình thứcVideo 6 phút — sáu khía cạnh chia hai nhóm rõ ràng, một ví dụ số tiền minh hoạ ranh giới giữa hai nhóm.

Ý chínhMột bộ luật dữ liệu tốt gồm ba phần mấu chốt: danh mục giá trị hợp lệ cho phép viết được kiểm tra tự động ngay lập tức; quy tắc nghiệp vụ — ví dụ khoản tiền hoàn lại có thể âm, hoặc một khoản phụ phí chỉ áp dụng với một hình thức thanh toán nhất định — giúp tránh chặn nhầm dữ liệu đúng; và phần quan trọng nhất, những gì bộ luật không quy định, cho phép trả lời trung thực "không thể biết" thay vì đoán bừa rồi tự tin sai. Khi gặp một con số lạ, câu hỏi không phải "có đáng ngờ không" mà là con số đó rơi vào phần nào trong ba phần trên. Không có bộ luật này, mọi bất thường trông giống nhau, và người xử lý dữ liệu sẽ vừa chặn nhầm dữ liệu đúng vừa bỏ lọt dữ liệu sai cùng một lúc.

Kỹ năngHọc viên tra được một giá trị bất thường vào đúng phần của bộ luật dữ liệu và phân biệt được "sai theo luật", "đúng nhưng trông lạ", và "không thể biết".

Hình thứcVideo 6 phút — ba phần của một bộ luật dữ liệu mẫu hiện dần kèm ví dụ số liệu thật.

Ý chínhHọc viên khảo sát một tập dữ liệu thật chứa nhiều điểm bất thường, và với mỗi phát hiện phải ghi đủ năm phần: thấy gì, tìm bằng cách nào, thuộc khía cạnh chất lượng nào, phán quyết ra sao, và cần thêm gì để chắc chắn. Ba phán quyết được phép chọn là sai — vi phạm điều viết rõ trong bộ luật dữ liệu; đúng — trông lạ nhưng bộ luật giải thích được; và không thể biết — bộ luật không nói gì, cần ghi rõ cần hỏi nguồn nào. Nhầm lẫn phổ biến ở bước này là dừng lại ngay sau khi tìm ra điểm bất thường mà không phân loại tiếp: một khoản phí bất thường có thể không vi phạm quy tắc nào được viết rõ, nhưng vẫn đáng để hỏi ngược lại nguồn trước khi kết luận đúng hay sai.

Kỹ năngHọc viên phân loại đúng một phát hiện bất thường vào một trong ba phán quyết dựa trên bộ luật dữ liệu, và nêu được cần nguồn nào để xác nhận trường hợp không thể biết.

Hình thứcTương tác mô phỏng 5 phút trên dữ liệu cấu hình sẵn: học viên xem một phát hiện, chọn phán quyết trước khi hệ thống hiện gợi ý dựa trên bộ luật, so sánh hai trường hợp trông giống nhau nhưng phán quyết khác nhau. Phương án thay thế: bài đọc kèm năm phát hiện mẫu đã có phán quyết và giải thích.

Ý chính4 câu kiểm tra: ba hướng xử lý một bản ghi lỗi, khác biệt giữa đúng kiểu dữ liệu và đúng thực tế, phần quan trọng nhất của một bộ luật dữ liệu, và cách phán quyết một phát hiện không có quy tắc rõ ràng.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi sang phần quan sát dữ liệu vận hành.

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

Ý chínhBốn điều đầu tiên đo tại một điểm và chỉ nói "đang có sự cố": độ mới trả lời dữ liệu có đúng lịch không, khối lượng trả lời số dòng có bị rơi không, phân phối trả lời giá trị có lệch bất thường không, và cấu trúc trả lời cột có bị đổi không. Điều thứ năm — dòng chảy dữ liệu — khác hẳn bốn điều kia: nó không đo tại một điểm mà nối các điểm đo lại với nhau, cho phép lần ngược từ triệu chứng về đúng bước gây ra sự cố. Độ mới báo hiệu đang có vấn đề, nhưng chỉ dòng chảy dữ liệu mới nói được vấn đề nằm ở bước nào — ví dụ bước nạp dữ liệu lúc rạng sáng, không phải ở model.

Kỹ năngHọc viên gọi tên được năm điều cần quan sát trên một pipeline dữ liệu và phân biệt được điều nào chỉ báo hiệu, điều nào chỉ ra nguyên nhân.

Hình thứcVideo 6 phút — năm điều hiện dần quanh một sơ đồ pipeline, ví dụ số liệu minh hoạ mỗi điều.

Ý chínhKhi một bước đồng bộ dữ liệu thất bại âm thầm lúc rạng sáng, không có gì báo lỗi — công việc kết thúc, nhật ký không ghi gì bất thường, và điều duy nhất sai là không có gì mới, mà "không có gì mới" trông y hệt "không có gì cần làm". Nếu không có quan sát dữ liệu, người dùng đầu tiên phát hiện ra sau nhiều giờ, khi dữ liệu đã cũ và agent trả lời sai theo chính sách đã lỗi thời; nếu có quan sát dữ liệu, độ mới vượt ngưỡng được phát hiện gần như ngay lập tức và người trực chạy lại bước nạp dữ liệu trước khi có người dùng nào thấy câu trả lời sai. Bài học cốt lõi khi agent trả lời sai: kiểm tra đúng thứ tự độ mới, khối lượng, cấu trúc, rồi dòng chảy dữ liệu — mới đến model.

Kỹ năngHọc viên mô tả được vì sao một sự cố dữ liệu có thể hoàn toàn im lặng đối với hệ thống, và áp dụng đúng thứ tự chẩn đoán khi agent trả lời sai.

Hình thứcỞ nhà: video 6 phút dựng cùng một sự cố hai lần, có và không có quan sát dữ liệu, để đối chiếu trực tiếp. Trên lớp: tương tác 3 phút, học viên chọn bốn chỉ số cần mở theo đúng thứ tự trong một tình huống sự cố mới, tránh hai chỉ số gây nhiễu. Phương án thay thế: video minh hoạ bốn chỉ số kèm giải thích vì sao hai chỉ số còn lại là bẫy.

Ý chínhMột cam kết về độ mới hiệu quả không viết theo lịch chạy kỹ thuật mà viết theo hệ quả người dùng thấy được — ví dụ chính sách hoàn tiền phải xuất hiện trong câu trả lời của agent trong một khoảng thời gian nhất định kể từ khi tài liệu được ký, không phải "pipeline chạy mỗi 4 tiếng". Điểm đo phải là thời điểm tài liệu thực sự sẵn sàng để agent đọc, không phải lúc tệp vừa rơi vào thư mục tạm — đo sai điểm khiến cam kết báo tốt trong khi người dùng vẫn thấy dữ liệu cũ. Các loại nguồn khác nhau cần ngưỡng khác nhau, và nên có hai mức cảnh báo: đi hết nửa thời gian cho phép thì báo nhẹ để xử lý trong giờ hành chính, hết toàn bộ thời gian thì báo khẩn cho người trực, vì lúc này cam kết với người dùng đã bị vi phạm.

Kỹ năngHọc viên viết được một cam kết độ mới theo ngôn ngữ nghiệp vụ và xác định đúng điểm cần đo.

Hình thứcVideo 5 phút — ví dụ cam kết viết sai rồi viết lại đúng, kèm hai mức cảnh báo trên trục thời gian.

Ý chínhMột nhóm lỗi nguy hiểm hơn vì không làm pipeline dừng lại và không làm số dòng thay đổi: tỉ lệ giá trị thiếu tăng vọt ở một cột sau khi nguồn đổi cách trả dữ liệu, độ dài nội dung ngắn bất thường báo hiệu bước đọc dữ liệu vừa hỏng, tỉ lệ ngôn ngữ lạ hoặc nhiễu tăng đột biến, ràng buộc giữa các cột trở nên vô lý dù từng cột riêng lẻ vẫn hợp lệ, và giá trị thời gian vượt quá hiện tại do lệch múi giờ hoặc lỗi phân tích. Nhóm lỗi này khó phát hiện nhất vì không có một thời điểm hỏng rõ ràng để lần theo — chúng chỉ làm câu trả lời của agent tệ dần theo thời gian, không có một sự kiện gãy đột ngột nào để cảnh báo bắt được.

Kỹ năngHọc viên nhận diện được năm dấu hiệu hỏng âm thầm không làm pipeline dừng lại, khác với lỗi làm số dòng rơi hẳn.

Hình thứcVideo 5 phút — năm dấu hiệu liệt kê kèm một ví dụ số liệu cho mỗi dấu hiệu.

Ý chínhPhát hiện lệch phân phối là so sánh phân phối giá trị của một tập dữ liệu mới với một tập dữ liệu mốc để xem đã đổi hay chưa; học viên chạy công cụ phát hiện lệch trên hai tập dữ liệu vận hành thật và quan sát cột nào bị đánh dấu lệch. Đây là điểm dễ đánh giá sai nhất trong ngày: một cách quan sát duy nhất — ví dụ chỉ một kiểu biểu đồ tổng hợp — có thể che giấu hoàn toàn một điểm lệch nhỏ về tỉ lệ nhưng ảnh hưởng lớn về hệ quả, trong khi một cột bị đánh dấu lệch rõ ràng chưa chắc đã thực sự hỏng nếu bộ luật dữ liệu giải thích được sự thay đổi đó. Công cụ tốt hơn không sửa được việc chọn sai tập dữ liệu mốc hoặc đặt sai câu hỏi cần trả lời — phải tự hỏi phân phối lệch có thật sự tương ứng với dữ liệu hỏng hay chỉ là hành vi người dùng thay đổi.

Kỹ năngHọc viên dự đoán được liệu một cách quan sát duy nhất có phát hiện ra một điểm lệch nhỏ hay không, và phân biệt được cột bị đánh dấu lệch với cột thực sự hỏng.

Hình thứcTương tác mô phỏng 6 phút trên dữ liệu cấu hình sẵn: học viên dự đoán trước liệu một điểm lệch nhỏ có bị phát hiện không khi chỉ xem một kiểu biểu đồ, rồi đổi sang cách xem chi tiết hơn để kiểm tra dự đoán. Phương án thay thế: video so sánh hai cách quan sát cùng một tập dữ liệu.

Ý chính4 câu kiểm tra: điều nào trong năm điều quan sát dữ liệu chỉ ra được nguyên nhân thay vì chỉ báo hiệu, điểm đúng để đo một cam kết độ mới, một dấu hiệu hỏng âm thầm không làm pipeline dừng lại, và vì sao một cách quan sát duy nhất có thể bỏ lọt một điểm lệch nhỏ.

Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi sang phần ra quyết định vận hành.

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

Ý chínhKhông phải mọi lỗi nghiêm trọng như nhau: lỗi khiến mọi thứ đi sau đều sai theo — ví dụ trùng khoá chính hoặc lỗi bảng mã không thể phục hồi — nên dừng hẳn pipeline; lỗi có khoá đúng nhưng nội dung đáng ngờ nên được tách ra một khu vực riêng để người có chuyên môn xem lại trước khi cho vào kho chính; còn lỗi ở trường không bắt buộc hoặc sai chính tả trong thông tin mô tả chỉ cần ghi lại rồi đi tiếp. Cách xếp mức đúng là hỏi "nếu lỗi này lọt qua, hậu quả tới đâu và có chờ được không", không phải hỏi "lỗi này nghe đáng sợ tới mức nào". Mức xử lý phải được viết rõ trong bộ luật dữ liệu, và khu vực chứa bản ghi bị tách riêng không bao giờ được để agent đọc — nếu không, thứ vừa được tách ra vẫn đi thẳng vào câu trả lời.

Kỹ năngHọc viên xếp được một lỗi cụ thể vào một trong ba mức xử lý dựa trên hậu quả nếu lỗi lọt qua.

Hình thứcVideo 6 phút — sơ đồ ba nhánh xử lý dựng dần từ một dòng dữ liệu đầu vào.

Ý chínhHọc viên viết thêm quy tắc kiểm tra cho một tập dữ liệu vận hành thật, dựa trên những phát hiện đã tìm được trước đó, rồi chạy thử và đọc số dòng bị chặn cùng đặc điểm chung của các dòng đó. Với mỗi quy tắc, câu hỏi không dừng ở "quy tắc có chạy được không" mà đi tiếp ba bước: những dòng bị chặn có thật sự hỏng hay bộ luật vẫn cho phép chúng, trong số bị chặn bao nhiêu phần trăm là lỗi thật, và quy tắc này nên dừng hẳn, tách riêng, hay chỉ ghi lại. Đây là bước rèn thói quen quan trọng nhất của phần vận hành: viết được một quy tắc kỹ thuật dễ, nhưng biết quy tắc đó đủ tin cậy để dừng cả hệ thống hay không mới là quyết định khó.

Kỹ năngHọc viên viết được một quy tắc kiểm tra dữ liệu, đo được tỉ lệ lỗi thật trong số bị chặn, và xếp được quy tắc vào đúng mức xử lý.

Hình thứcTương tác 6 phút trên dữ liệu cấu hình sẵn: học viên dự đoán quy tắc sẽ chặn bao nhiêu dòng trước khi chạy, rồi đọc đặc điểm chung của các dòng bị chặn để xác nhận hoặc sửa dự đoán. Phương án thay thế: bài đọc kèm ba quy tắc mẫu đã chạy sẵn và kết quả phân tích.

Ý chínhCơ chế chạy lại là mặc định của mọi hệ thống vận hành tự động — pipeline sẽ chạy lại dù có được thiết kế cho việc đó hay không, nên phải đảm bảo chạy lại không tạo ra bản ghi trùng. Hai cách phổ biến: cập nhật theo khoá tự nhiên của bản ghi thay vì luôn sinh mã định danh mới, để chạy lại thì ghi đè đúng bản ghi cũ; hoặc nạp vào một khu vực tạm rồi chỉ chuyển hướng đọc sang khu vực đó khi đã nạp xong, để agent không bao giờ đọc phải dữ liệu đang nạp dở. Không có cơ chế này, một lần chạy lại để sửa dữ liệu cũ sẽ tự tạo ra bản ghi trùng: agent có thể lấy được cả bản cũ lẫn bản mới và trả lời hai kiểu khác nhau cho cùng một câu hỏi.

Kỹ năngHọc viên giải thích được vì sao chạy lại không idempotent gây trùng lặp, và chọn được một trong hai cách đảm bảo chạy lại an toàn.

Hình thứcVideo 5 phút — hai cách đảm bảo chạy lại an toàn minh hoạ song song.

Ý chínhMột bản ghi sự cố hữu ích trả lời 5 câu hỏi liên tiếp: người dùng thấy gì, chỉ số nào đã báo hiệu — hoặc chưa có chỉ số nào báo, và đó chính là lỗ hổng cần vá, nguyên nhân gốc nằm ở bước hoặc bảng nào, đã làm gì để ngăn thiệt hại lan rộng, và đã thêm gì để ngăn tái diễn. Dòng đáng giá nhất trong năm dòng là phần phát hiện: nếu không có chỉ số nào báo trước khi người dùng thấy, việc cần làm sau sự cố không phải chỉ là sửa lỗi mà là thêm một chỉ số mới để đo — vì lỗi lần sau sẽ khác, nhưng chỗ không ai đo thì vẫn nguyên đó. Tích luỹ nhiều bản ghi sự cố theo thời gian tạo thành một cuốn từ điển vận hành, giúp lần sự cố sau được xử lý nhanh hơn.

Kỹ năngHọc viên viết được một bản ghi sự cố đầy đủ năm phần, và xác định đúng khi nào cần thêm chỉ số đo mới thay vì chỉ sửa lỗi.

Hình thứcVideo 5 phút — mẫu bản ghi sự cố năm dòng áp dụng lên đúng ví dụ sự cố đã học ở module quan sát dữ liệu.

Ý chính3 câu kiểm tra: cách chọn giữa dừng hẳn, tách riêng, hay chỉ ghi lại một lỗi; vì sao chạy lại không an toàn gây trùng lặp; và dòng quan trọng nhất trong một bản ghi sự cố.

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

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 bốn điểm chính: không có bộ luật dữ liệu thì mọi bất thường trông giống nhau, vừa chặn nhầm dữ liệu đúng vừa bỏ lọt dữ liệu sai; lệch phân phối không đồng nghĩa với dữ liệu sai — nó chỉ nói phân phối đã đổi, không nói ai đúng; pipeline chạy xong là chuyện của chương trình, còn dữ liệu đúng là chuyện của dữ liệu, hai khẳng định khác nhau; và khi agent trả lời sai, thứ tự luôn là độ mới, khối lượng, cấu trúc, dòng chảy dữ liệu, rồi mới đến model. Giới thiệu Ngày 11.

Kỹ năngHọc viên tóm tắt được bốn đ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ínhCách viết một bộ kiểm tra chất lượng dữ liệu chạy được, ghi log được, và đưa vào quy trình tự động được — từ việc để công cụ đọc dữ liệu và gợi ý quy tắc, tới viết bộ quy tắc đầy đủ, chạy kiểm tra trước khi dữ liệu đi tiếp, và sinh báo cáo. Mở rộng cho item 3.3 và 3.4.

Kỹ năngHọc viên đọc hiểu được cấu trúc một bộ kiểm tra chất lượng viết bằng mã, đủ nền để tự viết bộ đầu tiên.

Hình thứcVideo 7 phút, ghi màn hình viết một bộ kiểm tra từ đầu đến khi chạy được.

Ý chínhHai công cụ — đo lệch phân phối và kiểm tra quy tắc từng dòng — trả lời 2 câu hỏi khác nhau và không thay thế nhau được: một tập dữ liệu có thể không lệch phân phối chút nào nhưng vẫn chứa dòng vi phạm quy tắc nghiệp vụ rõ ràng, và ngược lại. Mở rộng cho item 4.5.

Kỹ năngHọc viên giải thích được vì sao cần dùng cả hai công cụ song song, không dùng một cái thay cho cái kia.

Hình thứcVideo 6 phút, hai công cụ chạy song song trên cùng một tập dữ liệu có cả lỗi lệch phân phối và lỗi vi phạm quy tắc.

Ý chính6 câu hỏi thiết kế mà bất kỳ hệ thống điều phối pipeline nào cũng phải trả lời — điều gì kích hoạt một lần chạy, chính sách thử lại khi lỗi, có đợi tín hiệu dữ liệu sẵn sàng không, ngưỡng cảnh báo khi trễ hạn, ghi log thế nào để lần theo được, và chạy lại một khoảng thời gian trong quá khứ có an toàn không. Mở rộng cho item 5.1 và 5.3.

Kỹ năngHọc viên liệt kê được 6 câu hỏi thiết kế cần trả lời trước khi đưa một pipeline vào vận hành tự động.

Hình thứcVideo 6 phút, 6 câu hỏi hiện dần kèm ví dụ ngắn cho mỗi câu.

Ý chínhHọc viên nhận một pipeline dữ liệu cho một trợ lý nội bộ xử lý câu hỏi khách hàng và yêu cầu kỹ thuật, đã dựng sẵn nhưng chưa hoàn chỉnh — dữ liệu thô từ nhiều hệ thống nguồn có bản ghi trùng, thiếu ngày, xung đột phiên bản, và một nguồn hợp lệ bị bỏ sót. Học viên phân tích dữ liệu thô, đối chiếu với bộ câu hỏi đánh giá để xác định pipeline còn thiếu gì, rồi sửa và mở rộng bộ quy tắc làm sạch cùng bộ kiểm tra chất lượng cho tới khi toàn bộ pipeline chạy không bị chặn. Bước tiếp theo là cố ý làm hỏng dữ liệu để đo ảnh hưởng lên chất lượng truy xuất trước và sau khi sửa, hoàn thành hồ sơ dữ liệu và quy trình xử lý sự cố, rồi kiểm tra độ mới của dữ liệu đã nạp. Học viên nộp pipeline chạy được, bằng chứng trước và sau, cùng bộ tài liệu vận hành.

Kỹ năngHọc viên tự phát hiện lỗ hổng trong một pipeline dữ liệu có sẵn, sửa được để dữ liệu chảy thông suốt từ nguồn tới nơi agent đọc, và chứng minh bằng số liệu rằng dữ liệu sau khi sửa tốt hơn trước.

Hình thứcLab 4 giờ tại lớp với người hướng dẫn, theo repo có sẵn. Kèm dữ liệu thô mẫu từ năm hệ thống nguồn và bộ câu hỏi đánh giá dùng để xác nhận kết quả.