4. SLA基础与指标体系

在行情数据链路中,“延迟”如果只停留在“感觉有点慢”的层面,就无法驱动运维决策,也无法向业务方证明系统是否达标。SLA、SLO、SLI 这三个概念,正是把模糊的体验转化为可执行、可考核、可复盘的工程语言。理解它们之间的层级关系,是搭建行情延迟监控体系的第一步。

一、核心原理:SLA、SLO、SLI 的层级关系

SLI(Service Level Indicator,服务等级指标)是对系统实际表现的量化测量,回答“现在到底有多快”。在行情场景中,SLI 可以是“行情快照从交易所发出到客户端可读的耗时”,单位是毫秒。SLI 必须是可采集、可聚合、可复现的原始数据。

SLO(Service Level Objective,服务等级目标)是团队对 SLI 设定的内部目标值,回答“我们希望做到多快”。例如“P99 端到端延迟不超过 50ms,月度达标率不低于 99.9%”。SLO 是工程团队自我约束的标尺,通常比对外承诺更严格,留出缓冲空间。

SLA(Service Level Agreement,服务等级协议)是面向客户或业务方的正式承诺,回答“我们承诺做到多快,做不到怎么赔”。SLA 往往包含赔偿条款、统计周期和免责条件,因此它的阈值通常比 SLO 宽松,避免因偶发波动触发违约。

三者的关系可以概括为:SLI 是“温度计读数”,SLO 是“健康目标”,SLA 是“合同承诺”。没有 SLI,SLO 和 SLA 都是空话;没有 SLO,SLA 就缺乏内部预警缓冲。
行情延迟监控的三层指标体系 SLA 服务等级协议 对外承诺:P99 ≤ 80ms,月度达标率 ≥ 99.5%,违约触发赔付 SLO 服务等级目标 内部目标:P99 ≤ 50ms,月度达标率 ≥ 99.9%,用于预警与容量规划 SLI 服务等级指标 原始测量:P50 / P95 / P99 / Max / 达标率,按秒级窗口聚合 缓冲 测量

二、行情延迟 SLA 的常见指标

行情延迟的 SLI 不能只看平均值。平均值会被大量正常样本稀释,掩盖尾部用户的糟糕体验。因此业界普遍采用分位数与达标率组合,形成完整的延迟画像。

指标 含义 行情场景典型用途 常见阈值示例
P50 50% 请求的延迟低于该值,即中位数 反映大多数用户的常态体验 ≤ 8ms
P95 95% 请求的延迟低于该值 识别轻度拥塞与网络抖动 ≤ 25ms
P99 99% 请求的延迟低于该值 核心 SLA 承诺指标,覆盖尾部体验 ≤ 50ms
Max 统计窗口内的最大延迟 排查极端卡顿、GC 停顿、重连风暴 ≤ 200ms
达标率 满足阈值的时间窗口占比 月度 SLA 结算与赔偿判定 ≥ 99.9%

分位数之间不是孤立的。P50 与 P99 的差距(尾延迟放大倍数)能反映系统稳定性:如果 P50 是 5ms 而 P99 是 200ms,说明存在明显的长尾问题,可能是某几个行情源或某段网络路径拖累。达标率则把“是否达标”变成时间维度上的比例,便于按天、按周、按月结算。

三、方法流程:从采集到 SLA 结算

  1. 埋点采集:在行情网关、解码模块、分发队列、客户端 SDK 等关键节点打时间戳,记录每条行情消息的进入与离开时间。
  2. 延迟计算:用离开时间减去进入时间,得到单条消息的端到端延迟,单位统一为毫秒。
  3. 窗口聚合:按 1 秒或 10 秒窗口计算 P50、P95、P99、Max,避免逐条上报造成存储爆炸。
  4. 达标判定:将每个窗口的 P99 与 SLO 阈值比较,标记达标或未达标。
  5. 周期结算:按自然月统计达标窗口占比,得到月度达标率,与 SLA 条款比对。
# 示例:用 PromQL 计算行情端到端 P99 延迟
histogram_quantile(
  0.99,
  sum(rate(market_data_latency_bucket[5m])) by (le, source)
)

# 示例:计算过去 30 天 P99 达标率
sum_over_time(
  (market_data_latency_p99 <= 50)[30d:1m]
) / count_over_time(
  (market_data_latency_p99)[30d:1m]
)
建议把 P99 达标率拆分为“按行情源”和“按交易所”两个维度。同一套 SLA 下,不同源的实际表现可能差异巨大,拆分后才能定位是全局问题还是局部问题。

四、案例与场景:一次 P99 超标复盘

某券商行情中台对外 SLA 承诺“P99 端到端延迟 ≤ 80ms,月度达标率 ≥ 99.5%”。某月结算时达标率仅为 99.1%,触发赔偿条款。团队复盘发现:P50 和 P95 全月正常,但每天开盘前 3 分钟 P99 飙升至 300ms 以上,Max 达到 1.2s。

进一步排查发现,开盘前大量客户端同时发起全量快照请求,解码线程池被瞬时打满,导致部分消息在队列中排队超过 200ms。问题不在网络,而在应用层的并发控制。团队随后增加了快照请求的限流与优先级队列,并在 SLO 中新增“开盘前 5 分钟 P99 ≤ 100ms”的独立目标,作为 SLA 的内部预警。

常见误区一:只看平均值。平均值达标不代表尾部达标,SLA 通常考核的是 P99 或达标率,平均值参考价值有限。
常见误区二:SLA 与 SLO 阈值倒挂。如果 SLO 比 SLA 还宽松,内部就没有预警空间,等到 SLA 违约时已经来不及干预。
常见误区三:统计窗口过粗。按小时聚合会掩盖分钟级抖动,建议至少保留秒级或分钟级原始窗口,再向上汇总。

建立指标体系后,下一步才是监控告警与可视化。但在此之前,请确保团队对 SLI 的定义、采集点、聚合方式和统计周期达成一致——口径不统一,后续所有数字都不可信。