为省5-10美元差点毁库！Claude一条指令删光200万条数据、网站停摆24小时，创始人坦言：全是我的错

Ne0inhk

14 Mar 2026 — 13 min read

编译 | 屠敏

出品 | ZEEKLOG（ID：ZEEKLOGnews）

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 感到不对劲。毕竟生产环境早已存在，理论上不应该出现大规模“创建资源”的操作。

他立即暂停执行并询问 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 点确实创建过备份。事件存在，但点击之后却无法打开，快照也无法访问。

「那一刻我完全不确定：备份是真的被删除了，还是只是看不见。」Alexey 有些崩溃地说。

云成本增加 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