Bài 8 — Vận hành production: giám sát, gỡ lỗi và mở rộng

Agent chạy trên laptop khác xa agent phục vụ hàng trăm người dùng. Bài cuối bàn về việc đưa MCP server/agent vào production và giữ nó khỏe mạnh.

1. Chiến lược gỡ lỗi phân tầng

Khi agent "trả lời sai", lỗi có thể ở nhiều tầng. Cô lập theo thứ tự:

• Server một mình: dùng MCP Inspector gọi trực tiếp tool. Tool trả đúng không?
• Client kết nối: tools/list có ra đủ tool? Handshake OK?
• Model chọn tool: model có gọi đúng tool với tham số hợp lý? Nếu sai → sửa description.
• Diễn giải kết quả: model hiểu đúng kết quả trả về không?

> Khung tư duy: đi từ dưới lên (tool → client → model). Đừng sửa prompt khi lỗi thực ra nằm ở tool trả sai dữ liệu.

2. Logging & observability

Ghi log mỗi lời gọi tool: tên tool, tham số (che secret), thời gian, kết quả/lỗi, độ trễ, người dùng.

[2026-06-27 10:12] user=42 tool=orders_query args={phone:***} latency=120ms status=ok
[2026-06-27 10:12] user=42 tool=email_send status=denied reason=no_scope

Nhớ: với stdio, log đi stderr (bài 3). Với HTTP, đẩy log về hệ thống tập trung (ELK, CloudWatch...).

3. Xử lý lỗi & độ ổn định

• Timeout mỗi tool call; đừng để agent treo vì một API chậm.
• Retry có backoff cho lỗi tạm thời (mạng), KHÔNG retry cho lỗi logic (tham số sai).
• Fail rõ ràng: trả message lỗi để model tự xử lý (hỏi lại, thử cách khác).
• Circuit breaker: nếu một server hỏng liên tục, tạm ngắt để không kéo sập cả agent.

4. Hiệu năng & chi phí

• Giới hạn kích thước output tool: trả dữ liệu đã lọc, không phải cả bảng → tiết kiệm context/token.
• Cache kết quả resource ít đổi (chính sách, cấu hình).
• Giới hạn số vòng lặp agent để chặn chi phí runaway.
• Chọn transport đúng: HTTP cho phép scale ngang (nhiều instance sau load balancer).

5. Versioning & tương thích

Hệ thống nội bộ thay đổi. Khi sửa tool:

• Giữ tương thích ngược: đừng đột ngột đổi tên/tham số tool đang được agent dùng.
• Cần đổi lớn → thêm tool mới (query_orders_v2) song song, chuyển dần rồi mới gỡ cái cũ.
• Cập nhật description khi hành vi đổi, để model chọn đúng.

6. Các bước đưa lên production

• Kiểm thử từng server bằng Inspector + test tự động cho logic tool.
• Bật bảo mật (bài 6): auth, phân quyền, audit log.
• Chọn transport HTTP + đặt sau reverse proxy/HTTPS nếu chia sẻ.
• Thêm timeout, retry, rate limit.
• Cắm observability: log, metric (tần suất gọi, tỉ lệ lỗi, độ trễ).
• Chạy thử với nhóm nhỏ (canary) trước khi mở rộng.
• Lập runbook: server chết thì làm gì, ai được cấp quyền gì.

Checklist sẵn sàng production

• [ ] Test tự động cho logic tool.
• [ ] Auth + phân quyền + audit log bật đầy đủ.
• [ ] Timeout, retry, rate limit, giới hạn vòng lặp.
• [ ] Logging tập trung + metric lỗi/độ trễ.
• [ ] Giới hạn kích thước output, có cache khi hợp lý.
• [ ] Chiến lược versioning tool.
• [ ] Runbook sự cố + kế hoạch rollback.

Sai lầm thường gặp

• Deploy stdio server "tạm" lên production cho nhiều người dùng → không scale, không auth. Chuyển sang HTTP có bảo mật.
• Không có observability → agent hỏng âm thầm, phát hiện qua khiếu nại người dùng.
• Đổi tool đột ngột phá vỡ agent đang chạy → luôn versioning và tương thích ngược.
• Trả output khổng lồ → hóa đơn token phình to, model chậm và rối.
• Không giới hạn vòng lặp/không circuit breaker → một server lỗi kéo sập toàn bộ trải nghiệm.

Tổng kết khóa học

Bạn đã đi trọn hành trình: hiểu MCP (bài 1), kiến trúc & transport (2–3), tự xây server với tool và resource (4–5), cứng hóa bảo mật (6), nối agent end-to-end (7), và vận hành production (8). Bây giờ bạn có đủ nền tảng để kết nối agent với công cụ và dữ liệu nội bộ theo chuẩn hóa, an toàn và mở rộng được. Hãy bắt đầu bằng một server nhỏ, một tool thật của công việc bạn — rồi lớn dần.