AI Agent Trong Vận Hành Hệ Thống: Từ Runbook Tĩnh Đến Tự Động Hóa Có Kiểm Soát

AI agent vận hành hệ thống không còn là ý tưởng xa vời. Trong vài năm gần đây, đội sysadmin/SRE đã quen với monitoring, log tập trung, CI/CD, Infrastructure as Code và ChatOps. Bước tiếp theo là dùng AI agent để đọc tín hiệu vận hành, đối chiếu runbook, đề xuất hành động và trong một số trường hợp tự thực hiện thao tác an toàn đã được giới hạn sẵn.

Nhưng “đưa AI vào production” không đồng nghĩa với việc trao quyền root cho một chatbot. Cách đúng là thiết kế AI agent như một thành phần vận hành có kiểm soát: có quyền tối thiểu, có phê duyệt khi rủi ro cao, có log, có rollback và có tiêu chí nghiệm thu rõ ràng. Bài viết này đi từ khái niệm đến một lab thực chiến để bạn có thể áp dụng cho hạ tầng Linux, Kubernetes hoặc WordPress production.

1. AI agent vận hành hệ thống là gì?

AI agent vận hành hệ thống là một tiến trình có khả năng nhận mục tiêu, đọc ngữ cảnh kỹ thuật, chọn công cụ phù hợp và thực hiện hoặc đề xuất bước tiếp theo. Khác với script truyền thống, agent có thể tổng hợp nhiều nguồn thông tin như alert Prometheus, log Nginx, trạng thái systemd, thay đổi Git gần nhất, ticket incident và runbook nội bộ.

Script: chạy đúng những gì đã viết, ít linh hoạt.
Runbook tĩnh: hướng dẫn con người xử lý, phụ thuộc kinh nghiệm người trực.
AI agent: đọc runbook, phân tích tình huống, gọi tool, ghi nhận kết quả, hỏi phê duyệt khi cần.

Điểm quan trọng: agent không thay thế kỷ luật vận hành. Nó khuếch đại quy trình tốt và cũng có thể khuếch đại quy trình tệ nếu bạn không giới hạn quyền.

2. Use case phù hợp cho sysadmin/SRE

2.1. Triage cảnh báo

Khi nhận alert “CPU high” hoặc “HTTP 5xx tăng”, agent có thể tự động thu thập dữ liệu ban đầu:

hostname
uptime
systemctl --failed
journalctl -u nginx --since "15 minutes ago" --no-pager | tail -80
ss -tulpn | head
free -h
df -h

Thay vì người trực mất 5 phút copy từng lệnh, agent gom output, tóm tắt điều bất thường và liên kết với thay đổi gần nhất.

2.2. Kiểm tra sau deploy

Sau mỗi lần deploy, agent có thể chạy smoke test, kiểm tra status code, log lỗi và metric latency:

curl -I https://example.com/
curl -fsS https://example.com/healthz
journalctl -u php8.3-fpm --since "10 minutes ago" --no-pager | grep -i fatal || true

Output mẫu:

HTTP/2 200
healthz: ok
No PHP fatal errors in last 10 minutes

2.3. Đề xuất rollback có kiểm soát

Nếu p95 latency tăng mạnh ngay sau deploy, agent có thể đề xuất rollback về release trước, nhưng không tự đổi production nếu policy yêu cầu approval.

3. Kiến trúc an toàn: agent không được toàn quyền

Một thiết kế production nên tách thành bốn lớp:

Context layer: monitoring, logs, inventory, runbook, changelog.
Tool layer: các lệnh được whitelist, API nội bộ, script kiểm tra.
Policy layer: quy định hành động nào được chạy tự động, hành động nào cần phê duyệt.
Audit layer: lưu prompt, tool call, output, người phê duyệt và kết quả.

Ví dụ policy đơn giản:

read_only:
  - systemctl status *
  - journalctl --since *
  - kubectl get *
  - curl -I *

low_risk_auto:
  - cache warmup
  - restart non-critical worker in staging
  - create incident summary

requires_approval:
  - systemctl restart nginx
  - kubectl rollout undo deployment/*
  - wp plugin update --all
  - modify firewall rule

forbidden:
  - rm -rf /
  - dump secrets
  - disable audit logging

Đừng chỉ dựa vào lời nhắc “đừng làm bậy”. Hãy giới hạn ở tầng tool, user permission, sudoers, network ACL và approval workflow.

4. Lab: agent hỗ trợ điều tra lỗi Nginx 502

Giả sử website thỉnh thoảng trả 502. Ta chuẩn bị một runbook ngắn:

# runbooks/nginx-502.md
1. Kiểm tra Nginx có đang chạy không.
2. Kiểm tra upstream PHP-FPM hoặc app backend.
3. Xem error log trong 15 phút gần nhất.
4. Kiểm tra disk, memory, connection.
5. Nếu PHP-FPM chết, đề xuất restart và yêu cầu approval.
6. Sau khi xử lý, curl lại URL và ghi incident summary.

Nhóm lệnh read-only mà agent được phép chạy:

systemctl is-active nginx
systemctl is-active php8.3-fpm
journalctl -u nginx --since "15 minutes ago" --no-pager | tail -100
journalctl -u php8.3-fpm --since "15 minutes ago" --no-pager | tail -100
df -h
free -m
curl -I https://example.com/

Khi phát hiện php8.3-fpm không active, phản hồi tốt của agent không phải là tự restart ngay, mà là:

Phát hiện: nginx active, php8.3-fpm failed.
Bằng chứng: journalctl có lỗi "child exited on signal 11".
Tác động: request PHP có thể trả 502.
Đề xuất: restart php8.3-fpm, sau đó kiểm tra HTTP 200 và log fatal.
Yêu cầu phê duyệt: systemctl restart php8.3-fpm

Sau khi được phê duyệt, thao tác có thể chạy:

sudo systemctl restart php8.3-fpm
systemctl is-active php8.3-fpm
curl -I https://example.com/

Output kỳ vọng:

active
HTTP/2 200

5. Logging và audit: thứ bắt buộc nếu có agent

Mỗi tool call của agent nên lưu:

Thời gian chạy.
Người hoặc hệ thống kích hoạt.
Mục tiêu incident/ticket.
Lệnh/API được gọi.
Output đã lọc bí mật.
Quyết định policy: auto, requires approval, denied.
Người phê duyệt nếu có.

Audit log giúp trả lời câu hỏi sau incident: agent đã thấy gì, vì sao đề xuất hành động đó, có ai phê duyệt, và kết quả thực tế ra sao.

6. Observability cho chính AI agent

Agent cũng là một service production nên cần giám sát. Tối thiểu hãy có metric:

Số incident được triage mỗi ngày.
Tỷ lệ đề xuất đúng/sai theo đánh giá sau sự cố.
Số hành động bị policy chặn.
Thời gian trung bình từ alert đến summary đầu tiên.
Số lần cần con người can thiệp.
Lỗi tool, timeout, rate limit.

Nếu agent thường xuyên đề xuất sai, vấn đề có thể nằm ở runbook thiếu, metric nhiễu, quyền quá rộng hoặc context không đủ.

7. Các lỗi thường gặp khi triển khai

7.1. Cho quyền quá rộng

Chạy agent bằng user có sudo full là lỗi nghiêm trọng. Hãy tạo user riêng, chỉ cho phép lệnh cần thiết qua sudoers và bắt approval cho thay đổi production.

7.2. Không lọc secret

Log vận hành có thể chứa token, DSN, cookie hoặc header nhạy cảm. Cần cơ chế redaction trước khi đưa vào agent hoặc lưu audit.

7.3. Runbook mơ hồ

Runbook kiểu “kiểm tra server” không đủ. Hãy viết điều kiện, lệnh, output kỳ vọng, ngưỡng quyết định và rollback.

7.4. Không có rollback

Nếu agent có thể thay đổi trạng thái hệ thống, mỗi hành động cần đường lùi: restart service nào, rollback release nào, restore config nào, ai chịu trách nhiệm.

8. Checklist nghiệm thu trước khi đưa vào production

Agent chạy bằng user riêng, quyền tối thiểu.
Danh sách tool được whitelist, không cho chạy shell tùy ý nếu không cần.
Hành động rủi ro cao bắt buộc approval.
Có audit log bất biến hoặc khó chỉnh sửa.
Secret được redaction khỏi prompt, output và log.
Runbook có lệnh cụ thể, output mẫu, điều kiện dừng.
Đã test trên staging hoặc lab giả lập incident.
Có metric theo dõi chất lượng đề xuất của agent.
Có cơ chế tạm dừng/disable agent khi có bất thường.

9. Bài tập lab cuối bài

Hãy dựng một VM Ubuntu nhỏ và triển khai Nginx + PHP-FPM hoặc một app demo. Sau đó:

Tạo runbook xử lý HTTP 502.
Viết script chỉ chạy nhóm lệnh read-only.
Giả lập lỗi bằng cách stop PHP-FPM.
Yêu cầu agent tạo incident summary và đề xuất bước xử lý.
Chỉ cho phép restart sau khi bạn phê duyệt.
Kiểm tra lại HTTP 200 và lưu báo cáo sau xử lý.

Khi lab này chạy ổn, bạn có thể mở rộng sang Kubernetes rollout, WordPress plugin update, backup verification hoặc kiểm tra chứng chỉ SSL sắp hết hạn.

Kết luận

AI agent vận hành hệ thống hữu ích nhất khi được đặt trong khuôn khổ sysadmin/SRE nghiêm túc: quyền tối thiểu, runbook rõ, quan sát đầy đủ, phê duyệt cho hành động nguy hiểm và rollback luôn sẵn sàng. Nếu làm đúng, agent giúp giảm thời gian triage, chuẩn hóa thao tác trực ca và biến kiến thức vận hành thành quy trình có thể lặp lại. Nếu làm ẩu, nó chỉ là một công cụ tự động hóa rủi ro cao hơn cron job.