1、SLA基础概念：什么是SLA、SLO与SLI的区别、实时数据SLA的特殊性

聊实时数据产品，绕不开SLA。我见过不少团队，一上来就拍胸脯说“我们保证99.9%可用”，结果上线第一天就崩了。为什么？因为连SLA、SLO、SLI都没分清。

这一节，咱们先把这三个概念掰扯清楚。顺便聊聊实时数据的SLA，跟传统离线系统到底差在哪。

1.1 什么是SLA？

SLA（Service Level Agreement），服务等级协议。说白了，就是一份合同。你跟用户签的，或者你跟业务方签的，白纸黑字写清楚：我保证做到什么程度，做不到怎么赔。

举个例子。你做一个实时风控系统，业务方要求“每次请求必须在200毫秒内返回结果”。你同意了，这就是一个SLA条款。如果超时了，按约定扣服务费或者赔积分。

我个人习惯把SLA分成两类：

• 对外SLA：面向客户或业务方，语言要通俗，指标要可验证。比如“每月可用时间不低于99.9%”。
• 对内SLA：面向研发和运维团队，用来约束内部行为。比如“核心链路P99延迟不超过500ms”。

嗯，这里要注意：对内SLA可以比对外SLA更严格。你对外承诺99.9%，内部最好按99.99%去设计。留点余量，别把自己逼死。

1.2 SLO与SLI的区别

很多新人搞混SLO和SLI。我刚开始带团队时也犯过这个错——开会时大家各说各的，吵了半天才发现说的不是同一个东西。

咱们用一张图理清楚：

简单说：

• SLI（Service Level Indicator）：你实际测量的原始数据。比如“过去5分钟的平均延迟是150ms”、“错误率是0.01%”。它是客观的，不带任何承诺。
• SLO（Service Level Objective）：你给自己定的目标。比如“P99延迟不超过200ms”、“可用性不低于99.9%”。它是技术指标，用来指导研发和运维。
• SLA（Service Level Agreement）：你对外承诺的SLO。比如“每月可用时间不低于99.9%，否则赔偿10%服务费”。它是商业条款，有法律效力。

1.3 实时数据SLA的特殊性

实时数据产品的SLA，跟传统离线系统完全不是一个玩法。我踩过不少坑，挑几个最典型的说说。

1.3.1 延迟敏感度极高

离线系统跑批，跑4小时还是5小时，用户感知不强。但实时系统不一样。你做个实时大屏，数据延迟超过10秒，业务方就炸了。做个实时推荐，响应超过100ms，用户就流失了。

所以实时数据的SLA，延迟指标是核心。而且不是平均延迟，是P99、P999。平均延迟好看没用，尾延迟才是杀手。

1.3.2 数据一致性更难保证

离线系统可以靠事务、重跑、校验来保证数据一致。实时系统呢？数据流是连续的，没法回滚。一旦出现乱序、重复、丢失，修复成本极高。

举个例子。你在做实时交易风控，一条交易数据丢了，可能就漏掉一笔欺诈。你事后补回来？晚了，钱已经转走了。

所以实时数据的SLA，必须包含数据完整性指标。比如“端到端数据丢失率不超过0.01%”、“数据重复率不超过0.1%”。

1.3.3 可用性定义不同

离线系统的可用性，通常看服务是否在线。实时系统不一样。服务在线，但数据延迟了，算不算可用？

我个人习惯把实时系统的可用性分成三层：

可用性层级	定义	典型SLO
服务可用	API/服务能正常响应请求	99.9%
数据可用	数据在预期时间内到达	P99延迟 ≤ 5秒
业务可用	数据能正确支撑业务决策	数据准确率 ≥ 99.99%

你想想看，服务可用不代表数据可用。服务跑得好好的，但Kafka积压了，数据延迟半小时，业务方照样骂你。所以实时SLA必须把数据可用性单独拎出来。

1.3.4 监控和告警更复杂

离线系统一天跑一次，出问题第二天才知道。实时系统不行，问题必须分钟级发现、秒级响应。

我建议实时数据SLA配套的监控体系要覆盖三个维度：

• 端到端延迟：从数据产生到消费，全链路打点
• 数据质量：丢失率、重复率、乱序率
• 系统容量：吞吐量、积压量、资源使用率

好了，这一节就到这里。SLA、SLO、SLI的区别，以及实时数据的特殊性，心里有数了吧？后面我们会一步步深入，讲怎么设计这些指标、怎么落地、怎么兜底。