分布式系统如何做根因分析？

简化版

根因分析先确认用户影响、时间线和故障域，再基于变更、依赖、Metrics、Trace、Logs 和业务对账提出并证伪假设。根因不是“最后一个报错组件”，而是能解释症状并通过修复或实验验证的因果机制。

详细版

事故中先止血并保留现场，锁定开始/恢复时间、受影响租户和 SLO；对照发布标记、版本差异和依赖拓扑。由指标找异常层级，用 Trace 分解关键路径，用日志和状态记录验证具体机制，同时检查观测缺口。

复盘区分触发因素、根本条件和放大因素，给出带 owner、期限和验证方式的改进。避免把“人为错误”当终点；要追问为何系统允许单次操作扩大、为何检测与回滚未及时生效。

完整版教学

一、先定义影响而非猜原因

记录哪些用户、功能、区域在何时失败，错误率和最长延迟是多少。没有影响边界，排障会被无关 CPU 尖峰和历史错误带偏。

心法：证据先于故事；每个根因假设都要能预测并解释观测现象。

二、止血与取证顺序

限流、回滚或隔离先降低损失，同时保存版本、配置、线程栈、队列水位和关键日志。随意重启可能恢复服务，却删除了证明死锁或泄漏的现场。

止血动作也进入时间线，便于判断恢复是否由该动作造成。

三、时间线与变更

10:02 config changed
10:05 new traffic reached 50%
10:07 DB pool saturation
10:08 checkout SLO alert
10:12 rollback
10:15 recovered

时间先后是必要但非充分条件；还需比较未变更实例和其他区域作为对照。

四、由广到窄下钻

证据	回答问题	限制
业务/SLI	影响多大	不给机制
Metrics	哪层异常	聚合丢细节
Trace	哪段耗时/失败	可能采样
Logs	具体上下文	可能噪声/缺失
数据对账	最终事实	通常较慢

多种证据交叉比单条异常日志可靠。

五、构造可证伪假设

假设“新连接池配置过小”应预测新版本连接等待升高、旧版本正常、回滚后下降。若所有版本同时异常，该假设不足，需要检查共享数据库容量。

一次只改变一个关键变量，优先在影子或受控环境复现，避免生产试错扩大事故。

六、根因层次

触发因素可能是配置值 20，根本条件是无容量校验，放大因素是每层重试，检测缺口是只告警 CPU。复盘同时修正这些层次，才能降低复发概率和影响半径。

改进项写成“为连接池配置增加基于压测下限的 CI 校验”，而不是“以后更小心”。

七、常见误区与追问

• 误区：第一条错误日志就是根因。 它可能只是下游症状。
• 误区：回滚后恢复就完成分析。 还需解释机制和为何未被提前阻止。
• 误区：时间相关等于因果。 需要对照、预测和验证。
• 误区：根因必须只有一个。 分布式事故常有触发、条件和放大链。
• 追问：观测数据矛盾怎么办？ 检查采样、时钟、口径和采集管道健康。
• 追问：何时允许重启？ 用户风险要求止血时，但先尽可能保存关键现场。
• 追问：如何验收改进？ 自动测试、故障演练和指标证明防线生效。

八、加强记忆

根因分析按“定影响—先止血—留证据—建时间线—提可证伪假设—多信号验证—分层整改”推进。不要止步于报错组件或个人操作；真正闭环要解释触发、系统性条件、放大与检测缺口，并用演练验证改进。