10月20号早上，谷歌云伦敦机房停电了。

物理故障，europe-west2-b可用区，变压器出了问题。这种事故按理说是"基础设施的事"，跟应用层没关系。电力恢复了，服务就该恢复了，对吧？

没那么简单。

电来了之后，部分客户发现新工作负载创建不了。因为恢复流程本身就依赖一堆配置——哪些服务先启动、流量怎么路由、健康检查阈值多少。这些配置在电力恢复后需要重新适配，而适配过程又引入了新的错误。Revolut全线瘫痪，HSBC和Lloyds的交易也出了问题。

电力故障是"急性病"，来得猛但好诊断。配置错误是"慢性病"，藏在恢复流程里，你以为问题解决了，其实刚埋下新的雷。

一行清理脚本，六个小时

今年2月20日Cloudflare那次更典型。

下午五点四十六分，一个API配置变更部署上线。这个变更里有个清理子任务，负责删除"已废弃"的BYOIP前缀记录。逻辑很简单：查询需要删除的记录，然后删除。

但清理脚本有个bug——当API返回空结果时，它没有报错退出，而是把"空"理解成了"全部"。就像你让扫地机器人清理垃圾，机器人没看到垃圾，于是把房子拆了。

十分钟后，1100个BGP前缀被撤回，占BYOIP总数的25%。Uber Eats、Wikipedia、Steam、Microsoft 365，加上Cloudflare自家的1.1.1.1，全从互联网上"消失"了。

六个小时后才完全恢复。

事后Cloudflare提了个概念叫"断路器"——给配置变更加熔断机制。变更速度太快？暂停。变更范围太大？暂停。变更后指标异常？自动回滚。

这个思路不难实现。难的是你得先承认"配置变更会出大事"这个前提。

代码有流水线，配置有什么？

我想了很久，为什么配置变更总是出事。

代码上线前有CI/CD，有灰度，有回滚，有feature flag。一个PR改了什么文件、什么逻辑，review的人能看懂。配置变更呢？大多数团队的配置管理远没有代码那么严格。代码有自动化测试，配置的验证靠"看看对不对"。代码有canary发布，配置改错了直接全量生效。

今年1月Cloudflare还出过一次事。工程师要删掉迈阿密路由器上波哥大的前缀路由，diff看着很"无害"。结果删错了。25分钟内全网IPv6路由被带偏。

25分钟。一个diff。一个看着无害的diff。

这两次Cloudflare事故有个共同点：变更本身很小，爆炸半径远超预期。代码变更很少这样——一个PR影响范围再大，code review时也能看到改了哪些文件。配置变更不一样，一个参数从A改成B，影响可能横跨十几个服务，但变更单上只有一行。

我自己栽过的跟头

说到配置，我也栽过。

我们有个前端配置平台，支持零代码变更业务需求。有一次环境变量从staging同步到production，格式差了个前缀。测试环境跑了三天没问题，上线后部分用户看到空白页。

查了两个小时才发现，那个配置项在staging有默认值兜底，production没有。

这件事让我对"配置变更"这四个字有了生理性的警觉。后来我们给配置变更也加了review流程和灰度机制。但说实话，执行层面还是会打折扣。配置变更太"小"了，小到让人觉得不值得走那么重的流程。

直到看到Cloudflare的事故报告——他们也是"小"变更，六个小时。

熔断器本身也可能有bug

Cloudflare提的断路器方案很好，但有个元问题：断路器本身也是配置。

Azure去年10月出过一次事故，根因是配置变更绕过了安全校验。为什么绕过？因为校验机制本身有个bug。

这就尴尬了。你用一个系统去保护另一个系统，结果保护系统自己出了问题。

我自己也没完全想明白怎么管好配置。熔断器是个方向，但熔断器的熔断器呢？层层嵌套下去，总有一个最底层的"信任"是裸奔的。

可能最终还是要回到一个很朴素的认知：对生产环境保持敬畏。不管改的是代码还是配置，不管这一行看起来有多"小"。

写到这里我翻了一下2026年至今的宕机记录，全球主要云服务商的重大事故里，配置变更直接相关的占比不低。电力故障、硬件损坏、网络中断——这些传统意义上的"基础设施风险"反而在减少。

真正越来越危险的，是那些看不见、摸不着、改起来轻飘飘的配置项。