谷歌工程师复盘：3个"合理"决策如何把系统拖垮

2023年，某头部云厂商的一次故障让12个区域同时掉线，恢复耗时7小时。事后复盘发现，根因是三年前一个"临时"的超时设置——没人记得要改回去。这种故事在工程圈反复上演，但人们依然用同样的方式制造下一个。

生产系统本质上是一场持续运行的实验。问题在于，大多数团队早就停止了观测。

「临时方案」的复利陷阱

每个系统诞生时都有明确意图：需求文档、架构评审、上线 checklist。但杀死它们的不是文档缺失，而是未被观测的缓慢变异。

我见过最昂贵的软件退化，并非来自糟糕的代码质量。某支付团队曾在双11前把缓存TTL从5分钟调到30秒——为了扛住峰值。这个"临时"调整存活了四年，期间没人测算过它对数据库的真实压力。直到一次常规扩容触发了连锁反应，账单比预期高出800%。

早期假设的寿命往往远超其合理性。一个性能捷径、一个赶工引入的依赖、一次"只此一回"的例外处理。单独看，每个决策都经得起推敲。但系统不会局部崩溃，它们死于累积效应。

沉默的漂移如何失控

假设与现实的鸿沟很少主动示警。没有单一的破坏性变更，只有可预测性的逐渐流失：延迟从50ms爬到200ms，边缘案例从3个变成300个，故障恢复从自动脚本退化为值班手册。

团队用"英雄主义"填补洞察的空白。凌晨三点的电话、手工执行的修复步骤、口口相传的"这次要这样搞"。领导层隐约感到脆弱，却说不清具体哪里不对。

常见的应对是加流程：更严格的变更审批、更长的测试周期、更多的文档模板。但这治标不治本。流程无法替代观测，它只能让团队在信息不足时更有仪式感地犯错。

把实验重新跑起来

真正有效的做法听起来过于朴素：持续比对"我们认为系统在做什么"和"它实际在做什么"。

Netflix 的混沌工程（Chaos Engineering，一种通过主动注入故障来验证系统韧性的方法）之所以有价值，不是因为它制造故障，而是它强制暴露假设与现实的偏差。没有这种外部刺激，漂移会被误认为是稳定。

一位 SRE 负责人曾向我展示他的团队仪表盘：不是监控指标的数量，而是"未验证假设"清单——每个架构决策附带一个到期日，到期必须重新测量。三年后，他们的平均故障恢复时间（MTTR）下降了67%。

技术债的真正成本不是修复工作量，而是你不知道它在哪里。当所有生产系统都是实验，唯一的问题是：你的对照组还在运行吗？