可用率是怎么测出来的：本站的统计口径与局限

先说局限性

1. 测量点单一 —— 从本站服务器测，不代表你的网络环境
2. 按天判定 —— 一天内的多次采样聚合成一个「天」的判断，粒度较粗
3. 样本需要积累 —— 站点刚上线时样本不足，此时展示的是公开数据集基线
4. 只测可达性 —— 不测输出质量、不测是否降级

看到「96.7%」时，应该理解为「在这套口径下的可达比例」，而不是「这家站有 96.7% 的时候好用」。

口径详解

按天判定，不是按请求

可用率 = 可达天数 / 总天数

「可达」指：当天至少有一次探测成功。

为什么这样设计：如果按请求算，一个站的可用率会趋近 100%（因为多数请求是成功的），数字拉不开差距，没有区分度。

按天判定能让「挂过一整天」和「从没挂过」区分开。

副作用：数值会很集中（没有站能到 99.9%）。所以本站设了稳定性分档作为主信号：

看分档比看精确数字更有意义 —— 96.7% 和 96.5% 的差别没有实际意义，但「稳定」和「波动」的差别有。

数据来源会标注

为什么要有这个标注：本站的原则是「实测值」与「外部数据」分开呈现。把外部数据说成自己的实测值，是一种常见但有害的做法。

样本积累到一定数量后，展示口径会自动切换为「本站实测」。

为什么样本需要积累

一个刚上线的监测系统，如果第一天就用「1 次采样」去算可用率，结果必然是：

1 次成功 → 100%
1 次失败 → 0%

这两个数字都是失真的。所以本站设了最小样本阈值，未达到时保留公开数据集基线并标注来源。

这也意味着：某站显示「数据来自公开数据集」不代表它有问题，只代表我们的样本还不够。

你该怎么用这些数据

可以用的：横向比较稳定性分档（同口径下的相对排序是有效的）；观察分档随时间的变化（变差是信号）。

不宜直接用的：把可用率当作 SLA 承诺（它是观测值，不是承诺）；用单次延迟数值下结论；跨口径比较。

更可靠的做法

如果你的业务对可用性要求高，不要只依赖任何第三方的监测数据（包括本站）：

一、自建轻量探针。 从你自己的服务器每隔几分钟请求一次，记录成功率。这个数据的相关度最高 —— 因为它测的是「你的链路」。

二、和本站数据交叉看。 如果你自测的失败率明显高于本站数据，说明问题可能在你这一侧的网络。

三、关注趋势而不是绝对值。 一个站从「稳定」掉到「波动」，比它当前处于哪个档位更值得关注。

相关阅读

• 中转站的「响应延迟」该怎么看
• 给中转站做一次体检：20 分钟可完成的验证清单
• 选型之后：怎么持续监控你的 API 供应商