刚看完 Cloudflare 的故障复盘，虽然有点心疼他们，但是吃瓜还是蛮快乐的

[swananan]

https://blog.cloudflare.com/18-november-2025-outage/

几个零散的感想：

1. 复盘这么快其实很正常，所有公司在处理这种大故障，都是连夜复盘的，但是复盘结果完全透明公开，我觉得 Cloudflare 还是牛逼
2. 11 点半 5xx 大盘报警，2 点半定位根因，开始止血恢复。我想想，都有点窒息，对于排障工程师来说，这三个小时太难熬了。果然，定位根因的方式来恢复故障会非常慢
3. 核心组件没有处理好从来没出现过的小概率场景，然后引发全盘血崩，是最经典的大故障引入方式了。不过，unwrap 是什么鬼，哈哈哈，写这行代码的哥们，还有负责 review 的哥们，要有心理阴影了

[Amex]

怪写代码的人或者 reviewer 没意义 而且 root cause 不是因为 features 太多导致 hit limit 么

[defage]

墨菲定律

一般大的场景和问题，大家都能关注到。

那种极小概率，但容易黑天鹅的，通常就是容易漏。 这是一定的，不然定律就失效了。这世界就是这样哈哈哈

[diivL]

@defage 墨菲定律是这么说的吗？现在的人学会给词就到处用吗？

[atpex]

@Amex doubled features 是直接原因不是根本原因，你编程的时候不能假定 feature 数量一定是合理的。

[zepc007]

@diivL 是这么说的啊，也适用这个场景啊

[swananan]

@Amex 感觉不能考验人性，写了代码，出了问题，或多或少肯定要担责的

[goodryb]

额，难道 cloudflare 做数据库变更不灰度和验证吗；还有这个 200 硬性限制，超过就 panic 是认真的吗，太离谱了

[malusama]

panic 直接就业务不可用了， 不是应该降级吗

[aloxaf]

还有一个感同身受的事情：cloudflare 的状态页面碰巧也挂掉了，导致他们认为两者存在关联，继而认为这是一场攻击。

太经典了，两个简单的问题同时出现，结果被误认为存在关联，然后排查路径就歪了😆

[7beloved]

月初我司一行 sql 导致 C 端全线崩，也是连夜复盘

[j8sec]

哈哈，我司底层 API 海外流量在 Cloudflare 上，
代理商电话打爆了，笑不出来。