从命令行到自动诊断：构建 AI 驱动的故障树与交互式排障机器人
引言
在网络行业，故障是永恒的主题。但令人困惑的是：即便企业投入巨额预算堆设备、做双活、上可视化系统，只要遇到真正棘手的事故，大家最后还是回到命令行，靠工程师的直觉、经验和试探式验证步骤，一步步往前摸。
而现在的问题是：**网络的复杂度远远超过了人脑能同时处理的规模。**多协议叠加、遥测爆炸式增长、变化越来越频繁……传统的'工程师 + CLI'的模式正在变成瓶颈。
本文旨在把'工程师思路的自动化'写成一套真正可以落地的体系：故障树、证据链、主动探测、对话式诊断机器人，以及自动修复流水线。
它不是让 AI 取代工程师，而是把工程师最有价值的地方提炼出来，做成可复用、可审计、可回放、可持续改进的系统。文章的结构基于在企业网络、数据中心和运营商环境里做过多个'自动诊断 / 自动修复'项目的经验整理，目标是提供一个可运行的 MVP 方案。
1、问题定义与目标
1.1 问题为什么难？
企业网络里的故障，不是单点事件，而是 多源异构信号 的叠加：
- Syslog 和 Trap 每秒几十条；
- Telemetry 每秒上万指标；
- Flow 告诉你'流量被重路由'；
- 配置变更影响任何协议；
- 应用监控又从另一个维度给你提示；
- 人工工单再叠加噪声。
真正的 root cause 就像是被压在这一堆信号下面的薄薄一层'事实'。要从这里面找关键线索，需要经验，也需要时间。
而网络团队最常见的两个痛点就是：
1）信号多，但线索稀疏 —— 需要人在脑中拼模型
2）排障路径不可复现 —— 工程师 A 和工程师 B 的排查完全不同
一旦问题变大，就会出现：
- 排查漏掉关键步骤；
- 不同工程师得到不同结论；
- 验证方法不一致；
- 无法回放、无法复盘。
这不是'人不行'，而是方法不行。
1.2 工程化目标
我们要构建的，是一条完整的 诊断闭环：
- 从海量信号里抽取初步候选根因；
- 自动生成'最小验证步骤'，减少盲目试错；
- 用对话式机器人与工程师协作；
- 自动执行安全、可回滚的命令；
- 最终把整个过程变成可重放、可持续改进的知识体系。
目标是：
- 降低 MTTR
- 降低误判率
- 提高排障路径可复现性
- 可逐步增强自动化，不跳步骤
这就是本文要写的内容。
2、总体架构
如果你做过网络可视化项目，你会知道：
'采集、存储、展示'并不能解决故障定位问题。
真正的差距在于：'推理能力'。
因此本文的架构不是 NMS 的扩展，而是全新的诊断系统架构。
2.1 六层结构（自上而下）
我把整个系统拆成六层，每层职责明确、边界清晰。
1）接入层（数据采集）
从各种数据源接入：
- gNMI / Telemetry
- Syslog / Trap
- Flow / NetFlow / sFlow / IPFIX
- 配置库 & 变更日志
- ITSM 工单
- 应用监控数据
- 仿真环境的状态快照（可用于验证）
这里的重点不是'采多少'，而是做 可控的采样策略与时间同步。
2）规范化层（数据归一化）
