Các bài trước trong module đã đi qua cách cài AWS MCP cho từng công cụ riêng lẻ (Claude Code, OpenCode, Gemini CLI, Cursor) và vài prompt mẫu cho từng loại việc. Bài này ghép toàn bộ lại thành một workflow end-to-end, mô phỏng đúng một ca thực tế hay gặp trong hệ thống serverless: một alarm CloudWatch bắn lên giữa đêm, bạn cần vừa xử lý ngay incident, vừa không quên phần "dọn dẹp" chi phí phát sinh do nguyên nhân gốc gây ra. Đây là loại workflow mà giá trị của AI Agent + AWS MCP thể hiện rõ nhất — không phải ở một câu trả lời đơn lẻ, mà ở khả năng nối liên tục nhiều nguồn dữ liệu (alarm, log, trace, code, IAM, cost) trong một chuỗi hội thoại duy nhất.
Tổng Quan Workflow: Từ CloudWatch Alarm Đến Fix và Báo Cáo Chi Phí
Trước khi vào chi tiết từng bước, cần hình dung toàn cảnh workflow gồm ba giai đoạn, tương ứng ba phần tiếp theo của bài này:
- Thu thập context — lấy đầy đủ thông tin alarm, log, trace liên quan qua AWS MCP, tổng hợp thành một bức tranh đủ để bắt đầu điều tra, thay vì mở rời rạc nhiều tab console.
- Phân tích root cause — để AI đối chiếu chéo giữa log/trace vừa lấy được với code trong repo và cấu hình IAM/resource thật, đưa ra giả thuyết nguyên nhân có dẫn chứng cụ thể.
- Áp dụng fix và tổng kết — sửa code/IaC dưới sự review của bạn, sau đó yêu cầu AI tổng hợp báo cáo gồm cả phần reliability (đã fix gì) và phần cost (incident này gây tốn thêm bao nhiêu, và có cần tối ưu gì thêm không).
Điểm khác biệt của workflow này so với cách làm truyền thống không phải là AI "thông minh hơn" con người trong việc đọc log — mà là AI có thể giữ toàn bộ context (alarm, log, trace, code, policy, cost) trong cùng một phiên làm việc, loại bỏ phần lớn thời gian bạn tốn để tự chuyển ngữ cảnh giữa CloudWatch console, X-Ray console, Cost Explorer, và editor.
Công cụ dùng trong ví dụ này là Claude Code (đã cài AWS MCP theo hướng dẫn ở bài đầu module), nhưng toàn bộ prompt đều áp dụng được cho OpenCode, Gemini CLI, hay Cursor — vì bản chất là gọi cùng một bộ tool AWS MCP, chỉ khác agent CLI đang điều phối.
Mẹo: Trước khi bắt đầu điều tra một incident thật, mở một session/conversation mới riêng cho ca đó — đừng tiếp tục trong một session cũ đã chứa nhiều context không liên quan, vì context không liên quan sẽ làm loãng khả năng suy luận của AI và chiếm context window một cách lãng phí.
Bước 1: Lấy Alarm Context, Log và Trace Qua MCP
Giả định tình huống: alarm checkout-service-prod-error-rate-high vừa bắn lên trong CloudWatch, báo error rate của một Lambda function vượt ngưỡng 5% trong 10 phút. Bước đầu tiên là để AI tự thu thập toàn bộ context liên quan, trước khi đưa ra bất kỳ giả thuyết nào.
Prompt: "Alarm 'checkout-service-prod-error-rate-high' vừa chuyển sang
trạng thái ALARM. Lấy chi tiết alarm này (metric, threshold, thời điểm
chuyển trạng thái), rồi lấy metric Invocations, Errors, Duration,
Throttles của Lambda checkout-service-prod trong 30 phút trước và sau
thời điểm alarm bắn, để tôi thấy rõ pattern thay đổi."
Sau khi có bức tranh metric, bước tiếp theo là lấy log chi tiết trong đúng khoảng thời gian đó, dùng Logs Insights để tránh kéo toàn bộ raw log:
Prompt: "Chạy Logs Insights trên log group /aws/lambda/checkout-service-prod
trong khoảng 15 phút trước và sau thời điểm alarm bắn. Lọc message chứa
'ERROR' hoặc mã lỗi 5xx, group theo error message, đếm số lần xuất hiện,
sort giảm dần. Giới hạn 20 dòng."
Query Logs Insights tương ứng agent sẽ chạy:
fields @timestamp, @message
| filter @message like /ERROR/ or @message like /statusCode":5/
| stats count(*) as occurrences by @message
| sort occurrences desc
| limit 20
Nếu hệ thống có bật AWS X-Ray, bước cuối của giai đoạn thu thập context là lấy trace của một vài request lỗi cụ thể để biết chính xác request đang kẹt ở đâu:
Prompt: "Lấy 5 trace có lỗi gần thời điểm alarm bắn nhất từ X-Ray cho
service checkout-service-prod. Với mỗi trace, cho tôi breakdown thời
gian ở từng segment (gọi DynamoDB, gọi service inventory, thời gian xử
lý nội bộ), và đánh dấu segment nào chiếm nhiều thời gian nhất hoặc bị
lỗi."
Kết thúc bước này, bạn nên có trong tay: pattern metric bất thường, top error message cụ thể, và breakdown trace — đủ dữ liệu để chuyển sang giai đoạn phân tích nguyên nhân mà không cần tự tay tra thêm gì nữa.
Mẹo: Luôn yêu cầu AI lấy metric/log của một khoảng thời gian bao trùm cả trước và sau thời điểm alarm bắn (không chỉ sau) — dữ liệu "trước" thường tiết lộ trigger ban đầu (ví dụ một deploy, một traffic spike) mà nếu chỉ nhìn log sau alarm, bạn dễ bỏ lỡ.
Bước 2: AI Phân Tích Root Cause Trên Code, Config và IAM
Có context rồi, bước tiếp theo là để AI đối chiếu với code thật trong repo và cấu hình resource/IAM thật trên AWS, thay vì chỉ dừng ở việc mô tả lại log.
Prompt: "Top error message vừa tìm được là 'ProvisionedThroughputExceededException'
khi gọi DynamoDB table 'orders-prod'. Lấy cấu hình capacity mode hiện tại
của table này (on-demand hay provisioned, và giá trị RCU/WCU nếu
provisioned), kèm metric ConsumedWriteCapacityUnits trong 1 giờ qua, để
xác nhận có đúng là bị throttle do vượt capacity không."
Nếu xác nhận đúng là throttle do capacity, bước tiếp theo là tìm nguyên nhân traffic tăng — có thể do một thay đổi ở phía code gọi nhiều lần hơn bình thường (ví dụ một bug gây retry loop):
Prompt: "Đọc file src/services/order-repository.ts, tìm đoạn code gọi
DynamoDB PutItem cho table orders-prod. Có logic retry nào ở đây không?
Nếu có, retry có backoff hay retry liên tục ngay lập tức? So sánh với
thời điểm deploy gần nhất của service này — deploy đó có nằm trong
khoảng 1 giờ trước khi alarm bắn không?"
Giả sử agent phát hiện: một PR deploy 40 phút trước alarm đã thêm logic retry 3 lần liên tiếp không có backoff khi gặp lỗi tạm thời, vô tình khiến mỗi request lỗi tạo thêm 3 lần gọi DynamoDB, đúng lúc traffic đang cao — đây là root cause hợp lý, có dẫn chứng cụ thể (thời điểm deploy khớp, đúng đoạn code gây tăng số lượng request).
Với ca có liên quan tới quyền hạn (một dạng root cause khác hay gặp), quy trình tương tự áp dụng cho IAM:
Prompt: "Một số request lỗi có message 'AccessDenied' khi gọi
dynamodb:PutItem. Kiểm tra execution role của Lambda
checkout-service-prod, dùng iam:SimulatePrincipalPolicy để xác nhận
action dynamodb:PutItem trên table orders-prod có đang bị Deny hay
không, và policy statement nào gây ra việc đó."
Ở bước này, việc quan trọng nhất không phải là tốc độ, mà là bạn luôn yêu cầu agent trích dẫn dẫn chứng cụ thể (số liệu metric, đoạn code, thời điểm deploy) cho mỗi giả thuyết — một root cause "nghe hợp lý" nhưng không có dẫn chứng đối chiếu dễ khiến bạn fix sai chỗ, incident tái diễn.
Mẹo: Khi AI đưa ra giả thuyết root cause, luôn hỏi ngược lại "bằng chứng nào xác nhận giả thuyết này, và có giả thuyết nào khác cũng khớp với log không" — buộc agent tự liệt kê phản chứng giúp bạn tránh confirmation bias, kể cả khi giả thuyết đầu tiên nghe rất hợp lý.
Bước 3: Áp Dụng Fix và Tạo Báo Cáo Chi Phí, Reliability
Với root cause đã xác nhận (retry không backoff gây tăng traffic vượt capacity DynamoDB), bước tiếp theo là fix — nhưng luôn qua code review, không để AI tự deploy trực tiếp.
Prompt: "Sửa file src/services/order-repository.ts để thêm exponential
backoff cho logic retry khi gặp ProvisionedThroughputExceededException,
base delay 100ms, tối đa 3 lần retry, có jitter để tránh nhiều request
retry cùng lúc. Không tự commit, chỉ sửa file để tôi review diff."
Song song, vì nguyên nhân gốc liên quan tới capacity, cũng nên đánh giá luôn có cần chuyển DynamoDB sang on-demand hoặc tăng provisioned capacity không, để tránh lặp lại incident tương tự khi có traffic spike khác:
Prompt: "Dựa trên pattern traffic của table orders-prod trong 30 ngày
qua (lấy metric ConsumedWriteCapacityUnits theo ngày), so sánh chi phí
ước tính nếu chuyển sang on-demand capacity mode với chi phí hiện tại
đang provisioned. Có nên chuyển không, và nếu giữ provisioned thì nên
tăng WCU lên bao nhiêu để có buffer an toàn 30%?"
Sau khi fix được review và merge (qua pipeline CI/CD bình thường của team, không phải AI tự deploy), bước cuối là tổng hợp báo cáo — đây là phần dễ bị bỏ qua nhất trong thực tế vì mọi người thường "fix xong là xong", nhưng lại là phần AI hỗ trợ tốt nhất vì đã có sẵn toàn bộ context của cuộc điều tra:
Prompt: "Viết một bản postmortem ngắn cho incident này, gồm: timeline
(từ lúc deploy gây lỗi tới lúc alarm bắn tới lúc fix được merge), root
cause, đoạn code đã sửa, và ước tính chi phí phát sinh thêm trong lúc
DynamoDB bị throttle (số request retry dư ra x chi phí mỗi write request).
Kèm 2-3 action item để tránh lặp lại, ví dụ thêm alarm riêng cho
ConsumedWriteCapacityUnits gần ngưỡng."
Bản postmortem này vừa phục vụ lưu trữ nội bộ, vừa là input tốt để review lại toàn bộ chuỗi alarm/dashboard hiện có — nhiều team sau một ca như vậy sẽ nhờ AI luôn đề xuất thêm alarm mới dựa trên đúng metric vừa dùng để điều tra, biến một lần incident thành một cải tiến observability lâu dài.
Mẹo: Luôn yêu cầu bản postmortem tách riêng phần "chi phí phát sinh do incident" (ví dụ retry dư, traffic bất thường) khỏi phần "chi phí vận hành bình thường" — gộp chung hai loại chi phí này khiến báo cáo gửi lên quản lý dễ bị hiểu sai về mức độ nghiêm trọng thực sự của incident.
Tổng Kết và Mẹo Sử Dụng
- Chia workflow điều tra incident thành ba giai đoạn rõ ràng: thu thập context, phân tích root cause có dẫn chứng, rồi mới tới fix và báo cáo.
- Luôn lấy dữ liệu (metric, log) bao trùm cả trước và sau thời điểm alarm bắn, không chỉ nhìn về sau.
- Buộc AI đưa dẫn chứng và tự xét phản chứng cho mọi giả thuyết root cause, tránh confirmation bias.
- Mọi fix (code, IaC, capacity) đều đi qua review của con người, AI chỉ đề xuất và soạn diff.
- Luôn tách riêng phần chi phí phát sinh do incident với chi phí vận hành bình thường khi báo cáo.
Mẹo: Sau vài lần lặp lại workflow này, hãy nhờ AI tự đóng gói lại thành một checklist hoặc prompt template cố định cho riêng hệ thống của bạn — một workflow điều tra tốt chỉ thực sự có giá trị dài hạn khi nó lặp lại được nhất quán, không phụ thuộc vào việc người trực ca đó có nhớ hết các bước hay không.