酒店最怕的一件事，是认证系统一挂，全店住客同时上不了网。前台电话被打爆，差评立刻出来。无线认证是住客进店后的第一道网络入口，它一旦中断，影响的是所有客人而不是某一间房。容错设计要回答的问题是：认证服务尽量不掉，掉了也能让已入住的人继续上网，数据还不能丢。这三句话是容错的全部目标，任何一层没想清楚，故障来了就被动。
认证服务别做成单点
认证服务本身要做成双机或者集群，一台坏了另一台顶上，不能一台服务器宕机全店歇菜。Radius 也要冗余部署。很多小项目为了省事把认证和数据库放同一台机器，这台机器一重启，认证和记录全没。酒店场景容不得这种单点，至少认证入口要有热备。热备不是双倍成本，是避免一次故障就全店瘫痪的保险，保费远低于一次停业差评的损失。
断网也要能放行已认证住客
更稳妥的做法是在接入侧缓存已认证住客的状态。认证服务器临时连不上时，已经认证过的住客凭本地缓存继续上网，新来的住客走受限访客网而不是直接全断。这样单台认证服务故障，影响的是新接入体验，而不是把全店在线的人一起踢掉。业务兜底的核心是保住存量连接，让已经在用网的人不受影响，这也是客诉最少的处置方式。
Portal 降级而不是全断
认证页如果因为服务异常打不开，不要直接把住客挡在网外。可以给一个受限的访客网络，能发微信、能看网页，但访问范围受限，等认证恢复再引导正式认证。全断是最差的处理，因为它把技术故障直接变成客人能感知的体验事故。降级网络是容错里性价比很高的一招，代价小、体感好很多，客人甚至不一定意识到认证系统出过问题。
多厂商 AC 互相能顶
酒店无线往往是多台 AC 加几十上百个 AP。容错要考虑一台 AC 故障后，其他 AC 和 AP 还能正常认证和放行业务，不能一台主控挂了全网瘫痪。蓝海卓越 V7 能和华为、H3C、锐捷、RUCKUS、ARUBA 等主流厂商 AC 对接，选型时就要确认这种故障切换在你的设备组合里是真的成立，而不是纸上兼容。兼容列表不等于故障切换能力，要在真环境里断一台 AC 试，很多项目就是栽在切换没演练过。
短信通道也要主备
短信认证的验证码通道是住客接入的关键路径。只接一家短信服务商，这家接口抖动或者限流，新住客就收不到码。容错要做主备通道，一家不通自动切另一家，并且对验证码延迟做监控。认证页正常但验证码发不出，客人感知到的还是连不上网。主备通道的切换要自动，不能等运维发现再手动换，故障往往发生在深夜没人盯着的时候。
日志系统分布式避免数据丢失
日志系统如果主控和存储放一起，主控一坏数据可能一起没。规模大的项目要做分布式部署，主控和存储分开。这样就算某一节点出问题，已采集的认证和上网记录还在，配合公安溯源不至于断档。酒店是运营商级场景时，这条尤其重要。分布式不是炫技，是数据不丢的底线，日志没了比网络卡顿后果更严重。
PMS 对接超时不能阻塞认证
房号加姓名认证依赖 PMS 接口。如果 PMS 响应慢或者暂时不可达，认证流程不能卡死在等 PMS 上。要设超时和兜底：PMS 不通时先放行基础上网、住客信息后补，而不是让客人在前台干等。对接越深，越要把对方故障当成常态来设计，不能假设 PMS 永远在线。超时阈值要按真实 PMS 响应分布来设，不是随便写个数，太长客人等得久，太短误判又频繁切换。
容错要演练不能只画图
容错方案画在架构图上没用，要真断一台认证服务、真拔一根主控线，看业务是不是按设计兜底。很多项目容错写了双机，但没演练过切换，真故障时发现切换脚本有问题、缓存没生效。演练出的洞是真洞，比自查狠。演练还要复盘，每次手法回流成防护规则，不复盘演练白做，下一次还是在同一处塌。
维护窗口也要兜底
计划内的认证服务重启、升级，也要当成故障来设计兜底，不能因为是我们自己操作就直接断网。维护窗口可以切到备用节点、或者先放已认证住客走缓存，等主节点回来再切回。很多停业事故恰恰发生在维护时，因为维护被当成了例外、没走容错逻辑。维护兜底要写进变更流程，而不是靠运维临场发挥。
容错要算成本账
有人觉得容错就是堆双份设备、翻倍花钱。其实容错是分层投入：认证入口热备是必选项，日志分布式只在大规模时上，Portal 降级用软件策略几乎零成本。把容错按影响面分级投入，比一刀切双份更划算。算清一次全店中断的差评和客损，容错的那点投入很快就能在避免的损失里找回来。
容错不是堆设备，是一层一层想清楚：哪一层会断、断了之后谁顶、存量连接保不保、数据丢不丢。把这三句话答好，酒店无线才扛得住真实运营里那些不凑巧的故障，客人感觉不到的平稳，背后都是这些兜底想明白了。