Bài toán

Khi một dịch vụ sập hoặc chậm đột ngột, phần lớn thời gian đầu của người trực không dùng để sửa — mà dùng để thu thập bối cảnh: dò log từng service, đoán nguyên nhân, đối chiếu xem có ai vừa deploy gì không.

Công cụ theo dõi trả lời được "có gì đó sai". Nó không trả lời được sai cái gì và nên làm gì trước. Khoảng trống đó hiện do con người lấp bằng kinh nghiệm — thường là lúc 2 giờ sáng.

Tệ hơn: có loại sự cố mà số đo nói ngược sự thật. Ví dụ deploy thiếu migration — 100% request lỗi, nhưng p95 chỉ 0,048 giây, nhanh hơn lúc bình thường, vì request chết ngay ở câu lệnh đầu. Nhìn số đo là không thể đoán ra.

Giải pháp kỹ thuật

Agent chạy vòng quét trên LangGraph, 8 node, quét Prometheus mỗi 10 giây:

1. Phát hiện — 6 luật viết theo triệu chứng, không theo loại lỗi: chậm hơn thường ngày · lỗi 5xx · pool cạn · service chết · burst đăng nhập · mất tín hiệu đo lường. Nhờ vậy loại sự cố chưa ai viết luật cho nó vẫn bắt được nếu gây ra một trong sáu triệu chứng.
2. Chẩn đoán — luật nêu bằng chứng trước, LLM chỉ diễn giải thành câu. Khi số đo không đủ, Agent nói thẳng "chưa đủ bằng chứng để nêu nguyên nhân gốc" thay vì đoán, rồi đọc log service — chỗ duy nhất chứa thông tin mà số đo không có.
3. Đề xuất — kèm runbook từng bước và phần rủi ro, đối chiếu lịch sử deploy để biết rollback về đâu.
4. Cổng người duyệt — LangGraph dừng hẳn, không có edge tự động đi tiếp. Cổng kiểm changelog Jira: người chuyển trạng thái mà trùng account Agent thì từ chối thi hành.
5. Tự đo lại — sau khắc phục, Agent chạy đúng những truy vấn đã phát hiện sự cố, nên "đã hồi phục" cùng một định nghĩa với "phát hiện". Nếu chưa đỡ, nó nói "chẩn đoán ban đầu có thể sai" thay vì báo thành công.

Vòng đời sự cố dùng Jira Cloud làm lớp lưu trữ: war room là issue, phê duyệt là workflow transition, dấu vết kiểm toán là changelog — thứ Agent không sửa được. Không tự xây CRUD, phân quyền, audit log.

Tính khả thi

Đã chạy end-to-end trên hạ tầng thật, không mô phỏng:

• Khắc phục thật: rollback trên service thanh toán — tỷ lệ lỗi 100% → 0%, 120/120 request thành công. Số đọc từ Prometheus.
• Phát hiện → đề xuất kèm runbook: 39 giây.
• Đo trên 50 tình huống dựng lại từ số đo thật: bắt được 21/25 sự cố, báo nhầm 5/25, xếp đúng mức độ 17/21.