做运维最怕的不是出故障，是出了故障之后发现预案里写的东西根本用不上。年初我们一个客户的WiFi认证系统出现了大面积认证失败，影响了好几千用户。当时按照预案去操作，结果发现预案里好几个关键步骤的前提条件都不满足，现场所有人手忙脚乱地现想办法。那次之后我把应急预案从一张纸扩展成了三页，而且每条都经过实际演练。

认证服务宕机的降级方案不能是"切备机"

很多预案的第一条写着"认证服务器故障时自动切换至备用节点"。这话在纸面上看没问题，但在实际操作中有几个暗坑。

第一个坑是主备切换不是真的自动化。有些WiFi认证系统的所谓"高可用"，实际上是冷备——备机虽然开着，但服务没有在运行，需要人工启动。当你发现主节点宕机的时候，首先要登录备机、启动服务、检查配置一致性、确认数据同步状态，这个过程熟练工也要五到十分钟。在此期间，所有用户的认证请求都在失败。

第二个坑是数据同步延迟。如果主备之间用的是异步复制，主节点宕机那一刻，最后几秒甚至几十秒的认证日志和计费数据可能还没来得及同步到备机。如果这时候你直接把备机切上去，就会丢数据。更坏的情况是，主节点缓过来之后又自动恢复了，这时候就出现了两个节点数据不一致的"脑裂"状态，后面修复数据的工作量远大于切换本身。

所以我们后来在预案里写了更细的东西：主备切换不只是切节点，还要同步检查数据一致性。如果主节点是因为数据库挂了而不是进程挂了，备节点切上去之后还要把主节点的网络断开，防止它恢复后造成脑裂。这些操作细节如果不在预案里写清楚，出故障的时候根本没人想得到。

认证链路中的单点隐患排查

WiFi认证系统是一个链条：终端 → AP → AC → Radius → 数据库/缓存 → 认证门户 → 短信通道。这个链条上只要有单点故障，整个认证就断了。

我们有一次排查故障时发现一个非常隐蔽的单点：虽然Radius服务做了主备，但两台Radius服务器连的是同一台数据库。那台数据库因为磁盘IO飙高导致响应超时，两台Radius同时挂了。所以所谓的高可用，其实只是冗余了一半——应用层冗余了，数据层还是单点。

后来我们的做法是，在WiFi认证系统的架构评审阶段，就画一张完整的认证链路图，每一个节点都标上它依赖的下游资源是什么，然后逐一检查：这个下游资源有冗余吗？冗余之间的切换是自动的还是手动的？切换过程中会不会丢数据？画完这张图之后，很多藏在暗处的单点就暴露出来了。

故障期间的降级策略

如果说预案的第一部分是"怎么恢复"，那第二部分应该是"恢复不了的时候怎么办"。这个逻辑很多人不愿意想，因为想这个意味着承认系统可能在某些情况下恢复不了。但实际情况是，有些故障确实不是几分钟能修好的——比如说短信通道全面瘫痪、比如说出口光纤被施工挖断了——这时候你需要一个临时降级方案把业务影响降到最低。

我们在WiFi认证系统里设计了几个降级策略。当短信通道不可用时，自动切换到"免认证模式"——但严格控制在这个模式下的上网时长（比如每次只给一个小时）和限速带宽（比如只给两兆），同时记录所有该模式下上网的用户的MAC地址和IP，事后补录认证信息。当Radius服务器完全不可用时，AC侧自动切换到本地MAC认证作为兜底——虽然安全性降低了，但至少保障了基本连通性。

这些降级策略的执行条件、触发逻辑、恢复流程，全部写在预案里，并且每个季度至少演练一次。不是说写一次就放那儿不管了，而是在每次系统升级、架构调整之后，重新审视预案是否还适用。预案是一份活的文档，不是一份应付检查的存档文件。 还有一个经验是，预案里一定要写清楚"谁来做决策"和"谁能拍板"。故障发生的时候最怕的不是技术搞不定，而是所有人都在等技术负责人拍板，技术负责人又联系不上。我们在预案里明确了一个授权链：如果一级负责人五分钟内未响应，授权自动下放给二级负责人；二级也联系不上就由值班工程师按预案直接执行，事后补报。这个授权机制比任何技术方案都重要，因为它保证了在关键时刻有人能动手，而不是所有人都在等人点头。另外预案里还要有一份"故障通报模板"，包括对外通知用户的标准话术、对内通报管理层的格式和时间节点。故障时的沟通成本往往比技术修复成本更高，一条不当的对外通知可能引发比故障本身更大的信任危机。