2. SLA 关键指标设计：可用性、性能、容量与安全

指标设计是 SLA 的骨架。我见过太多团队把 SLA 写成「保证系统稳定运行」这种空话，结果一出故障双方扯皮。说白了，指标必须可测量、可验证、可问责。这一章我们拆开揉碎了讲四个核心维度。

2.1 可用性指标：99.9% 到底意味着什么？

可用性是最常见的 SLA 指标。但很多人只写一个数字，不写计算口径。我遇到过一家客户，合同写 99.9%，结果故障 8 小时他们说不算，因为「维护窗口不计入」。嗯，这就是口径没定死的后果。

2.1.1 可用性计算公式

可用性 = (总时间 - 不可用时间) / 总时间 × 100%

这里的关键是「不可用时间」怎么定义。我个人习惯用 服务完全不可用 作为基准，部分功能降级不算。但有些场景需要更细的粒度，比如按请求成功率算。

2.1.2 常见可用性等级与容忍停机时间

2.1.3 可用性计算口径的坑

• 维护窗口是否计入？ 我建议明确写「计划内维护不计入不可用时间」，但维护窗口要有上限（比如每月不超过 2 小时）。
• 部分故障怎么算？ 比如 10 个节点挂了 1 个，算 10% 不可用还是 100%？我个人习惯按影响用户比例算。
• 第三方依赖故障？ 如果因为云厂商挂了导致你不可用，算谁的？最好在 SLA 里写清楚「第三方不可抗力除外」。

2.2 性能指标：响应时间与吞吐量

性能指标是用户最直观的感受。你想想看，一个页面 3 秒打不开，用户早就跑了。但性能指标不能只写一个平均值，那会掩盖很多问题。

2.2.1 响应时间

响应时间通常用 百分位 来描述，而不是平均值。为什么？因为平均值会被极端值拉偏。比如 99% 的请求 100ms，但 1% 的请求 10s，平均值才 199ms，看起来很好，实际上那 1% 的用户已经炸了。

2.2.2 吞吐量

吞吐量是系统在单位时间内能处理的请求数。常见单位有 QPS（每秒查询数）、TPS（每秒事务数）、RPS（每秒请求数）。

吞吐量指标要注意 峰值 vs 均值。我见过一个案例，合同写「系统支持 1000 QPS」，结果双十一流量冲到 5000 QPS，系统直接挂了。后来我们加了「峰值容忍」条款：允许 10% 的时间超过阈值，但不超过 2000 QPS。

吞吐量指标示例：
- 正常负载：平均 1000 QPS
- 峰值负载：最大 3000 QPS，持续不超过 5 分钟
- 限流策略：超过 3000 QPS 时返回 429 状态码

2.3 容量指标：别等爆了才想起来

容量指标经常被忽略。你想想看，系统平时跑得好好的，突然用户量翻倍，结果 OOM 了。这就是容量规划没做好。

2.3.1 核心容量指标

• 存储容量： 数据库、日志、文件存储的使用率。建议设置告警阈值，比如 70% 预警，85% 告警。
• 计算资源： CPU、内存、网络带宽的使用率。我习惯按「峰值使用率」来承诺，比如「CPU 峰值不超过 80%」。
• 连接数： 数据库连接、Socket 连接、线程数。很多故障都是连接数打满导致的。

2.3.2 容量规划示例

容量指标承诺：
- 存储使用率：不超过 70%（自动扩容触发阈值为 80%）
- CPU 峰值：不超过 75%（持续 5 分钟以上触发告警）
- 数据库连接数：不超过最大连接数的 60%
- 网络带宽：不超过 1 Gbps（峰值不超过 2 Gbps）

2.4 安全指标：合规与防护

安全指标在 SLA 里越来越重要。尤其是金融、医疗、政务行业，合规是硬门槛。我参与过一个政务云项目，SLA 里专门写了「等保三级合规」，不达标直接扣款。

2.4.1 常见安全指标

2.5 知识体系总览

下面这张图把四个维度的关键指标串起来了。你可以把它当作设计 SLA 时的检查清单。

2.6 指标设计的三个原则

最后分享三个我踩坑总结出来的原则：

1. 可测量： 指标必须能通过工具自动采集。别写「用户体验良好」这种主观描述。我见过一个 SLA 写「系统响应迅速」……这怎么量化？
2. 可验证： 双方都能用同一套数据验证。最好约定数据来源，比如「以 Prometheus 采集的数据为准」。
3. 可问责： 不达标要有明确的后果。比如「月度可用性低于 99.9% 时，退还当月 10% 服务费」。