认证系统上线后最怕的不是突然崩，而是悄悄变差——成功率从九九点五掉到九八，还没到客诉线，可没人看趋势，两周后就掉到九十几。运行监控和 SLA 要解决的，不是摆一堆指标让人扫，而是把“系统还健不健康”变成一组有阈值、会告警、能闭环的判断。指标是手段，SLA 才是结论：没有阈值，健康与否永远靠拍脑袋，等客诉涌进前台就晚了。
先定 SLA 阈值，再谈看什么
很多酒店先上监控大屏，再想看什么，结果指标一大堆却没有一条说清“到什么程度算病了”。顺序要反过来：先按这家酒店的真实历史分布定 SLA——认证成功率不低于多少、Portal 两秒内、短信验证码延迟在多少内、地址池水位低于多少就预警。阈值定太高天天误报、定太低形同虚设，得落在真实波动区间的上沿。阈值定下，监控才知道什么时候该响，否则只是漂亮的曲线。
要盯的指标覆盖认证全链路
SLA 之下具体看几类：认证成功率与失败率、Portal 响应时延、Radius 并发与队列、短信通道可达性和延迟、AP 在线率、地址池使用率、日志推送状态、PMS 对接成功率。任何一类异常都可能是故障前兆，单看网络通不通会漏掉大半。指标要覆盖从认证到放行的全链路，不是只盯出口带宽——带宽通不代表认证能放人，Portal 卡一样让客人上不了网。
故障要分级处置
认证全断是最高级，要立刻有人处理；局部慢、个别区域异常是观察级，按预案跟进。分级让有限的运维精力用在最要命的故障上，而不是被一堆轻微抖动淹没。告警也要分级，不然真问题藏在噪音里。分级标准提前写清楚，别等故障了再临时分，那时人手慌张最容易分错级。
远程运维与升级要可控
连锁或多门店酒店可以远程运维和 OTA 升级，但升级要可控、可回退，不能半夜推一版把全网搞挂。监控要覆盖升级后的关键指标，确认没引入退化。远程是效率，可控是底线。升级窗口避开入住高峰，回退预案预先验证过，不能升级失败才发现回退脚本没测。
和整体安全运营联动
认证和上网数据要进酒店整体安全运营，异常触发整体告警、联动处置。割裂看认证系统，问题藏在局部看不见；放进运营，蹭网、绕过、异常终端才连得起来看。监控的价值在联动，不在单点显示。联动后，一次异常能同时被网络和安全两侧看见，定位也快。
监控本身也要健康
监控系统和告警通道本身可能出问题：采集断了没人知道、告警短信发不出去。要监控监控器，采集中断和告警失败也要有兜底通知。监控挂了还显示一切正常，是最危险的盲区。监控的健康度单独纳入巡检，不能假设它永远在线。
用复盘把健康度量闭环
出了故障要复盘：哪个指标先红、告警有没有按时响、处置花了多久。复盘把 SLA 和监控的漏洞找出来，回流成阈值和预案的修正。不复盘，同样的故障下次还来，SLA 也成了摆设。复盘记录还是对老板交代系统健康投入产出的最好材料。
容量类指标也要进监控
除了成功率时延这类可用性指标，地址池使用率、日志盘剩余空间、AC 带机余量这些容量指标也要监控。容量类指标的特点是悄悄涨、突然爆：地址池慢慢被占满，某天早高峰一下就不够用。容量告警要设在临界之前，留出处置时间，等彻底满了再告警已经影响客人。
变更要纳入监控视野
配置改动、策略调整、版本升级这些变更本身，也要进监控：谁改了什么、改完关键指标有没有异动。很多故障不是设备坏了，是一次改动带出来的。把变更和指标联动看，能最快定位是不是刚改的某处引发的。变更监控还能防住配置漂移，避免没人记得某台设备被手动改过。
监控数据自身要留存复盘
监控产生的指标数据按一定周期留存，用来做趋势分析：地址池是不是逐周走高、某区域时延是不是在缓慢劣化。趋势比单点告警更能提前暴露问题。留存下来的数据，也是复盘和向上汇报系统健康度的素材。只显示当前值不留存历史，等于每次都从零看系统，看不出慢性病。
SLA 要与业务时段挂钩
SLA 阈值不能全天一个样，入住高峰和深夜的容忍度不同。早高峰认证成功率掉一点就得告警，深夜轻微抖动可以先观察。把 SLA 和业务时段挂钩，告警才贴真运营，既不漏真故障也不被夜间噪音淹没。时段化 SLA 还要和排班对应：高峰有人盯、低峰可降级响应。很多项目 SLA 一刀切，结果要么误报疲劳要么真故障被当成噪声。
告警疲劳要主动治理
告警太多等于没告警，运维对红色变麻木，真故障反而被忽略。要定期收敛告警：把已经稳定的误报关掉、把低价值抖动合并、把高频但不处置的项降权。告警治理和监控一样是持续动作，不是配完就完。疲劳的监控比没有监控更危险，因为它制造了系统很安全的假象，真出事时反而没人响应。
监控和 SLA 把认证系统从黑盒变成可观测的服务。它真正值钱的地方不在大屏多漂亮，而在问题刚冒头、指标刚变红时就被处理掉，客人根本没感觉。这种看不见的平稳，是运维真正该交付的东西，也是 SLA 把“健康”从一句口号变成可度量、可问责这件事本身的意义。