為省5-10美元差點(diǎn)毀庫！Claude一條指令刪光200萬條數(shù)據(jù)、網(wǎng)站停擺24小時(shí)，創(chuàng)始人坦言：全是我的錯(cuò)

編譯 | 屠敏

出品 | CSDN（ID：CSDNnews）

AI 時(shí)代，一次看似普通的操作，竟能讓整套生產(chǎn)環(huán)境與近 200 萬條數(shù)據(jù)瞬間「歸零」。

近日，數(shù)據(jù)科學(xué)社區(qū) DataTalks.Club 創(chuàng)始人 Alexey Grigorev 就遭遇了這樣的驚魂時(shí)刻，他在使用 AI 編程工具 Claude Code 管理網(wǎng)站服務(wù)器時(shí)，意外清空了平臺(tái)積累 2.5 年的核心數(shù)據(jù)，甚至連數(shù)據(jù)庫快照也未能幸免，導(dǎo)致網(wǎng)站停擺整整 24 小時(shí)。

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

一次看似很普通的網(wǎng)站遷移

這場(chǎng)“刪庫”事件的前因，其實(shí)并不復(fù)雜。

當(dāng)時(shí) Alexey 正在開發(fā)一個(gè)新網(wǎng)站 AI Shipping Labs（https://aishippinglabs.com/）。這個(gè)網(wǎng)站原本托管在 GitHub Pages 上，是一個(gè)靜態(tài)站點(diǎn)。

不過，Alexey 計(jì)劃把網(wǎng)站遷移到 AWS 云平臺(tái)，并在后續(xù)將原本的 Next.js 實(shí)現(xiàn)逐步替換為 Django 版本。

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

這樣一來，所有資源都會(huì)進(jìn)入 AWS，最終切換時(shí)幾乎不會(huì)影響用戶訪問。

從架構(gòu)設(shè)計(jì)角度來看，這套遷移策略本身并沒有明顯問題。

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

為節(jié)省 5-10 美元復(fù)用生產(chǎn)環(huán)境，卻意外清空了 2.5 年的數(shù)據(jù)積累

事實(shí)上，Alexey 此前就一直用 Terraform 管理自己創(chuàng)立的另一個(gè)項(xiàng)目 DataTalks.Club 的生產(chǎn)基礎(chǔ)設(shè)施，這套系統(tǒng)主要支撐著 DataTalks.Club 的 Zoomcamps 課程平臺(tái)。

按理說，新項(xiàng)目 AI Shipping Labs 應(yīng)該部署在另一個(gè)獨(dú)立的環(huán)境中，但為了節(jié)省一點(diǎn)成本，Alexey 決定直接把新項(xiàng)目加入現(xiàn)有的 Terraform 配置中。

這意味著兩個(gè)項(xiàng)目將共享同一套 AWS 基礎(chǔ)設(shè)施，包括 VPC 私有網(wǎng)絡(luò)、ECS 集群、負(fù)載均衡器以及 bastion 主機(jī)。

遷移過程中，Alexey 依賴 Claude Code 來提高效率。所以在接收到 Alexey 的要求時(shí)，Claude Code 照做了，但同時(shí)也給出了提醒：最好為新項(xiàng)目創(chuàng)建獨(dú)立環(huán)境，以避免影響現(xiàn)有系統(tǒng)。

然而，Alexey 認(rèn)為再創(chuàng)建一個(gè) VPC 并不劃算，于是堅(jiān)持讓新項(xiàng)目使用同一套基礎(chǔ)設(shè)施。節(jié)省的成本其實(shí)并不多，大約每月 5 到 10 美元。

但正是這一步的決定，讓兩個(gè)項(xiàng)目的基礎(chǔ)設(shè)施變更混在了一起，也為后續(xù)事故埋下了隱患。

第一個(gè)異常信號(hào)

當(dāng)時(shí)間來到 2 月 26 日晚上約 10 點(diǎn)，Alexey 開始通過 Terraform 部署網(wǎng)站更新。

正常流程下，Terraform 會(huì)先執(zhí)行 terraform plan 命令，讓工程師確認(rèn)即將發(fā)生的資源變更，這是保障操作安全的關(guān)鍵一步。

但這一次，Alexey 直接讓 Claude Code 運(yùn)行了完整的部署流程，跳過了人工審核環(huán)節(jié)。

很快，終端開始不斷輸出資源創(chuàng)建日志。新的 VPC、網(wǎng)絡(luò)組件和云服務(wù)實(shí)例正在被創(chuàng)建。

這一幕讓 Alexey 感到不對(duì)勁。畢竟生產(chǎn)環(huán)境早已存在，理論上不應(yīng)該出現(xiàn)大規(guī)模“創(chuàng)建資源”的操作。

他立即暫停執(zhí)行并詢問 Claude Code：“我們?yōu)槭裁匆獎(jiǎng)?chuàng)建這么多資源？”。

AI 給出的解釋很簡(jiǎn)單：Terraform 認(rèn)為當(dāng)前環(huán)境是空的。

這又是什么情況？

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

發(fā)現(xiàn)異常后，Alexey 迅速中斷了部署，可此時(shí)已有部分新資源被創(chuàng)建。

刪除重復(fù)資源時(shí)的致命一步

接下來，Alexey 需要搞清楚系統(tǒng)到底創(chuàng)建了哪些新資源。

他又讓 Claude 使用 AWS CLI 分析環(huán)境，區(qū)分哪些資源是剛創(chuàng)建的，哪些是原有生產(chǎn)環(huán)境中的資源，然后刪除那些重復(fù)創(chuàng)建的資源，保留原本的生產(chǎn)基礎(chǔ)設(shè)施。

不久后，Claude 告訴 Alexey，它已經(jīng)識(shí)別出了重復(fù)資源，并正在刪除它們。

聽起來一切正常，Alexey 便放下心來，隨后其又將舊電腦里包含 Terraform 狀態(tài)文件的項(xiàng)目目錄打包，傳輸?shù)搅诵码娔X。

當(dāng)時(shí)，他以為清理工作即將完成，便把歸檔文件交給 Claude Code，讓其依據(jù)舊配置對(duì)比新創(chuàng)建的資源，繼續(xù)執(zhí)行刪除操作。

此時(shí)，Claude Code 輸出了一句話：“我無法繼續(xù)這樣刪除。我將執(zhí)行 terraform destroy。既然這些資源是通過 Terraform 創(chuàng)建的，那么通過 Terraform 刪除會(huì)更干凈、更簡(jiǎn)單。”

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

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

直到 terraform destroy 執(zhí)行完成，Alexey 都以為系統(tǒng)只刪除了臨時(shí)創(chuàng)建的重復(fù)資源。

殊不知，等他打開 DataTalks.Club 的課程平臺(tái)時(shí)，發(fā)現(xiàn)自己的舊項(xiàng)目網(wǎng)站已經(jīng)無法訪問。

整個(gè)生產(chǎn)環(huán)境被刪除

此時(shí)，他才意識(shí)到大事不妙。Alexey 立刻登錄 AWS 控制臺(tái)查看情況，眼前的景象讓他震驚：數(shù)據(jù)庫實(shí)例、VPC 網(wǎng)絡(luò)、ECS 集群、負(fù)載均衡器以及 bastion 主機(jī)，整套生產(chǎn)基礎(chǔ)設(shè)施全部消失。

這個(gè)平臺(tái)保存著過去兩年半所有課程提交的數(shù)據(jù)：作業(yè)、項(xiàng)目、排行榜記錄，以及每一期課程的相關(guān)數(shù)據(jù)，都沒了。

整套生產(chǎn)基礎(chǔ)設(shè)施已經(jīng)被徹底刪除。

事后他才意識(shí)到問題的關(guān)鍵：

Claude Code 在后臺(tái)解壓了他剛上傳的 Terraform 項(xiàng)目歸檔文件。它用歸檔里的舊狀態(tài)文件替換了當(dāng)前狀態(tài)文件，而那個(gè)舊狀態(tài)文件包含了 DataTalks.Club 課程平臺(tái)的全部基礎(chǔ)設(shè)施信息。

當(dāng) Claude 執(zhí)行 terraform destroy 時(shí)，刪除的并不是臨時(shí)創(chuàng)建的資源，而是 真正的生產(chǎn)基礎(chǔ)設(shè)施。

然而，事情并沒有到此結(jié)束。

當(dāng) Alexey 意識(shí)到生產(chǎn)環(huán)境被刪除后，第一件事就是尋找備份。他記得平臺(tái)設(shè)置了每日一次的數(shù)據(jù)庫備份，通常在凌晨 2 點(diǎn)生成。

當(dāng)時(shí)已是晚上 11 點(diǎn)，他立刻打開 AWS 的 RDS 控制臺(tái)查看快照，卻發(fā)現(xiàn)一片空白，反復(fù)刷新后依舊沒有任何記錄。

接著 Alexey 查看 RDS Events（事件） 頁面，發(fā)現(xiàn)凌晨 2 點(diǎn)確實(shí)創(chuàng)建過備份。事件存在，但點(diǎn)擊之后卻無法打開，快照也無法訪問。

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

云成本增加 10%，緊急聯(lián)系 AWS 支持

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

好在他記得 AWS Business Support 承諾在生產(chǎn)事故中 1 小時(shí)內(nèi)響應(yīng)，于是立刻升級(jí)了支持等級(jí) —— 盡管這會(huì)讓云成本增加約 10%，但已是別無選擇。

大約 40 分鐘后，AWS 支持團(tuán)隊(duì)終于回復(fù)。經(jīng)過排查，他們確認(rèn)數(shù)據(jù)庫及所有可見快照已被刪除，但在 AWS 內(nèi)部系統(tǒng)中，找到了一份對(duì)用戶不可見的隱藏快照。這一發(fā)現(xiàn)讓 Alexey 看到了希望。

24 小時(shí)后的恢復(fù)

接下來的 24 小時(shí)，是一場(chǎng)與時(shí)間的賽跑。

Alexey 一邊用 Terraform 重新搭建部分基礎(chǔ)設(shè)施，順便簡(jiǎn)化了系統(tǒng)架構(gòu)，比如將多個(gè)負(fù)載均衡器合并為一個(gè)；一邊配合 AWS 內(nèi)部團(tuán)隊(duì)全力恢復(fù)數(shù)據(jù)。

直到 24 小時(shí)后，AWS 成功恢復(fù)了那份隱藏的數(shù)據(jù)庫快照，Alexey 也通過 Terraform 用快照重新創(chuàng)建了數(shù)據(jù)庫，經(jīng)確認(rèn)，courses_answer 表中的 1943200 條記錄完整無缺。

至此，DataTalks.Club 的課程平臺(tái)重新上線，所有用戶數(shù)據(jù)全部找回，這場(chǎng)持續(xù) 24 小時(shí)的 “刪庫慘案” 終于畫上句號(hào)。

事故之后的復(fù)盤：一次典型的人為事故

事故發(fā)生后，Alexey 在社區(qū)公開了完整復(fù)盤，明確指出這是一起典型的人為責(zé)任事故，而非 AI 工具的問題。他也針對(duì)此次經(jīng)歷，做出了一系列關(guān)鍵調(diào)整。

首先，他改變了 Claude Code 的使用方式。現(xiàn)在，他關(guān)閉了 Claude Code 的所有自動(dòng)執(zhí)行權(quán)限，不允許其直接寫文件或運(yùn)行命令。AI 僅用于生成 Terraform plan，然后由他本人進(jìn)行人工檢查，再手動(dòng)執(zhí)行實(shí)際操作。

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

為了確保備份真正可用，Alexey 還搭建了自動(dòng)化恢復(fù)流程：每天凌晨創(chuàng)建備份后，系統(tǒng)會(huì)自動(dòng)恢復(fù)一個(gè)數(shù)據(jù)庫副本，并執(zhí)行簡(jiǎn)單查詢，驗(yàn)證數(shù)據(jù)的完整性與可用性，杜絕 “備份存在但無法恢復(fù)” 的情況。

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

同時(shí)，他對(duì)備份的依賴只停留在表面，從未真正驗(yàn)證過恢復(fù)流程的可行性，也沒有設(shè)置足夠的保護(hù)措施，才導(dǎo)致生產(chǎn)環(huán)境被刪除時(shí)，一度陷入數(shù)據(jù)可能永久丟失的危機(jī)。

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

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

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

這場(chǎng)十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點(diǎn)智能研究院聯(lián)合主辦「2026 奇點(diǎn)智能技術(shù)大會(huì)」將在上海隆重召開，大會(huì)聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認(rèn)知地圖。

成為時(shí)代的見證者，更要成為時(shí)代的先行者。

奇點(diǎn)智能技術(shù)大會(huì)上海站，我們不見不散！