写这篇文章，我想先聊聊一个生活中常见的场景：你家冰箱坏了，里面的食物快坏了，你知道修理师傅来了，但他告诉你“先别关电源，可能只是小问题”，结果冰箱彻底罢工了。你会不会想，干嘛不先断电回滚，等确认没问题了再开？这其实跟大公司的运维决策很像。
Cloudflare官方甩锅Lua？真正的问题是没人敢回滚
12月5日，Cloudflare发生了一次大范围宕机，官方博客里把锅甩给了一个“Lua异常”，说是代码执行时触发了规则模块的bug。但这背后，真正让人头疼的不是代码本身，而是团队在面对问题时的决策困境：明明知道有问题，为什么不回滚，反而继续推送新版本？
事件时间线还原
● 12月5日，Cloudflare发布了一个涉及安全规则的配置更新。
● 代码一旦传播到全球网络，FL1代理中的Lua规则模块触发异常，导致服务中断。
● 官方博客承认是Lua代码执行异常导致，但没提及为何不回滚。
● Hacker News上质疑声四起：为什么不直接回滚？为什么要冒险再推一次？
“安全问题”与“部署系统缺陷”的博弈
Cloudflare这次事故的核心，不是Lua代码写得不好，而是部署流程和决策文化出了问题。
● 安全问题 ：这次更新是安全相关的，团队担心回滚会带来安全风险，可能让系统暴露在攻击面前。
● 部署系统缺陷 ：11月18日刚经历过一次类似的部署系统故障，说明他们的发布流程本身就有隐患。
这就像你家冰箱坏了，修理师傅说“先别断电，怕里面东西坏”，但其实断电才是最安全的选择。Cloudflare团队在“安全”和“稳定”之间摇摆，最终选择了继续发布，结果导致更大范围的宕机。
PM话术 vs 工程现实的冲突
从官方声明看，PM们总喜欢用“风险评估”、“安全优先”这样的词汇掩盖真实情况：
● PM话术 ：强调“我们采取了谨慎措施”，“确保安全不受影响”。
● 工程现实 ：团队没有回滚，反而继续推送，说明他们对风险的判断和实际操作脱节。
Hacker News上有人说，这更像是“牛仔式决策”，团队可能已经不按规矩出牌了。这背后反映的，是大公司里普遍存在的“技术债”和“组织压力”：
● 技术债 ：部署系统不完善，测试覆盖不足，代码甚至没经过单元测试。
● 组织压力 ：安全团队和运维团队之间的博弈，PM对上线时间和安全的双重压力，导致没人敢按下回滚按钮。
为什么没人敢回滚？
回滚听起来简单，但在大规模分布式系统里，回滚本身就是一场风险博弈：
● 回滚可能导致数据不一致、配置混乱。
● 可能引发安全漏洞暴露。
● 组织内部对回滚的责任归属不明确，怕被追责。
● 文化上，回滚被视为“失败”，团队更愿意“继续修复”。
这就形成了一个恶性循环：明知有问题，没人敢回滚，问题越积越多，最终爆发成大事故。
给技术管理者和运维工程师的几点建议
● 别把回滚当成失败 ，它是风险控制的必备手段。
● 完善部署和回滚流程 ，确保回滚可以快速、安全执行。
● 建立跨团队沟通机制 ，让安全、运维和开发在风险评估上达成共识。
● 减少技术债 ，包括代码测试覆盖和自动化部署。
● 培养敢于承担责任的文化 ，让团队敢于面对问题，及时止损。
这次Cloudflare的事故，表面上是Lua代码的锅，实际上是大公司运维文化的锅。技术再牛，决策不对，还是会翻车。比起找代码bug，真正难啃的是“没人敢回滚”的决策困境。
附：简单流程图帮你理解决策困境
部署新版本
↓
发现异常
↓
评估风险
↙ ↘
回滚？ 继续发布修复
↓ ↓
风险可控 风险扩大
↓ ↓
服务恢复 大规模宕机
别等到冰箱彻底坏了才后悔，技术管理这事儿，敢于回滚，才是稳扎稳打的真理。