Quy trình Thực tế: Giao tiếp Sự cố & Báo cáo Tình trạng

Phần lớn thời gian trong một incident nghiêm trọng không nằm ở việc tìm nguyên nhân — nó nằm ở việc giao tiếp liên tục với stakeholder trong khi vẫn phải tập trung debug. Đây chính là khoảng trống mà Slack MCP giải quyết tốt nhất: để agent lo phần thông báo có cấu trúc, còn engineer dồn toàn lực vào xử lý kỹ thuật. Bài này trình bày một workflow end-to-end hoàn chỉnh, từ lúc phát hiện sự cố đến lúc đóng postmortem, áp dụng được với bất kỳ client MCP nào đã học ở các bài trước (Claude Code, OpenCode, Gemini CLI, Cursor).

Tổng Quan Workflow: Từ Phát Hiện Đến Giao Tiếp Với Stakeholder

Một incident điển hình có 4 giai đoạn giao tiếp, và agent có thể hỗ trợ ở cả 4:

1. Phát hiện (detection) — alert từ monitoring (Datadog, Sentry, PagerDuty...) kích hoạt, engineer cần thông báo ngay cho team để tránh nhiều người cùng lao vào sửa một cách rời rạc.
2. Điều tra (investigation) — trong lúc debug, cần cập nhật định kỳ để stakeholder không phải hỏi "tình hình sao rồi" liên tục, làm phân tán sự chú ý của người đang xử lý.
3. Khắc phục (mitigation/fix) — khi fix được deploy, cần thông báo rõ đã xử lý xong hay chỉ là workaround tạm.
4. Tổng kết (postmortem) — sau khi ổn định, cần một bản tóm tắt đầy đủ cho những người không tham gia trực tiếp, và action item để tránh lặp lại.

Kiến trúc thực tế: bạn tạo một channel #incident-<ngày> riêng cho mỗi sự cố (theo convention nhiều team SRE hay dùng), agent MCP có quyền post vào channel này và vào #eng-leads (channel cấp cao hơn, ít nhiễu hơn để leadership theo dõi mà không cần đọc từng dòng debug chi tiết).

Mẹo: Luôn tách riêng "channel làm việc" (nơi engineer trao đổi chi tiết, có thể ồn) và "channel theo dõi" (nơi chỉ có cập nhật cấp cao, dành cho stakeholder không cần biết chi tiết kỹ thuật) — agent nên biết rõ nội dung nào thuộc về channel nào để tránh làm loãng thông tin ở channel theo dõi.

Bước 1: Mở Thread Sự Cố Với Ngữ Cảnh Có Cấu Trúc

Ngay khi phát hiện sự cố, việc đầu tiên là tạo một message mở đầu có cấu trúc rõ ràng — đây sẽ là "root message" mà mọi cập nhật sau đó reply vào dưới dạng thread, giữ channel gọn gàng.

Prompt mẫu:

Một alert vừa báo API /checkout trả lỗi 500 tăng đột biến từ
10:15 sáng nay (xem log: [paste log hoặc mô tả]).
Mở một incident thread mới trong #incident-2026-0822 theo mẫu:

🔴 INCIDENT MỞ | Mức độ: <ước lượng: thấp/trung/cao/nghiêm trọng>
Dịch vụ ảnh hưởng: checkout API
Thời gian phát hiện: 10:15
Người phụ trách: <tên tôi>
Tình trạng: Đang điều tra
Mô tả ban đầu: tỉ lệ lỗi 500 tăng từ 0.1% lên 12% trong 5 phút qua

Sau đó @mention nhóm on-call bằng <!subteam^ID-oncall>.

Agent gọi post_message với nội dung theo mẫu, lưu lại thread_ts (timestamp của message này chính là ID để mọi reply sau bám vào). Đây là điểm mấu chốt kỹ thuật: bạn cần yêu cầu agent ghi nhớ thread_ts này trong suốt session, vì các bước sau đều phải reply_to_thread bằng đúng giá trị này, không tạo message rời rạc.

Mức độ nghiêm trọng (severity) nên có bảng quy ước rõ ràng để agent không tự đoán tuỳ hứng — ví dụ:

Mẹo: Định nghĩa sẵn bảng tiêu chí mức độ nghiêm trọng này trong system prompt hoặc file cấu hình project — nếu để agent tự đoán mà không có tiêu chí, nó có xu hướng đánh giá quá thấp mức độ nghiêm trọng của sự cố ảnh hưởng doanh thu.

Bước 2: Tự Động Đăng Cập Nhật Tiến Độ Khi Việc Fix Tiến Triển

Trong lúc điều tra và fix, agent nên đăng cập nhật định kỳ vào đúng thread đã mở ở Bước 1 — không tạo message mới, không đăng vào channel khác. Ví dụ khi có tiến triển:

Vừa xác định nguyên nhân: connection pool tới database orders
bị exhaust do một query N+1 mới deploy hôm qua trong PR #498.
Reply vào thread incident đang mở (không tạo message mới):

🟡 CẬP NHẬT 10:42 | Đã xác định nguyên nhân
Root cause: query N+1 trong PR #498 làm connection pool cạn kiệt
Đang triển khai: rollback PR #498, ETA 10 phút
Tình trạng: Đang khắc phục

Một pattern nâng cao hữu ích: để agent tự động đăng cập nhật theo một nhịp cố định (ví dụ mỗi 15-20 phút) nếu incident kéo dài, thay vì chỉ đăng khi có tiến triển lớn — điều này giữ cho stakeholder biết agent/engineer vẫn đang hoạt động, tránh cảm giác "im lặng đáng lo".

Nếu chưa có cập nhật mới trong 15 phút kể từ lần đăng gần nhất,
tự đăng một dòng ngắn: "🟡 Vẫn đang xử lý, chưa có thay đổi lớn,
sẽ cập nhật khi có tiến triển." vào cùng thread.

Lưu ý về giới hạn thực tế: hầu hết client MCP (Claude Code, OpenCode, Gemini CLI, Cursor) không tự chạy nền liên tục theo thời gian thực — "tự động sau 15 phút" cần một cơ chế bên ngoài (cron job gọi lại agent, hoặc engineer chủ động gọi lại agent định kỳ) chứ MCP tool tự nó không có khả năng lên lịch (scheduling). Đừng nhầm "agent hiểu yêu cầu lên lịch" với "agent tự chạy được lịch đó mà không cần trigger từ ngoài".

Mẹo: Nếu cần cập nhật tự động theo lịch thật (không phải chỉ khi bạn hỏi), kết hợp thêm một cron job hoặc CI schedule gọi lại CLI agent theo mẫu lệnh cố định — MCP cung cấp "khả năng", còn "lịch trình" phải do hệ thống ngoài agent đảm nhiệm.

Bước 3: Tạo Bản Tóm Tắt Đóng Sự Cố và Action Item Theo Sau

Khi sự cố đã ổn định, bước cuối là tổng kết — đây là lúc agent phát huy giá trị rõ nhất vì nó đã "đọc" toàn bộ thread từ đầu, không cần con người ngồi ghép lại thủ công.

Sự cố đã ổn định từ 11:05 (rollback PR #498 thành công, error rate
về 0.1%). Đọc toàn bộ thread incident từ đầu, tạo bản đóng sự cố
theo mẫu:

✅ INCIDENT ĐÃ ĐÓNG | Thời gian: 10:15 - 11:05 (50 phút)
Root cause: <tóm tắt 1-2 câu>
Tác động: <số liệu cụ thể: % user ảnh hưởng, doanh thu ước tính nếu có>
Cách khắc phục: <tóm tắt>
Action item follow-up:
  - [ ] Thêm test coverage cho N+1 query (owner: <tên>)
  - [ ] Thêm alert connection pool usage > 80% (owner: <tên>)
  - [ ] Review lại quy trình code review cho PR có query phức tạp (owner: <tên>)

Đăng bản này vào thread gốc, VÀ đăng một bản gọn hơn (chỉ phần
tác động + root cause, bỏ action item chi tiết) vào #eng-leads.

Việc yêu cầu 2 bản khác độ chi tiết cho 2 audience khác nhau (engineer cần action item cụ thể, leadership chỉ cần biết tác động và nguyên nhân) là kỹ thuật quan trọng để tránh channel cấp cao bị ngập thông tin kỹ thuật không cần thiết.

Sau khi đăng, một bước thường bị bỏ quên: tạo ticket theo dõi action item thật (không chỉ nằm trong Slack). Nếu team có Jira/Linear MCP server chạy song song, đây là lúc phối hợp nhiều MCP server trong cùng một agent:

Với mỗi action item ở trên, tạo một ticket Linear trong project
"Reliability", gán đúng owner, deadline 1 tuần từ hôm nay, và
dán link ticket trở lại vào thread Slack tương ứng.

Mẹo: Luôn biến action item từ dạng "checklist trong message Slack" (dễ bị quên vì Slack không có concept "quá hạn") thành ticket thật trong hệ thống quản lý công việc có deadline và người theo dõi — nếu không, gần như chắc chắn ít nhất một action item sẽ rơi vào quên lãng sau 2 tuần.

Lưu Ý Thêm Khi Vận Hành Workflow Này Trong Thực Tế

Vài điều rút ra từ việc áp dụng quy trình này lâu dài trong một team thật:

• Luôn để con người là người quyết định "đóng incident", không để agent tự động đánh giá đã ổn định dựa trên suy luận — số liệu monitoring có thể trễ (delay) vài phút, đóng sự cố quá sớm dựa trên báo cáo của agent có thể khiến team bỏ qua dư chấn (aftershock) của sự cố.
• Review lại toàn bộ log tool call của agent sau mỗi incident lớn như một phần của postmortem — không chỉ review con người làm gì, mà cả agent đã đăng gì, đọc gì, có sai lệch nào không, để cải thiện prompt cho lần sau.
• Diễn tập (drill) định kỳ. Đừng để lần đầu agent thực hiện quy trình này là một incident thật — chạy thử với một "incident giả lập" trong channel sandbox mỗi quý để cả team quen với cách agent tham gia vào quy trình, và để phát hiện sớm nếu cấu hình MCP, scope, hoặc permission có vấn đề.
• Giữ nguyên bản audit đầy đủ. Với các ngành có yêu cầu compliance (fintech, healthcare), lưu lại toàn bộ log agent tạo ra trong incident (bao gồm cả tool call thô, không chỉ nội dung hiển thị) — có thể cần cho việc audit sau này.

Mẹo: Sau mỗi incident thật đã dùng agent hỗ trợ, dành 5 phút hỏi ngược lại chính agent: "Nhìn lại toàn bộ quy trình vừa xử lý, có bước nào tôi có thể cải thiện prompt hoặc cấu hình MCP để lần sau agent hỗ trợ tốt hơn?" — câu trả lời thường chỉ ra rất cụ thể những chỗ system prompt còn thiếu ràng buộc.