金融行业可观测性落地：一次支付链路超时的排查复盘

背景：一次真实的支付超时

某城商行的支付网关在周一上午 10 点出现批量超时，交易成功率从 99.95% 跌到 96%，客服开始接到用户投诉。按照监管要求，这类事件需要在规定时间内定位并上报。团队最后用 20 分钟锁定根因，复盘下来靠的不是运气，而是一套事先串好的三层可观测体系。

第一层：指标先圈定范围

告警先响的不是支付网关本身，而是下游"核心账务系统"的响应时间。打开指标大盘，核心账务的 P99 延迟从 80ms 飙到 4 秒，且只影响"余额查询"这一个接口，其他接口正常。这一步把排查范围从"整个支付链路"缩小到"核心账务的余额查询接口"。

关键点：指标看板要按接口维度拆开，而不是只存一个笼统的"系统延迟"。拆不开，就只能看到"核心账务变慢了"，看不到"只有余额查询变慢了"。

第二层：链路追踪定位到具体节点

顺着告警时间点，在链路追踪里过滤 service.name="core-ledger" AND operation="queryBalance"，拉出超时请求的调用链。发现 90% 的超时 Span 都停在同一处：余额查询内部对"账户缓存服务"的调用，耗时集中在 3.9 秒。

再看缓存服务的 Span，看到大量 get 操作返回了穿透标记——缓存没命中，全打到数据库了。到这里，根因方向已经清楚：缓存失效导致数据库被打满。

第三层：日志确认根因

最后用日志做确认。检索缓存服务在 10:02 到 10:05 之间的日志，过滤 level=error，看到一批 Connection pool exhausted 和 redis connection reset。往前翻到 10:01，找到一条 cache key evicted: BAL:* 的记录——某个批量任务误把余额缓存整段清空了。

三分钟恢复了缓存预热脚本，成功率回到 99.9% 以上。从告警到定位，20 分钟。

金融场景的建设建议

1. 指标、链路、日志必须用同一个 trace_id / 请求 ID 串起来，否则三层各查各的，关联靠人工。
2. 缓存、数据库、消息队列这些中间件也要接入可观测，故障往往不在应用代码里，而在中间件。
3. 交易类的关键链路做全量 Trace 采样，冷链路可以降采样，成本可控。
4. 告警阈值按接口维度配置，并设置分级：响应时间告警、错误率告警、业务量突降告警分开，避免告警风暴互相淹没。