4. 基于规则的故障诊断引擎

当网络规模从几十台设备扩展到上千台时，仅靠人工经验判断故障已经不可行。基于规则的故障诊断引擎把运维专家的判断逻辑固化成可执行规则，让系统在秒级内完成"采集数据—匹配规则—输出结论"的闭环。本章围绕规则引擎原理、故障规则库设计、阈值与状态机、规则匹配与冲突处理，以及典型规则的实现展开。

规则引擎的工作原理

规则引擎的核心是"条件—动作"（Condition-Action）模型。一条规则由三部分组成：事实（Fact）是引擎当前掌握的数据，例如某接口的收发光功率、CRC 错误计数、CPU 利用率；条件（LHS，Left-Hand Side）是对事实的判断表达式，如 rx_power < -20dBm；动作（RHS，Right-Hand Side）是条件成立后触发的结论或操作，如"判定为光路衰减异常，生成告警并建议检查尾纤"。

引擎运行时采用 Rete 算法或简单的顺序匹配。Rete 算法把规则条件编译成网络节点，当新事实进入工作内存时只沿受影响路径传播，避免每次全量重算，适合规则数量多、事实更新频繁的场景。对于中小规模网络，顺序匹配配合索引已足够，实现更简单、更易调试。

故障规则库设计

规则库不是规则的简单堆砌，而应按"故障域—对象类型—严重等级"分层组织。常见做法是给每条规则分配唯一 ID，并记录适用设备型号、采集指标、阈值、优先级、生效时间窗和处置建议。规则 ID 建议采用 域-对象-序号 格式，例如 LINK-IF-001 表示链路域接口类第一条规则，便于日志追溯和版本管理。

规则库需要版本化。每次调整阈值或新增规则都应记录变更人、变更原因和生效范围，避免"改了阈值没人知道"导致误判。规则之间还应避免重复覆盖，例如"接口 down"和"接口无光"可能同时命中，需要通过优先级或互斥条件明确谁先输出。

阈值与状态机

阈值分静态阈值和动态阈值。静态阈值如"CPU 利用率持续 5 分钟超过 85% 判定过载"，实现简单但容易在业务高峰期误报。动态阈值基于历史基线，例如取过去 7 天同一时段的 P95 值上浮 20% 作为门限，能适应流量周期性变化。

状态机用于处理"故障不是瞬时事件"的场景。以接口为例，可定义 UP、FLAPPING、DOWN 三个状态。当接口在 60 秒内 up/down 切换超过 3 次，从 UP 迁移到 FLAPPING，触发"链路震荡"规则；若持续 down 超过 120 秒，迁移到 DOWN，触发"链路中断"规则。状态迁移需要防抖，避免单次采样抖动造成误判。

规则示例：LINK-IF-003 链路震荡
条件：
  if_state == "FLAPPING"
  AND flap_count_60s >= 3
  AND hold_time >= 60s
动作：
  severity = "major"
  root_cause = "物理链路不稳定"
  suggestion = "检查光模块、尾纤及对端端口"

规则匹配与冲突处理

当多条规则同时命中时，需要冲突消解策略。常用方法有三种：优先级——数值越小越先执行，根因类规则优先于现象类规则；特异性——条件更具体的规则优先，例如"某型号设备光模块温度过高"优先于"设备温度过高"；抑制关系——高等级规则命中后抑制低等级衍生告警，避免告警风暴。

实际实现中通常组合使用：先按优先级排序，同优先级再按特异性，最后检查抑制表。诊断结论应携带置信度，例如根因规则置信度 0.9，衍生规则 0.5，便于上层编排决定是否自动处置。

典型规则案例实现

以"核心交换机 CPU 过载导致 BGP 邻居震荡"为例。规则库中定义两条规则：DEV-CPU-001 检测 CPU 持续过载，PROT-BGP-002 检测 BGP 邻居震荡。当两者在 5 分钟窗口内同时命中时，冲突消解逻辑判定 DEV-CPU-001 为根因，PROT-BGP-002 为衍生现象，最终输出"CPU 过载引发 BGP 震荡"，并建议检查路由条目数量和 ACL 策略。

落地时建议先用离线数据回放验证规则，确认误报率可接受后再接入实时采集。每条规则都应配套测试用例，记录输入事实和期望结论，作为回归测试基线。这样规则库才能随网络演进而稳定演进。