SLA 基础概念：定义、区别与数据场景的差异
聊数据新鲜度 SLA 之前，得先把基础概念掰扯清楚。我见过不少团队，SLA、SLO、SLI 混着用，最后指标对不上，扯皮不断。说白了，这三个东西是不同层面的东西，搞混了，后面自动化追踪就是空中楼阁。
SLA 到底是什么？
SLA，全称 Service Level Agreement，服务等级协议。它不是技术指标，是一份契约。你想想看，你跟业务方说“我保证每天凌晨 3 点前数据到位”，这就是一个 SLA 承诺。如果没做到，通常有惩罚条款——比如扣减服务费，或者业务方可以投诉。
我习惯把 SLA 理解为“对外承诺的底线”。它面向的是客户或业务方，语言要清晰，不能有歧义。比如：
- “每日核心报表数据在 T+1 08:00 前可用”
- “实时数据流延迟不超过 5 分钟”
- “月度可用性不低于 99.9%”
关键点：SLA 是合同性质的。它定义了“做不到怎么办”，而不是“怎么做”。
SLO 与 SLI：别再傻傻分不清
很多新手会把 SLO 和 SLA 划等号。其实它们分工明确：
- SLI（Service Level Indicator）：你实际测量的指标。比如“数据从源端到达数仓的延迟时间”、“每小时数据更新的成功率”。它是原始数据，不带目标值。
- SLO（Service Level Objective）：你给自己定的目标值。比如“99% 的数据更新延迟在 10 分钟内”。SLO 是内部用的，比 SLA 更严格。
举个例子你就明白了。我曾经负责一个实时风控项目，业务方 SLA 要求“数据延迟不超过 5 分钟”。但我们内部设的 SLO 是“99.5% 的数据延迟不超过 3 分钟”。为什么留余量？因为一旦 SLO 都达不到，SLA 肯定崩。这叫“安全垫”。
| 概念 | 面向对象 | 性质 | 示例 |
|---|---|---|---|
| SLA | 客户/业务方 | 契约，有惩罚 | “每日 08:00 前数据可用，否则扣减 5% 服务费” |
| SLO | 技术团队内部 | 目标，无惩罚 | “99.9% 的数据在 07:30 前就绪” |
| SLI | 监控系统 | 测量值 | “今日数据更新延迟 P99 = 2.3 分钟” |
我的习惯：SLO 永远比 SLA 严格 20%-30%。这样即使 SLO 偶尔失守，SLA 还能守住。别把 SLO 设得跟 SLA 一样，那是给自己挖坑。
数据 SLA 与传统 SLA 的差异
传统 SLA 主要管“服务能不能用”。比如一个 API 接口，SLA 关注的是可用性、响应时间、错误率。这些指标相对简单，监控工具也成熟。
但数据 SLA 完全不一样。数据不是“通断”问题，是质量问题。我遇到过最头疼的情况：数据管道没挂，ETL 没报错，但数据就是不对——字段空值率飙升，或者时间戳错位。传统 SLA 检测不出来。
具体差异我列了个表：
| 维度 | 传统 SLA（如 API） | 数据 SLA |
|---|---|---|
| 核心指标 | 可用性、延迟、吞吐量 | 新鲜度、完整性、准确性、一致性 |
| 故障表现 | 服务不可用、超时 | 数据延迟、数据缺失、数据错误 |
| 检测方式 | 健康检查、Ping、响应码 | 数据质量规则、字段校验、时间戳比对 |
| 恢复难度 | 重启、回滚、扩容 | 重跑 ETL、数据回溯、修复脏数据 |
| 责任界定 | 通常归平台团队 | 跨源系统、数据工程、业务方共同承担 |
嗯，这里要注意。数据 SLA 里最容易被忽视的是“准确性”。我曾经有个项目，数据每天准时 07:00 到位，新鲜度 SLA 完全达标。但业务方投诉说数据不对——因为上游源系统改了字段含义，ETL 没适配。你看，新鲜度达标不等于数据可用。所以数据 SLA 必须包含质量维度，不能只看“有没有按时到”。
避坑指南：我曾经吃过一次大亏。跟业务方签 SLA 时只写了“每日 08:00 前数据可用”，没定义“可用”的标准。结果数据到了，但全是空值，业务方说“这算可用吗？”从那以后，我所有数据 SLA 都附带一条：“可用”指数据通过预定义的质量检查，包括非空率、唯一性、时间戳连续性等。
数据新鲜度 SLA 的特殊性
回到我们课程的主题——数据新鲜度。新鲜度 SLA 是数据 SLA 的一个子集，但它有自己的脾气：
- 时间敏感：晚 1 分钟和晚 1 小时，影响天差地别。实时风控场景下，5 分钟延迟可能意味着几十万的损失。
- 分层定义：不同数据表的新鲜度要求不同。核心交易表可能要求秒级，日志分析表可以接受小时级。
- 依赖链复杂：一张报表的数据可能经过 5 层 ETL，每一层都有延迟。新鲜度 SLA 必须能穿透整个链路。
我习惯把数据新鲜度 SLA 拆成三个层次：
- 源端新鲜度：数据从业务系统产生到被采集的时间。
- 管道新鲜度：数据在 ETL 管道中流转的耗时。
- 服务新鲜度：数据在目标系统（数仓、报表、API）中可被查询的时间。
这三个层次，每一层都要有独立的 SLI 和 SLO。否则你根本不知道延迟卡在哪一环。
一张图理清关系
下面这张图展示了 SLA、SLO、SLI 在数据新鲜度场景下的层级关系：
你看，从 SLA 到 SLO 再到 SLI，是一个逐层细化的过程。SLA 是“承诺什么”，SLO 是“要做到什么程度”，SLI 是“实际是多少”。没有 SLI，SLO 就是空话；没有 SLO，SLA 就是赌博。
我的建议：刚开始做数据新鲜度 SLA 的团队，先别急着定 SLA。先跑一个月 SLI，摸清现状。比如你发现当前 P95 延迟是 8 分钟，那 SLO 可以定 10 分钟，SLA 定 15 分钟。这样既有改进空间，又不至于一开始就违约。
好了，基础概念就这些。记住三个关键词：SLA 是契约，SLO 是目标，SLI 是度量。下一层我们开始聊怎么制定具体的新鲜度指标——那才是真正动手的地方。