Một trợ lý vận hành bằng AI đã đảm nhận nhiệm vụ trực (on-call) của tôi trong bảy ngày, xử lý 11 cảnh báo và cắt giảm thời gian trung bình để khắc phục sự cố từ 45 phút xuống còn 20 phút. Thí nghiệm này có ý nghĩa quan trọng vì một mô hình ngôn ngữ với phạm vi vừa phải có thể tiết kiệm được nửa giờ trong việc ứng phó sự cố trong khi vẫn đòi hỏi sự giám sát chặt chẽ của con người.

Tại sao tôi lại để AI trực on-call

Các đội ngũ Cloud dành phần lớn ca làm việc để đào sâu vào các bản ghi (logs), kiểm tra các đợt triển khai (deployments) gần đây và xác nhận xem một yêu cầu mở rộng (scaling request) có an toàn hay không. Những tác vụ "nhàm chán" đó có tính lặp lại, nặng về dữ liệu và dễ gây mệt mỏi cho con người. Những tiến bộ gần đây trong các mô hình ngôn ngữ lớn hứa hẹn sẽ tự động hóa chính xác công việc đối soát khuôn mẫu (pattern-matching) đó, nhưng hầu hết các bản demo công khai đều chạy trong môi trường sandbox. Tôi muốn xem liệu sự kỳ vọng đó có trụ vững được trong một cụm (cluster) cấp độ sản xuất (production-grade) thực sự phục vụ các khách hàng trả phí hay không.

Thiết lập thử nghiệm

  • Quyền truy cập – Agent có thể đọc mọi chỉ số (metric), log và định nghĩa triển khai. Nó chỉ có quyền ghi vào một danh sách trắng (whitelist) hẹp: khởi động lại một pod, tăng số lượng bản sao (replica count) hoặc mở rộng một deployment. Bất kỳ hành động nào nằm ngoài những việc này đều cần sự phê duyệt rõ ràng của tôi.
  • Vai trò – Tôi coi mô hình này như một kỹ sư cấp thấp (junior engineer) trong ca trực đầu tiên. Nó nhận cảnh báo, thực hiện phân tích và đăng đề xuất vào kênh xử lý sự cố (incident channel).
  • Lưới an toàn – Tất cả các hành động ghi đều được kiểm soát thông qua một yêu cầu xác nhận "có/không" thủ công. Tôi cũng giới hạn mức sử dụng token của mô hình để giữ cho chi phí có thể dự đoán được.

Nơi AI tỏa sáng

Tốc độ của agent là lợi ích đáng chú ý nhất. Ngay khi một cảnh báo được kích hoạt, nó sẽ truy xuất các log liên quan, vẽ biểu đồ các chỉ số gần đây và liệt kê ba đợt triển khai cuối cùng. Vào lúc tôi mở laptop lên, công việc điều tra ban đầu đã được hoàn tất. Trong số 11 cảnh báo:

  • 8 là các vấn đề thông thường (tăng vọt bộ nhớ, khởi động lại container, lỗi cấu hình đơn giản). AI đã xác định chính xác nguyên nhân gốc rễ trong mỗi lần.
  • Nó đã cảnh báo tình trạng tăng bộ nhớ dần dần trong một microservice trước khi vấn đề leo thang thành một sự cố ngừng hoạt động vào lúc 2 giờ sáng, giúp đội ngũ có cơ hội can thiệp sớm.
  • Mức tiêu thụ token cho cả tuần duy trì ở mức khoảng 30 USD, nằm trong ngân sách trực on-call thông thường khi được giới hạn.

Những kết quả này chuyển hóa thành sự sụt giảm có thể đo lường được về thời gian khắc phục trung bình (MTTR) từ 45 phút xuống còn 20 phút, giúp các kỹ sư có thể tập trung vào những công việc có tác động cao hơn.

Nơi nó vấp ngã

Sự tự tin không đồng nghĩa với sự chính xác. AI đã sai một cách đầy tự tin trong 3 trên 11 cảnh báo:

  1. Nó đổ lỗi cho một đợt triển khai mã nguồn gần đây về lỗi kết nối cơ sở dữ liệu, nhưng lời giải thích đó là sai.
  2. Khi đối mặt với một bất thường về mạng lạ lẫm, nó đã đưa ra các cách khắc phục chung chung mà không giải quyết được vấn đề cốt lõi.
  3. Trong một cảnh báo liên quan đến tải (load), nó đã đề xuất mở rộng một dịch vụ từ 3 lên 30 bản sao. Vấn đề không phải là tải; mà là do một cấu hình lỗi.

Vì các rào chắn (guardrails) của tôi yêu cầu phê duyệt thủ công cho bất kỳ thao tác ghi nào, nên những sai lầm của mô hình đã được phát hiện trước khi chúng có thể gây ra thiệt hại. Tuy nhiên, sự việc này đã làm nổi bật một rủi ro cốt lõi: mô hình có thể đưa ra những đề xuất nghe có vẻ hợp lý nhưng không chính xác, đặc biệt là đối với các vấn đề mới lạ.

Quản lý chi phí và rủi ro

Hóa đơn token 30 USD cho thấy việc chạy một LLM trong vòng lặp sản xuất có thể rất rẻ nếu việc sử dụng được giám sát. Tuy nhiên, chi phí thực sự nằm ở rủi ro vận hành. Việc mở rộng sai lệch một deployment có thể dẫn đến chi phí đám mây tăng vọt không kiểm soát, và việc hoàn tác (rollback) một bản phát hành tốt có thể làm xói mòn lòng tin của khách hàng. Thí nghiệm đã củng cố hai biện pháp bảo vệ:

  • Kiểm soát hành động (Action gating) – Chỉ cho phép mô hình đề xuất, tuyệt đối không được thực thi các thay đổi có tác động cao mà không có một cú nhấp chuột của con người.
  • Giới hạn ngân sách (Budget caps) – Thiết lập các giới hạn cứng về mức tiêu thụ token và cảnh báo cho đội ngũ khi mô hình tiến gần đến ngưỡng giới hạn.

Những điều cần theo dõi tiếp theo

Cho đến lúc đó, các đội ngũ nên:

  • Theo dõi tỷ lệ các đề xuất do AI tạo ra cần phải can thiệp thủ công (manual override).
  • Đo lường tác động lên MTTR trên các danh mục sự cố khác nhau (thông thường so với mới lạ).
  • Kiểm tra mô hình trong môi trường staging với các cảnh báo giả lập trước khi cấp bất kỳ quyền ghi nào trên môi trường production.

Bài học rút ra cho các đội ngũ vận hành (ops teams)

  • Tự động hóa 80% những việc nhàm chán – Sử dụng AI để tổng hợp log, tương quan các chỉ số và tạo các giả thuyết ban đầu.
  • Dành 20% rủi ro cho con người – Việc mở rộng vượt quá một ngưỡng vừa phải, hoàn tác (rollback) và xóa bỏ nên được thực hiện sau một bước phê duyệt thủ công.
  • Coi mô hình là một cộng sự, không phải sự thay thế – Một kỹ sư am hiểu hệ thống có thể xác thực kết quả của AI nhanh hơn một người mới, biến trợ lý này thành một nhân tố nhân bội sức mạnh (force multiplier).

Một tác nhân AI chưa thể tự mình vận hành các hoạt động đám mây, nhưng với vai trò là đối tác hỗ trợ phân loại, nó đã mang lại những cải thiện đáng kể về tốc độ. Chìa khóa là phải kiểm soát mức độ tin cậy, thiết lập các rào chắn kiểm soát nghiêm ngặt, và để mô hình xử lý các công việc lặp đi lặp lại, trong khi chuyên môn của con người sẽ dẫn dắt các quyết định quan trọng.