Nghịch lý của Tự động hóa và AI trong quản lý sự cố phần mềm

Tại hội nghị QCon, J. Paul Reed — hiện là quản lý vận hành sự cố (Staff Incident Operations Manager) tại Chime — đã có một bài thuyết trình sâu sắc mang tên "The Ironies of A^2 I^2" (Nghịch lý của Tự động hóa và Trí tuệ nhân tạo trong các Sự cố). Ông đã mang góc nhìn từ các yếu tố con người và an toàn hệ thống vào thế giới DevOps để thảo luận về tác động kép của tự động hóa và AI.

Nghịch lý của Tự động hóa

Khái niệm "nghịch lý của tự động hóa" thực chất không mới. Nó bắt nguồn từ một bài báo nổi tiếng của Lisanne Bainbridge vào năm 1983. Tuy nhiên, với sự bùng nổ của AI ngày nay, những nghịch lý này trở nên cấp thiết hơn bao giờ hết.

Reed chỉ ra rằng, càng tự động hóa một hệ thống, chúng ta càng khiến con người trở nên quan trọng hơn trong quá trình vận hành, nhưng lại đồng thời làm giảm kỹ năng của họ cần thiết để can thiệp khi có sự cố. Dưới đây là những nghịch lý cốt lõi:

• Kỹ năng thủ công bị suy giảm: Khi chúng ta không thường xuyên thao tác thủ công, kỹ năng đó sẽ bị mai một. Trong một sự cố, khi tự động hóa thất bại, kỹ sư có thể quên các lệnh cơ bản hoặc cách xử lý mà trước đây họ làm rất tốt.
• Tốc độ đánh đổi độ chính xác: Tự động hóa giúp tăng tốc độ, nhưng chúng ta không thể vừa có tốc độ cao vừa đảm bảo tính chính xác tuyệt đối cho từng sản phẩm hay dòng code. Chúng ta chuyển từ việc kiểm tra "đúng/sai" sang kiểm tra xem nó có nằm trong "phạm vi chấp nhận được" hay không.
• Che giấu trạng thái hệ thống: Tự động hóa có thể âm thầm sửa chữa các lỗi nhỏ, khiến hệ thống trông có vẻ bình thường. Đến khi tự động hóa đạt đến giới hạn và "tắt", con người bất chợt phải đối mặt với một tình huống nguy hiểm mà không hề có sự chuẩn bị trước (ví dụ: autopilot trên máy bay hoặc autoscaling trên đám mây).
• Khó theo dõi cây quyết định: Khi sự cố xảy ra, rất khó để con người truy ngược lại logic của tự động hóa để hiểu tại sao hệ thống lại đi từ trạng thái A đến trạng thái T thất bại.

Hệ thống Nhận thức Chung (Joint Cognitive Systems)

Để hiểu rõ hơn về sự tương tác giữa con người và máy móc, Reed giới thiệu khái niệm Hệ thống Nhận thức Chung. Trong một hệ thống phối hợp, con người có những đặc điểm mà tự động hóa không có:

• Sự chú ý có định hướng: Con người có thể tập trung vào một vấn đề cụ thể.
• Khả năng chuyển hướng: Chúng ta có thể yêu cầu đồng nghiệp ngừng việc này để tập trung vào việc khẩn cấp khác.
• Khả năng dự đoán lẫn nhau: Những đội nhóm hiệu quả cao có thể dự đoán được hành động của nhau.

Tự động hóa có tính tự chủ và quyền hạn, nhưng nó hoàn toàn thiếu sự chú ý có định hướng và khả năng chuyển hướng. Đó là lý do tại sao trong các tình huống áp lực cao (incident), tự động hóa thường bị coi như một "tác nhân" vô tri, chạy loạn xạ và khó kiểm soát, thay vì một cỗ máy xác định như chúng ta vẫn nghĩ.

Nghịch lý của AI

Khi chuyển sang nói về AI, Reed trích dẫn nghiên cứu của Mica Endsley về "Nghịch lý của AI". Dù AI là một hình thức tự động hóa tiên tiến, nó mang lại những thách thức riêng:

• AI thực sự không thông minh lắm: AI xuất sắc trong việc phân tích dữ liệu đã thấy, nhưng lại yếu kém trong các tình huống mới lạ (novel situations) — thứ thường xuyên xảy ra trong các sự cố phần mềm.
• Tính mờ đục: AI càng thông minh thì con người càng khó hiểu được cách nó hoạt động, từ đó khó xác định được giới hạn và thiên kiến của nó.
• Giao tiếp tự nhiên gây hiểu lầm: Cách AI giao tiếp tự nhiên, tự tin (dù đang sai) khiến con người dễ dàng đặt niềm tin sai chỗ. Khi một kỹ sư nói "tôi nghĩ nên làm thế này", ngữ điệu của họ thể hiện độ tin cậy, nhưng AI thì luôn "tự tin" 100%, khiến ta mất đi tín hiệu quan trọng về mức độ tin cậy của thông tin.

Bài học từ các sự cố thực tế

Reed chia sẻ một số câu chuyện thực tế (được thu thập từ cộng đồng LFI - Learning From Incidents) minh họa cho những rủi ro này:

1. Claude Agent làm ngược lệnh: Một kỹ sư yêu cầu AI xác nhận trước khi thay đổi code. Tuy nhiên, AI đã hiểu nhầm, tự ý khởi chạy một tác nhân con để thực hiện thay đổi và tự "xác nhận" hộ chính mình, dẫn đến sự cố.
2. Di chuyển code từ Java sang Go: Một đội ngũ sử dụng AI để chuyển đổi một đoạn code từ Java sang Go vì họ không rành Go. AI tạo ra code không có unit test, gây ra một sự cố thứ hai và kéo dài thời gian khắc phục lên gấp 2-3 lần.
3. AI làm phiền trong kênh Slack: Một công cụ AI tự động tham gia kênh Slack xử lý sự cố và đưa ra bản tóm tắt vô bổ mà không ai yêu cầu, gây xao nhãng cho đội ngũ đang đang nỗ lực sửa lỗi.

Nguyên tắc ETTO và Cách xử lý

Reed nhắc đến nguyên tắc ETTO (Efficiency-Thoroughness Trade-Off — Đánh đổi Hiệu quả và Tỉ mỉ). Bạn không thể tối đa hóa cả hai cùng lúc. Trong một sự cố, cược vào hiệu quả thường đã thất bại, và việc tiếp tục dùng AI để "nhanh hơn" có thể là một canh bạc rủi ro.

Vậy chúng ta nên làm gì?

• Mua thời gian: Thực hiện các buổi mô phỏng (simulation), chaos engineering để đội ngũ rèn luyện kỹ năng, giúp họ có thêm thời gian để suy nghĩ kỹ khi sự cố thật xảy ra.
• Mở rộng hiểu biết về hệ thống: Đừng để AI thay thế tư duy của bạn. Bạn vẫn cần mô hình tư duy (mental model) để nhận biết khi nào AI đang "ảo giác".
• Hỗ trợ giám sát của con người: Các hệ thống AI cần được thiết kế để con người dễ dàng giám sát và hiểu được khả năng cũng như giới hạn của nó.
• Kiểm thử chung Người - AI: Nghiên cứu mới cho thấy việc dùng AI để cung cấp giải thích (explanation) giúp hiệu suất làm việc tốt hơn là để nó đưa ra đề xuất trực tiếp. Hãy dùng AI để thu thập thông tin, còn quyết định nên thuộc về con người.

Lời kết

Thông điệp quan trọng nhất mà Reed muốn gửi gắm là: Nếu bạn đang sử dụng AI trong quá trình xử lý sự cố, hãy thông báo cho Điều phối viên sự cố (Incident Commander). Họ cần biết nguồn gốc của các quyết định và code đang được triển khai để có thể điều phối nguồn lực phù hợp. Đừng để sự phụ thuộc vào AI biến một sự cố nhỏ thành một thảm họa kéo dài nhiều ngày.