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