2、SLA核心指标设计:可用性、准确性、时效性、完整性、一致性的定义与度量

好,咱们进入正题。上一章聊了SLA是什么、为什么重要。这一章,我们来拆解最核心的部分——五个关键指标。

我见过不少团队,一上来就拍脑袋定SLA:“可用性四个9!准确性99.9%!”结果呢?要么根本测不准,要么运维成本高到离谱。说白了,指标设计不是喊口号,得能落地、能度量、能追责。

这五个指标,我习惯叫它们“SLA五边形”。任何一个短板,都会让数据产品失信于用户。咱们一个一个过。

2.1 可用性(Availability)

定义:数据产品或服务在约定时间内,能够被正常访问和使用的概率。

可用性是最直观的指标。用户打不开页面、调不通API,第一反应就是“挂了”。

度量方式:

可用性 = (总时间 - 不可用时间) / 总时间 × 100%

举个例子:一个月30天,总分钟数是43200分钟。如果服务宕了43分钟,可用性就是 (43200-43)/43200 ≈ 99.9%。也就是我们常说的“三个9”。

等级 可用性 月均不可用时间 典型场景
基础 99.9% ≈43分钟 内部报表、离线分析
标准 99.99% ≈4.3分钟 在线API、实时看板
高可用 99.999% ≈26秒 交易风控、实时决策
注意:不可用时间怎么算?我见过有人把计划内维护也扣进去,这其实不合理。SLA里要明确“计划内维护是否计入”。我个人习惯是:计划内维护提前24小时通知,不计入;突发故障,全额计入。

2.2 准确性(Accuracy)

定义:数据值与真实值或标准值之间的接近程度。

准确性是数据产品的生命线。数据不准,再高的可用性也没用。你想想看,一个实时大屏上数字都是错的,老板拍板能放心吗?

度量方式:

准确率 = 正确记录数 / 总记录数 × 100%

我在项目中遇到过最典型的场景:用户画像系统。系统每天同步几千万条用户行为数据,其中一条“性别”字段,因为上游埋点错误,把“男”写成了“未知”。这一条数据,就让整个画像的准确率从99.9%掉到了99.5%。

经验之谈:准确性不能只看整体均值。要分层看——关键字段(金额、用户ID)的准确率要求要比非关键字段(备注、描述)高一个数量级。

2.3 时效性(Timeliness)

定义:从数据产生到数据可被消费的时间间隔。

时效性决定了数据的“新鲜度”。有些场景,数据晚到一分钟,价值就归零。比如实时风控,晚几秒可能一笔欺诈交易就过去了。

度量方式:

  • 延迟(Latency):单条数据从产生到入库的时间。例如:实时流处理要求延迟 < 5秒。
  • 新鲜度(Freshness):数据仓库中,最新数据的时间戳与当前时间的差值。例如:T+1报表要求新鲜度 < 24小时。

我曾经踩过一个坑:给业务方承诺了“实时数据延迟小于1秒”,结果上线后发现,网络抖动、Kafka积压、下游消费能力不足,实际延迟经常飙到10秒以上。后来我学乖了——时效性SLA要分位点来定,比如“P99延迟小于5秒”,而不是“平均延迟小于1秒”。

2.4 完整性(Completeness)

定义:数据集中所有必要字段和记录是否齐全,没有缺失。

完整性是数据质量的“底线”。字段为空、记录丢失,下游分析就会出偏差。

度量方式:

完整率 = 非空且有效的记录数 / 应记录总数 × 100%

举个例子:一张订单表,每天应该产生100万条记录。如果实际只入库了98万条,完整率就是98%。

关键点:完整性要区分“字段完整性”和“记录完整性”。字段完整性看的是某个字段的空值率;记录完整性看的是行数是否对得上。我建议两个都要监控。

2.5 一致性(Consistency)

定义:同一数据在不同系统、不同时间点、不同维度下,逻辑上保持一致。

一致性是数据治理的“老大难”。同一个用户ID,在CRM系统里叫“user_id”,在订单系统里叫“uid”,在日志系统里叫“account_id”。你说这是不是问题?

度量方式:

  • 跨系统一致性:对比两个系统的关键字段,计算匹配率。例如:CRM和订单系统的用户ID一致率应 > 99.9%。
  • 时间一致性:同一指标在不同时间点的计算结果是否一致。例如:今天跑的昨日营收,和昨天跑的昨日营收,差值应 < 0.1%。
  • 逻辑一致性:数据间的业务逻辑关系是否成立。例如:订单金额 = 商品单价 × 数量 + 运费 - 优惠。

嗯,这里要注意:一致性不是越高越好。有些场景下,因为最终一致性模型的存在,短暂的不一致是可以接受的。比如搜索引擎的索引更新,允许几分钟的延迟。

2.6 五边形关系图

这五个指标不是孤立的。它们互相影响,甚至互相制约。我画了一张图,帮你理清关系。

SLA 五边形核心指标关系图 数据产品SLA 可用性 服务可访问概率 准确性 数据与真实值接近度 时效性 数据新鲜度/延迟 完整性 字段/记录齐全度 一致性 跨系统/时间逻辑一致 五个指标相互制约:追求极致时效性可能牺牲完整性,高一致性可能降低可用性

2.7 指标设计的避坑指南

讲完定义和度量,我分享几个实战中容易踩的坑。

避坑一:指标粒度不匹配
我曾经给一个实时推荐系统定SLA,可用性写了99.99%。结果发现,这个系统依赖的底层数据服务只有99.9%的可用性。上层承诺再高,底层扛不住也是白搭。记住:SLA指标要分层对齐,上下游一致。
避坑二:只定指标,不定测量方法
准确性怎么测?是用抽样比对,还是全量校验?时效性是从客户端发起到服务端返回,还是从数据产生到落库?这些不写清楚,到时候扯皮都扯不清。我习惯在SLA文档里单独写一节“测量方法”,把采样频率、计算口径、数据来源都列明白。
避坑三:忽略业务语义
完整性不是越高越好。有些字段就是允许为空的,比如“用户昵称”。你非要定100%完整率,那只能逼着上游填默认值,反而污染数据。所以,完整性指标要区分“必填字段”和“可选字段”。

2.8 小结

这一章我们拆解了SLA的五个核心指标。说白了,可用性管“能不能用”,准确性管“对不对”,时效性管“快不快”,完整性管“全不全”,一致性管“乱不乱”。

设计指标时,我建议你记住三句话:

  • 指标要可度量:不能度量就无法管理。
  • 指标要可落地:别定一个技术上根本达不到的目标。
  • 指标要可理解:业务方、开发方、运维方都能看懂、能对齐。