4. 数据契约的SLA制定：可用性、新鲜度、完整性、准确性

数据契约签了，责任边界划清了，接下来就是最实在的部分——SLA（服务等级协议）。说白了，就是给数据质量定个“及格线”。没有SLA的数据契约，就像没有验收标准的合同，扯皮是迟早的事。

我个人习惯把数据SLA拆成四个维度：可用性（Availability）、新鲜度（Freshness）、完整性（Completeness）、准确性（Accuracy）。这四个维度基本覆盖了数据消费方最关心的点。下面我一个一个说。

4.1 可用性（Availability）

可用性，就是数据“能不能用”。数据表挂了、接口超时、任务跑不出来——这些都算不可用。我见过最惨的情况：某团队的数据管道每天凌晨3点跑，结果因为上游依赖的表没按时产出，整个链路断了，业务方早上9点开会时数据还是空的。

可用性SLA通常用“几个9”来衡量。99%和99.9%看起来只差0.9%，但背后的运维成本差了一个数量级。

可用性SLA还需要明确“什么算不可用”。是数据完全不可读？还是延迟超过阈值？还是数据量低于某个百分比？这些细节必须在契约里写清楚，否则事后扯不清楚。

4.2 新鲜度（Freshness）

新鲜度，就是数据“多新”。业务方要的是“今天的数据”，还是“上一小时的数据”，还是“实时数据”？这个差别很大。

我习惯把新鲜度分成三个档次：

• T+1（天级）：今天看昨天的数据。最常见，成本最低。
• 小时级：延迟在1小时以内。适合运营监控、实时报表。
• 近实时（分钟级）：延迟在5-15分钟。适合风控、推荐系统。

新鲜度SLA要写清楚“从数据产生到数据可用”的时间窗口。举个例子：

# 数据契约中的新鲜度SLA示例
sla_freshness:
  target: "T+1 08:00"
  description: "前一天的全量数据，在次日早上8:00前必须可用"
  exception: "如果上游数据延迟超过2小时，SLA自动顺延，但需通知消费方"
  measurement: "以数据表最新分区的时间戳为准"

4.3 完整性（Completeness）

完整性，就是数据“全不全”。数据量少了、字段缺失了、某些分区没跑出来——这些都算不完整。

完整性SLA通常用“数据行数对比”或“字段非空率”来衡量。举个例子：

这里有个坑：“预期行数”怎么算？如果上游数据本身就有波动，用固定值做阈值会频繁告警。我个人的做法是：用过去7天的滚动均值作为基准，允许±5%的波动。超出这个范围才触发告警。

4.4 准确性（Accuracy）

准确性，就是数据“对不对”。这是最难定义的维度。为什么？因为“对”的标准因人而异。

我通常把准确性SLA分成两类：

• 技术准确性：数据格式正确、类型匹配、不违反约束。这个相对好衡量。
• 业务准确性：数据值符合业务预期。这个需要业务方参与定义。

举个例子：

# 准确性SLA示例
sla_accuracy:
  technical:
    - "所有数值字段不能为负数（除非业务允许）"
    - "日期字段格式必须为 yyyy-MM-dd HH:mm:ss"
    - "枚举字段必须在允许值列表内"
  business:
    - "订单金额与支付系统对账差异 < 0.1%"
    - "用户活跃度指标与埋点数据偏差 < 5%"
  measurement: "每天运行数据质量检查任务，输出差异报告"

4.5 SLA的监控与告警

SLA定好了，不监控等于白定。我个人习惯在每个数据管道的关键节点埋点，实时计算SLA达标情况。

一个简单的SLA监控流程：

1. 数据产出时：记录时间戳、行数、字段统计信息
2. 与SLA阈值对比：判断是否达标
3. 不达标时：触发告警，通知生产方和消费方
4. 记录SLA历史：用于月度复盘和SLA调整

告警级别我建议分三级：

4.6 SLA的迭代与调整

SLA不是一成不变的。业务在发展，数据量在增长，技术架构在演进——SLA也需要跟着调整。

我建议每季度做一次SLA复盘：

• 过去一个季度的SLA达标率是多少？
• 哪些SLA指标经常不达标？原因是什么？
• 业务方对当前的SLA满意吗？有没有新的需求？
• 技术团队有没有能力提升SLA？成本是否可接受？

复盘之后，双方坐下来重新协商SLA。该升的升，该降的降。别把SLA当成死规矩，它应该是活的。