2. SLA指标体系设计:延迟、吞吐、可用性与数据新鲜度

聊完了SLA的基本概念,咱们得进入实操环节了。指标怎么定?哪些是关键?我见过不少团队,一上来就拍脑袋定个“99.9%”,结果上线后天天报警,运维同学苦不堪言。其实,特征平台的SLA指标,核心就四类:延迟、吞吐、可用性、数据新鲜度。咱们一个一个拆开聊。

核心观点: SLA指标不是越多越好,关键是“可测量、可预警、可追溯”。你定10个指标,不如把3个核心指标盯死。

2.1 延迟类指标:P99/P95/P50

延迟,说白了就是“用户等多久”。在特征平台里,这个“用户”可能是线上推理服务,也可能是离线批处理任务。我个人习惯,至少盯三个分位值:P50、P95、P99。

  • P50(中位数): 代表一半请求的延迟水平。如果P50都高,说明系统整体偏慢。
  • P95: 代表95%的请求都能达到的水平。我一般拿它做日常监控的基准线。
  • P99: 代表最慢的1%请求。这是SLA的“生死线”。

为什么特别关注P99?因为特征平台一旦出现长尾延迟,线上模型推理就可能超时,导致整个推荐链路降级。我在项目中遇到过,P50只有10ms,但P99飙到了500ms。排查后发现是某个热点特征的存储分片出现了毛刺。如果不看P99,这个问题根本发现不了。

避坑指南: 我曾经踩过一个坑——只监控平均延迟。平均延迟好看,但长尾请求把用户都卡死了。后来我强制团队,所有延迟SLA必须用P99定义,平均延迟只作为参考。

延迟指标的采集,建议用客户端埋点+服务端日志双重校验。客户端埋点能反映真实用户体验,服务端日志方便排查问题。嗯,这里要注意:时间戳一定要对齐,否则算出来的分位值会偏差很大。

2.2 吞吐量指标:QPS与TPS

吞吐量,就是“系统能扛多少并发”。QPS(每秒查询数)和TPS(每秒事务数)是孪生兄弟,但侧重点不同。

指标 定义 适用场景 我常用的阈值
QPS 每秒查询次数 纯读取特征(如特征缓存查询) 峰值不超过集群容量的70%
TPS 每秒事务数 读写混合(如特征写入+更新) 峰值不超过集群容量的60%

你想想看,QPS和TPS的区别在哪?QPS只管“查”,TPS要管“查+写+确认”整个事务。在特征平台里,线上推理服务通常只关心QPS,而数据同步管道更关心TPS。

我个人习惯,吞吐量指标要跟延迟指标联动看。比如QPS上去了,P99延迟也跟着涨,那说明系统快扛不住了。如果QPS涨了但延迟没变,说明还有余量。

注意: 不要只看瞬时峰值。我曾经遇到一个案例,某特征服务QPS瞬间冲到10万,持续了3秒,然后降下来了。监控系统没报警,但服务已经挂了。后来我加了“持续峰值时间”这个维度——比如QPS超过阈值持续5秒才报警。

2.3 可用性指标:9的个数

可用性,就是“系统能正常服务的时间比例”。大家常说的“几个9”,比如99.9%(三个9)、99.99%(四个9)。但特征平台的可用性,不能简单套用通用公式。

为什么?因为特征平台是“有状态”的。你服务还在,但特征数据过期了,算不算可用?我个人认为,特征平台的可用性应该分两层:服务可用性和数据可用性。

  • 服务可用性: API接口能正常响应。这个好算,用健康检查+请求成功率就行。
  • 数据可用性: 特征数据在预期时间内到达且正确。这个难算,需要结合数据新鲜度。

我建议,服务可用性定到99.95%以上(大约一年宕机不超过4小时),数据可用性定到99.9%以上。但别盲目追求高可用——每多一个9,成本可能翻倍。

经验之谈: 我见过最夸张的SLA是“六个9”(99.9999%),结果团队为了这个指标,光冗余部署就花了三倍成本,最后发现业务根本不需要。定可用性指标前,先问业务:你能容忍多久的数据不可用?

2.4 数据新鲜度指标

数据新鲜度,是特征平台独有的指标。它衡量的是“从数据产生到特征可用”的时间差。比如用户点击行为发生后,多久能体现在特征里?

新鲜度指标,我一般分三个等级:

  1. 秒级新鲜度: 用于实时推荐、风控等场景。延迟要求小于1秒。
  2. 分钟级新鲜度: 用于近线特征更新。延迟要求1-5分钟。
  3. 小时级新鲜度: 用于离线批处理特征。延迟要求1小时以内。

怎么监控新鲜度?我常用的方法是“时间戳对比法”。在特征数据里埋一个event_time字段,然后在查询时对比当前时间和event_time的差值。如果差值超过阈值,就报警。

# 伪代码:新鲜度监控逻辑
def check_freshness(feature_value):
    event_time = feature_value['event_time']
    now = time.now()
    latency = now - event_time
    if latency > FRESHNESS_THRESHOLD:
        alert("数据新鲜度超标: {}s".format(latency))

避坑指南: 我曾经遇到一个坑——数据新鲜度监控用的是服务端时间,但数据源的时间戳是客户端生成的。客户端时钟不准,导致新鲜度指标忽高忽低。后来我强制所有时间戳统一用NTP同步,并在监控里加了“时间戳偏差校验”。

2.5 指标体系全景图

好了,四个维度的指标都聊完了。咱们用一张图把它们串起来,看看整体关系。

特征平台SLA指标体系全景图 SLA指标体系 延迟类指标 吞吐量指标 可用性指标 数据新鲜度 P99 P95 P50 QPS / TPS 服务可用性 数据可用性 秒级/分钟级/小时级 核心原则 延迟、吞吐、可用性、新鲜度四维联动,缺一不可 每个指标都要有明确的采集方式、阈值定义和报警策略

这张图展示了四个维度的层级关系。中心是SLA指标体系,向外辐射出四个核心维度,每个维度下又有具体的子指标。我个人习惯,在搭建监控系统时,先按这个结构把指标分类,然后再逐个细化。

2.6 指标定义的最佳实践

最后,分享几个我踩过坑后总结出来的原则:

  • 指标要可量化: 别定“响应时间要快”这种模糊目标。要写成“P99延迟小于100ms”。
  • 指标要可复现: 不同团队拉出来的数据要一致。我建议统一用Prometheus + Grafana做指标采集和展示。
  • 指标要有时间窗口: 比如“过去5分钟内P99延迟”。别用“今天平均延迟”,那会掩盖问题。
  • 指标要有分级: 核心指标(P99、可用性)用红色报警,次要指标(P50、QPS)用黄色预警。

最后提醒: 指标定义完成后,一定要跟业务方对齐。我曾经遇到过,运维觉得P99 200ms算正常,业务方觉得超过50ms就不行。这种认知偏差,必须在SLA签订前消除。