定义
Fault Knowledge Base（故障知识库）存储故障现象、可能原因、解决方案、关联设备型号等信息，辅助 Fault Diagnosis 与 RCA。支持规则匹配与持续积累，降低 MTTR。
知识结构与匹配
故障知识库条目通常包含故障现象描述、告警码/错误码、可能原因列表、解决步骤、关联设备型号/固件版本、历史案例链接等。匹配可基于关键词、告警码、设备型号等；支持模糊匹配与相似度排序。知识来源包括历史 RCA 报告、Work Order 工单闭环、专家录入、设备厂商手册等。持续积累与更新是知识库价值的关键，需建立录入、审核、版本管理流程。
与 DMP 的集成
设备管理平台在 Fault Diagnosis 故障诊断、Remote Diagnosis 远程诊断流程中调用知识库。告警或诊断任务触发时，平台根据设备信息、告警类型检索知识库，推荐匹配案例与解决方案；运维人员可一键创建工单、关联案例。诊断闭环时，可将新案例沉淀至知识库，实现知识自增长。与 Event Stream 事件流、Log Collection 日志采集协同，形成完整的诊断支撑体系。
应用场景
适用于运维人员快速查找解决方案、新员工培训、重复性故障的自动化处理。故障知识库是运维经验资产化的重要载体，可显著缩短 MTTR 并提升首次解决率。
一条记录要能被检索命中
故障知识库里的一条记录，是把能够复用的判断写成可检索的结构，而不是把工单备注原样堆进去。检索至少要能靠告警码、现象关键词、产品型号和固件范围找到它，打开后能读到可能原因、需要核对的证据、处置步骤，以及做完如何确认已经恢复。步骤应写操作对象和预期现象，例如核对某个属性是否停在旧值，而不是只写“检查一下配置”。同一现象在不同硬件版本上若走不同步骤，应分成条目或写成显式分支，不能靠阅读的人自行猜测。来源要留得住：来自哪次闭环、是否经过审核、从何时起不再推荐。诊断程序只是按这些字段检索和排序；遥测是否支持该判断，仍取决于条目里写明的证据，而不是标题写得像那么回事。
什么样的闭环值得升格
适合沉淀的，是原因已经核实、步骤能在另一台同类设备上重复、并且边界写得清楚的案例。一次性的接线错误、现场电源接反、无法再现的偶发重启，留在工单里即可，不必升格为推荐方案。入库前应有人核对告警码是否稳定、步骤是否还指向已经下线的菜单、以及是否涉及需要额外授权的风险动作。只在特定批次出现的缺陷，要写上批次或固件的上下限。条目被引用时应能回到原始上下文，但不要把现场账号、精确位置等隐私写进通用步骤。知识库并不替代物模型：模型说明设备能上报什么，知识库说明这些上报应当如何解释。没有审核状态的草稿，不应出现在自动推荐的结果里。
停用了仍出现在推荐里
条目最常见的失效，是内容已经不对却仍被匹配到。固件改了告警码或寄存器含义之后，旧步骤会让人去看已经不存在的点。用短标题做相似度排序时，彼此包含的说法会把推荐漂到相邻但不同的故障上。多人同时编辑又没有版本，后一次保存把适用型号覆盖掉，检索范围会突然放大到全部产品。把“先重启”写成万能的第一步，会破坏需要保留现场的故障。解决方案只写“已更换备件”，没有判断标准和确认方法，下一次根本无法执行。停用若只是在界面上隐藏、匹配索引却未更新，自动诊断仍会把它当成现行方案。应按固件版本抽查实际命中的条目，而不是只看库里的条目数量有没有增加。已经审核通过并被引用的版本应冻结，后续修改另起一版，避免正在执行的步骤在半途被改掉。