Bài 1 — Agent DevOps là gì và khi nào nên dùng

Một AI agent DevOps không phải là chatbot trả lời câu hỏi. Nó là một vòng lặp: quan sát (observe) → suy luận (reason) → hành động (act) → kiểm tra kết quả. Agent nhận tín hiệu từ hệ thống (log, alert, trạng thái deploy), quyết định việc cần làm, rồi gọi công cụ (tool) như kubectl, GitHub API, PagerDuty để thực thi — thay vì chỉ gợi ý cho con người.

Phân biệt 3 cấp độ tự động hóa

• Script cứng (automation truyền thống): if-else cố định. Nhanh, rẻ, nhưng gãy khi gặp tình huống chưa lường trước.
• Copilot (agent gợi ý): agent phân tích và đề xuất, con người bấm nút thực thi. An toàn, phù hợp giai đoạn đầu.
• Autonomous (agent tự hành): agent tự quyết và tự làm trong phạm vi cho phép. Chỉ dùng cho hành động có thể đảo ngược (reversible) và có guardrail chặt.

Ví dụ cụ thể

Alert HighErrorRate bắn lúc 2h sáng. Thay vì đánh thức kỹ sư on-call:

• Agent đọc alert, truy vấn log 15 phút gần nhất, phát hiện lỗi 502 tăng vọt sau deploy v2.3.1.
• Agent so khớp với runbook "error spike sau deploy", đề xuất rollback.
• Nếu bật chế độ autonomous cho rollback (một hành động an toàn), agent tự chạy kubectl rollout undo, xác minh error rate giảm, rồi mở ticket tóm tắt.

Các bước đánh giá một use case có nên giao cho agent

• Hành động có đảo ngược được không? Rollback deploy: có. Xóa database production: không — cấm agent làm.
• Tín hiệu đầu vào có rõ ràng không? Có metric/log định lượng thì agent quyết tốt. Chỉ có cảm tính "hệ thống chậm" thì khó.
• Tần suất và độ lặp lại? Việc lặp đi lặp lại (restart pod, clear cache) là ứng viên tốt. Việc hiếm và phức tạp nên để người.
• Chi phí khi sai? Ước lượng thiệt hại nếu agent quyết sai. Cao thì bắt buộc human-in-the-loop.
• Có runbook/tài liệu chuẩn không? Agent học tốt nhất từ runbook đã được viết rõ.

Khung tư duy: Ma trận Rủi ro × Tần suất

              Tần suất THẤP        Tần suất CAO
Rủi ro CAO   | Người quyết      | Agent đề xuất + duyệt
Rủi ro THẤP  | Agent đề xuất    | Agent tự hành (autonomous)

Bắt đầu ở ô "tự hành" (rủi ro thấp, tần suất cao) để tạo niềm tin, rồi mở rộng dần.

Kiến trúc tối giản của một agent

agent:
  trigger: alert_webhook   # điều gì đánh thức agent
  context:
    - logs_last_15m
    - deploy_history
    - service_status
  tools:
    - kubectl_rollout_undo
    - query_logs
    - open_incident
  policy:
    autonomous_actions: [restart_pod, clear_cache]
    require_approval: [rollback, scale_down]
    forbidden: [delete_db, drop_table]

Sai lầm thường gặp

• Giao ngay hành động không thể đảo ngược cho agent tự chạy. Luôn bắt đầu bằng copilot, không autonomous.
• Không định nghĩa forbidden list. Agent sáng tạo ngoài ý muốn — phải chặn cứng các hành động chết người.
• Kỳ vọng agent thay thế toàn bộ SRE. Agent xử lý việc lặp lại; con người vẫn giữ phán đoán chiến lược.
• Không có cơ chế audit. Mọi hành động agent phải log lại để truy vết khi có sự cố.
• Chọn use case mơ hồ đầu tiên. Hãy chọn việc hẹp, đo được, rủi ro thấp để chứng minh giá trị trước.

So sánh nhanh: agent vs script truyền thống

Hãy tưởng tượng cùng một alert PodCrashLoop. Script truyền thống sẽ restart pod N lần rồi bỏ cuộc — nó không biết vì sao pod chết. Agent thì khác: nó đọc log crash, nhận ra OOMKilled, suy ra pod thiếu memory, và đề xuất tăng memory limit thay vì restart vô ích. Sự khác biệt nằm ở khả năng suy luận từ ngữ cảnh thay vì chạy theo kịch bản cứng. Đây chính là lý do agent tỏa sáng ở những tình huống "biến thể" mà script không lường trước được.

Một hiểu lầm phổ biến cần gạt bỏ

Nhiều người nghĩ agent DevOps nghĩa là "để LLM tự do gõ lệnh vào production". Sai. Agent thực chiến là một hệ thống có ranh giới rõ: LLM chỉ đóng vai bộ não suy luận trong một cái lồng guardrail được thiết kế kỹ. Phần thực thi vẫn là các tool được kiểm soát chặt. Bạn không giao chìa khóa cả nhà cho agent — bạn giao cho nó vài công cụ cụ thể trong một căn phòng có camera và cửa khóa.

Tóm tắt

Agent DevOps mạnh khi tín hiệu rõ, hành động đảo ngược được, và có guardrail. Đừng bắt đầu bằng tham vọng "agent tự vận hành mọi thứ"; hãy bắt đầu bằng một việc nhỏ, đo được, và mở rộng theo ma trận rủi ro × tần suất. Trong các bài tiếp theo, chúng ta sẽ lần lượt dựng nền tảng an toàn, cấp giác quan, rồi xây từng loại agent thực chiến.