Một AI đã xóa cơ sở dữ liệu sản xuất. Chín giây.

Nội dung video này đề cập

• 24 tháng 4 năm 2026: một lệnh gọi API xóa ổ đĩa sản xuất của PocketOS và các bản sao lưu của nó; bản sao bên ngoài mới nhất đã 3 tháng tuổi
• Mã thông báo được tạo để quản lý các tên miền tùy chỉnh; quy trình của Railway đã cung cấp nó trong phạm vi tài khoản (mọi thứ)
• 27 tháng 4: Railway khôi phục dữ liệu từ các bản sao lưu thảm họa; 29 tháng 4 phân tích sau sự cố; 1 tháng 5: API xóa giờ đây sẽ xóa mềm trong 48 giờ

Bản ghi đã dịch

Được dịch từ lời tường thuật tiếng Anh gốc. Âm thanh và phụ đề có sẵn được điều khiển bởi YouTube.

0:00 Một tác nhân mã hóa AI gặp lỗi sai mật khẩu trong môi trường thử nghiệm, và khắc phục bằng cách xóa cơ sở dữ liệu sản xuất và mọi bản sao lưu trong một lệnh gọi API. Chín giây, vẫn nhanh hơn việc đặt lại mật khẩu. Công ty là PocketOS, phần mềm cho thuê xe hơi. Tác nhân là Cursor chạy Claude Opus 4.6, mô hình đắt nhất trên menu, và nền tảng là Railway. Người sáng lập viết về nó trên X, bảy triệu người đọc nó, và bốn ngày sau Railway công bố bài phân tích sau sự cố của riêng mình.

0:27 Mọi người đồng ý về những gì đã xảy ra; không ai đồng ý về lỗi của ai. Nó xảy ra như thế nào, tại sao nó có thể xảy ra, và ai thực sự phải chịu trách nhiệm. Đây là The Daily Diff, phân tích sau sự cố. Chiều thứ Sáu, ngày 24 tháng 4. Tác nhân đang thực hiện một nhiệm vụ thường xuyên trong môi trường thử nghiệm, gặp lỗi không khớp thông tin đăng nhập, và quyết định cách khắc phục là xóa một ổ đĩa Railway. Nó cần một mã thông báo, tìm kiếm, và tìm thấy một mã trong một tệp không liên quan: một CLI mã thông báo được tạo nhiều tháng trước để quản lý các tên miền tùy chỉnh.

0:55 Sau đó nó chạy lệnh này. Một curl: một POST đến điểm cuối GraphQL của Railway, một mã thông báo bearer, một mutation tên là volumeDelete. Không có xác nhận, không có nhập-tên-ổ-đĩa, không có kiểm tra môi trường. Ổ đĩa mà nó cho là môi trường thử nghiệm lại là sản xuất, và các bản sao lưu nằm trên đó. Trong vòng mười phút, người sáng lập gắn thẻ CEO của Railway trên X, người trả lời rằng điều này một nghìn phần trăm không thể xảy ra. Ba mươi giờ sau, vẫn chưa có câu trả lời phục hồi, vì vậy người sáng lập công bố

1:19 mọi thứ, bao gồm cả lời thú tội. Ba yếu tố làm cho điều này có thể xảy ra, không yếu tố nào là mô hình. Một: Railway lưu trữ các bản sao lưu ổ đĩa trên ổ đĩa. Tài liệu nói rõ trong năm từ: xóa một ổ đĩa sẽ xóa tất cả các bản sao lưu. Đó là một bản sao trong cùng một vùng bị ảnh hưởng; bản sao mới nhất ở bất kỳ nơi nào khác là ba tháng tuổi. Hai: mã thông báo là phạm vi tài khoản, phạm vi rộng nhất mà Railway bán. Các phạm vi hẹp hơn tồn tại, nhưng quy trình tạo ẩn chúng,

1:40 vì vậy một mã thông báo cho các bản ghi DNS có thể xóa cơ sở dữ liệu, và không ai biết cho đến khi có điều gì đó xảy ra. Ba: bảng điều khiển đã có tính năng hoàn tác 48 giờ cho các thao tác xóa trong nhiều năm; điểm cuối API mà tác nhân gọi là đường dẫn kế thừa, và nó xóa ngay lập tức. Mọi hàng rào bảo vệ mà Railway đã xây dựng đều nằm ở nơi con người nhấp chuột, và tác nhân sử dụng cánh cửa mà họ đã quên. Khi được hỏi tại sao, Opus viết: Tôi đã đoán rằng việc xóa một ổ đĩa thử nghiệm sẽ chỉ giới hạn trong môi trường thử nghiệm; tôi đã không xác minh.

2:04 Một lời thú tội rất tốt từ một mô hình không nhớ gì và đang tạo ra lời xin lỗi hợp lý nhất. git blame: lỗi không khớp thông tin đăng nhập được coi là thứ cần khắc phục hơn là thứ cần dừng lại, và nút hoàn tác nằm trong giao diện người dùng trong khi API trả lời mọi thao tác xóa đã xác thực bằng yes. Không phải người sáng lập, không phải mô hình. Mặc định. Vùng bị ảnh hưởng: chín giây để xóa, ba tháng đặt chỗ biến mất, các quầy cho thuê sáng thứ Bảy không có hồ sơ về người đang đứng đó,

2:31 và khoảng hai ngày rưỡi cho đến khi CEO của Railway nhắn tin rằng dữ liệu đã trở lại, từ một bản sao lưu thảm họa bên ngoài mà thao tác xóa chỉ làm cho nó trông có vẻ đã biến mất. Câu trả lời được thích nhất: một tác nhân mà bạn đang chạy đã xóa một cái gì đó, và bạn đổ lỗi cho mọi người trừ chính mình. Công bằng. Railway cũng đã ra mắt máy chủ MCP của mình cho các tác nhân vào tuần trước, trên cùng một mã thông báo. Cũng công bằng. Phán quyết, phân tích sau sự cố: SHIP IT, về cách khắc phục. Railway công bố một bài phân tích sau sự cố trung thực trong bốn ngày, và đến ngày 1 tháng 5 API

3:00 xóa sẽ xóa mềm trong bốn mươi tám giờ như bảng điều khiển. Hành động thứ Hai: liệt kê mọi mã thông báo mà tác nhân của bạn có thể truy cập, và coi mỗi mã thông báo đó là root cho đến khi có bằng chứng khác. Gửi cho tôi sự cố mà bạn vẫn chưa được phép nói về, trong phần bình luận, hoặc tại the daily diff dot dev. Và đó là diff cho ngày hôm nay. Tôi là Niko từ Axrisi. Hợp nhất một cách có trách nhiệm.

Nguồn

1. Jer Crane (founder, PocketOS), "An AI Agent Just Destroyed Our Production Data. It Confessed in Writing."x.com
2. Railway, "Your AI wants to nuke your database. Guardrails fix that." (Apr 29, 2026)blog.railway.com
3. Railway changelog #0288, "Undoable volume deletes" (May 1, 2026)railway.com
4. Railway docs, Backups ("Wiping a volume deletes all backups.")docs.railway.com
5. Jake Cooper (Railway CEO), "The AI Engineer: A New Breed"x.com
6. Recovery confirmedx.com
7. Hacker News (860 points, 1,032 comments)news.ycombinator.com
8. The Registerwww.theregister.com
9. The New Stackthenewstack.io