金融行业故障定位：从告警到根因的 5 分钟排查路径

金融生产环境的三条硬约束

金融系统的可观测性，和互联网公司最大的区别在于约束不同。银行、券商、支付机构的生产环境通常有三条硬杠杠：

1. 稳定性优先：故障定位快慢直接关系到资金与客户，每一分钟都算钱
2. 审计要求严：谁在什么时间查了什么日志、改了哪个配置，必须可追溯
3. 数据不出内网：日志与链路是敏感数据，不能外发到第三方 SaaS

这三条决定了金融场景的故障排查方案不能照搬互联网那套"海量日志 + 模糊搜索"，而要更讲究分层和留痕。

告警分级：先救人再救火

告警的第一原则是分级，而不是平均用力。建议按影响面和业务重要性把告警分成三级：

• P0：资金相关链路（支付、清算、账务）报错，或核心系统不可用。立即电话+短信升级到值班负责人，5 分钟内必须有人响应
• P1：非资金核心功能（登录、查询）报错率超标。升级到当班工程师，30 分钟内响应
• P2：慢查询、资源水位预警、非核心告警。进入队列，当班处理即可

告警规则建议用「错误率 + 持续窗口」双重条件，避免瞬时抖动刷屏：

-- 支付接口错误率连续 5 分钟超过 1%，触发 P0
SELECT endpoint, error_rate
FROM metrics
WHERE service = 'payment' AND endpoint = '/pay/submit'
  AND ts > now() - 5m
HAVING error_rate > 0.01;

链路追踪：定位慢调用与错误传播

金融系统链路深、依赖多，一个交易请求可能穿透网关、风控、账户、清算、渠道五六个系统。出问题时，靠猜是猜不出在哪一环的。

炬鲸 OBSERVE 的链路追踪能按 trace_id 把一个交易请求的完整调用链展开，标注每一跳的耗时、返回码和错误信息。排查时重点看两处：

• 耗时最长的 span：90% 的"慢"问题都在这几个 span 上
• 错误传播点：一个下游报错，如何一层层冒泡成上层超时

定位到具体 span 后，可以直接下钻到该 span 关联的日志，看入参、出参和异常堆栈，通常到这里就能确定根因。

审计留痕与复盘

金融场景里，"查日志"本身也是一件需要留痕的事。炬鲸 OBSERVE 对所有敏感操作记录审计日志：谁、什么时间、用什么条件查询、是否导出、Token 何时轮换，全部可追溯。

每次故障结束后，建议做一份简短的复盘记录，沉淀成团队的知识库：

• 故障现象与影响面
• 定位路径（用了哪几个查询、哪条链路）
• 根因与修复动作
• 可复用的排查套路

把这些记录放进平台，下次遇到同类问题，新同事也能按图索骥。故障不可怕，可怕的是同一个坑掉两次。