Vấn đề
Cứ có sự cố là lặp lại đúng chuỗi thao tác cũ: dựng lại một booking hỏng từ bốn
nguồn log khác nhau, chạy SQL vào một DB production mà client mysql chuẩn còn
không kết nối nổi, drive tay một pipeline CI manual để deploy, hoặc provision
một nhà cung cấp mới qua hai codebase và một bảng DB.
Toàn bộ chuỗi đó nằm trong đầu một người. Ai hỏi thì người đó trả lời. Người đó nghỉ thì tắc.
Cách làm
Mỗi quy trình thành một file có định dạng cố định: khai báo tham số, khai báo chính xác những tool nó được phép đụng vào, và thân file là runbook kèm những cái bẫy đã từng tốn hàng giờ.
Điểm mấu chốt là guardrail được cơ khí hoá, không phải ghi chú:
- Ghi vào DB production thì phải đếm blast radius trước, phải in ra hostname và trạng thái read-only của đúng server đang kết nối rồi mới hỏi xác nhận.
- Consent hết hạn ngay trong lượt đó — "lần trước họ đồng ý rồi" không tính.
- Deploy prod phải gõ xác nhận, và không được báo đã deploy trước khi lệnh chờ pipeline trả về thành công.
- Lệnh cần
sudothì đưa cho người chạy, không tự chạy.
Phần nặng nhất là một pipeline đa agent để dựng tài liệu mapping API nhà cung
cấp: session chính chỉ làm orchestrator với whitelist cứng những gì được đọc,
mọi việc nội dung nằm trong 6 subagent có model và tool riêng, một script Python
tất định chạy trước mọi reviewer LLM (vì script không tự bào chữa được),
reviewer bị bịt mắt và được giao nhiệm vụ phản bác, còn người sửa là một agent
khác chỉ có quyền Edit.
Kết quả
~70 runbook riêng biệt trên 3 repo cài được bằng symlink — git pull là update.
6 subagent role, 9 MCP server nối ở mức từng tool, và 5 job chạy nền không tương
tác để ghi worklog và báo cáo tuần, có validate output trước khi ghi vào file
tracked.
Chi phí được theo dõi trong một file ghi mọi con số kèm nhãn đo-được hay ước-lượng, ngày và nguồn — trong đó có một lần tối ưu thất bại được ghi lại đầy đủ kèm phép tính hoàn vốn.
Không có con số "tiết kiệm X giờ" nào ở đây, vì không đo được thì không viết.