银行核心系统可观测方案：从告警风暴到精准定位

金融核心系统的三个痛点

银行核心系统是典型的老架构加高要求：交易链路长、系统多、可用性要求 99.99%。实际运维中三个问题最突出。

一是故障定位慢。一笔转账要经过渠道、核心、账务、清算十几个系统，出问题后靠人工翻日志逐段排查，MTTR 动辄以小时计。二是告警风暴。一次网络抖动可能引发上百条告警，值班人员被淹没，真正的根因告警反而被忽略。三是跨团队扯皮。A 系统说 B 系统超时，B 说 A 没传参数，没有统一的数据依据。

三合一数据模型

方案核心是让指标、链路、日志共用一套上下文。所有系统统一通过 OpenTelemetry 上报，trace_id 在交易入口生成并全链路透传；日志携带 trace_id；指标按服务和接口维度打标签。

这样，从一条业务告警（比如「核心转账成功率下降」）出发，可以下钻到具体接口、再下钻到慢的那几笔交易、最后定位到具体的日志报错，一条路径走到底，不用切多个工具。这条路径就是「几小时后给结论」和「直接给出报错 SQL 和具体交易」之间的差别，也给各团队同一份证据，结束扯皮。

告警(成功率下降) → 接口指标(转账) → 慢交易 trace → 关联日志(报错堆栈)

告警收敛与分级

告警要按影响面分级，而不是按数量。建议分四级：

• P0：核心交易成功率跌破阈值或资金类交易失败，立即通知 + 电话
• P1：非核心系统宕机或主链路延迟翻倍，5 分钟内响应
• P2：单节点异常或磁盘水位超 80%，30 分钟内处理
• P3：慢查询、缓存命中率下降等趋势性指标，工作日跟进

收敛规则上，把同一根因的告警合并成一条，比如同一时刻同一服务的多条告警自动归组，只通知一次。告警文案里直接带上可点击的 trace 链接，值班人员点开就能看到现场，不用再翻仪表盘。

把业务指标接进来

可观测性一旦接上业务指标，就不只是技术话题。挑几个真正要命的数字——转账成功率、TPS、平均端到端延迟、掉入人工处理的交易笔数——和基础技术指标放在同一块仪表盘上。这些数字通常是出问题时最先变化的，也能让管理层不用翻译 CPU 曲线就能做出判断。对涉及监管或客户承诺的指标设 SLO 阈值，让 P0/P1 告警从它们派生，而不是从原始的基础设施噪声里猜。

落地节奏建议

不要一上来全量接入。建议三步走：第一阶段先接入核心交易链路（渠道、核心、账务）做全链路追踪，解决「故障定位慢」；第二阶段补齐基础设施指标和告警收敛，解决「告警风暴」；第三阶段再扩展到外围系统并接入业务指标。

金融行业还涉及监管与审计要求，日志至少要保留 180 天，且要保证日志不可篡改。OBSERVE 支持冷存储归档和审计日志，在满足合规的同时控制存储成本。