原文链接：https://zaidesanton.substack.com/p/how-i-destroyed-the-companys-db
这本是一个安静的星期六。
我收到了支持团队的一条消息，说我们一个客户遇到了问题。我认为这个问题很重要，值得开始调试。15 分钟后，我明白了问题所在 - 在数据库中有一些损坏的订单需要删除。
事故还原
有几百个订单需要删除，所以我决定不手动操作，而是编写一个简单的 SQL 查询语句（警告 🚩）UPDATE ordersSET is_deleted = true
WHERE id in (1, 2, 3)
我按下了 CTRL + Enter 并运行了命令。当它花费超过一秒钟时，我明白发生了什么。我的客户端 DBeaver 看到空的第三行，并忽略了第四行。恢复
深吸一口气后，我知道我必须快速行动起来。不能犯更多错误浪费时间了。停止系统 - 约 5 分钟
创建变更前数据库（幸运的是我们有 PITR）的克隆 - 约 20 分钟
在等待期间给我的老板打电话 😨
根据克隆更新生产数据库的信息* - 约 15 分钟
*我决定不还原整个数据库，因为无法停止所有系统，因为我们有多个独立的系统。我不想在恢复过程中丢失所做的更改。我们用 GCP 提供的托管 PostgreSQL，所以我从更新之前创建了一个新的克隆。然后，我只导出了克隆中的 id 和 is_deleted 列，并将结果导入到生产数据库中。之后，就是简单的 update + select 语句。所以显然本可以很容易避免这 45 分钟的停机时间...发生了什么？
这可能听起来像是一个你永远不会犯的愚蠢错误（甚至在大公司中，根本不能犯）。确实。问题不在于错误的 SQL 语句。一个小小的人为失误从来都不是真正的问题。我运行那个命令只是整个失败链条的终点。为什么要在周末处理生产环境？在这种情况下，事情并没有那么紧急。没有人要求我立即修复它。我本可以等到星期一再处理。
谁会在生产数据库上更改而不先在 QA 环境上运行一下呢？
为什么我手动编辑了数据库而不是通过调用 API？
如果没有 API，为什么我没打电话给队友，在如此敏感的操作上进行双重检查？
- 最糟糕的是，为什么我没使用事务？其实只要用了
Begin，万一出错时使用 Rollback 就可以了。
错误一层层叠加，其中任何一个被避免了 - 整件事就不会发生。大多数问题答案都很简单：我太自信了。不过还好通过有章法的恢复程序，阻止了连锁反应。想象一下如果无法将数据库恢复到正确状态会发生什么灾难……这与切尔诺贝利有什么关系？
几个月前，我阅读了「切尔诺贝利：一部悲剧史」。那里发生的一系列错误使我想起了那个被诅咒的周末（并不是要低估或与切尔诺贝利灾难相比较）。RBMK 反应堆存在根本技术问题。
这个问题没有得到恰当传达。之前有涉及该问题的事件，但切尔诺贝利团队对此并不熟悉。
在安全检查期间，团队没有按程序操作。
- 爆炸后，苏联政府试图掩盖事实，从而大大加剧了损害程度。
反应堆设计师？其他电厂团队未能传达他们遇到的问题？切尔诺贝利团队？苏联政府？所有人都有责任。灾难从来不是由单一错误引起的，而是由一连串错误造成的。我们的工作就是尽早打断这条链条，并做到最好。后续
但他让我惊讶：「确保不再发生这种情况。但是我更喜欢这样 - 你犯了错误是因为你专注并且喜欢快速行动。做得越多，砸得越多。」那正是我需要听到的。如果以过于「亲切」的方式说：没关系，别担心，谢谢你修复它！我反而会感觉虚伪。另一方面，我已经感觉很糟糕了，所以没有必要进一步吐槽我。我们减少了对数据库直接访问的需求，并创建相关的 API。
我总是先在 QA 上运行查询（显而易见吧？没有比灾难更能教训人了）。
我与产品经理商量，了解真正紧急和可以等待的事项。
任何对生产环境进行更删改操作都需要两个人来完成。这实际上防止了其他错误！
可以应用在你的团队中的经验教训
事发后，我和团队详细分享了过程，没有隐瞒任何事情，也没有淡化我的过错。在责备他人和不追究责任之间有一个微妙的平衡。当你犯错误时，这是一个传递正确信息的好机会。如果你道歉 1000 次，他们会认为你期望当事情发生在他们身上时，他们也需要给出同样的回应。如果你一笑了之，并忽视其影响，他们会认为这是可以接受的。如果你承担责任、学习并改进自己 - 他们也会以同样的方式行事。
总结一下
鼓励行动派，关心客户，并解决问题。这就是初创企业成功的方式。
当犯错时，要追究责任。一起理解如何避免这种情况发生。
没必要落井下石。有些人需要更多的责任感，而有些人则需要更多的鼓励。我倾向于以鼓励为主。
BB仔约 5 分钟