2. SLA 关键指标定义：可用性、延迟、吞吐量、错误率

聊 SLA，绕不开这四个核心指标。我见过不少团队，一上来就拍脑袋定个「四个 9」，结果监控一上线，发现根本不知道该怎么算。今天咱们把这四个指标掰开揉碎了讲清楚。

2.1 可用性指标

可用性是最直观的指标。说白了，就是系统在约定时间内能正常服务的比例。公式很简单：

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

举个例子。一个月 30 天，总分钟数是 43200 分钟。如果宕机了 43 分钟，可用性就是 (43200 - 43) / 43200 ≈ 99.9%。嗯，这就是我们常说的「三个 9」。

但这里有个坑。我曾经遇到一个团队，把「不可用时间」定义成「用户完全无法访问」。结果呢？系统返回 502 网关超时，持续了 15 分钟，他们觉得「网关层的问题，不算核心服务不可用」——这明显不对。

常见的可用性等级对照：

我个人习惯，在定义可用性 SLA 时，会同时约定「不可用判定窗口」。比如：连续 30 秒内错误率超过 5%，才计入不可用时间。避免偶发抖动就触发 SLA 赔付。

2.2 延迟指标

延迟，就是用户发出请求到收到响应的时间。你想想看，一个页面 3 秒才打开，就算可用性是 100%，用户照样骂娘。

延迟指标通常用百分位来衡量。为什么不用平均值？我举个例子：

• 100 个请求里，99 个 10ms 返回，1 个 10s 返回
• 平均值 ≈ 109ms，看起来还不错
• 但 P99 延迟是 10s，说明有 1% 的用户体验极差

所以，我建议重点关注这几个分位值：

• P50（中位数）：一半用户的体验，反映整体水平
• P95：95% 的用户都能达到这个水平，常用于对外 SLA
• P99：99% 的用户体验，核心链路必须盯
• P999：千分之一的长尾请求，排查性能瓶颈用

延迟的测量点也很关键。是从客户端发起到客户端收到？还是从网关到服务端返回？我建议分两层：

• 端到端延迟：用户真实感知，用于 SLA 承诺
• 服务端延迟：排除网络因素，用于性能优化

2.3 吞吐量指标

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

这三个概念容易混。我简单区分一下：

吞吐量不能只看峰值。我记得有一次做压测，系统峰值 QPS 能到 5000，但持续 10 分钟后就开始 OOM。为什么？因为峰值是瞬时冲上去的，但系统的稳态吞吐量只有 3000。

定义吞吐量 SLA 时，建议明确：

• 是峰值吞吐量还是稳态吞吐量？
• 持续多长时间算达标？（比如连续 5 分钟）
• 是否区分正常流量和突发流量？

2.4 错误率指标

错误率，就是失败请求占总请求的比例。公式：

错误率 = 错误请求数 / 总请求数 × 100%

但「错误」怎么定义？HTTP 5xx 算错误，4xx 算不算？我见过一个案例，团队把 4xx 也算进错误率，结果 SLA 天天报警。后来发现是爬虫在疯狂扫无效链接。

我个人建议这样分类：

• 5xx：服务端错误，必须计入 SLA
• 4xx：客户端错误，不计入 SLA，但要监控趋势
• 超时：客户端超时也算错误，哪怕服务端处理成功了
• 业务错误：比如「余额不足」这种业务码，看情况定

错误率的阈值怎么定？一般 SLA 承诺 0.1% 以内。但要注意，错误率是比例指标，低流量时容易失真。比如只有 10 个请求，1 个失败，错误率就是 10%。所以我会加一个「最小样本量」条件：请求量低于 1000 时，不触发 SLA 判定。

2.5 四个指标的关系

这四个指标不是孤立的。我画了一张图，帮你理清它们之间的关系：

你看，这四个指标是环环相扣的。可用性出问题，错误率必然飙升。用户重试又推高吞吐量，系统扛不住，延迟就上去了。最后可能演变成雪崩。

所以，我建议在定义 SLA 时，不要只盯一个指标。比如：

• 可用性 ≥ 99.9%
• P95 延迟 ≤ 200ms
• 稳态吞吐量 ≥ 3000 QPS
• 错误率 ≤ 0.1%

四个条件同时满足，才算 SLA 达标。任何一个突破阈值，都要触发告警和响应流程。