证券行业可观测性实践：交易链路毫秒级告警与审计合规

证券行业的可观测性有两个特殊要求：一是交易链路对延迟极度敏感，几十毫秒的抖动就可能触发风控或影响撮合；二是监管要求关键日志可追溯、不可篡改、留存足够长时间。这两点决定了可观测性不能照搬互联网那套。

交易链路的埋点与基线

券商的典型链路是：行情网关 → 报单 → 柜台（集中交易）→ 撮合 → 回报。每一跳都要埋点，且必须带上两个关键标识：order_id（订单号）和 session_id（会话号），否则出了问题没法把一条订单的前后上下文串起来。

埋点用 OpenTelemetry 手动 Span，只在关键边界埋，不要全链路无脑埋——交易链路每多一层埋点就多几毫秒开销：

ctx, span := tracer.Start(ctx, "oms.match",
    trace.WithAttributes(
        attribute.String("order_id", orderID),
        attribute.Int64("qty", qty),
    ))
defer span.End()

延迟告警不要用固定阈值，用「基线 + 偏离」：先统计每个接口过去 14 天的 P95 延迟，告警条件设为"当前 P95 超过历史基线 2 倍且持续 1 分钟"。固定阈值（比如"超过 200ms 就告警"）在行情波动时会误报，非交易时段又太宽松，永远调不准。

告警分级与升级

证券的告警必须分级，否则一个行情推送抖动就会淹没真正的故障：

• P0：交易链路中断、撮合不可用，电话 + 短信，1 分钟内响应；
• P1：延迟超基线、降级启用，短信 + 企业微信；
• P2：单节点异常、资源水位告警，仅企业微信。

升级规则要写清楚：P1 持续 5 分钟未确认自动升 P0；非交易时段 P2 告警静默。这些在炬鲸 OBSERVE 里用告警策略的「分级 + 升级」配置一次到位，避免靠人肉转发。

审计与合规留存

监管的硬指标一般是两条：日志留存不少于 3 年（部分业务 5 年），关键操作日志不可篡改。做法是把日志分两层：

• 热数据（近 30 天）放检索层，供日常排查；
• 冷数据归档到对象存储，按天做哈希摘要并离线保存摘要链，防止事后篡改。

账号操作（登录、改权限、导出数据）单独打审计日志，字段包含操作者、时间、来源 IP、操作对象、前后值，和业务日志隔离存储。审计日志要定期演练恢复，避免"存了但取不出来"。

落地节奏

不建议一次性全链路改造。先挑一条最核心的业务链路（比如普通 A 股下单）做深度埋点和告警，跑稳一个交易周，再横向铺开。可观测性的价值在排障时体现，但改造的成本在前置埋点，分批做比一次做完风险低得多。