软件SLA介绍（Service Level Agreement，服务等级协议）（可签约SLA：服务提供方（厂商）与客户之间，就服务质量达成的可量化承诺协议）SLO服务目标、SLI服务指标、吞吐量
文章目录
- 软件 SLA 是什么？一文讲清“可签约 SLA”的本质与落地
- 一、什么是 SLA？
- 二、什么是“可签约 SLA”？
- 1️⃣ 指标可量化
- 2️⃣ 有明确统计口径
- 3️⃣ 有违约责任（关键！）
- 三、SLA vs SLO vs SLI（一定要分清）
- 四、软件 SLA 常见指标
- 1️⃣ 可用性（Availability）
- 2️⃣ 响应时间（Latency）
- 3️⃣ 吞吐量（Throughput）
- 4️⃣ 错误率（Error Rate）
- 5️⃣ 支持与响应（Support SLA）
- 五、SLA 是怎么签的？
- Step 1：定义服务范围（Scope）
- Step 2：确定指标
- Step 3：约定例外（Exclusions）
- Step 4：定义违约责任
- 六、SLA 的技术落地（重点）
- 1️⃣ 监控体系（Observability）
- 2️⃣ 高可用架构
- 3️⃣ 容灾设计
- 4️⃣ 故障处理机制
- 5️⃣ Error Budget（错误预算）
- 七、常见误区
- ❌ 误区1：SLA = 系统稳定
- ❌ 误区2：写越高越好
- ❌ 误区3：只关注可用性
- ❌ 误区4：没有罚则
- 八、总结
- 九、附：一个简单的 SLA 示例
软件 SLA 是什么？一文讲清“可签约 SLA”的本质与落地
在企业级软件、云服务、AI平台甚至外包开发中，经常会听到一个词：SLA。很多人知道它和“服务质量”有关，但一旦涉及“可签约 SLA”，就容易模糊。
这篇文章带你从工程和商业两个视角，把软件 SLA 的定义、指标、签约方式以及落地方法彻底讲清楚。
一、什么是 SLA？
SLA（Service Level Agreement，服务等级协议），本质上是：
服务提供方（厂商）与客户之间，就服务质量达成的可量化承诺协议。
它不是一句“我们会尽量稳定”，而是：
👉可测量 + 可验证 + 可追责
二、什么是“可签约 SLA”？
很多团队说“我们有 SLA”，但其实只是内部目标（SLO）。
真正的可签约 SLA必须满足三点：
1️⃣ 指标可量化
例如：
- 系统可用性 ≥ 99.9%
- API 响应时间 ≤ 200ms（P95）
- 故障恢复时间 ≤ 30 分钟
2️⃣ 有明确统计口径
例如：
- 可用性如何计算？（按分钟？按请求？）
- 是否包含计划维护时间？
- 数据来源是谁？（监控系统还是客户侧）
3️⃣ 有违约责任（关键！）
例如：
- 未达标 → 服务费返还 10%
- 严重故障 → 赔偿 SLA credits
- 多次违约 → 客户可解约
👉 没有赔偿条款的 SLA，本质只是“口头承诺”。
三、SLA vs SLO vs SLI（一定要分清）
很多人混淆这三个概念：
| 概念 | 含义 | 面向谁 |
|---|---|---|
| SLA | 服务等级协议（合同） | 客户 |
| SLO | 服务目标（内部目标） | 团队 |
| SLI | 服务指标（测量方式） | 系统 |
举个例子：
- SLI：API 成功率
- SLO：成功率 ≥ 99.95%
- SLA：写进合同，并附带赔偿条款
四、软件 SLA 常见指标
1️⃣ 可用性（Availability）
最核心指标：
Availability = (总时间 - 故障时间) / 总时间常见等级：
| 等级 | 可用性 | 每月可容忍故障 |
|---|---|---|
| 99% | 两个9 | ~7小时 |
| 99.9% | 三个9 | ~43分钟 |
| 99.99% | 四个9 | ~4分钟 |
2️⃣ 响应时间（Latency）
常见写法：
- P50 / P95 / P99
- API ≤ 200ms（P95）
👉 为什么不用平均值？
因为平均值会掩盖长尾问题。
3️⃣ 吞吐量（Throughput）
例如：
- 系统支持 ≥ 10,000 QPS
- 并发用户 ≥ 5,000
4️⃣ 错误率（Error Rate）
例如：
- 错误率 ≤ 0.1%
- 5xx 比例 ≤ 0.05%
5️⃣ 支持与响应（Support SLA）
偏运维/服务：
工单响应时间：
- P1：15分钟
- P2：1小时
修复时间（MTTR）
五、SLA 是怎么签的？
典型流程如下：
Step 1：定义服务范围（Scope）
明确：
- 覆盖哪些系统/API？
- 是否包括第三方依赖？
- 是否包括网络/云厂商问题？
Step 2：确定指标
例如：
可用性：≥ 99.9%（按月） API延迟：≤ 300ms（P95） 故障恢复：≤ 1小时Step 3：约定例外（Exclusions）
常见坑点：
- 计划维护是否计入故障？
- 不可抗力（云厂商宕机）是否免责？
- 客户自身操作导致问题是否排除？
Step 4：定义违约责任
最常见形式：
SLA Credits（服务抵扣）
| 未达标程度 | 赔偿 |
|---|---|
| 99.9 → 99.5 | 10% |
| 99.5 → 99.0 | 25% |
| < 99.0 | 50% |
六、SLA 的技术落地（重点）
签 SLA 不难，难的是做到。
1️⃣ 监控体系（Observability）
必须具备：
- Metrics（Prometheus）
- Logs（ELK）
- Tracing（Jaeger）
2️⃣ 高可用架构
常见方案：
- 多副本部署（K8s）
- 负载均衡
- 自动扩缩容
- 灰度发布
3️⃣ 容灾设计
- 跨 AZ 部署（Availability Zone）
- 多区域（Multi-region）
- 数据备份 + 恢复演练
4️⃣ 故障处理机制
- On-call 轮值
- 自动告警
- Runbook（标准操作流程）
5️⃣ Error Budget（错误预算）
这是现代 SRE 的核心理念：
Error Budget = 允许失败的时间例如：
- 99.9% SLA → 每月允许 ~43分钟故障
👉 用于平衡：
- 稳定性 vs 发布速度
七、常见误区
❌ 误区1：SLA = 系统稳定
错。SLA 是“承诺”，不是“能力”。
❌ 误区2：写越高越好
99.99% ≠ 更高级
👉 成本会指数级上涨（infra + 人力）
❌ 误区3：只关注可用性
忽略：
- 延迟
- 错误率
- 用户体验
❌ 误区4：没有罚则
👉 那就不叫“可签约 SLA”。
八、总结
一句话总结：
SLA 是把“系统稳定性”变成“合同责任”的工程与商业结合体。
如果你是：
- ToB SaaS / AI 平台
- 外包开发团队
- 云服务提供商
👉 那么“可签约 SLA”几乎是必备能力。
九、附：一个简单的 SLA 示例
服务：AI 推理 API 可用性：≥ 99.9%（按月） 延迟：P95 ≤ 300ms 错误率：≤ 0.1% 支持响应： P1：15分钟内响应，1小时恢复 赔偿： 低于99.9% → 10%费用返还 低于99.5% → 25% 低于99.0% → 50%