WiFi短信认证系统跑起来和跑稳之间，差的不只是时间，是背后有没有人每天在看几个关键运维指标。这几个指标没有一个是高深的，但没人看的话，任何一条掉下去都能慢慢把你的住客满意度拖没。

　　每天该做的第一件事：看短信发送成功率。WiFi短信认证系统的用户体验从这条指标开始算起。正常的日成功率应该在百分之九十七往上。低于百分之九十五，通常只有三种可能。第一种，短信通道拥塞，这种白天不容易出现，深夜反而可能因为大量营销短信扎堆发送导致通道排队；第二种，通道余额不足，负责充值的同事出差了或者忘了续费，通道被停掉之后系统没有自动告警，这种情况出奇地常见；第三种，国际住客比较多的时候，某国外运营商对中国短信通道做了批量拦截。日成功率一掉，别先去查系统日志，先查通道后台的发送记录看是哪一类号码在失败，基本能定位到根因。查通道后台比查系统日志快得多，因为成功率掉是通道侧的问题远多于系统侧。

　　每周至少查一次的事：数据上传的连续性和完整性。WiFi短信认证系统在公安合规框架下属于安全设施，住客的手机号、上网时间、IP地址、下网时间这些认证记录需要按规定上传到监管平台。上传链路断掉很少是因为产品问题，更多是中间网络波动导致一次上传失败后补传机制没有成功触发。成熟的系统都有本地缓存加异步补传的能力，但缓存不会永远存在。磁盘满了旧数据可能被覆盖，覆盖就意味数据丢失。你需要做的不是每天去确认数据是不是全传上去了，那个工作量太大，而是每周快速扫一眼上传监控页。过去七天里有没有红色标记？有没有某个时间段的数据总量明显比其他时间段少？这些信号比系统显示\u201C上传正常\u201D四个字可靠得多。

　　不能等出事才做的事：短信通道的周期性压测。压测不是把系统打崩看能不能恢复，是模拟两种真实情况。一种叫正常高峰：周五晚上入住率百分之九十的时候短信认证请求量是平时的三倍，你的通道响应时间还是不是跟平时一样？另一种叫单通道故障：主通道挂掉之后备通道的接管时间是多少秒？接管时间内有多少条短信认证请求积压了？压测结论每次都不一样，因为酒店入住数据在变，通道运营商的网络结构也在变。每季度做一次通道压测，不费多少时间，但能帮你在旺季之前发现一个即将在旺季暴露的问题。压测这件事不做的后果不是系统一定出问题，而是你永远不知道系统在几百人的认证洪峰下会不会出问题。

　　这三件事，日看短信成功率、周查数据上传完整性、季度做通道压测，说起来没有任何技术难度，问题在于很少有人把它们写进日常运维检查清单里。

　　除了这三件，还有一个容易被漏掉的运维动作：认证系统的版本更新管理。WiFi短信认证系统厂商会不定期发布版本更新，修Bug、加功能、优化性能。但版本更新不是越勤越好。每次更新都可能引入新的兼容性问题，尤其是和PMS对接的接口层。建议的做法是：厂商发布更新后，先在测试环境跑一周，确认PMS对接、Portal页面、短信通道三个核心链路都正常，再往生产环境推。不要厂商一发更新就直接上生产，这个习惯在酒店这种二十四小时运营的场景里风险太高。另外，每次更新前做一次全量配置备份，更新后如果出问题能快速回滚。回滚这件事，平时不觉得重要，真到需要的时候没有备份，恢复时间可能从十分钟变成半天。

　　还有一个运维层面的细节：短信通道的合同管理。短信通道通常按年签合同，到期自动续约或者到期停服。如果负责签合同的同事离职或者岗位变动，通道到期没人续费，系统不会自动提醒你\u201C通道快到期了\u201D，它只会在通道停掉之后默默记录发送失败。所以通道合同到期日应该写进运维日历里，提前一个月设置提醒。这个动作跟技术没关系，但它是运维里最容易出事的环节之一。

　　WiFi短信认证系统不像空调和热水，坏了住客立刻投诉。它坏的时候住客通常不投诉，而是直接认为这家酒店WiFi不行，下次不订了。这种流失是你永远收不到反馈的。运维的价值就在这里：不是等出事了去救火，是让系统在住客完全无感的状态下持续运转。一份写得清楚的运维检查清单，比任何灾备方案都更能帮你避开夜间紧急电话。毕竟凌晨两点被叫醒处理认证故障这件事，经历过的运维都不想再经历第二次。