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-5分钟。
- 小时级新鲜度: 用于离线批处理特征。延迟要求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指标体系,向外辐射出四个核心维度,每个维度下又有具体的子指标。我个人习惯,在搭建监控系统时,先按这个结构把指标分类,然后再逐个细化。
2.6 指标定义的最佳实践
最后,分享几个我踩过坑后总结出来的原则:
- 指标要可量化: 别定“响应时间要快”这种模糊目标。要写成“P99延迟小于100ms”。
- 指标要可复现: 不同团队拉出来的数据要一致。我建议统一用Prometheus + Grafana做指标采集和展示。
- 指标要有时间窗口: 比如“过去5分钟内P99延迟”。别用“今天平均延迟”,那会掩盖问题。
- 指标要有分级: 核心指标(P99、可用性)用红色报警,次要指标(P50、QPS)用黄色预警。
最后提醒: 指标定义完成后,一定要跟业务方对齐。我曾经遇到过,运维觉得P99 200ms算正常,业务方觉得超过50ms就不行。这种认知偏差,必须在SLA签订前消除。