之前我們連續分析了兩起誤刪庫事件，Linear 刪庫，GitLab 刪庫。就在我們準備讓這個主題告一段落時，業界又發生了一起刪庫事件。

這次的主角是 Resend，也是最近硅谷冉冉升起的明星初創公司。想重塑郵件體驗，挑戰像 Mailchimp 這樣的老牌玩家。

這次的刪庫事件依然是熟悉的配方，在執行數據庫 schema 變更時，本來是針對本地環境執行，但結果命令發給了生產數據庫，就這樣把數據都刪沒了。

而在恢復的過程中，第一次恢復使用了錯誤的備份，導致浪費了 6 個小時。又經過額外的 5 小時備份，才把數據庫恢復過來，但還是有 5 分鐘的數據丟失了。Resend 也列出了一些後續措施：

• 恢復 5 分鐘丟失的數據
• 收回所有用户對生產環境的寫權限
• 改進本地開發流程，以降低數據庫 schema 變更的風險
• 提高故障演練的頻率

也因為 Resend 小有名氣，所以也引來了 Hacker News 上網友們的鋭評：

太業餘了，像 email 這種核心組件，還是交給更加成熟的 AWS SES，Postmark，Sendgrid 這些吧。

或許這家公司根本就不該存在。

如何避免

筆者認為這個故障雖然有點低級。但連錯數據庫這個事情，不算少見。備份過程碰到意外，也很常見。當然低級的問題，解決起來也不難。

針對第一點，引入像 Bytebase 這樣的變更審核工具，所有針對生產環境的變更操作都要通過 Bytebase，經過人工審核後才能發佈。

針對第二點，首先是採用雲上的託管數據庫服務，因為他們提供了完整的數據備份和恢復功能。另外就是定期做災備演練。

大家也引以為戒吧。

💡 更多資訊，請關注 Bytebase 公號：Bytebase