共计 667 个字符，预计需要花费 2 分钟才能阅读完成。
之前咱们间断剖析了两起误删库事件，Linear 删库，GitLab 删库。就在咱们筹备让这个主题告一段落时，业界又产生了一起删库事件。
这次的配角是 Resend，也是最近硅谷冉冉升起的明星初创公司。想重塑邮件体验，挑战像 Mailchimp 这样的老牌玩家。
这次的删库事件仍然是相熟的配方，在执行数据库 schema 变更时，原本是针对本地环境执行，但后果命令发给了生产数据库，就这样把数据都删没了。
而在复原的过程中，第一次复原应用了谬误的备份，导致节约了 6 个小时。又通过额定的 5 小时备份，才把数据库恢复过来，但还是有 5 分钟的数据失落了。Resend 也列出了一些后续措施：
- 复原 5 分钟失落的数据
- 发出所有用户对生产环境的写权限
- 改良本地开发流程，以升高数据库 schema 变更的危险
- 进步故障演练的频率
也因为 Resend 小有名气，所以也引来了 Hacker News 上网友们的锐评：
太业余了，像 email 这种外围组件，还是交给更加成熟的 AWS SES，Postmark，Sendgrid 这些吧。
或者这家公司基本就不该存在。
如何防止
笔者认为这个故障尽管有点低级。但连错数据库这个事件，不算少见。备份过程碰到意外，也很常见。当然低级的问题，解决起来也不难。
针对第一点，引入像 Bytebase 这样的变更审核工具，所有针对生产环境的变更操作都要通过 Bytebase，通过人工审核后能力公布。
针对第二点，首先是采纳云上的托管数据库服务，因为他们提供了残缺的数据备份和复原性能。另外就是定期做灾备演练。
大家也引以为戒吧。
💡 更多资讯，请关注 Bytebase 公号：Bytebase
正文完
