金融交易系统可观测：黄金指标与 SLO 的落地方法

交易系统为什么需要不一样的可观测

交易系统的可靠性不是“能用就行”，而是“每一毫秒都有代价”。一笔支付晚 500ms，用户可能已经关掉页面；一笔下单在某个节点卡住，可能引发对账不一致。可观测在这里不是锦上添花，是风控和合规的一部分。

这类系统的特点决定了可观测的重点：流量有极强的峰谷，延迟要看尾部分布而不是平均值，错误要区分“业务失败”和“系统故障”，而且每一步都要留痕可审计。下面从指标、SLO、采样三个层面讲落地。

黄金指标：盯住四个数

Google SRE 的黄金指标对交易系统尤其适用，但用法要做调整：

• 延迟（Latency）：不要只看平均值，重点看 P95 和 P99。平均延迟可能很漂亮，但 1% 的慢请求足以让关键客户流失。交易系统建议直接盯 P99，并为“慢”定义明确阈值，比如核心支付接口 P99 < 300ms
• 流量（Traffic）：不只是 QPS，还要按交易类型拆分——查询、下单、支付、退款各自的量级完全不同，混在一起会掩盖某一类的异常
• 错误（Errors）：必须区分错误类型。HTTP 5xx 是系统故障，业务返回码（余额不足、风控拒绝）是正常业务结果。把两者混在“错误率”里，告警会一直误报
• 饱和（Saturation）：连接池、线程池、消息队列积压。交易系统的饱和往往先于延迟恶化出现，是很好的预警信号

在炬鲸 OBSERVE 里，给每个核心接口建一组指标卡片，把 P99 延迟、QPS、错误率、队列积压并排展示。但看板不是终点——看板只能告诉你“现在正常吗”，SLO 才能告诉你“这个月还扛得住几次变更”。

用 SLO 把可靠性量化

SLO（服务等级目标）是把“可靠”从形容词变成数字的方法。对交易系统，建议从这三个 SLI 起步：

• 可用性：成功请求 / 总请求，目标 99.9%
• 核心接口 P99 延迟：目标 300ms
• 交易成功率：已记账成功 / 已受理，目标 99.95%

SLI 的定义要精确到能写进代码。比如“成功请求”到底是 HTTP 2xx，还是“业务返回码为成功”？“已记账成功”以哪个系统的哪张表为准？定义含糊，SLO 就是空中楼阁。

SLO 定下后，错误预算（Error Budget）自然就有了。比如可用性目标 99.9%，一个月 30 天，预算就是 0.1% × 30 天 ≈ 43 分钟。团队可以用这 43 分钟来发布、灰度、做实验——预算烧完前该停就停。这才是 SLO 真正的作用：不是惩罚，而是给变更留出量化的空间，让“能不能上”从拍脑袋变成算账。

告警要跟着 SLO 走

有了错误预算，告警策略也应该随之调整：

• 预算消耗速度：当错误预算在短时间内消耗过快（比如一天烧掉一半），说明有持续性问题，需要立即介入
• 多窗口预算：同时看 30 天窗口和 1 天窗口，前者管长期趋势，后者抓突发恶化
• 宁可少而准：告警触发条件是“预算快烧完”而非“某一分钟错误率超阈值”，从根上减少误报

这套做法把告警从“盯着瞬时指标”变成“盯着可靠性余额”，和上一篇文章讲的动态基线正好互补。

采样与合规留痕的平衡

交易流量大，全量链路追踪的存储成本很高，所以要做采样。但交易系统的采样不能“一刀切”：

• 错误必采：只要出现错误或超时，这条 trace 无条件保留
• 关键交易必采：支付、退款、大额转账等核心链路 100% 采样
• 普通查询降采样：健康请求按 10% 或更低比例采样，足够做趋势分析

同时，采样策略本身要可审计——哪条被采样、为什么被采样，都要能解释。政企客户在合规审计时，会要求“某一笔交易在某一时刻的完整链路”，如果你的采样策略说不清，就等于留不下证据。炬鲸 OBSERVE 支持按规则配置采样，并把采样决策写进日志，审计时可回溯。

落地顺序建议：先给核心接口定 SLI 和 SLO，再上黄金指标看板，最后调采样策略。可观测是一层层叠加的，不要一上来就追求“全链路 100% 无死角”，那既贵又不必要。