Chẩn đoán SRE bằng Jev: Điều gì hiệu quả và điều gì thất bại

Trong nghiên cứu trước, nhóm tác giả đã thử dùng Jev như một công cụ hỗ trợ ra quyết định cho một LLM agent chẩn đoán và sửa sự cố. Lần này, họ tiến xa hơn: xây dựng một pipeline chẩn đoán hoàn toàn do Jev dẫn dắt, không cần bất kỳ LLM agent nào.

Kết quả khá ấn tượng: trên 21 kịch bản lỗi của SREGym-Lite, pipeline vượt qua 80/105 chẩn đoán (tương đương 76,2%), với thời gian chẩn đoán trung vị chỉ 14,6 giây. Đáng chú ý hơn, tỷ lệ này gần bằng GPT-5.6 Sol (medium) ở mức 77,8%, nhưng chạy nhanh hơn khoảng 7 lần và rẻ hơn khoảng 200 lần mỗi chẩn đoán.

Sơ đồ luồng chẩn đoán của pipeline

Pipeline chẩn đoán hoạt động như thế nào?

Điểm mấu chốt cần hiểu về Jev: nó trả lời câu hỏi bằng cách chọn từ một tập lựa chọn được cung cấp sẵn. Vì vậy, muốn dùng Jev để chẩn đoán, ta phải đưa cho nó cả bằng chứng lẫn các câu trả lời khả dĩ.

Pipeline mới bổ sung một bộ thu thập tự động để biến trạng thái của cụm Kubernetes thành các đầu vào đó. Quy trình diễn ra theo các bước:

• Bộ thu thập đọc các đối tượng Kubernetes, sự kiện, log pod gần đây và mức sử dụng tài nguyên. Nó nhóm các quan sát theo thành phần (ví dụ một Deployment) rồi tóm tắt dấu hiệu lỗi.
• Jev nhận các bản tóm tắt này và chọn thành phần có khả năng là nguồn gốc để điều tra sâu hơn.
• Bộ thu thập sau đó gom chi tiết về thành phần đó và chuẩn bị các mục bằng chứng được đánh số.
• Jev quyết định thành phần đó là nguồn gốc, nạn nhân gián tiếp hay không liên quan, đồng thời chọn bằng chứng hỗ trợ tốt nhất.
• Pipeline dùng các lựa chọn này để lắp ghép và nộp chẩn đoán. Nếu bằng chứng không đủ hỗ trợ giả thuyết, nó chuyển sang ứng viên khác.

Cần lưu ý: phiên bản này điều tra từng ứng viên một. Jev chỉ chọn trong các lựa chọn được đưa ra, không tự sinh lệnh cũng không viết báo cáo cuối cùng. Mã nguồn của pipeline đã được công bố trên GitHub.

Ví dụ thực tế: webhook ghi đè giới hạn bộ nhớ

Hãy xem lỗi mutating_webhook_resource_limits_social_network trong ứng dụng Social Network. Trong kịch bản này, các pod tạo cho nginx-thrift liên tục hết bộ nhớ. Template của Deployment quy định giới hạn 256Mi, nhưng pod mới chỉ có 16Mi. Nguyên nhân là một mutating admission webhook đã viết lại giới hạn ngay khi pod được tạo. Có tới bốn cấu hình webhook khác cùng tồn tại, nên chỉ tìm theo tên webhook sẽ không xác định được thủ phạm.

Bộ thu thập tìm thấy 27 Deployment trong social-network và tóm tắt từng cái. Với nginx-thrift, nó phát hiện sự khác biệt giữa pod và template, đồng thời nhận diện webhook khớp. Bản tóm tắt rút gọn mà Jev thấy ở lần gọi đầu tiên gồm:

• Pod bị OOMKilled và khởi động lại.
• Giới hạn bộ nhớ của pod đang chạy: 16Mi (template Deployment: 256Mi).
• Webhook khớp với việc tạo pod: gatekeeper-mutating-webhook-configuration.

Jev sau đó trả lời hai câu hỏi lựa chọn:

Câu hỏi: Thành phần nào có khả năng là nguồn gốc? Jev: deployment/nginx-thrift

Câu hỏi: Loại đối tượng nào mang lỗi? Jev: admission_webhook

Sự không khớp về giới hạn bộ nhớ và webhook trùng khớp trong bản tóm tắt đã hỗ trợ lựa chọn thứ hai.

Tiếp đó, pipeline gom thêm chi tiết và đưa cho Jev 26 mục bằng chứng, trong đó có hai mục then chốt:

• E6: Pod nginx-thrift bị OOMKilled.
• E10: Pod có giới hạn bộ nhớ 16Mi, dù template ghi 256Mi; webhook gatekeeper-mutating-webhook-configuration khớp với pod này.

Jev chọn E10 làm bằng chứng then chốt. Pipeline suy ra webhook trùng khớp đã gây ra thay đổi giới hạn bộ nhớ và nêu tên nó trong báo cáo. Cả năm lần thử trên kịch bản này đều vượt qua tiêu chí chấm điểm.

Kết quả trên 105 chẩn đoán

Nhóm tác giả chạy 21 kịch bản lỗi năm lần với phiên bản jev-1.13.0, chấm điểm bằng gpt-6-astra ở mức suy luận cao, dùng thang chín câu hỏi của SREGym và ngưỡng đạt 0,70.

Chỉ số	Kết quả
Chẩn đoán vượt qua	80/105 (76,2%)
Kịch bản đạt cả năm lần	16/21
Kịch bản thất bại cả năm lần	5/21
Thời gian chẩn đoán trung vị	14,6 giây
Số lần gọi Jev	252 (2,4 lần mỗi lượt)
Độ trễ API Jev trung vị mỗi lượt	0,53 giây
Token đầu vào cho Jev	3,48 triệu
Chi phí suy luận ước tính	0,15 USD

Điều đáng chú ý là kết quả có tính nhất quán cao một cách bất thường. Với mỗi kịch bản, hoặc cả năm lần đều đạt, hoặc cả năm lần đều thất bại. Ở 18 trong 21 kịch bản, cả năm lần còn nhận cùng một điểm số.

Các kịch bản thất bại toàn bộ gồm: edge_request_filter_cpu_saturation, kafka_poison_pill_hol_block, search_rate_retry_collapse_hotel_reservation, service_dns_resolution_failure_social_network và valkey_auth_disruption.

Hai dạng thất bại điển hình

Qua phân tích các lượt thất bại, nhóm tác giả nhận diện hai dạng lỗi riêng biệt.

Jev chọn sai manh mối

Trong lỗi edge_request_filter_cpu_saturation của Astronomy Shop, các request WAF được tạo có chủ đích đã kích hoạt một biểu thức chính quy đắt đỏ trong frontend-proxy, làm bão hòa CPU và gây timeout. Bộ thu thập đưa ra cả hai bằng chứng: thay đổi regex và giới hạn CPU 100m mới.

• E7: Thêm WAF_RULE_REGEX: ^([a-zA-Z]+)*$
• E8: Giới hạn CPU thay đổi: từ chưa đặt thành 100m

Jev chọn frontend-proxy và E8 trong cả năm lần. Mỗi chẩn đoán đạt 0,67 điểm: giám khảo chấp nhận vị trí và phạm vi ảnh hưởng, nhưng không chấp nhận phần giải thích. Các bài nộp đổ lỗi cho giới hạn thay vì quy tắc lọc.

Thiếu bằng chứng quyết định

Trong lỗi search_rate_retry_collapse_hotel_reservation, một đợt lưu lượng tìm kiếm ngắn làm đầy hàng đợi của thành phần rate. Search thử lại các cuộc gọi đã hết thời gian chờ, khiến rate tiếp tục quá tải ngay cả sau khi lưu lượng đến trở lại bình thường. Jev tập trung vào rate và giới hạn backend 20 QPS trong cả năm lần chạy. Các chẩn đoán mô tả tình trạng quá tải nhưng bỏ sót vòng lặp giữa hàng đợi, thời hạn chờ và các lần thử lại.

Bản ảnh chụp toàn cảnh có nêu cấu hình thử lại của search, nhưng không hiển thị giá trị của chúng. Pipeline chưa bao giờ điều tra chi tiết thành phần search, và không có lần gọi Jev nào chứa số liệu về độ sâu hàng đợi hay số lần thử lại. Nó cũng yêu cầu Jev chọn một thành phần nguồn gốc duy nhất, trong khi lỗi này nằm ở tương tác giữa hai dịch vụ.

Bài học và hướng phát triển

Cả bộ thu thập lẫn Jev đều thiết yếu cho kết quả đạt được. Bộ thu thập quyết định thu thập gì và hiển thị bao nhiêu chi tiết; Jev dùng góc nhìn đó để chọn nơi điều tra và bằng chứng nào hỗ trợ chẩn đoán.

Điểm mấu chốt được nhóm tác giả đặt ra là: nên cho Jev thấy trạng thái cluster ở mức chi tiết nào? Một bản tóm tắt quá thô có thể che mất chi tiết giải thích lỗi, trong khi đưa vào từng dòng YAML thì chôn vùi tín hiệu hữu ích. Chọn đúng mức chi tiết có thể quan trọng không kém khả năng phán đoán của mô hình.

Jev kém linh hoạt hơn một LLM agent vì chẩn đoán của nó phụ thuộc vào bằng chứng và các lựa chọn mà pipeline cung cấp. Nhưng tốc độ và chi phí thấp khiến nó trở thành công cụ chẩn đoán tuyến đầu đầy triển vọng, trong khi LLM agent có thể đảm nhận những ca cần điều tra rộng hơn.

Hướng phát triển tiếp theo là mở rộng pipeline cho các lỗi mà nguyên nhân trải rộng qua nhiều dịch vụ hoặc thay đổi theo thời gian. Điều đó đòi hỏi thu thập tín hiệu ở mức request và các chỉ số thay đổi liên tục, kết nối chúng xuyên thành phần, và cho phép Jev xét đến những giải thích liên quan nhiều hơn một dịch vụ.

Các dạng thất bại này cũng là ứng viên lý tưởng cho những mô hình nhỏ, chuyên biệt hóa như GPT-6 Luna — nhằm chuyển dữ liệu telemetry có cấu trúc thành ngôn ngữ tự nhiên mà Jev có thể tiếp nhận dễ dàng. Nhóm tác giả tin rằng tích hợp chẩn đoán do Jev dẫn dắt vào quy trình làm việc của một SRE agent là bước tiến quan trọng để kết hợp hiệu quả giữa mô hình System One và System Two.