AIOps故障复盘案例：智能告警收敛系统“静默”故障剖析

在AIOps（智能运维）逐渐成为企业IT运维核心大脑的今天，我们往往享受着告警降噪、根因定位带来的高效，却容易忽视“大脑”本身发生故障时的破坏力。当监控系统本身出现盲区，其带来的后果往往比常规业务故障更为严重。本文将复盘一起典型的AIOps告警收敛系统“静默”故障，探讨其排查过程、根因及改进之道。

故障背景

某日晚高峰期间，核心交易系统出现明显延迟，大量用户反馈支付失败。然而，运维团队并未收到任何P1/P2级别的告警，直到客服侧反馈激增，运维人员才通过手动查看Grafana大盘发现异常。

此时，底层Zabbix/Prometheus早已产生数百条原始告警（涵盖CPU飙高、接口RT超时、数据库慢查询等），但这些告警在流入AIOps智能告警收敛平台后，被“神秘”地降级或合并，导致最终推送到值班人员的仅是一条无关痛痒的P4级别通知。AIOps系统不仅未能起到“排雷”作用，反而成了“掩雷”的帮凶。

排查过程

故障发生后，我们立即启动紧急响应，排查重点从业务侧转向AIOps平台本身。

  1. 原始告警核对：首先对比底层监控平台与AIOps平台的日志。确认底层在5分钟内输出了约350条高优先级原始告警，但AIOps出口仅生成1条低级别告警。问题锁定在AIOps的收敛与降噪引擎中。
  2. 追踪收敛链路：逐层拆解AIOps的处理流水线（接收 -> 实体提取 -> 聚类 -> 关联 -> 降噪输出）。发现所有核心交易告警在“聚类”环节被归入了一个巨大的告警簇。
  3. 定位异常簇：检查该告警簇的元数据，发现其聚类标签为一个底层公共组件“DB-Proxy”。按照算法逻辑，当同一实体短时间产生大量告警时，系统会将其合并，并取该簇内“历史平均优先级”作为推送级别。
  4. 发现优先级倒挂：由于DB-Proxy平时产生的多为连接数波动的P4告警，此次虽然包含了大量P1的慢查询和连接池耗尽告警，但聚类算法被历史权重主导，将整个簇的优先级判定为P4，触发了“静默合并”策略。

根因分析

通过深入剖析，我们确认此次故障并非单一代码Bug，而是算法逻辑与运维场景的错配，具体根因如下：

  1. 特征漂移与实体提取缺陷：近期研发推行了微服务拆分，新服务命名规范未及时同步给AIOps平台。NLP实体提取模型未能识别出新的服务名，将其统一回退到了上游公共实体“DB-Proxy”。这导致本不相干的多个服务告警，被错误地按公共实体强行聚类。
  2. 聚类算法的“木桶效应”：当前聚类算法在计算告警簇优先级时，采用了历史加权平均策略。在“大簇”中，少量P1告警被海量的历史P4告警均值拉低，导致“劣币驱逐良币”，核心告警被淹没。
  3. 缺乏熔断与旁路机制：AIOps平台在检测到异常大的告警簇（如单簇超过100条告警）时，没有触发“算法降级”或“旁路透传”机制，依然盲目执行收敛，导致关键告警被静默。

改进措施

针对上述根因，我们从算法逻辑、数据闭环和系统韧性三个维度进行了彻底整改：

  1. 算法层：引入“一票否决”与动态权重

废弃单一的历史加权平均策略。在告警簇优先级计算中引入“一票否决”机制：只要告警簇内存在P1/P2级别的高优原始告警，该簇的最高优先级必须继承此P1/P2，且不被低优告警稀释。同时，针对聚类规模设置惩罚系数，簇越大，合并降级的阈值越难触发。

  1. 数据层：构建CMDB与实体提取的闭环反馈

解决特征漂移问题。将AIOps的实体提取模块与企业CMDB/服务树进行强一致性绑定。当出现未知实体时，不再硬编码回退到公共节点，而是标记为“Unkown”并单独成簇，同时触发自动化工单通知研发补充服务拓扑元数据。

  1. 系统层：增加AIOps自身的可观测性与熔断机制

AIOps系统不能成为黑盒。我们为AIOps平台自身增加了监控指标，如：聚类簇大小分布、高优告警降级率、算法处理延迟等。当出现“超级簇”或高优告警被降级时，触发AIOps内部熔断：停止收敛，将原始告警直接透传（Bypass）至通知渠道，宁可容忍一定的告警风暴，也绝不丢失关键告警。

总结

AIOps的本质是辅助运维，而非替代运维。在追求“降噪比”和“收敛率”的指标时，我们必须坚守“宁可误报，不可漏报”的底线原则。此次复盘深刻揭示了：再智能的算法，一旦脱离了真实的运维语境与元数据闭环，都可能成为制造黑天鹅的温床。只有为AIOps系统本身装上“熔断器”与“安全带”，才能真正让智能运维行稳致远。