新版本开放的那一刻，运维群里通常有人问：“今晚到底要开多少台？”这个问题本身就有问题。答案不是一个数字，而是一条随时间变化的曲线，而且曲线的不同段落卡住系统的，是不同的东西。把整晚当成“一个更大的晚高峰”去配置，结果往往是要么在开服前十分钟被登录请求砸穿，要么在开服三小时后守着一堆没人用的机器。下面按时间顺序来看，每一段该看什么信号、该做什么准备。
上线前一周：先用预约和历史版本确定量级，别急着定实例数
这个阶段只需要回答一个问题：这次的规模大约是平常晚高峰的几倍量级。可用的信息有三类：预约与预注册人数、过去几个同类版本（新赛季、大型资料片）的峰值与持续时间、以及官网和社区在预热期的访问趋势。预约人数不等于到场人数，两者之间有一个转化率，而转化率每个游戏、每次活动都不一样，所以九游会AI的做法是把历史版本里“预约→上线首日在线”的比例当成一个区间，而不是一个常数。
此时给出的应该是区间和情景，比如“保守、基准、偏高”三档，再附上每一档需要的基础容量与预热容量。实例数不在这个阶段锁定，是因为后面还有几次可以修正的机会。
前一天：补丁下载先动，CDN 与源站出口要单独算
多数版本在正式开服前就允许预下载补丁，下载量的高峰往往早于对局高峰。这一段的瓶颈是 CDN 与源站出口带宽，而不是游戏服务器的 CPU。如果补丁在同一时刻集中开放，回源请求会集中到少数节点，缓存预热不充分会把压力推回源站。需要提前确认的是：补丁分发的缓存是否已预热、限速策略是否就位、客户端在下载失败时的重试间隔是否带有随机抖动，否则一次失败会变成一次同步重试风暴。
这一段和后面的对局压力是两套资源，不要合并成一个“服务器数量”去估算。补丁与分发对网络能耗的影响，可以在相关的碳足迹文章里单独看。
开服前一小时：登录风暴比对局压力来得更快
开服倒计时归零后的头几分钟，压力集中在登录、鉴权、账号数据加载和角色列表读取上。这些服务多是无状态或半状态的，可以较快扩容，但它们依赖的数据库与缓存往往不能：数据库的连接数、缓存的命中率、消息队列的堆积才是真正的上限。所以这一段的容量规划要看“登录速率的峰值（每秒多少人）”，而不是“最终在线人数”。
对策通常是三件套：提前扩到目标基线，给登录入口设置排队而不是硬拒，以及降低这一时段的非关键请求，例如延后推送、推迟非必要的数据同步。排队队列要让玩家能看到位置与预估时间，玩家看到“在排队”的容忍度，远高于看到“连不上”。
开服后半小时：对局服务器和预热池的分工
玩家进入游戏之后，压力转移到对战房间实例。如果一台房间实例从触发到可接客要几分钟，那么开服后再扩容一定来不及，只能依靠预热池：提前把一批加载好地图与配置的实例放在待命状态。预热池的大小可以由预约情景的上沿、房间的平均容纳人数、以及每分钟新增房间数来估计。
这里要小心一个常见误判：把预热池按“最终在线人数”算，会多算很多。更合理的是按“前三十分钟内每分钟需要新建的房间数”去算，因为开服后人数是逐渐涨上去的，房间也是逐渐被创建出来的，并不是同一秒全部需要。
比如假设基准情景预计首小时新增 6 万玩家，每个房间容纳 10 人，那么首小时大约需要新建 6000 个房间，平均每分钟约 100 个。若房间实例的冷启动需要三分钟，预热池至少要能覆盖三分钟的新建量，也就是几百个待命房间，再叠加缓冲。这个推算比“按 6 万在线人数配置服务器”要具体，也更容易被验证。
晚高峰到回落：什么时候可以缩，什么时候不该缩
新版本首夜的曲线通常是先冲高、然后在几小时内回落，第二天到第三天出现次高峰。此时的调度原则和平常一样：扩容快，缩容慢。回落阶段最容易犯的错，是看到人数下降就马上回收实例，结果玩家在第二天中午再次涌入。较稳妥的做法是分梯度缩：先回收预热池，再回收多出来的基础实例，并保留一段观察期。
和日常的动态扩缩容相比，上线夜更依赖人工介入的时间窗口：运营、开发、运维需要有同一张监控大屏，并约定好触发人工干预的阈值。晚上玩家多就一定要多开服务器吗讲了日常预测的框架，上线夜是把这套框架放在更大的不确定性下运行。
预测最容易失准的四个地方
- 预约转化率偏差：同一批预约，热度不同，转化差别很大，需要用区间而不是单点；
- 玩法瓶颈没有预料到：新地图、新模式的单房间开销可能显著高于旧版本，压测数据比历史数据更重要；
- 外部因素：竞品同天上线、社区内容传播、直播平台带来的临时涌入；
- 故障后的回流：一旦出现登录故障，恢复后的第二波会比第一波更集中。
对这些情况，预测模型帮不上多少忙，主要靠压测、灰度放量和人工判断。所以九游会AI的位置，是给出情景区间和容量建议，而不是替代发布前的容量评审。
为什么这件事和“绿色”有关系
上线夜是最不能省的一晚，谁也不该为了少开几台机器去冒险。但上线夜的容量安排决定了随后几天回落是否顺利：如果预热池和基础实例在回落后长时间不回收，这些机器就成为低利用率的空转。这段空转的能耗，在玩家已经下线，服务器为什么还在耗电里有更细的拆解；而对于那些可以延后的后台任务，例如日志汇总、数据分析，可以避开上线夜的高峰，改在低碳的计算窗口去跑。这种做法减少的是拥挤，也可能降低碳排，但要注意，它是否真的降低碳排，取决于所在电网的碳强度，不是所有情况都成立。
九游会官网的九游会绿色运营栏目里，还有从空闲算力、低峰调度到区域选择的其他文章，可以对照阅读。九游会当前的思路，是把上线夜当作一个需要提前演练的场景，而不是一次靠经验的临场发挥。
上线前的检查清单
- 预约转化率历史区间是否已更新，情景（保守、基准、偏高）是否明确；
- 补丁分发的 CDN 缓存是否已预热，客户端重试是否带抖动；
- 登录、数据库、缓存的连接与吞吐上限是否压测过；
- 预热池大小是否按“每分钟新建房间数 × 冷启动时间”估算，而不是按最终在线人数；
- 排队和限流策略是否有清晰的玩家提示；
- 缩容的梯度与观察期是否事先约定。
这份清单不涉及任何特殊技术，重点是把每一项都写成有人负责、有阈值的检查项，而不是留在经验里。
