火烧眉毛，我是如何在周六删了公司的数据库

原文链接：https://zaidesanton.substack.com/p/how-i-destroyed-the-companys-db

这本是一个安静的星期六。

事故还原

UPDATE ordersSET is_deleted = true
WHERE id in (1, 2, 3)

恢复

1. 停止系统 - 约 5 分钟

2. 创建变更前数据库（幸运的是我们有 PITR）的克隆 - 约 20 分钟

3. 在等待期间给我的老板打电话 😨

4. 根据克隆更新生产数据库的信息* - 约 15 分钟

5. 启动系统 - 约 5 分钟

发生了什么？

1. 为什么要在周末处理生产环境？在这种情况下，事情并没有那么紧急。没有人要求我立即修复它。我本可以等到星期一再处理。

2. 谁会在生产数据库上更改而不先在 QA 环境上运行一下呢？

3. 为什么我手动编辑了数据库而不是通过调用 API？

4. 如果没有 API，为什么我没打电话给队友，在如此敏感的操作上进行双重检查？

5. 最糟糕的是，为什么我没使用事务？其实只要用了 Begin，万一出错时使用 Rollback 就可以了。

这与切尔诺贝利有什么关系？

1. RBMK 反应堆存在根本技术问题。

2. 这个问题没有得到恰当传达。之前有涉及该问题的事件，但切尔诺贝利团队对此并不熟悉。

3. 在安全检查期间，团队没有按程序操作。

4. 爆炸后，苏联政府试图掩盖事实，从而大大加剧了损害程度。

后续

• 我们减少了对数据库直接访问的需求，并创建相关的 API。

• 我总是先在 QA 上运行查询（显而易见吧？没有比灾难更能教训人了）。

• 我与产品经理商量，了解真正紧急和可以等待的事项。

• 任何对生产环境进行更删改操作都需要两个人来完成。这实际上防止了其他错误！

• 我开始使用事务处理机制。

可以应用在你的团队中的经验教训

总结一下

• 鼓励行动派，关心客户，并解决问题。这就是初创企业成功的方式。

• 当犯错时，要追究责任。一起理解如何避免这种情况发生。

• 没必要落井下石。有些人需要更多的责任感，而有些人则需要更多的鼓励。我倾向于以鼓励为主。

顺便说一句，如果团队采用了 Bytebase 的话，这个事故是大概率可以被避免的，因为 Bytebase 有好几道防线：

1. 用户不能随意通过使用 DBeaver 这样的本地客户端直连数据库，而必须通过 Bytebase 提交变更工单。

2. 变更工单的 SQL 会经过自动审查，如果影响范围有异常，会有提示。

3. 变更工单只有通过人工审核后才能发布。