API 可用率怎么算？看懂 SLA、成功率与故障期间的计费

API Reliability and Uptime: SLA, Success Rate and Billing on Failure

成功率的三种算法与陷阱

错误算法①：全部请求算分母——你的程式 bug 会拉低服务商分数。错误算法②：只算成功——故障被掩盖。正确：分母 = 抵达上游的请求，剔除 client 类错误（参数问题）；分子 = 服务端成功完成。

另一个陷阱：样本不足时报 0%。凌晨无流量显示「可用率 0%」是吓人又失真的——正确做法是回「无样本」。

故障期间的计费政策

这是最能看出服务商诚信的地方。政策应该是：上游故障的失败请求（401/403/500/逾时等）不计费、0 token 记录在案；你的程式参数错误（400）也不该被收费。OlithmRouter 的错误分类体系区分 client／billing／upstream，帐务上故障请求 0 费用。

怎么监控自己的依赖

不要只靠服务商的仪表板：①在程式端记录每次呼叫的 request_id 与延迟；②对照服务商日志；③设置简单的 synthetic 探测（每分钟一个小请求）建立自己的 SLA 历史。故障发生时，你手上要有双方数据。

恢复速度比故障频率更重要

服务一定会偶尔故障，差异在 MTTR（平均恢复时间）：有自动换家的服务商，单上游故障时你完全无感；没有的话每次故障都是一次事故。OlithmRouter 的多上游＋冷却设计，让多数上游级故障对使用者透明。

常见问题

99%+ 可用率代表什么？

代表按剔除口径统计的稳定分组成功率长期在 99% 以上；具体定义以服务商公开说明为准。

故障期间我损失的时间能赔吗？

技术上故障请求不计费已是标准做法；现金赔偿要看服务条款。更重要的是选有自动换家的服务商，从源头减少可感知故障。

怎么区分是我的问题还是服务商的？

看错误分类与 request_id：client 类（参数、余额）是你侧；upstream 类（401/403/5xx/逾时）是服务端。OlithmRouter 日志明确标注分类。

可用率资料能汇出吗？

OlithmRouter 控制台提供成功率统计与日志筛选汇出，可作为你的 SLA 对帐依据。

相关文章