RCA 的正确姿势
存储故障的根因分析常犯两个错误：一是急于找单点原因，忽略往往是多因素叠加；二是把结论停在「人为失误」，而人为失误恰恰是流程允许其发生的证据。有效的方法是把事件放到时间轴上，用跨设备证据还原因果顺序，对每个假设主动寻找能否证伪的证据，最后落到可执行的改进项上。
基本信息
| 分析步骤 | 固定时间轴 → 界定影响面 → 收集证据 → 提出假设 → 逐条证伪 → 给根因与改进项 → 验证改进 |
|---|---|
| 证据来源 | 阵列与控制器事件日志、交换机日志、主机内核与多路径日志、监控指标、变更记录 |
| 推理禁区 | 把相关当因果、把时间相邻当因果、只看单点原因、停在人为失误 |
| 输出物 | 时间轴、影响面、根因链、改进项与责任人、验证方式与完成时间 |
| 时效要求 | 尽快取证：设备日志缓冲区有限，重启或继续运行都会覆盖关键证据 |
| 边界说明 | 部分偶发事件无法定位唯一根因，此时应记录概率性判断与降险措施 |
典型使用场景
- 重大故障复盘，需要形成对外可交付的结论与改进计划时
- 偶发问题反复出现，需要系统性排查而不是每次重启了事时
- 变更后异常，需要判断是否与本次变更相关时
- 客户或业务方投诉，需要用时间轴与数据还原事实时
- 演练暴露的问题需要转化为流程改进时
把多源日志合成时间轴
把多源日志合成时间轴
# 各来源日志统一带时间戳抽取关键行，再排序合并
grep -h -E 'error|fail|reset|timeout' /var/log/array/event.log \
| sed 's/^/ARRAY /' > /tmp/tl.txt
journalctl -k --since '3 days ago' --no-pager \
| grep -E 'error|reset|path' | sed 's/^/KERNEL /' >> /tmp/tl.txt
cat /tmp/tl.txt | sort -k2,3 > /tmp/timeline.txt
# 时间轴建好后，把变更记录、告警记录的时间点标注上去
# 因果顺序只有在对齐时间后才站得住分析阶段与输出
| 阶段 | 动作 | 输出 |
|---|---|---|
| 界定 | 确认影响范围与起止时间 | 影响面说明与时间边界 |
| 取证 | 收集跨设备日志与指标 | 带时间戳的证据集合 |
| 假设 | 列出可能原因并标注验证方式 | 假设清单与证伪路径 |
| 结论 | 给出根因链与不确定性说明 | 根因结论与置信程度 |
| 改进 | 制定改进项与验证方式 | 改进清单、责任人与复核时间 |
「人为失误」是症状而不是根因。真正要回答的是：流程为什么允许这个操作发生、监控为什么没有提前发现、为什么没有拦住后果。改进项落在流程与监控上，才可能真正降低复发概率。
复盘在证据不足时急于给结论，往往会把改进方向带偏。宁可标注为「暂未定位，先采取降险措施」，也不要给出一个经不起追问的根因。