AI SRE Arena: Chuẩn đánh giá mở cho các tác nhân AI vận hành Kubernetes

Edge Delta vừa giới thiệu Project Arena, một khung đánh giá mã nguồn mở cho phép triển khai môi trường Kubernetes dùng một lần, tiêm lỗi nhân tạo và chấm điểm các cuộc điều tra sự cố do tác nhân AI thực hiện. Đây là nỗ lực nhằm tạo ra một tiêu chuẩn trung lập, có thể tái lập để đo lường năng lực thực tế của các công cụ AI trong vai trò kỹ sư độ tin cậy (SRE).

Bối cảnh: AI đang thay đổi vận hành hạ tầng

Trong vài năm qua, làn sóng AI tác nhân (agentic AI) đã len vào mọi tầng của ngăn xếp công nghệ, và vận hành hạ tầng là một trong những lĩnh vực hứa hẹn nhất. Thay vì chỉ hiển thị dashboard và cảnh báo, các sản phẩm mới tuyên bố có thể tự động điều tra nguyên nhân gốc rễ, xác định phạm vi ảnh hưởng và đề xuất cách khắc phục.

Vấn đề nằm ở chỗ: gần như không có cách nào để kiểm chứng những tuyên bố đó một cách khách quan. Mỗi nhà cung cấp công bố benchmark riêng, với kịch bản riêng và tiêu chí riêng. Project Arena ra đời để lấp khoảng trống này.

"Arena là điểm khởi đầu trung lập về nhà cung cấp cho việc triển khai môi trường Kubernetes dùng một lần, tiêm lỗi, lưu bản ghi điều tra từ bất kỳ sản phẩm nào và chấm điểm các cuộc điều tra đã hoàn thành bằng một giám khảo có thể cấu hình." — mô tả dự án

Cách hoạt động

Quy trình của Project Arena gồm bảy bước rõ ràng:

• Triển khai cụm và ứng dụng: chọn giữa kind cục bộ hoặc AWS EKS
• Kết nối sản phẩm: cài đặt collector và cấu hình cảnh báo theo hướng dẫn của từng nhà cung cấp
• Tiêm và xác minh lỗi: áp dụng manifest lỗi, xác nhận lỗi thực sự xảy ra
• Để sản phẩm điều tra: tác nhân AI phân tích log, sự kiện, trạng thái pod
• Lưu bản ghi điều tra: xuất file final.txt, intermediate.txt, actions.txt
• Chấm điểm bằng giám khảo: mô hình AI so sánh với đáp án chuẩn
• So sánh kết quả: xuất báo cáo CSV theo từng chỉ số

Điểm đáng chú ý là dự án không tự động cài đặt tác nhân của nhà cung cấp nào, cũng không đăng nhập hay cấu hình cảnh báo thay người dùng. Nó chỉ cung cấp môi trường, kịch bản lỗi và khung chấm điểm — còn việc tích hợp sản phẩm là do bạn quyết định.

Hai bộ kịch bản: full và smoke

Project Arena cung cấp hai lựa chọn độc lập với loại cụm:

• Bộ đầy đủ (full): gồm 21 kịch bản sự cố Kubernetes, yêu cầu worker AMD64 và image ứng dụng dựng sẵn
• Bộ smoke: gồm 6 kịch bản, dùng image Python công khai, có thể chạy trên kind ARM64 gốc — phù hợp với Mac Apple Silicon

Một cảnh báo quan trọng cho người dùng Mac chip Apple Silicon: việc chỉ dựng image lỗi ARM64 không đủ để ứng dụng full tương thích ARM64. Muốn chạy bộ đầy đủ, bạn cần cụm EKS AMD64 hoặc build chéo bằng emulation.

Kết quả benchmark gây chú ý

Edge Delta đã chạy thử nghiệm so sánh ba cấu hình trên cùng 21 kịch bản, chấm bằng GPT-6-Astra:

Chỉ số	Edge Delta native	Grafana native	Claude + edx	Claude + gcx
Phát hiện	18/21 (85,7%)	12/21 (57,1%)	—	—
Phân tích nguyên nhân gốc	83,3%	75,0%	85,7%	90,5%
Phạm vi ảnh hưởng	66,7%	66,7%	85,7%	85,7%
Đề xuất khắc phục	44,4%	41,7%	76,2%	71,4%

Đáng chú ý, khi so trên cùng 12 sự cố mà cả hai sản phẩm native đều điều tra, khoảng cách thu hẹp đáng kể — cho thấy việc chọn tập kịch bản ảnh hưởng mạnh đến kết quả. Đây chính là lý do cần một benchmark chuẩn hóa.

Các chỉ số được chấm điểm

Năm chiều đánh giá chính:

• Phát hiện (Detection): sản phẩm có nhận ra sự cố và bắt đầu điều tra trong cửa sổ quan sát không
• Phân tích nguyên nhân gốc: báo cáo cuối có giải thích đúng nguyên nhân không
• Phạm vi ảnh hưởng: có xác định đúng workload bị ảnh hưởng mà không phóng đại không
• Đề xuất khắc phục được hỗ trợ: có đưa ra cách sửa cụ thể, an toàn, không còn lời khuyên sai lệch không
• Mức độ sẵn sàng triển khai: đề xuất có đủ chi tiết để đưa vào thực thi không

Ban tổ chức nhấn mạnh rằng các chỉ số này đo đề xuất, không đo việc sửa chữa đã thực thi hay phục hồi đã xác minh.

Điều này có ý nghĩa gì với cộng đồng kỹ sư Việt Nam?

Với các đội DevOps và SRE tại Việt Nam — đặc biệt những nhóm đang cân nhắc đầu tư vào công cụ AI để giảm gánh nặng trực on-call — Project Arena mang lại giá trị thiết thực:

• Tự đánh giá trước khi mua: bạn có thể chạy chính sản phẩm đang dùng thử trong môi trường kiểm soát, thay vì tin vào demo của nhà cung cấp
• Chi phí hợp lý: chỉ cần Python 3.10+, kubectl, Docker và kind là chạy được phiên bản cục bộ; bộ smoke thậm chí chạy được trên laptop ARM64
• Giấy phép MIT: hoàn toàn mở, có thể tùy biến rubric và kịch bản theo đặc thù hệ thống của mình
• Lưu ý chi phí AWS: nếu chọn EKS, hãy nhớ rằng terraform tạo subnet ở ba vùng sẵn sàng và việc reset lỗi không dừng phát sinh phí

Một điểm cần lưu ý: dự án dùng giám khảo là mô hình AI, nghĩa là kết quả phụ thuộc vào chất lượng đáp án chuẩn và rubric. Khi so sánh, phải giữ cùng rubric, cùng mô hình giám khảo và cùng nhóm kịch bản thì kết quả mới có ý nghĩa.

Thách thức còn bỏ ngỏ

Việc chấm điểm bằng AI vẫn là con dao hai lưỡi. Mô hình giám khảo có thể đánh giá sai, đặc biệt với các sự cố phức tạp đòi hỏi kiến thức ngầm về hệ thống. Ngoài ra, mỗi lần gọi API đều phát sinh chi phí, và việc tái tạo kết quả giữa các phiên bản mô hình khác nhau là bài toán chưa có lời giải trọn vẹn.

Tuy nhiên, hướng đi là đúng: minh bạch hóa tuyên bố của nhà cung cấp. Khi ngày càng nhiều đội ngũ dùng chung một thước đo, thị trường AI vận hành sẽ buộc phải cạnh tranh bằng năng lực thực thay vì marketing.

Dự án có sẵn trên GitHub dưới giấy phép MIT, kèm script offline test (python3 -m unittest discover -s tests -v) để kiểm chứng tính đúng đắn trước khi triển khai.