一、项目背景

我们去年参与了某头部股份制银行的交易系统智能运维项目。这家银行的 core banking 加上周边信贷、支付、渠道系统，每天产生的日志量在峰值时段能到每秒十几万条，全量落盘后日均新增约 40TB。在此之前，他们的故障处理高度依赖值班工程师"人肉翻日志"：告警平台接了上百条规则，但规则之间是孤立的，一个交易超时往往同时触发十几条告警，谁也分不清哪条是根因、哪条是连带现象。

我们进场时拿到的痛点清单很典型：一是发现慢，很多故障是客户先投诉、监控才后知后觉；二是定位慢，一次跨系统的交易失败，平均要三到四个工程师拉群对日志，从发现到定位平均耗时约 90 分钟；三是误报多，静态阈值告警在业务高峰会被"正常抖动"反复触发，值班人员逐渐对告警麻木，真问题反而被淹没。银行对 MTTR（平均故障恢复时间）有硬性考核，业务方给我们定的目标很直接：把故障发现时延压到分钟级，把 MTTR 降一半，把误报率砍下来。

这个项目同样强调数据不出域，所有日志采集、模型训练和推理都跑在他们自建的私有云集群上，我们采用的 X 技术平台负责把日志流水线、向量检索和模型服务编排到一起。

二、落地场景

整个 AIOps 平台我们落地了四条联动的场景，从"看见异常"一路走到"自动处置"。

第一是日志采集归一。原来各系统日志格式五花八门——有的是单行文本，有的是 JSON，有的带自定义 traceId 规则。我们搭了一套采集管道，统一打上服务名、实例、时间戳、日志级别、traceId 这几类标准字段，再做模板提取（log template mining），把海量原始行压缩成有限的"模板簇"，这是后面所有检测的基础。

第二是异常检测。对归一后的指标和日志模板做时序异常检测，覆盖错误率突增、延迟升高、模板出现频次异常等模式。这里我们没有一上来就堆深度学习，而是先用统计方法（EWMA、季节性分解）兜底，再用我们采用的底座上跑的轻量时序模型做补充，降低误报。

第三是根因定位。当多个服务同时告警时，平台基于服务调用拓扑 + 日志模板共现关系，计算"哪个服务的异常最可能是源头"，给出一个带概率的根因排序，并附上关键证据日志。

第四是告警收敛与自愈联动。我们把同源、同窗口的告警聚合成一个"事件"，根因定位结果驱动运维编排系统执行预设的止损动作（如隔离故障实例、切流、重启下游），也就是自愈联动。

三、关键技术挑战与解决思路

挑战一：多源日志归一。 这是整个项目最脏最累的活。不同系统的时间戳时区不一致、字段命名混乱、有些日志根本没有 traceId。我们的做法是分两层：先写通用解析器把常见格式（JSON、带分隔符文本）自动识别，剩下的走正则模板库人工补；再强制在采集端注入统一上下文（统一时钟、统一 traceId 生成规则）。模板提取我们用了开源的 Drain 算法变体，把"User 12345 login from 10.0.0.1"这类归一成"<> login from <>"，模板数量从上亿行压到约 8 万个簇，检索和统计才变得可行。

挑战二：异常检测降误报。 静态阈值在银行这种"白天忙、凌晨闲"的业务里天然误报高。我们改用分时段基线：对每个指标按"工作日/周末 × 小时"建立季节性基线，再算动态阈值。同时引入"告警评分"机制——单个指标越界只记 1 分，只有多个关联指标同时异常、且日志模板错误率同步抬升时才升级为事件（记 5 分）。这套组合拳把误报率从日均约 300 条压到了约 40 条，值班人员的有效关注率明显提升。

挑战三：根因定位可解释。 黑箱式的根因结论运维是不敢信的。我们用"调用拓扑 + 概率传播"的思路：先从 CMDB 和链路追踪还原服务依赖图，把检测到的异常节点在图上进行随机游走式的影响传播打分，得分最高且处于传播上游的节点被判定为根因候选。每个候选都会附带"证据"——比如"该服务在 14:03 起错误率从 0.2% 升至 8%，且下游 3 个服务在其后 2 分钟内错误率同步上升"，让工程师一眼能验证。我们采用的 AI 网关在这里负责把不同检测模型的调用做编排和计量，避免重复推理浪费算力。

挑战四：告警收敛与自愈。 收敛的核心是"同因合并"：同一根因在 5 分钟窗口内触发的多条告警合并成一个事件卡片，附带根因和处置建议。自愈则采取保守策略——只对"高置信度且预设了安全剧本"的场景自动执行（如单实例 5xx 比例超阈值则自动隔离该实例），涉及数据变更或业务影响的动作一律只给建议、不自动执行，留给人确认。我们当时反复和银行安全团队拉通这条边界，避免"自动处置惹出更大事故"。

四、效果数据

项目在测试环境跑通后，我们在一个真实业务子系统上做了约两个月的灰度对照，下面是脱敏后的示意值：

这些数字来自该客户脱敏后的灰度统计，不同系统的复杂度不同，绝对值会有波动，但"发现更快、定位更准、误报更少"的趋势在多个子系统一致成立。

案例片段（已脱敏）： 下面是该项目一次真实故障的根因定位输出片段（服务名与 IP 已脱敏）：[EVENT-2024xxxx-07] 级别=P1 时间窗=14:02~14:09 收敛自原始告警 17 条 根因候选排序:  1) svc_payment_gw (置信 0.82)  证据: 14:03 起 5xx 率 0.2%→8.1%, 下游 svc_order/svc_account 在其后 2min 内错误率同步抬升  2) svc_order (置信 0.11)  证据: 受上游影响, 自身无独立异常  3) mq_cluster_02 (置信 0.07) 证据: 消费积压, 疑似被上游拖慢 建议处置: 隔离 svc_payment_gw 实例 pod-0a3f (已触发自愈剧本, 待人工确认)与之对应的异常检测动态阈值配置（我们采用的底座监控侧片段）：yaml rule:  metric: svc_payment_gw.error_rate  baseline: weekly_hourly        # 按 工作日/周末×小时 建基线  window: 5m  upper_bound: baseline * 3 + 0.5%   # 动态阈值=基线3倍+缓冲  promote_to_event_if:    - correlated_metric: downstream.error_rate      within: 2m    - log_template: "ERROR timeout *" count_surge: 5x

五、可复用经验总结

这个项目跑下来，团队沉淀了几条对各类 AIOps 落地都管用的经验。

第一，先归一、再去噪、再检测，顺序不能乱。我们踩过的最大的坑就是一开始想直接堆异常检测模型，结果被脏日志和格式混乱喂崩了。把采集归一、模板提取这些"苦活"做扎实，后面的模型才有干净的输入。这套思路放到任何日志、指标、链路数据治理场景都成立。

第二，根因一定要可解释。运维场景里，"告诉我哪里坏了"比"告诉我可能坏了"价值高十倍，而"告诉我的同时给我证据"才能让人敢用。我们坚持根因结论必须附带可验证的证据链，这既是技术选择，也是组织信任的建立过程。

第三，降误报比提召回更先影响 adoption。告警太多没人看，比漏报更致命——人会对噪音脱敏。我们用"分级评分 + 关联升级"把误报压下来后，值班团队才真正开始信任系统。这条在监控、安全告警等任何告警类系统里都适用。

第四，自愈必须划清边界。自动处置能省时间，也可能制造事故。我们的原则是"高置信 + 有安全剧本 + 可逆动作"才自动，其余一律只建议。配合 AI 网关的限流熔断与计量，把自动处置的调用也纳入统一管控，既安全又可审计。

结语：AIOps 的落地，本质上不是把 AI 塞进运维，而是把运维多年积累的专家经验，工程化地沉淀进"归一—检测—定位—处置"的闭环里。模型是放大器，真正决定效果的，还是前面那条干净、可解释、可信赖的数据与流程链路。