航空界爱公布航班准点率，AI 服务平台则用 SLA 承诺可用性——两者本质相同，都是在用统计数字给可靠性背书。但很多人没意识到，这串数字怎么统计，比数字本身重要得多，同一个「99.9%」，口径不同，含金量天差地别。
先带走一个判断：看 SLA 别只看百分比，先看三个口径——统计周期多长、什么算失败、哪些时段被排除。三个口径看明白了，承诺才真正可比较。
先分清承诺口径和统计口径
承诺口径写在文档里，规定服务方承诺什么：比如「月度可用性不低于 99.9%」。统计口径则规定怎么验证这个承诺：以分钟还是以请求为单位统计、按服务端记录还是客户感知计数、整月滚动还是按自然月。两者常被混为一谈，实际差别很大——按分钟统计时，一秒钟的抖动可能完全不进分母；按请求统计时，同样的抖动会让成百上千个请求计入失败。接入 Kimi 或讯飞星火这类开放接口前，值得把两份口径都翻一遍。
一次请求算不算失败的分界
不是所有坏结果都计入失败，分界线通常画在这里：服务端明确返回错误（如 5xx）计入，客户端自身网络问题不计入，调用方超限被限流的不计入。灰区在于超时——响应慢但最终成功，有的口径按「成功」计，有的按「劣化」单独统计。分界标准必须写得可执行，让双方拿着同一条原始记录能得出同一个结论，否则出故障时必起争执。
四种情形里哪些计入失败，分界线就画在这里。
| 情形 | 是否计入失败 | 口径要点 |
|---|---|---|
| 服务端明确返回错误（如 5xx） | 计入 | 责任在服务端，双方拿同一条原始记录能得出同一结论 |
| 客户端自身网络问题 | 不计入 | 故障在调用侧，与服务水平无关 |
| 调用方超限被限流 | 不计入 | 触发原因在配额使用方式上，配额数据要透明可查 |
| 响应超时但最终成功 | 灰区，按口径归档 | 有的按成功计，有的单列为「劣化」统计 |
失败判定的原始依据同样来自网关与监控记录，告警侧怎么消费这些数据，见预算告警的阈值是怎么设的？内部门道在这。
时间窗口里的算法
最常见的算法有两个。按时间算：可用性 = (总分钟数 - 故障分钟数) / 总分钟数，故障分钟指判定为不可用的时段。按请求算：可用性 = 成功请求数 / 总有效请求数。按时间算对长故障敏感，按请求算对高峰期故障敏感——同样宕机十分钟，发生在凌晨三点与发生在午高峰，按请求算的损失差距悬殊。服务方偏好按时间算，流量大的客户常要求按请求算，价格谈判里常见的拉锯就在这一条。
故障分钟从哪来？从健康探测与自动切换的记录里来，故障被系统发现并记录的时刻起算，见容灾切换是怎么触发的？健康探测。
免责时段与补偿的关联
SLA 通常附带免责条款：预演维护窗口、客户侧网络异常、不可抗力时段不计入故障。这些时段要在文档里明确列出并提前公告，否则统计完成后容易各说各话。可用性不达标时的补偿，常见形式是服务时长返还或费用减免，按不达标程度分档执行——这也是为什么统计口径如此重要，它直接决定补偿是否触发、触发多少。
补偿承诺能否兑现，还受部署形态影响：私有化交付的服务，责任边界与运维分工见私有化的授权是怎么管的？关键步骤一次讲清；混合部署下哪些时段归谁管，见混合部署的数据分界是怎么划的？。
SLA 口径核对清单
- 统计周期：自然月还是滚动月，周期写明
- 失败定义：服务端错误计入、限流不计入、超时归档要明确
- 统计单位：按时间或按请求，两者的敏感点不同
- 免责时段：维护窗口是否提前公告
- 补偿分档：不达标程度与补偿形式的对应表
关于SLA可用性，问得最多的三个
- 99.9% 和 99.99% 差多少？：按自然月算，前者允许约 43 分钟不可用，后者只允许约 4.3 分钟，成本差距远超数字差距。
- 限流导致的失败算谁的？：通常算调用方的，因为触发原因在配额使用方式上，但配额数据要透明可查。
- 边缘节点参与统计吗？：看部署架构，边缘侧节点通常单独约定，它的算力约束带来的降级也单独统计，见边缘设备的算力约束是怎么应对的？。
