大模型如何参与生产故障分析？确定性证据与 AI 协同实践

大模型如何参与生产故障分析？确定性证据与 AI 协同实践

一、项目背景：金融核心系统对运维可观测性提出更高要求

随着金融机构数字化建设不断深入，银行 IT 基础设施逐渐形成由核心业务系统、分布式应用、数据库、中间件及网络基础设施共同构成的复杂架构。

江苏省某农商银行管理着 20 余套核心业务系统，涉及柜面、信贷、支付清算、核心会计、ESB 服务总线、银联、二代支付及超级网银等关键业务链路。

这些系统需要保持 7×24 小时稳定运行。对于支付清算等关键业务而言，故障发现是否及时、影响范围能否准确判断、恢复操作是否可控，都会直接影响业务连续性。

在原有运维体系下，该行已经部署多套监控工具，但随着监控对象和业务链路不断增加，传统以单点指标监测为主的方式逐渐暴露出一些问题：

• 多套监控系统独立运行，告警数据缺乏统一标准，运维人员需要跨平台查询。
• 业务系统与基础设施之间缺少完整的关联关系，故障发生后难以快速识别影响范围。
• 支付交易链路缺乏端到端监测能力，单个指标异常难以直接定位具体故障节点。
• 告警分析依赖人工经验，重复告警和关联告警增加了故障排查负担。

因此，该项目将建设重点放在多源监控数据融合、业务链路可观测、智能告警分析及事件处置闭环等方面。

二、建设思路：构建从数据采集到事件处置的可观测体系

项目采用分层建设思路，将原有监控数据、业务交易数据、资源配置数据及日志信息进行关联，形成统一的运维分析基础。

整体建设包含五个环节：

1. 数据接入： 接入 BPC 业务交易数据、Zabbix 资源监控数据及其他监控平台告警信息。
2. 统一建模： 通过 CMDB 建立业务系统、应用服务、服务实例和基础设施之间的关联关系。
3. 监控分析： 对异构告警进行标准化、归并、去重及关联分析。
4. 智能研判： 基于交易链路和监控数据提取故障证据，再通过 AI 生成异常说明与排查建议。
5. 事件处置： 将关联告警组织为 Incident，由运维人员确认分析结论后执行受控操作，并完成恢复验证和复盘。

在具体实施中，项目使用嘉为蓝鲸运维平台承载统一配置管理、监控告警、运营可视化及自动化处置等能力。

三、关键技术实践

1. 多源告警标准化：解决不同监控系统之间的数据孤岛

不同监控系统在告警字段、事件标识和数据结构方面存在差异，直接进行关联分析容易出现重复统计和信息丢失。

项目首先建立统一告警字段模型，将不同来源的告警映射为标准化数据结构，同时保留原始 Payload，便于后续追溯。

在数据处理方面，主要采用以下方法：

• 字段标准化： 对不同监控来源的告警字段进行统一映射。
• 幂等去重： 根据数据来源和原始事件 ID 识别重复事件。
• 告警指纹： 根据告警特征识别语义相近的问题模式。
• 历史关联： 结合告警历史、共现关系和资源信息开展分析。

通过统一数据模型，将原本分散在不同监控系统中的告警信息纳入统一分析流程，为后续关联分析提供基础。

2. CMDB 统一建模：建立业务与基础设施的关联关系

在复杂的金融 IT 环境中，单独掌握主机、应用或数据库的运行状态，并不足以判断故障对业务的实际影响。

项目以 CMDB 为基础，建立应用、服务、服务实例、主机之间的分层资源模型，并维护业务系统的部署架构及上下游依赖关系。

当某个资源或服务发生异常时，可以结合配置关系查询关联业务对象，辅助判断故障影响范围。

这一过程将分散的资源信息转化为具有关联关系的配置数据，也为告警关联、变更风险分析及故障定位提供了统一的数据依据。

3. 黑盒监控与 AI 协同：让告警分析建立在可验证的证据上

对于支付清算等关键业务链路，仅依赖服务器 CPU、内存、网络流量等基础指标，难以完整反映业务交易是否正常。

因此，项目将业务交易数据纳入监控分析范围，围绕交易码、请求方、服务方、返回码、分钟级趋势，以及 ESB 节点 IP、端口等信息开展关联查证。

在智能分析流程中，采用确定性分析与生成式 AI 协同的方式：

第一步：程序化查证。

根据告警类型和预设规则，自动查询相关交易记录、上下游节点、服务端点及指标变化，完成数据计算和证据提取。

第二步：证据过滤。

对提取的信息进行有效性判断，过滤无关数据和缺少支撑的异常推断，避免将未经验证的信息直接作为故障结论。

第三步：AI 辅助研判。

将已经确认的事实交给大模型，生成结构化异常说明，包括异常现象、可能影响范围、关联证据和后续核查建议。

第四步：人工确认。

运维人员结合实际情况审核分析结果，并决定是否执行后续操作。

这种方式将 AI 的作用定位在信息理解、归纳和辅助分析，而不是直接替代监控规则和专业判断。

4. Incident 事件管理：从单条告警处理转向关联事件治理

当多个监控系统同时产生告警时，运维人员往往需要逐条判断告警之间是否存在关联。

项目引入 Incident 事件管理机制，将具有相关性的告警组织为统一事件。

事件处理过程包括：

1. 接收来自不同监控系统的告警。
2. 根据时间、资源对象、业务关系及告警特征进行关联。
3. 将相关告警归并为统一事件。
4. 自动提取事件证据，生成结构化分析报告。
5. 运维人员确认研判结果。
6. 根据审批及执行规则联动自动化操作。
7. 完成业务恢复验证、事件归档和复盘。

通过这一机制，运维人员可以从逐条查看告警转向围绕事件进行分析和处置，同时保留完整的处理记录。

四、典型场景验证

场景一：IC 卡协议支付超时定位

在 IC 卡协议支付场景中，当交易出现超时异常时，传统排查方式需要运维人员跨多个系统查询交易状态、服务调用关系及 ESB 节点信息。

通过业务交易数据与基础设施监控数据关联，系统能够根据异常交易码反查上下游服务节点，并进一步定位 ESB 端点 IP、端口等信息。

在该场景的实践中，故障定位时间由人工跨 4 个系统排查约 30 分钟，缩短至系统自动分析约 2 分钟，完整保留了相关证据链。

场景二：银联前置往账成功率异常

针对银联前置往账成功率异常，项目以交易码作为主要分析对象，并结合发卡行、受理行等辅助维度，对不同交易方向进行区分。

通过明确当前交易方向与配对交易方向，减少因分析对象混淆造成的判断偏差，使值班人员能够按照统一的数据口径开展异常分析。

场景三：多系统告警关联分析

当多个系统同时出现异常时，传统方式通常需要人工逐条核对告警信息。

通过告警指纹识别、资源关系关联及事件归并，数十条相关告警可以被组织为一个 Incident 事件。

运维人员由逐条查看告警转向查看结构化事件报告，降低了重复信息对故障判断的干扰。

五、实施效果与建设价值

经过持续建设，该项目在故障定位、异常发现及运维协同方面取得了阶段性成效。

在此基础上，项目还形成了以下能力：

• 关键业务链路可观测： 将交易数据与基础设施监控信息关联，提升支付业务异常的识别和定位能力。
• 运维分析标准化： 通过统一告警模型、资源拓扑和事件管理，减少对个人经验的依赖。
• 故障处置可追溯： 将异常分析、人工确认、自动化执行及恢复验证纳入统一事件记录。
• 信创适配分析： 结合实际业务运行数据，辅助开展分布式数据库、国产处理器等基础设施的性能评估。

六、实践总结：金融行业可观测性建设的三个关键点

从该项目的建设过程来看，金融行业开展智能运维与可观测性建设，需要重点关注三个方面。

第一，统一数据模型比单纯增加监控数量更重要。

监控系统数量增加并不必然带来更好的故障定位能力。只有将告警、资源、业务和交易数据建立关联，才能从单点异常识别进一步走向业务影响分析。

第二，AI 分析需要建立在确定性证据之上。

在金融生产环境中，异常分析需要具备可解释性和可追溯性。通过程序完成数据查证与规则计算，再由 AI 进行信息归纳，可以降低无依据推断带来的风险。

第三，自动化处置必须保留人工确认和审计机制。

自动化不等于无条件执行。对于涉及生产业务的操作，应明确执行权限、审批条件、操作记录和恢复验证机制，确保自动化处置过程可控。

该农商银行的实践表明，金融行业智能运维建设的重点，正在从单一监控能力向业务链路可观测、告警关联分析和事件闭环管理转变。

项目实践由嘉为蓝鲸参与建设，并入选第五届“鼎新杯”数字化转型应用征集相关成果（具体奖项及入选名称以官方公布信息为准）。