SLA、SLO、SLI 有什么区别？（附写好 SLA 的 5 个建议）
SLA 是服务商与客户的协议，SLO 是服务在指定时间窗内的目标，SLI 是衡量服务表现的指标。SLO 可以独立于 SLA 存在。本文讲清三者关系、各自的常见坑、企业到底要不要 SLA，以及服务商写好 SLA 的 5 条实操建议。
三句话先讲清三者关系：
- SLA（服务等级协议）：服务商与客户之间的正式协议，写明服务承诺。例如"月度可用性不低于 99.99%，工作日客服 24 小时内响应"；
- SLO（服务等级目标）：为服务指标设定的目标及评估时间窗。例如“月度可用性不低于 99.99%”。SLO 可以是内部目标，不必写入 SLA；
- SLI（服务等级指标）：衡量服务表现的指标及测量口径，例如“成功请求数 / 有效请求总数”。99.90% 是这个指标在某个时间窗内的测量值。是否达到 SLO，要用约定的同一时间窗比较；是否触发 SLA 后果，还取决于合同的计算规则、范围和例外。
SLA：一纸有赔偿条款的合同
SLA 覆盖服务商对产品性能和功能的承诺。可用性是最常见的条款，违约后果通常是服务抵扣金（Service Credit）——按约定抵扣后续服务费用，具体比例和申请条件取决于合同；也可能另有合同约定的赔偿或延长服务期。
一份标准 SLA 的结构：
- 服务范围：提供什么服务；
- 义务条款：有效期内必须达成哪些 SLO；
- 度量方式：用哪些 SLI 衡量、如何测量、报告频率与颗粒度；
- 时效：协议有效期、审计与重新谈判的时间点；
- 罚则：不达标时双方承担什么后果。
SLA 的两个常见坑
- SLO 定义含糊：什么叫"宕机"？页面完全打不开算宕机，那慢到无法正常工作算不算？定义不清，出纠纷时各说各话；
- 条款脱离真实用户：SLA 往往是法务、销售、采购、技术多方妥协的产物，而大多数参与制定的人根本不会用这个服务。制定 SLA 必须让最终使用者的需求占主导地位。
SLO：有时间窗的服务目标
SLO 是服务团队要自我考核的靶子，也可以被写入 SLA 对外承诺；没有 SLA 的服务同样可以设置 SLO。对于成功率类 SLI，99.9% 的目标允许同一评估窗内有 0.1% 的有效请求不成功，这部分就是错误预算（error budget）。请求比例不能直接换算成停机分钟数；只有按时间统计的可用性目标，才适合在相同口径下计算允许中断时长。
SLO 的最大问题：定义细节
"月度可用性 ≥ 99.95%"好写，"可用性到底怎么算"难定。举个假设例子：如果一份协议规定，只有连续 10 分钟以上、超过 10% 的请求返回 HTTP 500 的时段才计入宕机——也就是说 502 错误不算、8% 错误率不算、9 分钟的中断也不算。这就是为什么要用大白话把每个 SLO 的精确口径写死。
SLI：先定义怎么测，再比较测量值
SLI 要先说明什么算成功、分母包含哪些请求、从哪里采集、如何处理缺失数据，再给出测量结果。短时间窗内低于目标，不等于整个月的 SLO 已经失败，更不能直接推导出 SLA 违约。客户端、服务端和外部拨测各有覆盖范围；采样、探测位置和数据缺失都可能影响结果。SLO 口径含糊，SLI 的测量必然扯皮。
SLA 到底要不要有？
**不是必需品。**很多广泛使用的企业级软件根本没有 SLA。分视角看：
对服务商：要不要提供 SLA 主要看客户体量。大客户有采购部门和硬性采购规范，没 SLA 单子签不下来；而年费几千块的小单子（刷公司卡就买了）通常不需要 SLA。
对采购方：别被罚则条款迷了眼。评估 SLA 要花法务、财务、DevOps 多方时间；带 SLA 的采购流程也更长。更重要的是——有些厂商 SLA 平平但服务极其稳定，有的厂商 SLA 漂亮但故障频发。你要的是可用的服务，不是抵扣券。买之前翻对方状态页上的历史可用性记录，比研究罚则条款有用得多。大额、长约、新供应商这三种情况，SLA 的确定性价值才真正显现。
写好 SLA 的 5 个建议（给服务商）
- 围绕客户痛点写：对开发团队，"可用性"是服务器响应、验证码服务等 5 个组件的组合；对客户，"可用性"只意味着"能用/不能用"。把复杂的后端口径收敛成客户视角的简单结果指标，客户看得懂，开发团队的责任边界也更清晰；
- 用简单的语言：抛弃法律腔，用大白话写。语言越简单，未来扯皮越少；
- 别把能测的指标都塞进去：客户真正在乎的就那几个。能测不等于要写进协议——无关紧要指标只会稀释重点、增加违约面；
- SLO 承诺留有余量：承诺值要保守，低于你的实际能力。把内部目标定在 99.95%，对外承诺 99.9%，留出缓冲带，别顶着极限签协议；
- 把不可控因素写成例外条款：例如客服响应时效，如果需要客户提供排查信息后才能处理，这类等待时间必须明确排除在 SLA 计时之外，否则响应时长永远说不清。
用数据支撑 SLA 的签与守
SLA 的底气来自测量能力。观测云**可用性监测（云拨测）**从用户视角持续测量可用率与故障时长，提供所选探测位置和频率下的可用性数据；监控器与事件时间线可以辅助追踪故障与响应过程。它们可以支撑内部 SLO 评估，但不会自动成为合同认可的 SLA 履约凭证，测量口径与保留方式仍需提前约定。 1 2
常见问题（FAQ）
Q：SLO 和 SLA 必须先有哪个？
通常先定义并验证 SLI 与 SLO，再决定哪些目标写入 SLA；这是一种降低承诺风险的做法，并非必须遵循的固定顺序。SLO 不需要依赖 SLA 才能成立。
Q：内部 SLO 和对外 SLA 数值一样吗？
可以一样，也可以不同。常见做法是在相同测量口径和时间窗下，把对外目标定为 99.9%、内部目标定为 99.95%，为对外承诺留出余量；不同口径下的两个百分比不能直接比较。
Q：SLI 用什么工具测才算数？
关键不是工具名称而是口径：可以采用服务端计数、客户端观测或外部拨测，具体取决于要测的用户体验及覆盖边界；双方需事先认可测量方法。这些写进 SLA 的"度量方式"章节。
Q：客户要求我们赔偿 SLA 里没有的项目怎么办？
先核对主合同、其他适用条款和该 SLA 的范围，再由商务与法务评估。SLA 没有写明某项后果，不能据此断定整份合同都不涉及它。
