1. SLA 基础概念：特征平台的定海神针
大家好，我是老赵。今天咱们聊聊特征平台 SLA 那些事儿。
很多人一听到 SLA、SLO、SLI 就头大，觉得这是运维团队搞出来的概念游戏。其实不然。我在一线摸爬滚打这么多年，见过太多因为 SLA 没定义清楚导致的线上事故。说白了，SLA 就是你和用户之间的一纸契约——你承诺提供什么水平的服务，用户据此决定是否信任你。
1.1 什么是 SLA？
SLA，全称 Service Level Agreement，服务等级协议。它是一份正式约定，明确了服务提供方（比如特征平台团队）和服务消费方（比如推荐算法团队）之间的责任边界。
举个例子。我负责的特征平台承诺：特征查询接口的月度可用性不低于 99.9%，单次查询 P99 延迟不超过 50ms。这就是一份典型的 SLA 条款。
核心要点：SLA 不是技术指标，而是商业承诺。它背后往往有赔偿条款、升级流程和沟通机制。
1.2 SLA、SLO 与 SLI 的区别
这三个概念经常被混用，但它们的层次完全不同。我习惯用一个比喻来解释：
- SLI（Service Level Indicator）——仪表盘上的读数。比如“过去 5 分钟特征查询的平均延迟是 32ms”。
- SLO（Service Level Objective）——你给自己定的目标。比如“P99 延迟要保持在 50ms 以内”。
- SLA（Service Level Agreement）——对外公布的承诺。比如“月度可用性 99.9%，否则退还 10% 费用”。
你看，SLI 是原始数据，SLO 是内部目标，SLA 是外部契约。三者的关系可以用下面这张图来理解：
我的经验：很多团队只盯着 SLA 看，忽略了 SLO 的日常管理。我建议把 SLO 设得比 SLA 更严格——比如 SLA 承诺 99.9%，SLO 就定 99.95%。这样即使 SLO 偶尔被突破，SLA 依然安全。
1.3 特征平台为什么需要 SLA？
这个问题我问过不少刚入行的同学。有人说“为了考核”，有人说“为了追责”。这些都对，但不够本质。
特征平台是机器学习基础设施的核心组件。它负责生产、存储、分发特征数据。一旦出问题，影响的是下游所有模型推理和训练任务。我经历过一次特征延迟事故，导致推荐系统用了过时特征，线上 CTR 掉了 15%，花了整整两天才恢复。
特征平台需要 SLA 的原因有三：
- 依赖链太长——一个特征可能被几十个模型使用，出问题就是雪崩效应。
- 数据时效性敏感——特征过期几分钟，模型效果可能就大打折扣。
- 排障成本高——没有 SLA 基线，你根本不知道“正常”是什么样，出了问题也无从对比。
避坑指南：我曾经见过一个团队，上线特征平台半年都没定义 SLA。结果每次出故障，算法团队和平台团队互相甩锅。后来花了两个月才把 SLA 补上，但信任已经受损了。记住：SLA 不是用来限制你的，是用来保护你的。
1.4 常见的特征服务 SLA 指标
特征平台的 SLA 指标和其他在线服务有相似之处，但也有自己的特色。我整理了一张常用指标表：
| 指标类别 | 指标名称 | 典型 SLO | 说明 |
|---|---|---|---|
| 可用性 | 服务可用率 | ≥ 99.9% | 特征查询接口的正常响应比例 |
| 延迟 | P99 查询延迟 | ≤ 50ms | 最慢的 1% 请求的响应时间 |
| 延迟 | P50 查询延迟 | ≤ 10ms | 半数请求的响应时间，反映典型体验 |
| 准确性 | 特征值正确率 | ≥ 99.99% | 返回的特征值与预期一致的比例 |
| 时效性 | 特征新鲜度 | ≤ 5min | 特征从产生到可查询的最大延迟 |
| 吞吐量 | QPS 达标率 | ≥ 设计容量的 80% | 实际吞吐与设计容量的比值 |
| 数据完整性 | 特征覆盖率 | ≥ 99.9% | 请求的特征中成功返回的比例 |
这里我想特别强调一下特征新鲜度这个指标。很多团队只关注延迟和可用性，忽略了特征的新鲜度。但你想，如果推荐模型用的特征是 30 分钟前的用户行为，而用户已经浏览了新内容，那推荐结果肯定不准。我见过一个案例，特征新鲜度从 2 分钟退化到 15 分钟，模型 AUC 直接掉了 0.03。
核心原则：特征平台的 SLA 指标必须覆盖“能不能用”（可用性）、“快不快”（延迟）、“准不准”（准确性）、“新不新”（时效性）四个维度。缺一个，你的 SLA 就是不完整的。
1.5 如何制定合理的 SLA 目标？
制定 SLA 不是拍脑袋。我一般遵循以下步骤：
- 第一步：收集历史数据——至少回顾过去 3-6 个月的线上表现，找到各项指标的基线。
- 第二步：对齐业务需求——和算法团队、产品团队沟通，了解他们对延迟、新鲜度的真实容忍度。
- 第三步：设定 SLO 缓冲区——SLO 要比 SLA 严格 10%-20%，给自己留余量。
- 第四步：定义测量方式——明确用什么工具、什么粒度、什么窗口来测量 SLI。
- 第五步：建立告警和升级机制——SLO 被突破时谁负责处理，SLA 被突破时如何赔偿。
嗯，这里要注意一点：SLA 不是越严格越好。我见过有人把 SLA 定到 99.999%，结果为了达到这个目标，团队投入了 80% 的精力在冗余和容灾上，反而没时间做功能迭代。说白了，SLA 要匹配业务价值，不是炫技。
我的建议：刚开始做特征平台 SLA 的团队，先定 99.9% 可用性 + P99 50ms 延迟 + 5 分钟新鲜度。跑两三个月，根据实际表现再调整。别一上来就追求五个九，那是大厂才玩得起的游戏。
好了，这一章的内容就到这里。SLA 是特征平台保障的基石，后面的章节我们会深入每个指标的监控和实现细节。记住：没有 SLA 的特征平台，就像没有仪表盘的飞机——你敢飞，乘客可不敢坐。