4、SLA制定流程：需求调研、指标定义、基线测量、目标设定、评审发布
好，咱们进入正题。SLA 制定这件事，说白了就是跟业务方签一份「数据服务军令状」。我见过太多团队一上来就拍脑袋定指标，结果上线不到两周就被投诉打脸。为什么会这样？因为跳过了最关键的几个步骤。
我个人习惯把 SLA 制定拆成五个阶段：需求调研 → 指标定义 → 基线测量 → 目标设定 → 评审发布。这五个阶段环环相扣，少一个都不行。你想想看，连业务方到底要什么都不知道，你怎么定指标？连当前水平都没摸清，你怎么设目标？
核心原则：SLA 不是运维单方面定的，是跟业务方「谈」出来的。谈之前，你得有数据、有底线、有预案。
4.1 需求调研：别急着定指标，先搞清楚业务到底要什么
这一步最容易被忽略。很多团队上来就问「你的 SLA 要几个 9？」——这是典型的错误姿势。业务方可能连「可用性」是什么都不清楚，你问他几个 9，他只能随口说个 99.9%。
我在项目中遇到过这样的情况：某业务方要求「数据延迟不超过 5 分钟」。我们吭哧吭哧优化了三天，结果人家说「其实我们只是希望每天早上 9 点前能看到昨天的报表」。你看，真实需求是 T+1 的时效性，不是 5 分钟延迟。
需求调研的核心产出是一份 SLA 需求清单，至少包含以下内容：
| 调研维度 | 关键问题 | 常见误区 |
|---|---|---|
| 业务场景 | 数据用在什么环节？决策/报表/实时风控？ | 把「想要」当「需要」 |
| 使用时段 | 7×24 小时还是仅工作时间？ | 默认全天候，实际用不上 |
| 容忍度 | 能接受多长时间的不可用？ | 说「不能断」，实际能忍 30 分钟 |
| 数据新鲜度 | 需要实时、小时级还是天级？ | 盲目追求实时，成本翻倍 |
| 数据完整性 | 允许丢数据吗？丢多少能接受？ | 要求 100% 完整，不现实 |
我的小技巧：调研时别只问「你要什么」，多问「如果做不到会怎样」。这能帮你判断哪些是真正的底线，哪些是「最好有」的期望。
4.2 指标定义：把模糊的期望变成可测量的数字
需求调研完了，你手里有一堆「快一点」「稳一点」「别丢数据」之类的描述。现在要做的，是把这些翻译成技术指标。
我个人习惯用 SLA 指标矩阵 来梳理。说白了，就是给每个业务需求找到对应的量化指标：
- 可用性：服务正常运行时间 / 总时间。注意区分「系统可用」和「数据可用」。
- 时效性：数据从产生到可被查询的时间差。常见的有「延迟不超过 X 分钟」。
- 完整性：成功写入的数据量 / 应写入的数据量。注意去重和乱序处理。
- 准确性：数据值与真实值的偏差。这个最难定，通常用抽样校验。
- 吞吐量：单位时间内能处理的数据量。峰值场景要单独评估。
嗯，这里要注意：指标不是越多越好。我见过一个团队定了 15 个 SLA 指标，结果运维每天光看板子就花两小时，业务方也记不住。我的建议是：核心指标不超过 5 个，每个指标都要有明确的业务含义。
避坑指南：我曾经在一个项目中把「可用性」定义为「API 接口返回 200 的比例」。结果接口返回 200 了，但数据是空的——业务方照样投诉。后来我们改成「可用性 = 能返回有效数据的请求比例」。定义指标时，一定要跟业务方确认「什么算好，什么算坏」。
4.3 基线测量：没有数据，一切承诺都是空话
指标定义好了，别急着设目标。你得先知道当前水平在哪。基线测量的目的就是摸清家底。
我建议至少采集 2-4 周 的连续数据。为什么这么久？因为一周的数据可能覆盖不了周末的流量波动，两周才能看到一些周期性规律。如果遇到大促或活动期，最好单独标注。
基线测量要关注三个值：
- P50（中位数）：代表日常水平。比如延迟中位数 200ms。
- P95/P99：代表极端情况。P99 延迟 1s 意味着 99% 的请求在 1s 内完成。
- 最差值：历史上最差的表现。这个值决定了你的「保底承诺」不能低于它。
举个例子，我在一个实时数仓项目中测到的基线数据：
| 指标 | P50 | P95 | P99 | 最差值 |
|---|---|---|---|---|
| 数据延迟 | 30s | 2min | 5min | 12min |
| 可用性 | 99.95% | 99.8% | 99.5% | 98.2% |
| 完整性 | 99.99% | 99.9% | 99.5% | 97.8% |
看到最差值了吗？如果业务方要求可用性 99.9%，你得先问问自己：历史上最差是 98.2%，你凭什么承诺 99.9%？要么优化系统，要么调整预期。
核心观点：基线测量不是为了证明「我能做到」，而是为了告诉业务方「我现在在哪，我能承诺到什么程度」。诚实面对现状，比盲目承诺更受尊重。
4.4 目标设定：承诺要留有余地
基线数据出来了，现在可以定目标了。目标设定我建议分两档：
- SLO（服务等级目标）：日常追求的目标，比如延迟 P99 ≤ 1s。达不到要改进，但不一定触发处罚。
- SLI（服务等级指标）阈值：触发处罚或告警的硬线，比如延迟 P99 > 3s 持续 5 分钟算一次故障。
目标怎么定？我的经验公式是：
SLO = 基线 P95 × 0.8（比当前好一点，但别太激进）
SLI 阈值 = 基线最差值 × 1.2（留 20% 的缓冲空间）当然，这只是参考。如果业务方确实需要更高的标准，那就得配套投入资源。我在项目中遇到过业务方要求「延迟不超过 10s」，但基线 P95 是 30s。最后我们谈的结果是：第一版 SLO 定 20s，同时给一个月时间优化，优化到位后再调整到 10s。
我的建议：目标设定时，一定要跟业务方说清楚「承诺的代价」。你要 99.99% 的可用性？可以，但成本可能是 99.9% 的三倍。让业务方自己做权衡，而不是你单方面拍板。
4.5 评审发布：让 SLA 真正落地
目标定好了，别急着发邮件。评审发布这一步，是 SLA 能否真正执行的关键。
评审环节我建议至少包含三方：
- 业务方：确认指标和阈值是否满足真实需求。
- 数据团队：确认技术可行性，评估改造成本。
- 运维/稳定性团队：确认监控告警是否到位，故障响应流程是否就绪。
评审通过后，发布时要包含以下内容：
- SLA 文档：指标定义、测量方式、目标值、处罚条款。
- 监控看板：实时展示 SLA 达标情况，业务方能自己看。
- 告警规则：接近阈值时提前告警，别等超了才通知。
- 故障响应流程：谁负责处理？多长时间内响应？升级路径是什么？
我曾经犯过一个错：SLA 文档写得漂漂亮亮，但监控没跟上。结果第一个月复盘时，发现有一半的指标根本没法准确测量。后来我们定了一条铁律：SLA 发布前，监控必须先上线。
避坑指南：评审时别只走形式。我见过一个团队评审会开了 10 分钟就过了，结果上线后业务方说「这个指标我不认，当时没看清楚」。后来我们改成：评审会必须有业务方签字确认，并且留 3 个工作日的「冷静期」，期间任何一方可以提出异议。
好了，这五个阶段走下来，一份靠谱的 SLA 基本就成型了。记住：SLA 不是一锤子买卖，它需要持续迭代。业务变了、系统变了、数据量变了，SLA 也得跟着变。下一阶段我们会聊怎么监控和运营 SLA，但那是后话了。