系统升级这种事情，技术团队关注的往往是新功能、新架构、新性能指标，但用户只关心一件事：升级期间我还能不能上网？尤其是WiFi认证系统这种直接面向终端用户的基础设施，一旦升级过程中出现了大面积断网，用户的投诉量能在半小时内把IT部门淹没。过去两年我经历了两次WiFi认证系统的大版本升级换代，总结了一些经验。

先搞清楚哪些数据必须无损迁移

WiFi认证系统升级最核心的问题是数据迁移。你要迁移的数据很多：用户账号信息、套餐和计费策略、历史认证日志、历史计费记录、设备指纹库、黑白名单。不是所有的数据都要以同样的优先级处理。

第一优先级是用户账号和当前有效的套餐策略。这些数据如果迁移过程中丢失或错乱，用户认证就会失败，或者被错误地扣费，这是最严重的生产事故。第二优先级是黑白名单和设备指纹库，这些影响安全策略的正确性。第三优先级才是历史日志和历史计费记录，这些数据丢失不会影响当前业务，但会影响合规审计。

我们在第一次升级的时候就犯过一个错：把全部数据放在一起做全量迁移，新旧系统之间的数据同步跑了两天都没结束。后来学乖了，先把核心账号数据切过去、验证通过、业务跑起来，然后再在后台异步迁移历史数据。历史数据迁移期间，旧系统的查询接口保留，万一有人要查历史账期，可以同时查两个系统。等历史数据全迁完之后再关掉旧系统。

新旧系统并行运行是唯一稳妥的切换方式

很多人喜欢做方案里的"一刀切"：定好某个时间窗口，全网停服，升级系统，恢复服务。这个方式最简单，但风险也最大——万一升级后出了什么意想不到的问题，你已经没有退路了。

我们采用的是新旧WiFi认证系统并行运行然后灰度切换的方案。具体做法是：新系统部署好之后，在DNS层面把认证门户的域名解析从旧系统逐步切到新系统。先切百分之十的流量，观察一个小时，确认认证成功率、响应时间、错误率都在正常范围内，再切到百分之三十、百分之五十、百分之一百。

这个过程对网络设备的影响也要考虑。AP和AC上配的Radius服务器地址要改，AAA认证模板要改，Portal重定向URL要改。这些网络设备侧的配置变更，同样不能全网一把梭。我们先在一个楼层试，然后再扩展到一栋楼，最后才覆盖整个园区。

用户侧的无感体验比技术方案更值得花时间

升级期间最怕的就是用户发现"变了"。哪怕认证流程只是从点两次按钮变成了点一次，都会有用户打电话来投诉说"上不了网了"。所以无感迁移要在用户端做到极致。

我们做了几件事。第一，Portal认证页面的UI在新系统中做得和旧系统几乎一模一样，用户看不到任何视觉变化。第二，用户如果之前在旧系统上勾选了"记住设备"或者"自动登录"，这个偏好在新系统中要得到保留，不能让用户重新设置。第三，升级当天如果有用户因为切换到新系统导致认证失败，系统自动回退到旧系统并记录失败原因，不会让用户反复尝试然后放弃。

还有一个容易被忽略的：升级之后的用户通知。我们会在用户第一次在新系统上认证成功后，弹出一个轻提示："认证系统已完成升级，您的上网体验不受影响。如有问题请联系IT服务台。"这句话写不写差别很大——写了，用户知道有变化但被告知了，心里踏实；不写，用户可能会瞎猜是不是中了病毒或者被黑了。

最后说一个教训：无论你准备得多么充分，升级窗口里一定会出意料之外的问题。所以要给自己留足回滚的时间和余地。我们的原则是，如果升级开始后一个小时内任何环节出现了计划外的问题，立即回滚，改天再升。宁愿多花一周准备，也不要带着一身冷汗硬撑着上线。 再补充一个在多次升级中验证过的做法：升级前一定要做一次全量数据的"预演迁移"。就是在测试环境里拿生产数据的完整备份跑一遍整个迁移流程，不要跳过任何步骤。预演迁移能暴露很多在文档上看不到的细节问题：比如某个字段在新旧系统中的数据类型不一致导致导入失败、比如某些特殊字符在数据同步过程中被截断、比如新系统对密码哈希算法的兼容性不如预期。这些问题在预演中发现，你可以在正式升级前写脚本修复；但如果在正式升级中才发现，那就只能紧急止血然后临时改方案，风险和压力都不是一个量级。另外升级当天一定要有一份通信保障预案，因为WiFi认证系统一旦出问题，用户的第一反应就是用手机流量上网然后打电话投诉，客服那边的电话量可能会瞬间暴增，如果客服团队不知道发生了升级、没有统一的话术，就会造成更大的混乱。所以我们升级前一定会提前通知客服团队，给他们一份FAQ，告诉他们怎么回答用户的问题，什么情况该升级到技术团队，什么情况可以安抚用户等待。