Đây là bài tổng hợp toàn bộ kiến thức của module: xây một pipeline hoàn chỉnh, end-to-end, biến một sheet log thô (dữ liệu ghi tự động từ hệ thống, chưa qua xử lý) thành một báo cáo đã review, sẵn sàng gửi cho stakeholder — toàn bộ dùng agentic engineering (kỹ thuật xây dựng và điều phối AI agent) qua Google Sheets MCP. Pipeline này không phải lý thuyết; nó phản ánh đúng nhịp làm việc thật của một engineer khi được giao task "tổng hợp báo cáo tuần" mà trước đây tốn nửa ngày làm tay. Bài chia thành ba bước rõ ràng: profiling và làm sạch dữ liệu, chạy phân tích và ghi lại số liệu suy ra, và cuối cùng sinh tóm tắt tường thuật (narrative) để phân phối.
Tổng Quan Workflow: Từ Spreadsheet Lộn Xộn Đến Báo Cáo Đã Review
Hình dung tình huống thật: mỗi ngày, một webhook ghi log incident (sự cố) từ hệ thống monitoring thẳng vào tab Incidents-Raw trong một spreadsheet — không có validation, không chuẩn hóa, mỗi người can thiệp tay thêm một chút khác biệt về format. Tab này có khoảng 300-500 dòng mới mỗi tuần. Nhiệm vụ: mỗi thứ Hai, tạo một báo cáo tuần cho engineering leadership, bao gồm số liệu chính xác và một đoạn tóm tắt dễ đọc.
Pipeline có 3 giai đoạn nối tiếp, mỗi giai đoạn là một "checkpoint" bạn review trước khi cho agent tiếp tục sang giai đoạn sau — đây là nguyên tắc quan trọng nhất của bài này: không chạy toàn bộ pipeline trong một lệnh duy nhất không giám sát, dù về mặt kỹ thuật agent hoàn toàn có thể làm được trong một lần gọi.
Giai đoạn 1: Profiling + Cleaning → [BẠN REVIEW] →
Giai đoạn 2: Analysis + Write-back → [BẠN REVIEW] →
Giai đoạn 3: Narrative Summary + Distribution
Lý do chia nhỏ không chỉ vì an toàn dữ liệu (đã nói ở bài 1), mà vì chất lượng: một tóm tắt tường thuật được sinh ra từ số liệu sai ở giai đoạn 1 sẽ đọc rất trôi chảy, rất tự nhiên, và hoàn toàn sai — đây là dạng lỗi nguy hiểm nhất khi làm báo cáo bằng AI, vì văn bản trôi chảy tạo cảm giác đáng tin cậy giả.
Mẹo: Luôn thiết kế pipeline báo cáo AI thành các checkpoint có thể review độc lập, đừng để một lệnh duy nhất chạy từ đầu đến cuối không giám sát — một đoạn tóm tắt viết mượt nhưng dựa trên số liệu sai là rủi ro lớn nhất của toàn bộ workflow này, và nó chỉ có thể bị bắt lỗi ở đúng bước số liệu được sinh ra, không phải ở bước đọc câu văn cuối cùng.
Bước 1: Profiling Sheet, Phát Hiện Schema, và Làm Sạch Dữ Liệu
Trước khi phân tích bất kỳ thứ gì, agent cần hiểu thực sự dữ liệu đang có gì — không giả định schema, mà thực sự kiểm tra.
Đọc tab "Incidents-Raw" trong spreadsheet ID 1PqRsT...
Không phân tích gì cả — chỉ profile dữ liệu:
1. Liệt kê tên cột thực tế ở dòng 1.
2. Với mỗi cột, cho biết: số dòng có giá trị, số dòng trống, và 3 giá trị mẫu.
3. Với cột có vẻ là ngày/thời gian, cho biết có bao nhiêu format khác nhau đang tồn tại.
4. Với cột có vẻ là category/enum (ví dụ severity, status), liệt kê tất cả giá trị unique.
Bước profiling này thường lộ ra những vấn đề kiểu: cột severity có cả "P1", "p1", "Priority 1", "1" cùng nghĩa nhưng viết khác nhau; cột resolved_at có dòng để trống thay vì null rõ ràng; cột created_at lẫn hai format ngày khác nhau do có người sửa tay một số dòng.
Sau khi có bức tranh thật, mới ra lệnh làm sạch — và luôn ghi vào tab mới, không sửa trực tiếp Incidents-Raw:
Dựa trên kết quả profiling trên, tạo tab mới "Incidents-Cleaned":
- Chuẩn hóa cột severity về đúng 4 giá trị: P0, P1, P2, P3
(map "Priority 1"/"p1"/"1" → "P1", tương tự cho các mức khác).
- Chuẩn hóa mọi ngày về format yyyy-mm-dd HH:mm.
- Với dòng có resolved_at trống VÀ created_at cách đây hơn 14 ngày,
đánh dấu cột mới "flag" = "stale-unresolved" (không tự set resolved_at,
chỉ đánh dấu để người xem tự xử lý).
Giữ nguyên toàn bộ dòng gốc trong Incidents-Raw, không xóa hay sửa gì ở đó.
Mẹo: Luôn chạy bước profiling riêng, không gộp chung với bước làm sạch trong một lệnh — nhìn thấy trước các giá trị unique và format lẫn lộn thật sự tồn tại giúp bạn viết rule chuẩn hóa chính xác hơn nhiều so với để agent tự đoán rule "hợp lý" dựa trên giả định chung, vốn thường sai với dữ liệu do người thật nhập tay qua nhiều tháng.
Bước 2: Chạy Phân Tích và Ghi Lại Số Liệu Suy Ra
Với dữ liệu đã sạch ở Incidents-Cleaned, giờ mới đến bước tính số liệu thật cho báo cáo.
Đọc tab "Incidents-Cleaned" trong spreadsheet ID 1PqRsT...
Tính cho tuần ISO vừa kết thúc (dựa trên created_at):
1. Tổng số incident mới, breakdown theo severity.
2. MTTR (mean time to resolve) theo severity, chỉ tính các incident đã resolved
(resolved_at không trống), đơn vị giờ.
3. Số incident có flag "stale-unresolved" hiện tại (không giới hạn theo tuần —
đây là số tồn đọng tính đến hiện tại).
4. Top 3 category (dựa trên cột "category") có nhiều incident nhất trong tuần.
Ghi các số liệu này vào tab mới "Weekly-Metrics-<tuần hiện tại theo yyyy-Www>",
mỗi số liệu một dòng có label rõ, giữ số liệu ở dạng số/giá trị thô
(chưa cần diễn giải bằng câu, đó là bước sau).
Việc tách "tính số liệu, ghi số thô" ra khỏi "viết tóm tắt bằng câu" (bước 3) là chủ đích — nó cho bạn một điểm review độc lập trên chính số liệu, trước khi số liệu đó bị "gói" vào văn xuôi trôi chảy khó soát lỗi bằng mắt.
Trước khi tiếp tục sang bước viết tóm tắt, in lại toàn bộ số liệu vừa ghi
ra đây dưới dạng bảng, để tôi xác nhận số liệu đúng trước khi đi tiếp.
Mẹo: Luôn yêu cầu agent in lại đúng số liệu vừa ghi (không phải mô tả lại bằng lời) trước khi cho phép sang bước viết tóm tắt — đây là checkpoint rẻ nhất và hiệu quả nhất trong toàn bộ pipeline, vì soát một bảng 6-8 số liệu tốn vài giây, còn phát hiện một số liệu sai sau khi đã gửi báo cáo cho leadership tốn công sửa sai uy tín nhiều hơn nhiều.
Bước 3: Sinh Tóm Tắt Tường Thuật và Phân Phối Nó
Sau khi số liệu đã được bạn xác nhận đúng ở bước 2, giờ mới để agent viết tóm tắt bằng ngôn ngữ tự nhiên — và luôn yêu cầu nó bám chặt vào số liệu đã chốt, không tự thêm diễn giải ngoài phạm vi dữ liệu có.
Dựa CHÍNH XÁC trên số liệu đã ghi trong tab "Weekly-Metrics-2026-W34" (đã được xác nhận đúng),
viết một đoạn tóm tắt 5-6 câu bằng tiếng Việt, giọng văn báo cáo nội bộ,
cho engineering leadership, gồm:
- Tình hình tổng quan tuần này (tăng/giảm so với tuần trước nếu có dữ liệu).
- Điểm cần chú ý nhất (ví dụ: MTTR của P0 tăng, hoặc số incident tồn đọng cao).
- Không thêm nhận định nguyên nhân nếu dữ liệu không hỗ trợ rõ (ví dụ không suy diễn
"do đợt deploy X gây ra" nếu không có dữ liệu liên kết incident với deploy).
Ghi đoạn tóm tắt vào ô A1 của tab mới "Weekly-Report-Final", giữ bảng số liệu
bên dưới từ dòng 3.
Với phần phân phối (distribution) — gửi báo cáo đi — cách an toàn nhất là để agent chuẩn bị nội dung sẵn sàng, nhưng con người là người bấm gửi, đặc biệt với báo cáo lần đầu chạy pipeline này:
Chuẩn bị nội dung tóm tắt trên dưới dạng có thể copy trực tiếp vào email hoặc Slack.
KHÔNG tự động gửi email hoặc post Slack — chỉ in nội dung ra đây để tôi review
và tự gửi trong vài lần chạy đầu, cho đến khi pipeline đã ổn định.
Sau khi pipeline đã chạy ổn định vài tuần và bạn tin tưởng chất lượng số liệu + tóm tắt, mới cân nhắc nối thêm bước gửi tự động (qua Slack MCP hay Gmail), nhưng luôn giữ lại bước "in ra tab Sheets trước" như một bản ghi kiểm tra (audit trail) độc lập với kênh phân phối.
Mẹo: Đừng tự động hóa bước gửi báo cáo ngay từ lần chạy đầu tiên, dù về kỹ thuật hoàn toàn khả thi — chạy tay bước gửi trong vài tuần đầu cho bạn cơ hội phát hiện những lỗi tinh vi (số liệu đúng nhưng diễn giải gây hiểu nhầm, giọng văn không phù hợp) mà chỉ lộ ra khi có người thật đọc kết quả cuối, trước khi nó đến tay toàn bộ leadership.
Tips
- Luôn chia pipeline báo cáo AI thành các checkpoint review độc lập: làm sạch → phân tích → tường thuật, không chạy gộp không giám sát.
- Chạy profiling riêng biệt trước khi viết rule làm sạch — đừng để agent tự đoán rule chuẩn hóa dựa trên giả định chung.
- Tách bước "ghi số liệu thô" ra khỏi bước "viết tóm tắt bằng câu" để có điểm soát lỗi rẻ và hiệu quả trước khi số liệu bị gói vào văn xuôi.
- Giữ bước gửi báo cáo (phân phối) ở dạng thủ công trong ít nhất vài lần chạy đầu, trước khi tự động hóa hoàn toàn.
Mẹo: Lưu lại mỗi lần chạy pipeline này thành một tab riêng có timestamp (không xóa tab tuần trước) trong ít nhất vài tháng đầu — khi có ai hỏi "tại sao số liệu tuần này khác tuần trước", bạn có ngay bản ghi đầy đủ từng bước để đối chiếu, thay vì phải chạy lại và hy vọng dữ liệu nguồn chưa bị thay đổi.