机场稳定性怎么记录？用固定采样计算真实可用率

机场宣传中的“稳定”很难靠一次测速证明。更有用的方法，是先定义什么算成功，再在固定时间点做小样本检查，用成功率和故障持续时间描述自己的真实可用性。

先定义一次成功请求

不要把“客户端显示已连接”当作成功。一次检查至少应完成：域名解析、TCP/TLS 连接、收到有效 HTTP 响应，并在限定时间内拿到一小段正文。目标地址应长期稳定、允许自动访问，测试文件不必很大。

建议把结果分成三类：成功；慢但成功；失败。慢的阈值按实际用途设定，例如网页首字节超过 3 秒、完整小文件超过 10 秒。失败则记录 DNS、连接、TLS、HTTP 或传输阶段，不要只写“不能用”。

连续测试一百次只覆盖几分钟，无法代表一天。可以在早晨、午间、晚高峰和深夜各测三次，连续记录七天。每次使用同一设备、网络、目标和客户端模式，并写下节点、时间、退出码和总耗时。

成功率计算为“成功次数 ÷ 总检查次数”。Google SRE 的可靠性资料指出，对部分可用或负载随时间变化的服务，用成功操作占比衡量可用性通常比只看一段停机时长更有意义。个人机场测试也可以借用这个思路，但样本规模较小，结果只代表你的接入条件。

一次失败时，先检查同节点的第二个目标，再切换备用节点，最后对照直连。若所有目标和节点都失败，问题可能在本地网络或客户端；若只有一个目标失败，不应算作机场整体不可用；若多个目标在同一节点失败而其他节点正常，才更接近节点级故障。

表格可包含：检查时间、节点、目标、成功/慢/失败、阶段、耗时、切换节点结果、恢复时间。恢复后补写故障持续分钟数，不要删除失败行。

月底比较不同机场时，先看晚高峰成功率，再看最长连续故障和恢复是否需要手工切换。99% 这样的数字只有在采样规则、总次数和失败定义公开时才有意义。样本太少时，直接写“84 次检查中成功 81 次”比写“稳定率 96.4%”更诚实。

验收标准是：采样计划覆盖至少七天；失败有分层原因；原始记录可复查；没有把目标站自身故障全部算给机场。这样的机场推荐结论更接近真实使用，而不是测速截图竞赛。