2. SLA设计原则：SMART原则

聊SLA设计，绕不开SMART原则。这五个字母，说白了就是五个筛子——你定出来的每个SLA指标，都得拿它们过一遍。我见过太多团队，SLA写得像散文，结果上线第一天就崩了。为什么？因为指标根本没法落地。

SMART不是新概念，但在数据产品这个领域，它有自己的一套玩法。咱们一个一个拆开看。

2.1 S——明确性（Specific）

明确性，就是你的SLA不能有歧义。什么叫“系统稳定”？什么叫“查询性能良好”？这些词在SLA里就是毒药。

我建议你这么写：

• 错误写法：“数据查询速度要快。”
• 正确写法：“95%的查询在3秒内返回结果。”

你看，后者把“快”这个模糊概念，变成了一个可验证的数值。你想想看，如果SLA写成“快”，运维和业务方对“快”的理解能一样吗？

举个例子。你定一个“数据延迟不超过1小时”。这够具体吗？不够。你得说清楚：

• 延迟从哪个时间点开始算？（数据产生时间？还是数据到达时间？）
• 1小时是P99还是P95？
• 如果超过1小时，怎么算违约？

嗯，这里要注意。明确性不是让你写小作文，而是把边界画清楚。

2.2 M——可测量性（Measurable）

可测量性，是SMART里最容易被忽略的一条。很多团队定SLA时拍脑袋，定了才发现根本没法测。

我在项目中遇到过一件事。某次我们承诺“数据完整性达到99.9%”。听起来很漂亮对吧？但上线后才发现，我们根本没有工具去测量“完整性”。最后只能靠人工抽检，一个月下来，数据根本没法看。

所以，定SLA之前，先问自己：这个指标能测吗？怎么测？用什么工具测？

2.3 A——可达性（Achievable）

可达性，说白了就是别吹牛。我见过最离谱的SLA，是某团队承诺“数据实时性达到秒级”。结果他们的数据源是T+1的离线批处理。这不是搞笑吗？

定SLA时，你得考虑：

• 当前的技术能力能不能支撑？
• 团队资源够不够？
• 历史数据表现怎么样？

我个人的习惯是，先看过去3个月的实际表现。比如查询P99响应时间，过去3个月平均是2.8秒，那你定3秒是合理的。定1秒？那就是给自己挖坑。

你想想看，如果SLA定得太高，团队天天救火，最后指标还是完不成。业务方不满意，团队也累。何必呢？

2.4 R——相关性（Relevant）

相关性，就是你的SLA要跟业务目标挂钩。很多数据团队定的SLA，技术上看很漂亮，但业务方根本不关心。

举个例子。你承诺“数据仓库的CPU使用率不超过80%”。业务方会关心这个吗？不会。他们关心的是：报表能不能按时出？数据准不准？

所以，定SLA时，你得想清楚：这个指标对业务方意味着什么？

我建议你每次定SLA时，都拉上业务方一起过一遍。问问他们：这个指标你们用得上吗？如果他们说“无所谓”，那就砍掉。

2.5 T——时限性（Time-bound）

时限性，就是你的SLA得有截止时间。没有时间约束的SLA，等于没有SLA。

比如你承诺“数据质量问题会在发现后修复”。什么时候修复？没人知道。你得写成：

• P0级数据质量问题：2小时内响应，4小时内修复。
• P1级数据质量问题：4小时内响应，24小时内修复。
• P2级数据质量问题：24小时内响应，72小时内修复。

你看，有了时间约束，团队才知道优先级，业务方也知道什么时候能恢复。

2.6 SMART原则的落地框架

五个原则讲完了，但怎么落地？我画了一张图，把整个逻辑串起来。

这张图的核心逻辑很简单：每个SLA指标，都要从中心出发，经过五个原则的检验，最后才能落地。缺一个，指标就是瘸腿的。

2.7 一个完整的例子

说了这么多，咱们看一个完整的例子。假设你要定一个“数据报表查询”的SLA：

• S（明确性）：核心报表（日活、营收、留存）的查询P99响应时间不超过3秒。
• M（可测量性）：通过APM工具采集每个查询的响应时间，按天统计P99。
• A（可达性）：过去3个月P99平均2.5秒，最高2.8秒，3秒目标合理。
• R（相关性）：业务方每天看报表，3秒内出结果能提升工作效率。
• T（时限性）：按天统计，每月出SLA报告。如果连续3天P99超过3秒，触发告警。

你看，这样定出来的SLA，每个环节都经得起推敲。业务方看得懂，技术团队做得到，运维团队能监控。