海鸥加速器线路优化：连续 30 天可用率 99.94%

2026 年 9 月 30 日，海鸥加速器公布 3.3.7 版本的稳定性数据：8 月 31 日至 9 月 29 日的 30 天里，12 组线路的综合可用率为 99.94%，单次故障平均恢复时间从 190 秒降到 12 秒。期间共发生 7 次线路级故障，均未传导到用户侧超过 20 秒。故障自动摘除与双路冗余是本次改动的核心。

稳定性问题的特点是小而频繁。7 月至 8 月的日志显示，线路级故障平均每周 2.1 次，单次持续 90 秒至 300 秒，多数由上游机房的路由震荡引起。用户侧的感受是一次突然的断连，通话中断，或者下载任务报错。真正不可用的时间只占 0.06%，但每一次都足以打断一场会议。

傅野（运维值班负责人）：“可用率 99.9% 听起来很好，摊到一个月也有 43 分钟。目标不是把数字写好看，而是让那 43 分钟不落在用户正在用的那一秒。”

故障自动摘除的上线

旧流程依赖人工判断。监控告警触发后，值班人员登录面板查看链路状态，确认是单线路问题还是上游整体故障，再手动把线路从调度池里摘掉。这个过程平均耗时 190 秒，其中 60 秒用于确认告警不是误报。摘除之前，新连接仍在往故障线路上分配。

新流程把判断交给探测网络。每条线路部署 3 个探测点，每 5 秒发起一次握手并请求一个 4KB 的测试文件，连续 2 次失败即判定为不可用，自动从调度池摘除并标记 30 分钟。30 分钟内探测恢复的，线路自动回归；未恢复的，转入人工排查。误判由第 3 个探测点的结果交叉校验。

双路冗余解决的是单点故障。香港与东京两组主用线路各自接入两个不同的上游机房，BGP 路由同时宣告，任一上游中断时流量在 8 秒内切到另一条。9 月的 7 次故障里有 4 次属于上游单点中断，用户侧完全没有感知，只在内部日志留下一条 8 秒的切换记录。

表 1：7 次线路故障的处置记录（2026-08-31 至 2026-09-29）

日期	故障类型	影响线路	恢复耗时
09-03	上游路由震荡	香港 · 03	8 秒（自动切换）
09-07	机房链路中断	东京 · 02	11 秒（自动摘除）
09-11	探测超时	新加坡 · 01	9 秒（自动摘除）
09-16	上游路由震荡	洛杉矶 · 05	14 秒（自动切换）
09-21	证书更新失败	香港 · 07	18 秒（人工介入）
09-25	带宽打满	东京 · 02	12 秒（自动摘除）
09-28	上游路由震荡	首尔 · 01	10 秒（自动切换）

30 天可用率与恢复时间

可用率的统计口径为：每条线路按分钟采样，1 分钟内探测成功率低于 90% 记为不可用，把不可用分钟数除以当月总分钟数，得到单线路可用率，再按并发权重加权得到综合值。9 月的不可用分钟合计 26 分钟，占比 0.06%，对应可用率 99.94%。去年同期的口径相同，数值为 99.61%。

恢复时间的中位数是 10 秒，95 分位是 18 秒，最长一次 18 秒出现在 9 月 21 日的证书更新失败。该故障涉及人工介入，自动摘除把线路移出调度池用了 11 秒，剩余 7 秒用于替换证书。故障期间受影响的连接数为 214 条，其中 187 条在 20 秒内自动重连成功。

需要说明的是，99.94% 不含用户本地网络故障。客户端侧统计显示，同期用户侧断连的原因中，本地 Wi-Fi 切换占 41%，移动网络信号弱占 23%，线路故障占 6%，其余为设备休眠与手动断开。线路故障在用户感知的断连里占比不高，但单次影响时长最长。

三类故障的处置与后续计划

第一类是上游路由震荡，处置方式是双路冗余加自动切换，目标是用户无感。第二类是机房链路中断，处置方式是自动摘除加流量再分配，用户会经历一次 10 秒左右的重连。第三类是配置类故障，比如证书过期与规则错误，这类无法靠探测完全覆盖，仍需人工介入，但自动摘除能先把影响面收住。

下一步计划有三项。一是把探测间隔从 5 秒缩短到 3 秒，把自动摘除的判定时间压到 6 秒以内。二是把双路冗余从两组主用线路扩展到全部 12 组，预计在 11 月完成。三是上线故障订阅页，用户可以选择接收某条线路的状态通知，故障与恢复各发一封邮件。

苏澜（运营负责人）：“9 月关于断连的工单是 63 条，8 月是 241 条。数量下降的大头来自自动摘除，人工介入的占比从 78% 降到 12%。”

数据会按月公布，统计口径保持不变，方便与历史月份对比。用户如果想查看自己所在线路的实时状态，可以在客户端的状态栏看到最近 10 分钟的探测结果，绿色代表正常，橙色代表探测失败正在重试。想体验新的稳定性机制，可以下载 3.3.7 及以上版本客户端。