银行核心系统的可观测性落地：从一笔转账看全链路

金融场景的特殊性

银行的分布式架构和互联网公司不一样。核心系统跑在 CICS 或小型机上、渠道系统在 x86 集群上、还有一大批外包系统——技术栈跨度极大，故障往往跨系统传导。一笔转账慢了，可能是核心交易慢，也可能是前置网关慢，传统监控只能看到"某个系统 CPU 高"，定位不到具体是哪个环节。

更麻烦的是，银行各个系统的日志格式、时间基准、监控工具都不统一。核心系统有核心系统的日志，渠道系统有渠道系统的监控，出了问题要各团队分别排查，最后对时间轴才能拼出全貌。炬鲸 OBSERVE 在多家银行的落地经验，形成了一套可复制的方案。

统一接入，分层采集

第一层是交易链路。核心系统的 CICS 交易通过一个轻量级探针采集交易号、交易码、耗时，这些数据以 span 的形式上报，和外围系统的 OpenTelemetry 链路拼在一起，形成从柜面、手机银行到核心的完整链路。关键是把"交易号"作为统一的 trace 上下文贯穿始终。

第二层是基础设施。小型机、Oracle、存储通过 exporter 采集指标，纳入统一的告警体系。银行的小型机很多还是 SNMP 或带外管理，需要用专门的采集器适配，不能指望它们原生支持 Prometheus 协议。

第三层是业务日志。核心系统的交易流水、渠道系统的报文日志统一接入日志检索，支持按交易号一键检索该笔交易在全部系统的日志。日志统一接入后，跨系统的日志比对从"手工翻文件"变成"一条 SQL"。

一个真实案例

某城商行上线后遇到一次故障：手机银行转账平均耗时从 800ms 涨到 3 秒。按传统方式，各团队各自查自己的系统，两天没定位。

接入 OBSERVE 后，用交易号在链路追踪里检索，10 分钟定位到根因：核心系统返回的账户查询响应变慢，进一步下钻发现是某个分库的连接池被打满，连接等待占了 1.8 秒。原因是上一批次的批量还款任务没有释放连接。重启那个批处理作业后，耗时立刻回落。

这个案例的关键不是"链路追踪多厉害"，而是交易号贯通之后，排查从"找是哪个系统"变成了"直接看是哪一步慢"。

落地要点

三个实践结论，供技术负责人参考：

1. 交易号贯通是关键。链路追踪和日志检索之间用交易号打通，是金融场景排查效率的核心。没有这个，再漂亮的拓扑图也查不了单笔交易。落地时要把交易号的生成和传递规范固化到开发规范里。
2. 告警要分级。核心系统故障影响面大，告警必须分级：P0 直接电话、P1 走短信、P2 走邮件。分级规则要按"影响交易量"而不是"影响机器数"来定——一台核心机器抖动，影响的交易量可能比十台渠道机器都大。
3. 合规要求要前置。金融数据的采集和存储要满足等保和监管要求，日志脱敏（卡号、身份证号、手机号）必须在采集端完成，而不是在查询端。脱敏策略要和合规部门确认，避免"先采集、后补救"。

落地的节奏

这套方案不建议一口气全上。比较稳妥的节奏是：先接链路追踪和交易号贯通（见效最快），跑稳定后接日志统一检索，最后再补基础设施指标和告警分级。每阶段都能独立看到收益，也方便在推进过程中和合规、安全团队对齐脱敏策略。

效果

上述客户上线三个月后，故障平均定位时间（MTTD）从 2 小时降到 15 分钟，跨系统问题的定位占比从 30% 降到 5%。这个数据是实打实跑出来的，不是 PPT 数字。