TL;DR消费级接入线路上的可用性是个工程问题，不是表格里的一个数字。大部分故障靠一条与业务分离的管理线加带外硬件远程恢复；恢复不了的那些才是有意思的部分——一家把这些公布出来的主机商，比一家报可用率百分比的告诉你更多。
为什么可用率百分比几乎说明不了任何事
公布的可用率通常是个营销数字：未经审计、自己测量、也没有说明什么才算宕机。两家主机商可以报同一个数字，而恢复能力天差地别。
真正能预测可用性的，是一个更窄的问题：当站点断电或断网、现场又没有人时，接下来具体会发生什么？这个答案是具体且可核验的。百分比不是。
故障模式，以及哪些能远程恢复
| 故障 | 能远程恢复吗 | 需要什么 |
|---|---|---|
| 操作系统卡死 | 能 | 连到宿主机的带外 KVM |
| 宿主机硬件僵死 | 能 | 智能插座 + 固件里的来电自启 |
| 站点短时断电 | 能 | UPS 撑过去；撑不过时靠固件自启 |
| 业务线掉线 | 能 | 一条独立于客户流量的管理线 |
| 管理通道本身失效 | 只有它自己有备份时才行 | 一条不与前者共享故障域的备用上行 |
| 运营商改动线路配置 | 常常不能 | 上行没有有效配置时，现场任何东西都救不了 |
可用性真正的胜负手在最后两行，而这两行恰恰是大多数服务商从不谈的。
我们跑的是什么
- 一条不承载任何客户流量的管理线，使救援路径不与被救对象共享故障域。
- 一台直连宿主机的带外 KVM——提供控制台与固件级操作，而不是一个需要操作系统还活着的 agent。
- 宿主机电路上的智能插座，用于机器需要硬重启的情况。
- 固件里设好来电自启，供电恢复后宿主机自己起来。
- UPS，让短时中断根本不会演变成一次重启。
这是一笔不随客户数增长的一次性成本，这也正是它成立的全部理由。派人是线性增长的，最终会吃掉毛利。
这套东西没能覆盖的两次故障
这两次比设备清单更有教益，所以我们公布它们。
2026-07-26——救援路径依赖了被救对象。我们的控制面隧道，从它本该管理的那台路由器后面出网。路由器一挂，能修好它的那台盒子也一并够不着了。死锁，而且完全是自己造成的。我们从中得到的规则是：救援路径绝不能与它的目标共享任何依赖。控制面此后默认走管理线。
2026-08-07——我们准备的故障模式，不是实际发生的那个。运营商技师把我们的线路从 DHCP 改成静态配置。我方设备仍配置为 DHCP，随租约到期逐个掉线，管理线也在其中。我们预设的是「带外路由器死机，拔电重启」，实际发生的是「它活得好好的，但上行没有有效配置」——智能插座对此毫无用处。最后是靠仍保持 DHCP 的那条线恢复的：给它的调制解调器断电重启，带外路由器重新拿到有效地址，其余全部远程完成——代价是一整天的失联。
从第二次得出的改进是可观测性，而不是更多硬件：现在每条线路在监控里都有自己的探针，「活着但没有有效配置」成了一种看得见的状态，而不是靠猜。残余的缺口——上行本身成为伤亡——依然存在，我们宁愿直说，也不想让人以为它不存在。
该问任何服务商的五个问题
- 带外管理走的是不是与客户流量分开的线路？共用一条，意味着救援路径会和故障一起死掉。
- 宿主机自己不响应时会怎样——有没有控制台与固件级访问，还是只有一个跑在操作系统里的 agent？
- 断电之后机器会自己起来，还是需要有人去按一下？
- 你们上一次宕机是什么时候，最后是靠什么修好的？答不出具体细节的服务商，要么没发生过，要么没在记录——两种情况都值得知道。
- 你们现在还有哪些故障模式是没覆盖的？这里一个诚实的回答，比任何百分比都值钱。
上面五个问题我们都答。我们的说法是「大部分故障能在几分钟内转为远程恢复」——而不是「永远不需要到现场」，后者是任何一家在普通建筑里运营的主机商都无法诚实承诺的。
常见问题
什么是带外管理？
一种不依赖服务器本身或它常规网络通路就能够到它的手段——通常是通过一条独立线路提供控制台与电源控制。它是把「到现场」变成「远程修好」的那个东西。
管理线为什么必须独立？
因为与目标共享故障域的救援路径，会在同一时刻一起死掉。2026 年 7 月我们具体地学到了这一点：控制面从它本该管理的那台路由器后面出网，路由器一挂就够不到了。
你们承诺多少可用率？
我们不报这个数字。可用率通常未经审计、自行测量，所以我们改为公布事故，并明确说明什么能远程恢复、什么不能。这是可核验的，百分比不是。
什么情况是远程修不好的？
任何导致管理通道本身失去有效上行的情况。运营商改了线路配置，或者上行硬件坏了，远程拔多少次电都没用——这正是为什么备份上行要走另一种介质。