1. 课程导入与全景认知

网络故障自动诊断与运维编排，解决的是同一个现实矛盾的两面：网络规模与业务复杂度持续上升，而人工排障的速度、经验和一致性却难以同步扩展。传统模式下，一次"业务访问慢"的投诉，往往要经过多轮电话确认、逐台设备登录、手工比对配置、反复猜测与回滚，平均修复时间（MTTR）被大量消耗在信息收集和路径确认上，而不是真正的修复动作上。本课程要建立的，是一套把"发现问题—定位问题—验证判断—执行修复—确认恢复"这条链路尽可能自动化、可编排、可复用的工程方法。

两个核心概念：自动诊断与运维编排

网络故障自动诊断，指系统在无人或极少人工干预的情况下，自动采集网络状态数据，依据预设的规则、模型或推理逻辑，判断故障位置、故障类型与影响范围，并给出可解释的结论。它的关键不是"多采集数据"，而是"从数据到结论"的推理过程可复现、可追溯。典型输出不是一句"网络异常"，而是类似"核心交换机 SW-CORE-01 的 Gi1/0/24 上联口在 14:32:07 出现 CRC 错误激增，导致 VLAN 30 内 12 台终端丢包率超过 8%"这样的定位结论。

运维编排，指把多个原子操作（采集、判断、配置下发、验证、通知、回滚）按依赖关系组织成可执行的工作流，并保证执行顺序、失败处理与幂等性。编排的价值在于把"专家脑子里的排障步骤"变成"系统可执行的流程资产"。例如，一个"接入端口环路处置"编排可以定义为：检测到端口广播包速率超阈值 → 自动关闭该端口 → 通知责任人 → 等待确认 → 若 5 分钟内未确认则保持关闭并升级告警。

技术栈全景

把这条闭环拆开看，技术栈大致分为五层，每层都有明确的输入输出边界：

• 数据采集层：SNMP 轮询、Syslog/Trap 接收、gNMI/Telemetry 流式订阅、NetFlow/sFlow 流量采样、API 拉取设备状态。这一层决定诊断的"视野"。
• 数据治理层：时间序列库（如 Prometheus）、日志检索（如 Elasticsearch）、拓扑与配置库（CMDB/网管）。核心任务是把多源数据对齐到统一的时间轴与设备标识上。
• 诊断分析层：阈值与基线告警、关联分析、拓扑路径推理、根因定位算法、故障知识库匹配。这是"从数据到结论"的核心。
• 编排执行层：工作流引擎（如 Ansible、StackStorm、Argo Workflows 或自研调度器）、设备驱动/适配器、凭据与权限管理、幂等与回滚机制。
• 交互与治理层：告警收敛、工单联动、可视化大屏、审计日志、变更审批。它决定自动化能否被组织真正信任和采纳。

需要强调的是，这五层不是必须一次性建齐。多数团队的合理路径是：先把采集与告警做扎实，再逐步引入关联分析与编排，最后才追求全自动闭环。跳过数据质量直接做"AI 根因定位"，通常得到的是不可解释、不可运维的黑盒。

典型应用场景

这套能力并非只服务"大厂级"网络。以下四类场景在中小规模网络中同样高频出现，且收益明显：

以"接入端口环路"为例，一个可落地的判断逻辑是：采集层每 10 秒读取一次端口广播包速率；诊断层判断是否连续 3 个周期超过 5000 pps；若成立，则结合拓扑库确认该端口为接入端口（非上联口），排除误判；编排层执行端口关闭，并记录操作前后的端口状态与流量作为验证依据。整个过程的目标是把原本需要 10～20 分钟的人工定位压缩到 1 分钟以内，同时保留完整审计记录。

学习路径规划

本课程后续 29 章将沿着"认知—数据—诊断—编排—落地"的主线推进，建议按以下顺序建立能力：

1. 建立全景与术语共识（本章）：理解自动诊断与编排的边界、技术栈分层与典型场景。
2. 打牢数据基础：掌握 SNMP、Syslog、Telemetry、流采样等采集方式的适用条件与数据质量要求。
3. 掌握诊断方法：从阈值告警到关联分析、拓扑推理、根因定位，理解每种方法的适用边界与误报来源。
4. 构建编排能力：学习工作流定义、幂等设计、失败处理与回滚，把排障经验固化为可执行资产。
5. 完成落地闭环：通过案例与复盘，把诊断与编排接入真实运维流程，形成可度量、可迭代的体系。