从微软蓝屏事件聊到数据库系统中的纸牌屋

2024 年 7 月 19 日，全球约有 850 万台 Windows 电脑崩溃，无法重启，陷入蓝屏死机状态。这次故障影响了全球各地的企业和政府，波及运输、金融服务、医疗保健等绝大多数行业。

故障发生几小时后，蓝屏原因找到，是美国网络服务提供商 CrowdStrike 更新错误所致。

第二天，红迪（reddit）网的 AskReddit 社区（该社区旨在「讨论一些下饭的问题」），出现了一篇紧跟时事的帖子：「为纪念微软蓝屏事件，来聊聊你在工作中闯的最大的祸」。

让我们从「很久很久很久以前的一场悲剧」开始欣赏打工人干的好事。 网友 pm1966 公司曾经的 DBA 在测试时注释了 WHERE 子句，导致数百万条记录在几秒钟内消失。事情发生在周五下午，混乱持续了整个周末。 他现在的评价是，这事不能完全归咎于他；但假如他对自己的数据库编程更有信心，他本可以迅速发现这个错误。

网友 slyiscoming 想到了大量数据造成的堵塞。他曾经为客户关闭一个大型数据库，服务器花了 3 天时间才恢复。他还在更新一个生产型客户的测试环境时，工作到凌晨 3 点，才将更改回滚，因为当时他们还没有回滚脚本。

网友 quiggyfish 因为没有重视备份，花了团队大量的精力，才从误删所有数据库的灾难性事故中复原。

网友 eury13 当时在一家初创软件公司工作。某天临下班时，他在内部管理平台上照常注销取消订单的客户账户。CEO 突然路过，注意到平台上离职员工的名字，并要求他将这些账户一并注销。 但前员工的一些用户账户被硬编码到了他们的代码库中，这意味着一旦这些账户被注销，系统就会因无法完成各种进程而瘫痪。 团队通过重新启用旧的用户账户解决了这个问题，他也没有惹上麻烦。但要为这种麻烦事加班，真是糟糕……

同一个公司，同一个 eury13，还有一个故事，是关于数据库开放写入权限的后果。 他们的公司管理账户时，必须手动更改 SQL 数据库。某次他弄错了 ID 号，因此错误地注销了一个用于系统监控的账户。监控工具发现后发送了大量警报，在各种系统中引发连锁故障，系统又瘫痪了。 虽然他又一次没有被解雇，监控账户重新打开，一切恢复正常，但他事后想想，那家公司的系统简直是个纸牌搭的房子。他们没有任何控制措施来防止像这样的无辜失误造成巨大的连带问题。

所以（借用网友 db-master 的评论）： 这个故事告诉我们，为了避免闯同样的祸，请用 Bytebase。

---

💡 更多资讯，请关注 Bytebase 公号：Bytebase