SRE dựa trên AI: Tự động hóa phản hồi sự cố và tương lai của DevOps

Trong bối cảnh công nghệ hiện đại, Trí tuệ nhân tạo (AI) đang tạo ra những bước tiến lớn trong lĩnh vực DevOps và Kỹ sư Độ tin cậy Trang web (SRE). Thay vì chỉ dừng lại ở việc giám sát thụ động như trước đây, các đội ngũ kỹ thuật hiện nay đang chuyển hướng sang các mô hình vận hành dự đoán và tự động hóa cao hơn.

Gần đây, một buổi thảo luận chuyên sâu với sự tham gia của các chuyên gia từ Amazon, Storytel, Grainger và NeuBird đã làm rõ cách các tác nhân AI và mô hình tạo sinh (generative models) được ứng dụng vào việc phát hiện sự cố, phân tích nguyên nhân gốc rễ và khắc phục sự cố. Mục tiêu cuối cùng là đảm bảo trải nghiệm tốt nhất cho người dùng cuối ngay cả khi hệ thống gặp vấn đề.

AI trong SRE và phản hồi sự cố

Vấn đề đầu tiên AI cần giải quyết trong DevOps

Khi được hỏi về vấn đề thực tế đầu tiên mà AI nên giải quyết trong DevOps, Rohit Dhawan, Engineering Manager tại Amazon, chỉ ra rằng đó chính là sự quá tải nhận thức (cognitive overload) hay quá tải thông tin.

Các kỹ sư SRE thường phải quản lý lượng lớn nhật ký (logs) và xử lý số lượng vé hỗ trợ khổng lồ. Những vé này thường chứa hàng chục bình luận từ nhiều đội ngũ khác nhau. Khả năng tóm tắt thông tin này một cách ngắn gọn để người trực trực (on-call) có thể nắm bắt nhanh chóng những gì đã xảy ra và các bước tiếp theo là nơi AI phát huy tác dụng đầu tiên. Điều này không chỉ giúp tiết kiệm thời gian mà còn giúp chuyển giao ca trực hiệu quả hơn.

Nơi sự chú ý của con người bị lãng phí

Goutham Rao, đồng sáng lập NeuBird AI, chia sẻ rằng con người có xu hướng mắc lỗi khi phải thực hiện các công việc lặp đi lặp lại và nhàm chán, trong khi AI thì không. Sự chú ý của kỹ sư thường bị lãng phí vào việc tìm kiếm dữ liệu thay vì hành động dựa trên nó.

Pavan Madduri, Senior Cloud Platform Engineer tại Grainger, gọi đây là "thuế quan sát" (observability tax). Vấn đề cốt lõi là tỷ lệ cảnh báo trên nhiễu (alert-to-noise ratio). AI cần giải quyết vấn đề này bằng cách lọc các cảnh báo, phân loại đâu là thông tin cần hành động ngay và đâu chỉ là thông tin tham khảo. Điều này giúp giảm mệt mỏi cho người vận hành và cho phép họ tập trung vào các vấn đề thực sự quan trọng.

Quản lý sự cố lúc 3 giờ sáng

Kịch bản kinh điển của mọi kỹ sư SRE là nhận được cuộc gọi báo động lúc 3 giờ sáng. Alina Astapovich, Platform Engineer tại Storytel, đặt câu hỏi: "Ai sẽ bị ảo giác (hallucinate) trước, tôi hay AI?".

Theo Alina, giai đoạn quan trọng nhất khi bắt đầu điều tra sự cố là xác định đúng đường đi và điểm khởi đầu. Một công cụ AI tốt sẽ giúp tóm tắt các dấu vết (traces) và nhật ký (logs) để kỹ sư biết vấn đề nằm ở đâu. Tuy nhiên, cô cũng cảnh báo rằng AI cần hiểu rõ về bố cục hạ tầng hiện tại. Nếu AI đề xuất giải pháp cho một cụm cluster đã bị xóa từ 3 năm trước, nó sẽ dẫn kỹ sư đi sai hướng. Do đó, sự giám sát của con người vẫn là bắt buộc, ngay cả khi sử dụng AI.

Kỹ thuật ngữ cảnh và Cơ sở kiến thức doanh nghiệp

Goutham Rao so sánh việc sử dụng AI như đi khám bệnh: Nếu bạn không mô tả chính xác triệu chứng cho bác sĩ, bạn sẽ không nhận được chẩn đoán tốt. Tương tự, các mô hình ngôn ngữ lớn (LLM) chỉ hoạt động hiệu quả khi được cung cấp đúng ngữ cảnh (context).

Để một giải pháp tác nhân AI (agentic solution) thành công, nó cần tiếp cận tất cả các nguồn dữ liệu mà một kỹ sư con người thường sử dụng: từ CloudWatch, CloudTrail, mã nguồn, cho đến các tài liệu nội bộ trên Jira hay Confluence. Việc thiếu một mảnh dữ liệu quan trọng có thể khiến AI đưa ra kết luận sai lệch hoặc không tìm ra nguyên nhân gốc rễ.

Hệ thống đa tác nhân (Multi-agent Systems)

Các chuyên gia thảo luận về xu hướng sử dụng nhiều tác nhân AI chuyên biệt thay vì một tác nhân duy nhất làm mọi thứ. Tại Storytel và Grainger, họ đang xây dựng các hệ thống mà trong đó một "tác nhân chính" đóng vai trò bộ não, điều phối các tác nhân phụ chuyên biệt khác nhau.

Ví dụ, một tác nhân có thể chuyên giám sát logs Datadog, trong khi một tác nhân khác theo dõi việc mở rộng quy mô với KEDA. Chúng phối hợp với nhau để tương quan các chỉ số, soạn thảo file YAML và thậm chí tạo ra pull request để người trực chỉ cần xem xét và phê duyệt. Điều này biến kỹ sư từ người vận hành thành người phê duyệt.

Bảo mật và Kiểm soát quyền truy cập

Một lo ngại lớn khi đưa AI vào vận hành là bảo mật dữ liệu. Alina Astapovich nhấn mạnh rằng việc cấp quyền cho AI nên dựa trên mức độ tin cậy tương tự như khi bạn sử dụng các dịch vụ của nhà cung cấp đám mây (như AWS). Nếu bạn đã tin tưởng lưu trữ dữ liệu trên AWS, việc cấp quyền cho công cụ AI của AWS để truy cập dữ liệu đó là hợp lý.

Tuy nhiên, với các dữ liệu nhạy cảm hoặc khi xây dựng giải pháp tùy chỉnh, các doanh nghiệp có thể cân nhắc chạy các mô hình LLM riêng trên máy chủ ảo (on-prem) để đảm bảo an toàn tuyệt đối. Về quản lý quyền hạn, các giải pháp AI doanh nghiệp cần hỗ trợ Kiểm soát truy cập dựa trên vai trò (RBAC), đảm bảo rằng AI chỉ thực hiện những hành động mà người dùng tương ứng được phép thực hiện (ví dụ: kỹ sư cấp cao có thể restart pod, nhưng thực tập sinh thì không).

Chủ động so với Thụ động

Về việc lựa chọn giữa tác nhân chủ động (trước sự cố) và thụ động (trong sự cố), Goutham Rao cho rằng chủ động luôn tốt hơn nếu có thể. Phòng ngừa sự cố luôn tốt hơn là khắc phục. Tuy nhiên, phân tích chủ động thường tốn kém hơn về chi phí tính toán.

Trong trường hợp phản ứng thụ động, tốc độ là yếu tố then chốt. Một tác nhân AI tốt, ngay cả khi không thể tự động giải quyết hoàn toàn vấn đề, cũng phải giúp tiết kiệm thời gian bằng cách loại bỏ các hướng đi sai lầm và cung cấp điểm tin cậy (confidence score) cho các đề xuất của mình.

Kết luận

AI chắc chắn đang tăng tốc cho lĩnh vực SRE và DevOps, chứ không làm cho nó mong manh hơn như một số lo ngại. Tuy nhiên, thành công của việc tích hợp AI phụ thuộc rất nhiều vào việc cung cấp ngữ cảnh đúng đắn và duy trì kiến thức lĩnh vực của đội ngũ con người. AI là công cụ mạnh mẽ để giải quyết sự quá tải dữ liệu và tự động hóa các quy trình lặp lại, nhưng con người vẫn đóng vai trò giám sát và đưa ra quyết định chiến lược cuối cùng.