為省5-10美元差點毀庫！Claude一條指令刪光200萬條數據、網站停擺24小時，創始人坦言：全是我的錯

編譯 | 屠敏

出品 | CSDN（ID：CSDNnews）

AI 時代，一次看似普通的操作，竟能讓整套生產環境與近 200 萬條數據瞬間「歸零」。

近日，數據科學社區 DataTalks.Club 創始人 Alexey Grigorev 就遭遇了這樣的驚魂時刻，他在使用 AI 編程工具 Claude Code 管理網站服務器時，意外清空了平臺積累 2.5 年的核心數據，甚至連數據庫快照也未能幸免，導致網站停擺整整 24 小時。

這起事故不僅在開發者社區引發熱議，更給所有依賴 AI 工具與自動化運維的從業者敲響了警鐘。事后，Alexey Grigorev 公開復盤了整個過程，并揭露了此次事故的核心問題。讓我們一起看看。

一次看似很普通的網站遷移

這場“刪庫”事件的前因，其實并不復雜。

當時 Alexey 正在開發一個新網站 AI Shipping Labs（https://aishippinglabs.com/）。這個網站原本托管在 GitHub Pages 上，是一個靜態站點。

不過，Alexey 計劃把網站遷移到 AWS 云平臺，并在后續將原本的 Next.js 實現逐步替換為 Django 版本。

為了保障遷移過程平穩，Alexey 制定了看似十分穩妥的方案：先把靜態網站遷移到 AWS S3，再把域名的 DNS 管理遷到 AWS，然后在一個子域名上部署新的 Django 版本。等到一切運行穩定后，再把主域名切換到新系統。

這樣一來，所有資源都會進入 AWS，最終切換時幾乎不會影響用戶訪問。

從架構設計角度來看，這套遷移策略本身并沒有明顯問題。

然而，理論上的可行，并不等于實際執行就一定安全。真正的挑戰，恰恰就出現在執行的過程中。

為節省 5-10 美元復用生產環境，卻意外清空了 2.5 年的數據積累

事實上，Alexey 此前就一直用 Terraform 管理自己創立的另一個項目 DataTalks.Club 的生產基礎設施，這套系統主要支撐著 DataTalks.Club 的 Zoomcamps 課程平臺。

按理說，新項目 AI Shipping Labs 應該部署在另一個獨立的環境中，但為了節省一點成本，Alexey 決定直接把新項目加入現有的 Terraform 配置中。

這意味著兩個項目將共享同一套 AWS 基礎設施，包括 VPC 私有網絡、ECS 集群、負載均衡器以及 bastion 主機。

遷移過程中，Alexey 依賴 Claude Code 來提高效率。所以在接收到 Alexey 的要求時，Claude Code 照做了，但同時也給出了提醒：最好為新項目創建獨立環境，以避免影響現有系統。

然而，Alexey 認為再創建一個 VPC 并不劃算，于是堅持讓新項目使用同一套基礎設施。節省的成本其實并不多，大約每月 5 到 10 美元。

但正是這一步的決定，讓兩個項目的基礎設施變更混在了一起，也為后續事故埋下了隱患。

第一個異常信號

當時間來到 2 月 26 日晚上約 10 點，Alexey 開始通過 Terraform 部署網站更新。

正常流程下，Terraform 會先執行 terraform plan 命令，讓工程師確認即將發生的資源變更，這是保障操作安全的關鍵一步。

但這一次，Alexey 直接讓 Claude Code 運行了完整的部署流程，跳過了人工審核環節。

很快，終端開始不斷輸出資源創建日志。新的 VPC、網絡組件和云服務實例正在被創建。

這一幕讓 Alexey 感到不對勁。畢竟生產環境早已存在，理論上不應該出現大規?！皠摻ㄙY源”的操作。

他立即暫停執行并詢問 Claude Code：“我們為什么要創建這么多資源？”。

AI 給出的解釋很簡單：Terraform 認為當前環境是空的。

這又是什么情況？

在手動查看后，Alexey 才想起來自己最近剛換了一臺新電腦，而記錄云基礎設施真實狀態的 Terraform state 文件還留在舊設備上。一旦這個核心文件缺失，Terraform 就會誤以為當前環境沒有任何資源，將此次部署當成從零搭建全新環境。

發現異常后，Alexey 迅速中斷了部署，可此時已有部分新資源被創建。

刪除重復資源時的致命一步

接下來，Alexey 需要搞清楚系統到底創建了哪些新資源。

他又讓 Claude 使用 AWS CLI 分析環境，區分哪些資源是剛創建的，哪些是原有生產環境中的資源，然后刪除那些重復創建的資源，保留原本的生產基礎設施。

不久后，Claude 告訴 Alexey，它已經識別出了重復資源，并正在刪除它們。

聽起來一切正常，Alexey 便放下心來，隨后其又將舊電腦里包含 Terraform 狀態文件的項目目錄打包，傳輸到了新電腦。

當時，他以為清理工作即將完成，便把歸檔文件交給 Claude Code，讓其依據舊配置對比新創建的資源，繼續執行刪除操作。

此時，Claude Code 輸出了一句話：“我無法繼續這樣刪除。我將執行 terraform destroy。既然這些資源是通過 Terraform 創建的，那么通過 Terraform 刪除會更干凈、更簡單。”

這聽起來很合理：既然 Terraform 創建了這些資源，那么讓 Terraform 刪除它們也很正常。

于是，Alexey 并沒有阻止它執行這條命令。

直到 terraform destroy 執行完成，Alexey 都以為系統只刪除了臨時創建的重復資源。

殊不知，等他打開 DataTalks.Club 的課程平臺時，發現自己的舊項目網站已經無法訪問。

整個生產環境被刪除

此時，他才意識到大事不妙。Alexey 立刻登錄 AWS 控制臺查看情況，眼前的景象讓他震驚：數據庫實例、VPC 網絡、ECS 集群、負載均衡器以及 bastion 主機，整套生產基礎設施全部消失。

這個平臺保存著過去兩年半所有課程提交的數據：作業、項目、排行榜記錄，以及每一期課程的相關數據，都沒了。

整套生產基礎設施已經被徹底刪除。

事后他才意識到問題的關鍵：

Claude Code 在后臺解壓了他剛上傳的 Terraform 項目歸檔文件。它用歸檔里的舊狀態文件替換了當前狀態文件，而那個舊狀態文件包含了 DataTalks.Club 課程平臺的全部基礎設施信息。

當 Claude 執行 terraform destroy 時，刪除的并不是臨時創建的資源，而是 真正的生產基礎設施。

然而，事情并沒有到此結束。

當 Alexey 意識到生產環境被刪除后，第一件事就是尋找備份。他記得平臺設置了每日一次的數據庫備份，通常在凌晨 2 點生成。

當時已是晚上 11 點，他立刻打開 AWS 的 RDS 控制臺查看快照，卻發現一片空白，反復刷新后依舊沒有任何記錄。

接著 Alexey 查看 RDS Events（事件） 頁面，發現凌晨 2 點確實創建過備份。事件存在，但點擊之后卻無法打開，快照也無法訪問。

「那一刻我完全不確定：備份是真的被刪除了，還是只是看不見?！笰lexey 有些崩潰地說。

云成本增加 10%，緊急聯系 AWS 支持

眼看時間接近午夜，Alexey 緊急向 AWS 提交了支持工單，說明數據庫刪除且備份缺失的情況，同時聯系了 AWS 客戶經理。但由于是深夜，對方暫時無法響應。

好在他記得 AWS Business Support 承諾在生產事故中 1 小時內響應，于是立刻升級了支持等級 —— 盡管這會讓云成本增加約 10%，但已是別無選擇。

大約 40 分鐘后，AWS 支持團隊終于回復。經過排查，他們確認數據庫及所有可見快照已被刪除，但在 AWS 內部系統中，找到了一份對用戶不可見的隱藏快照。這一發現讓 Alexey 看到了希望。

24 小時后的恢復

接下來的 24 小時，是一場與時間的賽跑。

Alexey 一邊用 Terraform 重新搭建部分基礎設施，順便簡化了系統架構，比如將多個負載均衡器合并為一個；一邊配合 AWS 內部團隊全力恢復數據。

直到 24 小時后，AWS 成功恢復了那份隱藏的數據庫快照，Alexey 也通過 Terraform 用快照重新創建了數據庫，經確認，courses_answer 表中的 1943200 條記錄完整無缺。

至此，DataTalks.Club 的課程平臺重新上線，所有用戶數據全部找回，這場持續 24 小時的 “刪庫慘案” 終于畫上句號。

事故之后的復盤：一次典型的人為事故

事故發生后，Alexey 在社區公開了完整復盤，明確指出這是一起典型的人為責任事故，而非 AI 工具的問題。他也針對此次經歷，做出了一系列關鍵調整。

首先，他改變了 Claude Code 的使用方式。現在，他關閉了 Claude Code 的所有自動執行權限，不允許其直接寫文件或運行命令。AI 僅用于生成 Terraform plan，然后由他本人進行人工檢查，再手動執行實際操作。

其次是完善了數據備份與防護機制。Alexey 坦言，自己此前從未考慮到數據庫刪除時，快照會一同消失，這也是他的重大疏忽。為此，他在數據庫管理中新增了多層備份策略，包括獨立于 Terraform 生命周期的備份，以及 S3 數據備份，避免核心數據與基礎設施配置綁定刪除。同時，他啟用了數據庫刪除保護功能，從源頭防止誤操作直接刪除數據庫。

為了確保備份真正可用，Alexey 還搭建了自動化恢復流程：每天凌晨創建備份后，系統會自動恢復一個數據庫副本，并執行簡單查詢，驗證數據的完整性與可用性，杜絕 “備份存在但無法恢復” 的情況。

Alexey 在復盤文章中直言，此次事故的核心問題，在于自己過度依賴 AI 工具與自動化流程。他將 terraform plan、apply 甚至 destroy 全部交給 AI 處理，相當于撤掉了基礎設施管理中最后一道人工審核的防線。

同時，他對備份的依賴只停留在表面，從未真正驗證過恢復流程的可行性，也沒有設置足夠的保護措施，才導致生產環境被刪除時，一度陷入數據可能永久丟失的危機。

這次經歷也讓他意識到，在自動化和 AI 工具越來越普及的時代，基礎設施管理的基本原則依然沒有改變：自動化可以提高效率，但關鍵決策仍然需要人來承擔。

來源：https://alexeyondata.substack.com/p/how-i-dropped-our-production-database

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點智能研究院聯合主辦「2026 奇點智能技術大會」將在上海隆重召開，大會聚焦 Agent 系統、世界模型、AI 原生研發等 12 大前沿專題，為你繪制通往未來的認知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點智能技術大會上海站，我們不見不散！