金融核心交易链路可观测性实践：故障定位从 30 分钟到 3 分钟

一笔交易从下单到成交，中间经过网关、风控、行情、撮合、清算十几个环节，任一环节抖动都会反映到整体时延上。过去出问题，我们的做法是拉上各团队开会，各自翻自己的日志比对时间戳，一次定位动辄半小时以上。后来把这套体系重做了一遍。

统一埋点与关联标识

可观测的前提是数据能关联起来。我们定了一条硬规矩：每个进入系统的请求，必须在网关生成唯一 traceId，并随调用链向下传递；日志、指标、链路三者的关联键统一为 traceId + businessId（业务单号）。这样无论从哪个入口查，都能顺藤摸瓜拉到同一笔交易的全部信息。

埋点用 OpenTelemetry 标准，避免绑死某个厂商。关键 span 明确标注：网关入口、风控规则匹配、行情订阅、撮合引擎、清算落库，每个 span 记录耗时和结果状态码。

用 SLO 驱动告警，而不是堆阈值

传统告警是给 CPU、内存、QPS 拍脑袋设阈值，误报和漏报都多。我们改成以 SLO 为核心：对「交易端到端时延 P99 < 300ms」和「交易成功率 ≥ 99.95%」两个目标，用多窗口燃尽率（burn rate）做告警。

具体做法：1 小时窗口内消耗 2% 的错误预算发 warning，6 小时消耗 5% 发 critical，避免单个瞬时抖动就炸群。告警信息直接带上受影响的服务、span 和 traceId 样例，收到告警的人点链接就能进到问题现场。

链路、日志、指标三合一

排查时最浪费时间的是在三个系统间切换。我们把链路追踪页面做成入口：点开一条慢交易，能看到整条调用链每个环节的耗时分布，哪个 span 变红一目了然；点那个 span，自动下钻到它所在节点的日志；对应的指标（GC、线程池、连接池）也贴在旁边。定位从「哪个环节慢」到「为什么慢」一步到位。

一次真实故障复盘

某日下午，交易成功率告警触发，P99 时延从 120ms 飙到 800ms。按老办法可能要找风控和撮合两边对时间。这次点开告警里的 traceId，调用链显示风控规则匹配 span 从 5ms 涨到 600ms，且集中在某一条规则上；下钻日志看到该规则频繁触发数据库慢查询。定位到是这条规则当天上线后缺少索引导致，回滚规则后恢复，全程约 3 分钟。

复盘结论：关联标识 + SLO 告警 + 三合一视图，是这三分钟的关键。可观测性不是锦上添花，对交易系统来说是故障时能少亏多少钱的问题。