Cảnh báo từ Rootly: Lạm dụng AI xử lý sự cố khiến kỹ sư mất kết nối với hệ thống

Khi tôi còn là một SRE tại LinkedIn vào năm 2012, tôi đã thiết kế một hệ thống có khả năng tự phục hồi và học hỏi từ các sự cố trước đó. Khả năng của AI thời điểm đó còn cách rất xa so với những gì chúng ta có ngày nay, và dự án đó chỉ dừng lại ở mức nguyên mẫu, nhưng giờ đây điều đó đã trở thành hiện thực.

Các công cụ này làm được tất cả: kiểm tra cảnh báo, hình thành giả thuyết, truy vấn dữ liệu đo lường (telemetry), đối chiếu các bản triển khai gần đây và thậm chí tự mình thực hiện các bản sửa lỗi. Dù tôi rất thích nhìn thấy điều đó, nhưng tôi có một mối lo ngại lớn: chúng ta đang dần mất đi sự kết nối với các hệ thống của mình.

Các công cụ này càng giải quyết tốt các sự cố thường quy thì những người phản hồi (human responders) càng ít có cơ hội thực hành. Và khi một sự cố mơ hồ, nghiêm trọng xảy ra mà tự động hóa không thể giải quyết, các kỹ sư phản hồi sẽ gặp rắc rối.

Những công cụ phản hồi sự cố có hỗ trợ AI này, thường được gọi là “AI SRE” – một thuật ngữ mà tôi không mấy ưa thích – thực sự rất tuyệt vời ở nhiều khía cạnh. Chúng mang lại cảm giác kỳ diệu, đặc biệt là khi chúng xử lý một sự cố thường quy vào ban đêm và bạn không cần phải thức giấc vì một vấn đề về dung lượng hệ thống.

Vấn đề nằm ở chỗ, các sự cố thường quy cũng chính là cách để những người phản hồi phát triển “trực giác” một cách an toàn về cách hệ thống của họ vận hành và gặp lỗi. Khi AI gặp phải một sự cố hóc búa, chưa từng thấy trước đây mà nó không thể giải quyết, các kỹ sư sẽ phải tiếp quản với ít kinh nghiệm thực tế hơn so với trước đây.

Nhà nghiên cứu về yếu tố con người Lisanne Bainbridge đã mô tả nghịch lý này trong bài báo nổi tiếng năm 1983 của bà, "The Ironies of Automation" (Những nghịch lý của tự động hóa). Bà giải thích rằng tự động hóa làm giảm cơ hội thực hành công việc thường quy của người vận hành, trong khi vẫn để họ chịu trách nhiệm cho các tình huống mới và bất thường. Bà lập luận rằng, do đó, người vận hành cần phải có kỹ năng cao hơn và được đào tạo bài bản hơn so với trước khi có tự động hóa.

Trong những năm tới, tôi dự đoán rằng MTTR trung bình cho hầu hết các sự cố sẽ giảm xuống – nhờ vào phản hồi sự cố có hỗ trợ AI – nhưng thời gian giải quyết sẽ tăng vọt đối với các sự cố phức tạp vì những người phản hồi sự cố đã mất kết nối với hệ thống của họ và đang chật vật trong việc điều tra.

Chúng ta có thể nhìn vào ngành hàng không để tìm cảm hứng.

Hệ thống tự động trên máy bay xử lý phần lớn quá trình bay, nhưng phi công vẫn chịu trách nhiệm cho các tình huống mà tự động hóa không thể quản lý: hỏng động cơ, thiết bị đo đạc không đáng tin cậy, hủy cất cánh, thất tốc (stall) và các điều kiện bất thường khác.

Những sự kiện này cực kỳ hiếm gặp. Ví dụ, các động cơ tuabin hiện đại có tỷ lệ tắt máy giữa chuyến bay dưới một lần trên 100.000 giờ bay. Nói cách khác, điều đó hiếm đến mức một phi công thương mại có thể hoàn thành cả sự nghiệp mà không bao giờ gặp phải tình huống đó ngoài đời thực, ngoại trừ trong mô phỏng.

Nhưng khi sự cố xảy ra, phi công phải phản ứng nhanh chóng và chính xác. Ví dụ, trên chuyến bay 235 của TransAsia Airways, cánh quạt động cơ bên phải đã tự động chuyển sang chế độ "feather" (cánh quạt nằm song song với luồng gió) ngay sau khi cất cánh. Và mặc dù máy bay được thiết kế để tiếp tục bay bằng động cơ bên trái, phi hành đoàn đã xác định sai vấn đề. Máy bay bị thất tốc và rơi chỉ 117 giây sau cảnh báo đầu tiên.

Phi công hàng không thường xuyên quay lại các thiết bị mô phỏng để diễn tập các tình huống khẩn cấp hiếm gặp. Theo quy định của FAA Hoa Kỳ, các cơ trưởng phải hoàn thành khóa đào tạo định kỳ hoặc kiểm tra năng lực sáu tháng một lần, bao gồm các kịch bản như hỏng động cơ khi cất cánh.

Mặc dù hầu hết các sự cố phần mềm không đe dọa đến tính mạng, nhưng đó không phải là lý do để chúng ta không hoàn thiện kỹ năng của mình. Hóa ra, công nghệ tạo ra vấn đề cũng có thể giúp giải quyết nó.

Tại Rootly, nơi tôi làm việc, chúng tôi đã hợp tác với Uptime Labs để áp dụng ý tưởng này thông qua các mô phỏng sự cố thực tế. Các kỹ sư sẽ ngồi vào vị trí chỉ huy sự cố trong một tình huống giả lập sự cố thương mại điện tử, sử dụng các công cụ quan sát (observability tools) trong khi phối hợp với các bên liên quan được hỗ trợ bởi LLM trên Slack.

Kết quả mang lại cảm giác rất thật. Bạn phải điều tra xem điều gì đang xảy ra sai sót trong khi vẫn giữ cho quá trình phản hồi được tổ chức chặt chẽ và đối phó với CEO cũng như bộ phận hỗ trợ khách hàng. Bạn được thực hành các kỹ năng quan trọng trong một sự cố: hiểu được thông tin không đầy đủ, giao tiếp rõ ràng, điều phối con người và thực sự điều hành quá trình phản hồi.

Nhưng còn việc sử dụng AI như một người huấn luyện thì sao? Những người phản hồi có thể yêu cầu một tác nhân (agent) giải thích các bước nó đã thực hiện, các tín hiệu nó đã kiểm tra và bằng chứng đằng sau chẩn đoán của nó.

Nhưng giải thích và quan sát không phải là sự thay thế cho thực hành. Bạn có thể học được vài điều từ việc xem Serena Williams thi đấu, nhưng bạn chỉ thực sự học chơi quần vợt bằng cách bước ra sân, và phản hồi sự cố cũng không khác biệt.

Tôi đã dành hơn nửa thập kỷ trong sự nghiệp của mình để xây dựng một trường kỹ thuật phần mềm dựa trên giáo dục tiến bộ: học thông qua thực hành. Đó là hình thức trực tiếp, nhưng chúng tôi không có giáo viên; sinh viên làm việc trên các dự án thay vì nghe giảng. Khi Dropbox nói với tôi rằng các sinh viên tốt nghiệp mà họ tuyển dụng vẫn còn quá thiếu kinh nghiệm trong việc xử lý sự cố, tôi đã tạo ra các dự án cung cấp cho sinh viên cơ sở hạ tầng bị lỗi và yêu cầu họ chẩn đoán và sửa chữa nó. Đối với hầu hết các kỹ năng thực hành, tôi tin rằng giáo dục thực tế vượt xa việc hướng dẫn thụ động.

Khi các LLM thực hiện nhiều công việc của chúng ta hơn, các đội ngũ kỹ thuật có nguy cơ tích lũy "nợ hiểu biết" (comprehension debt): một khoảng cách ngày càng lớn giữa cách hệ thống vận hành và mức độ hiểu biết của những người phản hồi về chúng.

Các kỹ sư nên thường xuyên tương tác với hệ thống mà họ giám sát, xử lý các lỗi lạ, thực hành làm việc dưới áp lực và diễn tập việc phối hợp, giao tiếp cần thiết trong một sự cố SEV0. Các bài tập trên bàn (tabletop exercises) và kỹ thuật hỗn loạn (chaos engineering) không phải là điều mới mẻ, nhưng việc thực hành đã trở nên quan trọng hơn bao giờ hết trong kỷ nguyên LLM.

Nhà nghiên cứu Bainbridge khuyến nghị nên cho người vận hành quyền kiểm soát thực tế thường xuyên và sử dụng mô phỏng để ngăn chặn sự suy giảm kỹ năng của họ. Đó chính là nghịch lý của tự động hóa: nó càng thành công, con người càng có thể ít chuẩn bị hơn cho khoảnh khắc nó thất bại.