【运维发布】发布窗口选择：用在线人数曲线定停服时机

停服更新最怕撞上在线高峰，踢掉几百人换来一片抱怨。选对发布窗口，同样的更新内容，玩家体验是两回事。本文讲如何用996引擎的在线数据选窗口、控流程。

场景与痛点

传奇类游戏在线曲线呈双峰：午间与晚间各一个高峰，凌晨两点到六点是低谷。但低谷时段不等于随便什么更新都能塞：跨零点的活动结算、挂机奖励发放都依赖服务端在跑。窗口选择要同时避开高峰与结算点，还要给回滚预留时间。

实现思路

先取两周的在线曲线叠加，找到公共低谷；再对照活动表排除结算时段；按更新内容估算停服时长，窗口长度至少是估算值的两倍。发布过程中用在线人数监控确认玩家已基本离线再动手。

关键实现

local online = grobalinfo(6)
if online > 200 then
    sendcentermsg(nil, "当前仍有" .. online .. "人在线，维护操作已暂缓")
    return
end

关服前的预告用居中公告滚动推送：

sendcentermsg(nil, "服务器即将例行维护，请各位玩家及时下线保存进度")
setontimerex(901, 600)

定时器901到点触发关服脚本，公告与执行之间留出一段缓冲，在线玩家有充足时间保存进度。

细节与避坑

grobalinfo(6)返回全服在线数，读数要放在关服流程第一步，超过阈值就推迟而不是强停。维护公告提前二十四小时在官网与登录弹窗双渠道预告，临时起意的停服最伤口碑。更新包先在测试环境过一遍启动流程，生产停服时长才敢往短里估。回滚方案在停服前写成命令清单，出问题时按清单执行而不是现场想。

小结

发布窗口的本质是把不确定的操作放进确定的时间段。曲线定窗口、公告定预期、监控定动作，三步走完，停服更新就从惊险动作变成例行公事。

延伸思考

多服运营时可以让各服错峰发布，运维人力复用同一套清单。若更新只涉及Lua脚本，评估热加载的可行性，能不停服就别停服。