Trình bày: Claude có thể tự sửa lỗi không? Dùng LLM cho xử lý sự cố

Trong một bài trình bày gần đây, kỹ sư độ tin cậy Alex Palcuie của Anthropic đã mang đến góc nhìn thực tế và đầy trải nghiệm về việc sử dụng các mô hình ngôn ngữ lớn (LLM) trong quy trình xử lý sự cố (incident response). Bài nói không chỉ nhấn mạnh vào khả năng của AI mà còn chỉ ra những giới hạn quan trọng và cách các đội ngũ kỹ thuật có thể tích hợp chúng một cách khôn ngoan.

LLM là "siêu nhân" trong quan sát và theo dõi

Theo Palcuie, một trong những điểm mạnh vượt trội nhất của LLM trong vận hành hệ thống là khả năng "đọc hiểu" khối lượng khổng lồ các log và trace (dấu vết) mà con người không thể xử lý trong thời gian thực. Khi hệ thống gặp trục trặc, việc rà soát hàng ngàn dòng log để tìm ra bất thường là công việc tốn thời gian và dễ bỏ sót. AI có thể quét nhanh, tổng hợp và tóm tắt các mẫu dữ liệu, cung cấp cho kỹ sư trực ca một bức tranh tổng quan ngay lập tức.

"AI đóng vai trò như một trợ lý quan sát không biết mệt mỏi, giúp kỹ sư tập trung trí óc vào việc phân tích và quyết định thay vì bị chìm trong biển dữ liệu thô."

Vẫn yếu trong phân tích nguyên nhân gốc rễ (Root Cause Analysis)

Tuy nhiên, điểm yếu chí mạng của LLM nằm ở khả năng phân biệt giữa tương quan (correlation) và nhân quả (causation). Palcuie nhấn mạnh rằng, một mô hình ngôn ngữ có thể dễ dàng chỉ ra rằng "CPU tăng cao cùng lúc với lỗi xuất hiện", nhưng nó lại rất khó để xác định liệu CPU tăng là nguyên nhân hay chỉ là hệ quả của một vấn đề sâu xa hơn. Việc thiếu hiểu biết về logic nghiệp vụ (business logic) và bối cảnh hệ thống khiến LLM đưa ra những suy đoán sai lầm, đôi khi gây nhiễu cho quá trình điều tra.

Điều này đồng nghĩa với việc, các kỹ sư không nên tin tưởng tuyệt đối vào chẩn đoán của AI. Vai trò của con người trong việc "thẩm định" và đưa ra kết luận cuối cùng vẫn là yếu tố then chốt.

Tích hợp AI vào quy trình trực ca mà không làm mai một chuyên môn

Một trong những lo ngại lớn nhất của các lãnh đạo kỹ thuật là việc quá phụ thuộc vào AI khiến kỹ năng của kỹ sư bị mai một. Palcuie đề xuất một cách tiếp cận cân bằng: sử dụng AI như một công cụ hỗ trợ (co-pilot) cho giai đoạn đầu của sự cố (phát hiện, phân loại, tóm tắt nhanh), nhưng vẫn duy trì quy trình bắt buộc để kỹ sư phải tự đào sâu vào phân tích kỹ thuật.

• Giai đoạn phát hiện (Detection): AI tổng hợp và gắn cờ các bất thường.
• Giai đoạn điều tra (Investigation): Kỹ sư sử dụng AI để tra cứu lịch sử, so sánh các phiên bản phát hành, nhưng tự mình xem xét các service graph và dependency.
• Giai đoạn khắc phục (Mitigation): AI có thể đề xuất các lệnh rollback hoặc cấu hình dựa trên runbook, nhưng mọi hành động thay đổi hệ thống đều cần sự phê duyệt của con người.

Palcuie cũng nhấn mạnh rằng, để AI hoạt động hiệu quả, dữ liệu huấn luyện và ngữ cảnh của hệ thống phải được "vệ sinh" tốt. Một LLM được huấn luyện trên codebase, tài liệu kiến trúc và lịch sử sự cố (postmortems) của chính công ty sẽ cho kết quả chính xác và hữu ích hơn rất nhiều so với mô hình tổng quát.

Kết luận: AI là cộng sự, không phải người thay thế

Bài trình bày của Alex Palcuie mang đến một thông điệp rõ ràng cho các đội ngũ vận hành và SRE tại Việt Nam: Hãy coi LLM như một thực tập sinh siêu nhanh nhạy nhưng còn thiếu kinh nghiệm. Chúng ta cần tận dụng tốc độ và khả năng xử lý dữ liệu của AI, nhưng vẫn phải giữ vai trò kiến trúc sư trưởng cho hệ thống của mình.

Việc xây dựng các quy trình có kiểm soát, kết hợp với việc đào tạo kỹ sư biết cách "ra lệnh" và "kiểm chứng" AI, chính là chìa khóa để biến AI thành lợi thế cạnh tranh thay vì một rủi ro tiềm ẩn trong công tác vận hành.