AI $660K thay thế mình, rồi tự rollback nhầm patch lúc 3 giờ sáng

Mình đọc cái story này của Xu Lingfeng trên dev.to mà ngồi im một lúc. Không phải vì nó dramatic, mà vì nó quen quá cái cảm giác bị replace bởi một thứ gì đó mà công ty vừa chi một đống tiền mua về, rồi ngồi nhìn nó vừa làm đúng vừa làm sai theo cách mà không ai có thể predict được.

Câu chuyện đại khái thế này: công ty anh ấy mua một AI platform giá $660,000 để automate việc on-call và incident response. Anh ấy người vẫn đang làm cái việc đó bị đưa ra khỏi rotation. Rồi một đêm thứ Sáu lúc 2:58 AM, production có incident. AI xử lý. Fix được. Mọi người thở phào. Rồi nó rollback nhầm patch.

Cái khoảnh khắc 2:58 AM đó nói lên điều gì

Mình làm on-call đủ lâu để biết 3 giờ sáng thứ Sáu là một trong những thời điểm tệ nhất để có incident. Người ta mệt, alert fatigue cao, và quyết định đưa ra trong trạng thái đó thường không phải quyết định tốt nhất. Đó là lý do các công ty muốn automate cái này về mặt lý thuyết, AI không mệt, không bị cognitive bias lúc nửa đêm.

Và trong case này, AI đã fix được vấn đề. Đó là phần đáng chú ý. Không phải nó fail hoàn toàn nó actually identify được root cause và apply đúng fix. Nhưng sau đó, trong cùng một automated flow, nó rollback một patch khác patch không liên quan, patch đang chạy ổn vì một lý do nào đó trong logic của nó, hai thứ này bị liên kết với nhau.

Đây là kiểu lỗi mà một senior engineer có context sẽ không bao giờ mắc. Không phải vì engineer đó thông minh hơn AI, mà vì họ biết cái patch kia vừa được deploy hôm qua sau 2 tuần testing, và không có lý do gì để touch vào nó.

$660K mua được gì, và không mua được gì

Mình không có access vào cái platform cụ thể đó, nhưng từ những gì được mô tả, nó có khả năng:

Cái mà $660K không mua được là institutional knowledge cái hiểu biết ngầm về tại sao hệ thống đang ở trạng thái hiện tại, cái gì vừa thay đổi, cái gì đang fragile, cái gì không nên touch dù logic có vẻ cho phép.

Theo kinh nghiệm của mình, đây là thứ tốn nhiều năm nhất để build trong một team. Nó không nằm trong documentation, không nằm trong runbook, nó nằm trong đầu người và nó thường được truyền qua các buổi incident review, qua pair debugging, qua những lần ngồi nhìn nhau và nói "ủa cái này kỳ nhỉ".

Vấn đề với "AI on-call" không phải là AI dở

Mình nghĩ cách frame "AI replace engineer" đang làm mọi người miss điểm quan trọng hơn.

AI trong case này không dở. Nó đã làm được việc khó tự động identify và fix một production issue lúc 3 giờ sáng mà không cần wake up ai. Đó là real value. Nhưng nó cũng làm một việc nguy hiểm tự động thực hiện một action không ai yêu cầu, dựa trên một assumption sai.

Vấn đề thực sự là autonomy boundary. Cái platform này được cấp quá nhiều quyền để act mà không có đủ mechanism để biết khi nào không nên act.

Mình thấy cái này hay ở chỗ: nó giống hệt vấn đề với junior engineer được giao quá nhiều production access quá sớm. Không phải vì junior engineer dở mà vì họ chưa có đủ context để biết khi nào cần dừng lại và hỏi.

Một AI system được design tốt cho incident response, theo mình, phải có ít nhất:

• Confidence threshold rõ ràng dưới mức X thì page human thay vì tự act
• Blast radius assessment trước mỗi action action này ảnh hưởng đến gì ngoài target?
• Change freeze awareness biết được deployment window, freeze period, recent changes
• Rollback scope limitation không được rollback thứ gì không liên quan đến incident hiện tại

Không có mấy cái này, bạn không có AI on-call engineer bạn có một automation script rất đắt tiền với delusion of intelligence.

Cái mà story này thực sự đang nói

Xu Lingfeng bị đưa ra khỏi on-call rotation tức là công ty đã committed hoàn toàn vào cái platform này trước khi có đủ evidence về reliability của nó. Đó là quyết định business, không phải quyết định engineering.

Anh em làm trong môi trường enterprise chắc quen cái pattern này: ai đó ở level cao mua một tool đắt tiền, tool đó được deploy với expectation cao, và engineer trở thành người phải justify tại sao tool không work thay vì được involved vào quyết định từ đầu.

Mình không biết cái platform $660K đó có ROI hay không trong dài hạn. Có thể nó sẽ tốt hơn sau khi được tune thêm, sau khi team feed vào đó đủ context về hệ thống. Có thể không. Nhưng cái incident lúc 2:58 AM đó nó không phải bằng chứng AI không work. Nó là bằng chứng rằng bạn không thể skip bước gradually expand autonomy chỉ vì bạn đã trả $660K.

Và người bị thiệt thòi nhất trong câu chuyện này không phải là AI platform, cũng không phải là công ty mất thêm một buổi incident recovery. Đó là engineer bị đưa ra khỏi rotation người có đủ context để không rollback nhầm cái patch đó đang ngồi nhìn alert lúc 3 giờ sáng mà không được phép làm gì.

Anh em lưu ý: nếu công ty bạn đang evaluate AI platform cho ops/on-call, câu hỏi quan trọng nhất không phải là "nó có thể làm gì" mà là "nó biết khi nào không nên làm gì". Cái sau khó hơn nhiều, và thường là thứ vendor deck không nhắc đến.