认证系统临时出故障，访客网络怎么不瘫痪
做企业访客WiFi认证的人，迟早要面对一个尴尬场景：认证网关本身、短信通道、或者认证服务器临时出了问题。这时候访客连上WiFi，弹不出认证页，或者收不到验证码，整栋楼的外来人员全都上不了网。前台电话被打爆，会议开始前网络全断，业务直接被卡在门口。
这种故障不会提前打招呼。它发生的时候，企业最需要的不是"马上修好"——修复总要时间——而是"这段时间里，访客网络能不能以一种可控的方式继续服务，而不是一刀切全断"。
先分清：是哪一段出了问题
访客上不了网，原因可能落在好几段不同的链路上。第一段是无线覆盖本身，AP或AC出问题，信号都没有了；第二段是认证网关，认证请求到了网关但网关响应不了；第三段是认证后端，账号数据库、用户策略这部分出问题；第四段是验证码通道，短信发不出去，访客收不到码；第五段是外部对接，比如企业微信扫码授权用的外部接口临时不通。
不同段落出问题，应急手段完全不一样。AC或AP硬件层面的故障，认证系统层面做不了什么，得走无线网络本身的抢修。但认证后端、短信通道、外部授权接口这几段出问题，是可以在认证系统层面做降级兜底的。下面说的应急策略，针对的就是这后几段。
降级放行：故障窗口里的临时白名单
认证系统出问题时，最直接的应急思路是临时进入一种"降级模式"：不再要求所有访客必须认证，而是按一个事先约定好的策略临时放行一部分流量。
具体怎么放，要有预案，不能现场拍脑袋。常见的做法是在故障窗口里，对访客SSID临时开放基础上网能力——允许访客访问公开互联网，但收紧权限：限速、限制可用时长、不开放任何内部资源。这相当于把访客网络临时从"认证后全放行"切换到"免认证但受限放行"。
这种降级不是长期方案，它是一个有明确起止的应急窗口。窗口一旦启动，运维人员要清楚几件事：现在全楼访客都在免认证状态上网，能做什么、不能做什么；这个窗口预计维持多久；什么时候切回正常认证流程。
短信通道故障：临时换一种认证方式
短信通道是访客认证里最脆弱的一环之一。短信服务商本身在高峰期可能延迟，企业自己的短信额度可能用尽，短信网关和运营商之间的链路也可能临时不通。这时候访客输入手机号，点了发送验证码，等半天收不到。
这类故障有比较成熟的应急做法：在认证页上临时切到备用认证方式。企业如果同时配置了多种访客认证通道——比如短信验证码和扫码授权并存——短信通道出问题时，可以临时把认证页默认引导到扫码授权，让访客由接待人扫码放行。或者前台临时发放一批纸质临时账号，手工录入，让访客先用着，等短信通道恢复。
关键是这些备用通道要在平时就配好、测过。等到短信真断了再去现配临时账号，现场会非常乱。
故障恢复之后怎么收口
应急放行不是放出去就不管了。认证系统恢复正常后，有几件事必须跟上。
第一是把降级策略切回来。临时放行窗口关闭，访客SSID恢复到认证后才能上网的正常状态。第二是补记录。降级窗口里访客上网是免认证的，这段时间的连接日志要和后续正常认证记录分开归档，事后查账时要能说清楚"这段时间属于应急降级期，不做实名追溯依据"。第三是复盘。故障到底落在哪一段、应急策略启动得够不够快、有没有访客因为这次故障投诉，都要记录下来，作为下一次预案调整的依据。
谁有权限启动和关闭降级
降级策略不是谁都能碰的。什么时候切降级、切到什么程度、什么时候切回来，要有明确的授权链路。值班工程师在监控里看到认证系统响应异常，可以先按预案做初步处置；但启动整楼降级放行，通常需要更上一级的确认。这个授权范围要在预案里写清楚，不能让值班人员在故障现场自己猜"我现在能不能把网放开"。
反过来，关闭降级、切回正常认证，也应该有记录。几点几分切回来的、切的时候系统状态是否已经恢复正常、降级窗口一共持续了多久，这些数字事后复盘要用。
把人工留给例外，把常规交给预案
企业访客WiFi认证的应急兜底，本质是一份提前写好的预案。平时就要想清楚：认证网关故障时切不切降级、短信断了用哪种备用认证、降级窗口开多久、谁有权限启动降级、恢复后谁负责切回来。这些决策点如果等到故障发生那一刻才讨论，每个环节都会慢半拍。
另外要清楚边界：应急放行是临时措施，不能因为"反正放了也没人投诉"就长期保持。免认证状态下的访客上网，没有实名身份对应，合规上是要打折的。它只是让业务在系统故障窗口里不至于完全停摆的一个手段，不是一个可以常态化的运行状态。