Bug一出现，最危险的是立刻找到原因

系统一报错，群里很快会出现一句话：“应该是缓存。”

这句话未必错。危险在于，它太像答案了。只要大家接受它，后面的搜索就会围着缓存展开：清缓存、重启、改过期时间。问题暂时消失，结论也就顺手坐实。

可“改完以后不报错”只能说明一次干预和一次结果同时发生，不能单独证明它就是根因。

最近读到一篇谈系统思维的文章，里面有个我很喜欢的比喻：问题像哑铃，太快放下，就没有训练发生。原文把“不急着结束问题”说得很玄，我更愿意把它翻成一个工程动作：先保留多个可被推翻的假设。

Google SRE 的事故复盘指南强调无责复盘、足够详细的根因分析，以及能真正落实的行动项。它关注的不是抢先找到一个可以责怪的人或组件，而是让证据支持后续改变。

还是拿缓存举例。至少可以同时列出三种解释：缓存里有旧值；缓存只是放大了数据库慢查询；重启碰巧让并发下降。三种解释对应的证据不一样，也有不同的推翻条件。

如果清缓存后旧值消失，但数据库延迟没有变化，第一种解释得到支持。如果只要并发恢复，错误就再次出现，缓存更可能只是表面现象。如果同样请求绕过缓存仍然超时，搜索方向就该转向下游。

把这些条件写出来，会比“大家都觉得像缓存”慢几分钟，却能少掉下一次一模一样的救火。

我现在更愿意把“原因”分成三层：眼前触发了什么，哪些系统条件让它有机会发生，哪一项改变能阻止它再次发生。三层可能指向不同东西，不必硬塞进一句口号。

真正的根因不是最早出现的解释，而是经过反证以后仍然站着、还能指向有效改动的那一个。

资料：

来源