3. SLA 指标定义：可用性、准确性、时效性、完整性、一致性

好，咱们进入正题。

SLA 不是一句空话，它得落地。落地靠什么？靠指标。没有指标，你跟业务方说「系统很稳定」，人家问你多稳定，你答不上来，那就尴尬了。

我个人习惯，把数据产品的 SLA 拆成五个维度：可用性、准确性、时效性、完整性、一致性。这五个词，你肯定都见过。但每个维度到底怎么定义、怎么量化、阈值设多少，这里头门道不少。

我刚开始带数据团队那会儿，也踩过坑。比如跟业务承诺「数据准确率 99.9%」，结果人家拿明细一比对，发现某张报表的字段映射错了，直接投诉到 VP 那里。嗯，从那以后，我对每个指标的定义都抠得特别细。

下面我一个一个说。

3.1 可用性（Availability）

可用性，说白了就是「系统能不能用」。数据产品也一样——数据服务是不是正常响应？数据接口是不是能调通？

我见过很多团队把可用性定义成「系统不宕机」。其实不够。对于数据产品，可用性应该拆成两层：

• 服务可用性：API 接口、查询引擎、数据服务能否正常返回结果。
• 数据可用性：数据表是否就绪、分区是否加载完成、数据是否可被消费。

举个例子。你有个实时数仓，服务端没宕机，但某个业务分区的数据因为上游延迟还没刷进来。这时候服务可用性是 100%，但数据可用性可能是 0%。用户查不到数据，照样投诉你。

所以我的建议是：可用性指标要同时覆盖服务和数据两个层面。

层级	指标定义	常见阈值	监测方式
服务可用性	接口/服务正常响应率	99.9% ~ 99.99%	健康检查 + 拨测
数据可用性	数据表/分区就绪率	99.5% ~ 99.9%	元数据检测 + 数据质量监控

3.2 准确性（Accuracy）

准确性，是数据产品的命根子。

数据不准，再快的查询、再炫的报表，都是废的。业务方不会因为你响应快就原谅你数据错了——他们只会说「你们的数据不靠谱」。

准确性的定义，我一般分三种场景：

1. 值准确性：数据字段的值是否正确。比如订单金额是不是 100 元，而不是 99.99 元。
2. 逻辑准确性：数据加工逻辑是否符合业务规则。比如「去重用户数」是不是真的去重了。
3. 参照准确性：数据与权威源（如财务系统、CRM）是否一致。

我在项目中遇到过最典型的问题：ETL 脚本里有个 join 条件写错了，导致某张报表的「活跃用户数」比实际多了 30%。这个 bug 跑了两个月才被发现。为什么？因为准确性监测没做到位。

准确性的量化方式，我推荐用「数据差错率」：

数据差错率 = 错误记录数 / 总记录数 × 100%

阈值建议：
- 核心业务数据（交易、财务）：差错率 < 0.01%
- 一般业务数据（用户画像、行为日志）：差错率 < 0.1%
- 辅助数据（标签、中间表）：差错率 < 0.5%

3.3 时效性（Timeliness）

时效性，就是「数据多久能到」。你想想看，业务方早上 9 点开会，数据到 10 点才刷出来，那这个数据还有用吗？

时效性的定义，不能只写「T+1」这种模糊说法。我习惯把它拆成三个时间点：

• 数据产生时间：业务事件发生的时间。
• 数据到达时间：数据进入数仓/数据平台的时间。
• 数据就绪时间：数据加工完成、可供查询的时间。

时效性 SLA 的核心，就是「数据就绪时间」与「数据产生时间」的差值。

数据场景	时效性要求	监测指标
实时风控	秒级（< 5s）	端到端延迟 P99
实时大屏	分钟级（< 5min）	数据新鲜度
离线报表	T+1 早上 8:00 前	任务完成时间
数据同步	小时级（< 1h）	同步延迟

这里有个坑：很多人只关注「平均延迟」，忽略了长尾。我见过一个实时管道，平均延迟 200ms，但 P99 延迟到了 30 秒。业务方在高峰期查数据，经常超时。所以，时效性指标一定要看分位数（P95、P99）。

3.4 完整性（Completeness）

完整性，就是「数据全不全」。

数据缺了，分析结论就可能偏。比如算 GMV，如果某天的数据丢了，那当天的 GMV 就是 0，整个月的趋势图就断了一截。

完整性的定义，我一般从两个维度看：

1. 记录完整性：数据行数是否完整。比如今天应该有 100 万条订单，实际只有 98 万条。
2. 字段完整性：数据字段是否完整。比如「用户手机号」字段，空值率是不是异常升高。

完整性量化的公式：

记录完整率 = 实际记录数 / 预期记录数 × 100%
字段完整率 = 非空记录数 / 总记录数 × 100%

阈值建议：
- 核心表：记录完整率 ≥ 99.9%，字段完整率 ≥ 99.5%
- 一般表：记录完整率 ≥ 99.5%，字段完整率 ≥ 99%
- 日志表：记录完整率 ≥ 99%，字段完整率 ≥ 95%

3.5 一致性（Consistency）

一致性，是五个指标里最容易被忽视的。

什么叫一致性？同一个业务实体，在不同数据源、不同时间点、不同加工链路里，数据应该保持一致。

我举个例子。用户「张三」在 CRM 系统里叫「张三」，在数仓的用户表里也叫「张三」，但在订单表里被写成了「张 三」（中间多了个空格）。这就是不一致。这种问题，单看准确性是看不出来的——每个系统里的数据本身都是对的，但放在一起就对不上了。

一致性我分成三类：

• 跨系统一致性：同一数据在不同系统间保持一致。比如 CRM 和数仓的用户 ID 要能关联上。
• 跨时间一致性：同一数据在不同时间点保持一致。比如昨天的「累计用户数」加上今天的新增，应该等于今天的「累计用户数」。
• 跨链路一致性：同一数据经过不同加工链路后保持一致。比如实时链路和离线链路算出的「今日 PV」应该一致。

一致性的量化方式：

一致率 = 一致记录数 / 总记录数 × 100%

阈值建议：
- 核心维度数据（用户、商品、门店）：一致率 ≥ 99.99%
- 交易数据：一致率 ≥ 99.9%
- 行为数据：一致率 ≥ 99.5%

3.6 五个指标的关系

这五个指标不是孤立的。它们之间有关系，甚至有时候会互相制约。

你想想看，为了追求时效性（秒级产出），你可能牺牲了完整性（部分数据还没到）。为了追求准确性（全量校验），你可能牺牲了时效性（校验耗时太长）。

所以，设计 SLA 的时候，一定要根据业务场景做权衡。实时风控场景，时效性优先；财务对账场景，准确性优先；用户画像场景，完整性优先。

下面这张图，是我自己总结的五个指标的关系框架：

你看这张图，五个指标围绕 SLA 核心，彼此之间没有的优先级。具体怎么权衡，取决于你的业务场景和数据产品定位。