2023年，某头部云厂商的一次故障让12个区域同时掉线，恢复耗时7小时。事后复盘发现，根因是三年前一个"临时"的超时设置——没人记得要改回去。这种故事在工程圈反复上演，但人们依然用同样的方式制造下一个。
生产系统本质上是一场持续运行的实验。问题在于，大多数团队早就停止了观测。
「临时方案」的复利陷阱
每个系统诞生时都有明确意图：需求文档、架构评审、上线 checklist。但杀死它们的不是文档缺失，而是未被观测的缓慢变异。
我见过最昂贵的软件退化，并非来自糟糕的代码质量。某支付团队曾在双11前把缓存TTL从5分钟调到30秒——为了扛住峰值。这个"临时"调整存活了四年，期间没人测算过它对数据库的真实压力。直到一次常规扩容触发了连锁反应，账单比预期高出800%。
早期假设的寿命往往远超其合理性。一个性能捷径、一个赶工引入的依赖、一次"只此一回"的例外处理。单独看，每个决策都经得起推敲。但系统不会局部崩溃，它们死于累积效应。
沉默的漂移如何失控
假设与现实的鸿沟很少主动示警。没有单一的破坏性变更，只有可预测性的逐渐流失：延迟从50ms爬到200ms，边缘案例从3个变成300个，故障恢复从自动脚本退化为值班手册。
团队用"英雄主义"填补洞察的空白。凌晨三点的电话、手工执行的修复步骤、口口相传的"这次要这样搞"。领导层隐约感到脆弱，却说不清具体哪里不对。
常见的应对是加流程：更严格的变更审批、更长的测试周期、更多的文档模板。但这治标不治本。流程无法替代观测，它只能让团队在信息不足时更有仪式感地犯错。
把实验重新跑起来
真正有效的做法听起来过于朴素：持续比对"我们认为系统在做什么"和"它实际在做什么"。
Netflix 的混沌工程（Chaos Engineering，一种通过主动注入故障来验证系统韧性的方法）之所以有价值，不是因为它制造故障，而是它强制暴露假设与现实的偏差。没有这种外部刺激，漂移会被误认为是稳定。
一位 SRE 负责人曾向我展示他的团队仪表盘：不是监控指标的数量，而是"未验证假设"清单——每个架构决策附带一个到期日，到期必须重新测量。三年后，他们的平均故障恢复时间（MTTR）下降了67%。
技术债的真正成本不是修复工作量，而是你不知道它在哪里。当所有生产系统都是实验，唯一的问题是：你的对照组还在运行吗？
热门跟贴