定义
Fault Diagnosis（故障诊断）基于设备 Telemetry、Event Stream、Log Collection 等数据，结合 Fault Knowledge Base 进行故障定位与 RCA 根因分析。支持规则匹配与 AI 辅助诊断，是 Remote Diagnosis 的核心能力。
诊断方法与流程
故障诊断可采用规则匹配（基于阈值、模式、告警组合）、Fault Knowledge Base 案例检索、机器学习异常检测等方法。流程通常为：从 Event Stream 获取告警、从 Log Collection 获取日志、从 Time Series DB 获取遥测历史；进行特征提取与模式匹配；输出可能原因与建议措施。与 RCA 根因分析配合，可追溯故障根本原因，支撑纠正与预防。
与 DMP 的集成
设备管理平台在 Remote Diagnosis 远程诊断、Work Order 工单处理中嵌入故障诊断能力。告警可自动触发诊断流程，输出诊断报告并推荐 Fault Knowledge Base 案例；诊断结果可关联工单、驱动 Remote Maintenance 远程维护操作。平台持续积累诊断案例，沉淀至知识库，形成「诊断—沉淀—复用」的闭环，持续降低 MTTR。
应用场景
适用于设备异常后的快速定位、批量故障的根因分析、重复性故障的智能推荐。故障诊断是运维能力成熟度的关键指标，可显著提升运维效率与客户满意度。
定位线索不等于告警标题
故障诊断要产出的是对现象的解释，而不是把告警标题换一种说法再输出一遍。它把一段时间内的测点形态、事件先后和日志片段放在一起，对照该型号已知的失效方式，给出可能原因、还缺哪一类证据、以及建议先核对哪一步。告警“温度高”只说明某个量越过了阈值；诊断则要区分传感器漂移、散热受阻、负载异常，还是阈值本身设错。同一告警码在不同固件、不同安装方式下可以对应不同原因，所以结论必须带上型号和版本范围。输出应保留不确定的部分，列出已经被排除的解释，而不是只给一个斩钉截铁的名称。健康分下降可以作为排队依据，但不能代替对原始测点的核对，分数是综合结果，判断仍要回到曲线和日志。
自动诊断能跑起来的前提
诊断流程值得自动启动，至少要有稳定的设备身份、可对齐的时间范围，以及和该型号对应的规则或案例。缺测点时不能靠事件标题脑补曲线；缺日志时不能把“通信超时”直接写成主板损坏。一批设备同时告警时，应先看是不是网关、供电或上行链路这些共同原因，再逐台做设备内部的判断。规则要用告警码、固件版本和关键测点的组合来匹配，而不是只匹配中文描述。涉及停电、拆机或安全动作的建议，以及知识库里没有相近案例的新型号，仍应留给人工确认。诊断和建议要分开：诊断可以列出下一步，但改写设备影子或下发控制命令仍要按权限单独执行。
把时间接近当成因果
容易出错的是把时间上靠近的症状写成因果关系。通信中断之后温度读数消失，并不等于温度传感器已经损坏；升级失败和存储告警同时出现，可能都是供电不足的结果。规则若写成“命中即确定”，又没有排除条件和版本范围，旧固件的特例会污染新型号。只看最近一条事件、不看恢复事件，会把已经复归的抖动当成持续故障。日志时区和测点时区不一致时，人会把无关的报错行配到故障时刻上。诊断结论写回知识库时若不标注适用固件，下一次会把过时步骤推荐给已经改过协议的设备。用第一台的结论覆盖同批其余设备，也会漏掉其中原因并不相同的个体。结论上应写明所用数据的起止时间，后来的人若换一段曲线复核，才能知道当时看的是不是同一窗口。