定义
RCA（Root Cause Analysis）即根因分析，追溯故障的根本原因而非表象。设备管理平台结合 Fault Diagnosis、Audit Log、Fault Knowledge Base 进行 RCA，辅助故障修复与 Preventive Maintenance 预防。
分析方法与流程
RCA 常用方法包括 5-Why、鱼骨图、故障树分析（FTA）等。流程通常为：收集故障现象、时间线、Log Collection 日志、Audit Log 操作记录及环境因素；识别直接原因与贡献因素；追问「为什么」直至根因；制定纠正与预防措施。设备管理平台可整合 Event Stream 事件流、遥测历史、OTA 记录等数据，辅助构建故障时间线；Fault Knowledge Base 可沉淀历史 RCA 案例，支持模式匹配与经验复用。
与 DMP 的集成
平台在 Remote Diagnosis 远程诊断、Work Order 工单闭环中嵌入 RCA 能力。诊断报告可包含根因分析结论与建议措施；工单关闭时可要求填写 RCA 摘要，沉淀至知识库。RCA 结果可驱动 Preventive Maintenance 计划调整、产品改进、运维流程优化，形成「故障—分析—改进」的持续改进闭环。
应用场景
适用于重大故障复盘、批量设备异常分析、重复性故障的根因根治。RCA 是运维成熟度的重要标志，有助于从被动救火转向主动预防，降低故障复发率与 MTTR。
直接原因和根本原因在记录里怎么分开
根因分析要留下两层结论，而不是一句“设备异常”。直接原因回答故障时刻设备或链路处于什么状态，例如进程没有起来、证书过期、电源跌落。根本原因回答这个状态为什么会在这批设备上出现，例如升级包里少了启动脚本、证书续期任务被停用、同一供电回路被新增负载拉低。只写直接原因，修复会停在重启和换件；只写根本原因而没有现场证据，又无法证明判断针对的是这一次故障。
记录里应能指回原始材料：哪一段日志、哪一段遥测、哪一条操作审计、哪一个版本号。结论句和证据分开存放，后来的人才能复核，而不是只能相信当时的措辞。同一故障若有多个贡献因素，要标明哪个是触发因素、哪些是使故障放大的条件。例如弱网是长期背景，真正触发失败的是超时被配成零。把背景写成根因，预防措施会打在无法改变的链路上，该改的参数却留着。
时间线齐备之后才适合下结论
下结论的使用条件是时间线已经能对齐。至少要有故障被发现的时刻、设备最后一次正常上报的时刻、期间的升级或配置变更、以及现场或远程处置的时刻。时钟不一致时，应先把设备时间、平台时间和操作者时间换算到同一基准，再谈论先后。缺了变更记录，分析只能停留在“现象与某指标同时出现”，这还不是原因。
批量故障更要先分组再分析。同一小时里离线的设备，可能分属不同固件、不同站点、不同运营商。未分组就做一条总原因，会把只影响其中一个批次的缺陷推广成平台级结论。分组之后，每组仍要有自己的证据，不能用最大那一组的结论覆盖小分组。分析过程中拉取的历史点应来自时序库里原始采样或标明口径的聚合，避免用已经降采样的均值解释短时尖峰。
把关联现象写成唯一根因
同时出现不等于引起。告警风暴期间，连接数、消息堆积、磁盘占用往往会一起升高，随便挑一个写成根因，后续预防就会只扩容那一项。更稳妥的写法是列出候选，逐个说明若去掉它，故障是否仍会发生。说不清的候选应保留为未证实，而不是为了关闭工单选一个看起来最完整的故事。
另一种偏差是在证据还没到齐时先改配置，再把“改完就好了”当成原因。恢复可能来自重试、来自临时重启，也可能来自恰好结束的外部故障。处置动作本身要记入时间线，并注明是试验还是修复。知识库只应收录能复现判断步骤的案例：现象、证据、排除了什么、最后改了什么。没有排除步骤的案例会被下次相似告警直接套用，把一次偶然恢复固化成错误规程。
复盘会议结束时，预防措施要写成可检查的改动：改哪一个参数、哪一版模型、哪一条操作规程，以及由谁在什么日期前核对改动已经生效。只写“加强培训”或“提高意识”，下一次相同故障无法判断措施是否落地。措施若涉及一批设备，列出标识范围，避免只改了试验台。知识库条目与这次工单互相引用，但条目里不写入仅对单台偶然成立、又没有证据的猜测，以免下次被当成标准原因。若措施依赖外部改固件，写明对方版本号、预计交付时间和未交付之前用什么临时监测顶上。没有临时监测的空窗，应在工单上保持打开，不能因为复盘会已经开过就视为预防完成。