Đây là bài tổng kết của module, ráp lại toàn bộ kiến thức từ các bài trước thành một quy trình end-to-end hoàn chỉnh — từ lúc nhận alert đầu tiên đến khi có postmortem (báo cáo sau sự cố) sẵn sàng gửi cho team. Khác với các bài trước tập trung vào một client cụ thể, bài này tập trung vào tư duy quy trình: bạn cần hỏi gì, theo thứ tự nào, và làm sao để AI hỗ trợ tối đa mà vẫn giữ được sự kiểm soát và chính xác cần thiết khi đang xử lý một incident thật đang ảnh hưởng người dùng.
Tổng Quan Quy Trình: Từ Monitor Alert Đến Root Cause và Postmortem
Một quy trình điều tra incident có AI hỗ trợ hiệu quả thường đi qua 4 giai đoạn rõ ràng, và việc hiểu rõ ranh giới giữa các giai đoạn giúp bạn biết khi nào nên tin tưởng AI tự chạy, và khi nào cần con người quyết định:
[Monitor Alert kích hoạt]
│
▼
[Giai đoạn 1: Thu thập context] ← AI làm rất tốt, ít rủi ro
- Monitor nào trigger, threshold gì
- Service/host nào bị ảnh hưởng
- Log lỗi liên quan
│
▼
[Giai đoạn 2: Correlation] ← AI hỗ trợ mạnh, cần con người verify
- Nối trace, deploy marker, metric bất thường
- Tìm nghi vấn root cause
│
▼
[Giai đoạn 3: Quyết định hành động] ← BẮT BUỘC con người quyết định
- Rollback? Scale? Mute alert tạm? Escalate?
│
▼
[Giai đoạn 4: Tổng hợp postmortem] ← AI làm tốt phần viết, con người
- Timeline, root cause, action items duyệt nội dung trước khi gửi
Nguyên tắc quan trọng nhất xuyên suốt quy trình: AI thu thập và tổng hợp dữ liệu rất tốt, nhưng quyết định hành động ảnh hưởng đến production luôn phải do con người phê duyệt. Đây không phải giới hạn kỹ thuật của MCP mà là nguyên tắc vận hành an toàn — một agent có thể gọi tool sai (ví dụ hiểu nhầm "mute monitor" là hành động an toàn khi thực ra alert đó đang cảnh báo đúng) nếu bạn cho nó quyền tự quyết định hành động thay đổi trạng thái hệ thống.
Mẹo: Trước khi bắt đầu bất kỳ điều tra incident thật, hãy nói rõ với agent ngay từ prompt đầu tiên: "Bạn chỉ thu thập và phân tích dữ liệu, không thực hiện bất kỳ hành động thay đổi trạng thái nào (mute, resolve, scale) mà không hỏi tôi trước." Câu này thiết lập đúng kỳ vọng ngay từ đầu, giảm rủi ro agent tự hành động khi bạn đang tập trung đọc kết quả và chưa kịp để ý.
Bước 1: Thu Thập Monitor Context, Affected Services, và Error Logs
Khi alert vừa kích hoạt, mục tiêu bước 1 là có được "bức tranh tổng quan" nhanh nhất có thể — không đi sâu vào root cause ngay, chỉ cần biết mức độ nghiêm trọng và phạm vi ảnh hưởng.
Prompt mẫu ngay khi nhận alert:
Monitor "checkout-api Error Rate High" vừa trigger. Cho tôi biết:
1. Threshold cấu hình là gì, giá trị hiện tại vượt bao nhiêu so với threshold.
2. Monitor này đã từng trigger trong 30 ngày qua chưa, tần suất thế nào.
3. Những service nào khác đang có alert cùng thời điểm (có thể là sự cố lan rộng
không chỉ riêng checkout-api).
4. Lấy 20 log lỗi gần nhất của service checkout-api, group theo error type.
Agent sẽ gọi tuần tự get_monitor, search_monitors (để check các alert khác đang active cùng lúc — bước này cực kỳ quan trọng để phân biệt "sự cố cục bộ" và "sự cố lan rộng do hạ tầng chung"), và aggregate_logs. Kết quả điển hình:
1. Threshold: error rate > 2% trong 5 phút. Hiện tại: 7.8% — vượt gần 4 lần.
2. Monitor này chỉ trigger 1 lần trong 30 ngày qua (3 tuần trước, do lỗi
third-party payment provider, đã tự resolve sau 12 phút).
3. Có 2 monitor khác đang Alert cùng thời điểm: "RDS CPU High" (database
chính) và "API Gateway 5xx Rate". => Khả năng cao đây là sự cố ở tầng
hạ tầng chung (database), không phải lỗi riêng của checkout-api.
4. 85% log lỗi có message "QueryTimeoutError" trên bảng `orders`.
Chỉ với bước 1, bạn đã có đủ thông tin để đưa ra một giả thuyết ban đầu mạnh (database đang là nút nghẽn) và biết đây không phải sự cố cô lập — điều này định hướng ngay bước điều tra tiếp theo nên tập trung vào đâu, tránh lãng phí thời gian điều tra sai hướng.
Mẹo: Luôn hỏi "có monitor/service khác đang alert cùng thời điểm không" ngay ở bước đầu tiên. Đây là câu hỏi con người thường quên hỏi khi đang tập trung vào một alert cụ thể, nhưng lại là chìa khoá để phân biệt nhanh giữa "lỗi cô lập của một service" và "sự cố hạ tầng lan rộng" — hai loại này cần chiến lược xử lý hoàn toàn khác nhau.
Bước 2: Liên Kết Traces, Deploy Markers và Infrastructure Metrics
Sau khi có giả thuyết ban đầu từ bước 1 (nghi vấn database), bước 2 là xác nhận hoặc loại trừ giả thuyết đó bằng cách nối chéo nhiều nguồn dữ liệu.
Giả thuyết hiện tại: database chính đang là nút nghẽn, gây QueryTimeoutError
lan sang checkout-api. Xác nhận bằng cách:
1. Lấy metric CPU, connection count, và slow query log của RDS instance
chính trong 30 phút qua.
2. Có deploy nào (app hoặc infrastructure/terraform) trong 1 giờ trước khi
alert trigger không?
3. Lấy 3 trace chậm nhất của checkout-api, xác định chính xác query nào
đang chậm và có phải cùng pattern với slow query log của RDS không.
Kết quả điển hình cho thấy sức mạnh thật của correlation tự động:
1. CPU của RDS instance tăng từ 35% lên 94% bắt đầu 18:02 UTC. Connection
count tăng từ 80 lên 480 (gần giới hạn max_connections=500).
2. CÓ: một migration Terraform "add index to orders.customer_id" được apply
lúc 18:00 UTC — đúng 2 phút trước khi CPU bắt đầu tăng.
3. Cả 3 trace chậm nhất đều có span "SELECT * FROM orders WHERE
customer_id = ?" mất 2-4 giây — TRÙNG với bảng đang được thêm index.
=> Root cause xác nhận: việc thêm index (CREATE INDEX không dùng CONCURRENTLY)
trên bảng orders đã lock bảng/gây tải I/O cao trong quá trình build index,
làm mọi query vào bảng này bị chậm nghiêm trọng, dẫn đến connection pool bị
giữ lâu hơn bình thường và nhanh chóng đạt giới hạn.
Đây là ví dụ hoàn hảo cho việc AI phát hiện ra một liên kết mà con người rất dễ bỏ sót trong lúc gấp gáp: một thay đổi hạ tầng tưởng như "vô hại" (thêm index để tối ưu) lại chính là nguyên nhân, vì nó không dùng flag an toàn cho production.
Mẹo: Luôn hỏi rõ về deploy/migration hạ tầng (không chỉ deploy code ứng dụng) trong cùng khung thời gian nghi vấn. Nhiều team chỉ quen hỏi "có deploy app nào không" mà quên các thay đổi ở tầng database, network, hay infrastructure-as-code — trong khi đây lại là nguồn root cause phổ biến và khó phát hiện bằng mắt thường nhất.
Bước 3: Tạo Incident Summary và Action Items Theo Sau
Sau khi đã xác nhận root cause và (giả định) team đã xử lý xong sự cố (ví dụ hủy migration đang chạy, hoặc chờ index hoàn tất), bước cuối là tổng hợp toàn bộ thành tài liệu postmortem có thể chia sẻ ngay.
Prompt tổng hợp:
Sự cố đã được xử lý (migration index đã hoàn tất, hệ thống ổn định trở lại
từ 18:34 UTC). Dựa trên toàn bộ dữ liệu đã thu thập trong phiên này, viết
một bản postmortem theo cấu trúc:
1. Tóm tắt (2-3 câu, cho người không rành kỹ thuật)
2. Timeline chi tiết (UTC, kèm nguồn dữ liệu mỗi mốc)
3. Root cause (kỹ thuật)
4. Impact (số request lỗi ước tính, thời gian ảnh hưởng)
5. Action items (đánh dấu rõ mức độ ưu tiên: P0/P1/P2)
Kết quả điển hình, có thể copy gần như trực tiếp vào công cụ quản lý incident của team:
## Tóm tắt
Checkout API bị lỗi trong 32 phút (18:02-18:34 UTC) do một migration thêm
index trên bảng orders làm quá tải database chính, khiến khách hàng không
thể hoàn tất thanh toán trong khoảng thời gian này.
## Timeline
18:00 UTC | Terraform apply "add index to orders.customer_id" | deploy marker
18:02 UTC | RDS CPU tăng 35% → 94%, connection count 80 → 480 | metric
18:03 UTC | Log QueryTimeoutError xuất hiện lần đầu ở checkout-api | log
18:04 UTC | Monitor "checkout-api Error Rate High" trigger (7.8%) | monitor
18:06 UTC | Monitor "RDS CPU High" và "API Gateway 5xx Rate" cùng trigger | monitor
18:20 UTC | On-call engineer xác nhận root cause qua điều tra AI-assisted | (manual)
18:25 UTC | Migration bị huỷ / index build hoàn tất (tuỳ hành động thực tế) | (manual)
18:34 UTC | Error rate về lại baseline 0.3% | metric
## Root Cause
Migration tạo index không dùng CONCURRENTLY trên bảng orders đang có traffic
cao, gây lock/tải I/O lớn trong quá trình build index, làm cạn kiệt
connection pool của database chính.
## Impact
Ước tính 1,240 request checkout thất bại trong 32 phút (dựa trên log
error rate x traffic trung bình). Không phát hiện mất dữ liệu.
## Action Items
- [P0] Thêm rule bắt buộc CONCURRENTLY (hoặc chạy migration ngoài giờ cao
điểm) cho mọi CREATE INDEX trên bảng có traffic cao — owner: platform team.
- [P1] Thêm monitor cảnh báo sớm connection pool > 70% capacity, thay vì chỉ
cảnh báo khi error rate đã tăng — owner: SRE team.
- [P2] Review lại checklist pre-deploy cho migration, thêm bước review từ
DBA cho mọi thay đổi schema trên bảng lớn — owner: eng leadership.
Một bản postmortem như vậy, nếu viết tay từ đầu, thường tốn 1-2 giờ sau một incident đã đủ mệt để xử lý. Với dữ liệu đã thu thập sẵn trong suốt quá trình điều tra, AI có thể tổng hợp bản đầu tiên trong vài phút — bạn chỉ cần review, chỉnh sửa giọng văn, và bổ sung các quyết định "manual" (như quyết định huỷ migration) mà agent không tự chứng kiến được.
Mẹo: Luôn tự tay bổ sung hoặc verify lại các dòng "hành động của con người" (như thời điểm ai đó quyết định rollback, ai duyệt escalate) trong timeline do AI tạo — agent chỉ biết những gì nó truy vấn được từ Datadog, không biết các quyết định/trao đổi diễn ra ngoài phạm vi dữ liệu telemetry (như trong cuộc gọi Slack huddle hay trao đổi trực tiếp).
Mẹo Sử Dụng Hiệu Quả
Tổng kết những nguyên tắc quan trọng nhất khi áp dụng quy trình AI-assisted này vào thực tế đội nhóm:
- Luôn thiết lập rõ ranh giới ngay từ đầu: AI thu thập/phân tích, con người quyết định hành động ảnh hưởng production.
- Ở giai đoạn thu thập context, luôn hỏi thêm "có alert/service khác cùng thời điểm không" để phân biệt sự cố cô lập và sự cố lan rộng.
- Ở giai đoạn correlation, luôn hỏi về cả deploy ứng dụng VÀ thay đổi hạ tầng/database/migration — root cause thường ẩn ở phần ít người nghĩ tới.
- Luôn yêu cầu agent trích dẫn nguồn dữ liệu cụ thể (log ID, trace ID, tên metric) ở mỗi bước, để dễ verify và để postmortem cuối cùng có độ tin cậy cao.
- Bổ sung tay các quyết định/hành động của con người mà AI không thể tự biết vào bản postmortem cuối cùng trước khi công bố.
Mẹo: Sau vài lần áp dụng quy trình 4 giai đoạn này, hãy đóng gói các prompt hiệu quả nhất của từng giai đoạn thành một "runbook" chuẩn trong repo (ví dụ
docs/ai-incident-runbook.md), tham chiếu trong file rule của AI client bạn dùng. Qua vài tháng, đây sẽ trở thành tài sản vận hành thực sự giúp giảm đáng kể MTTR (Mean Time To Resolution — thời gian trung bình để giải quyết sự cố) của toàn team, không phụ thuộc vào việc một cá nhân nào đó "giỏi hỏi AI".