TG咨询高峰来临时，云手机实例不够，可能表现为排队变长、启动变慢或操作卡顿；提前预留过多，又会产生闲置成本。处理云手机业务高峰期的容量预留与扩容触发条件，先要回答三个问题：峰值会来多少用户、现有实例能承载多少、扩容需要提前多久启动。
先建立容量基线，再估算峰值
云手机容量不等于实例总数。实际可服务规模还受实例规格、应用资源占用、网络质量、登录流程和同时在线时长影响。同一批实例，运行轻量应用与持续渲染的应用，负载可能明显不同，因此不要直接照搬其他业务的设备配比。
建议在业务平稳时记录每分钟在线实例数、CPU与内存使用率、启动成功率、排队时间及网络延迟；再选一个接近真实流程的时段，测量从发起请求到实例可操作的耗时。将稳定运行的并发量记为基线，并通过逐步增加实例观察瓶颈，找出CPU、内存或启动队列先达到限制的位置。
把扩容触发条件写成可执行规则
云手机业务高峰期的容量预留与扩容触发条件，应同时包含负载信号、持续时间和动作。单次尖峰容易造成误扩容，可把持续观察作为条件。以下数值是初始告警参考，不是通用容量标准；需根据实例规格、应用和服务目标校准。
- CPU：平均使用率持续约5至10分钟高于70%—80%，且操作响应变慢，可先扩一小批实例并观察。
- 内存：使用率接近75%—85%并持续上升，或出现频繁回收、应用重启，应检查单实例负载；单纯增加实例未必能解决规格不足。
- 排队与启动：等待时间超过业务可接受范围、启动成功率下降时，按待服务请求量和实例启动耗时补充容量。
- 需求预测：已知活动、集中测试或批量任务开始时间时，按预计并发量提前准备，不要等监控告警后才启动。
触发后先扩容约10%—20%作为小步调整的起点，观察一个完整的业务波动周期，再决定是否继续增加；若增长迅速或启动耗时较长，应提高初始余量。百分比仅作操作参考，具体步长取决于单批启动时间、预算和回滚能力。
按波动形态选预留方式
峰值规律、必须及时可用：预留基础容量
如果每天固定时段有稳定需求，或临时缺机的影响较大，可把最低保障规模预留出来，其余部分按需增加。优点是峰值开始时更有把握；缺点是预测偏高会造成闲置。预留量可按近期相似时段的实际并发峰值估算，并扣除已确认不再使用的任务。
波动随机、可接受等待：按需扩容
需求不规律且服务允许短暂排队时，可主要使用按需实例。它减少长期空置，但若创建、初始化或应用登录需要时间，突发需求可能先遇到等待。应预先测量完整启动耗时，并把它纳入告警提前量，而不是只看资源创建速度。
既有稳定底量又有突发峰值：混合预留
多数不确定业务可采用“基础容量预留＋弹性扩容”。例如日常保持覆盖稳定并发的实例，预测到活动或集中操作时提高余量；高峰结束后分批缩容，避免实例仍被占用时提前回收。云手机业务高峰期的容量预留与扩容触发条件应配套设置缩容规则，避免只扩不收。
新手可按四步落地
- 整理近几周可比时段的并发量、排队情况和实例启动耗时；没有历史数据时，先进行小规模压测并标明测试条件。
- 选定业务底线，例如可接受的最长等待时间、启动成功率和操作响应目标。
- 设置分级告警：接近容量上限时提醒，持续超阈值时扩容；同时指定每次扩容数量与观察时长。
- 高峰结束后核对峰值、闲置量和异常记录，调整下一次预留规模，并验证缩容不会中断正在使用的实例。
复盘时分别看“实例不够”和“单实例规格不合适”：前者适合增加容量，后者可能需要调整规格或应用负载。把云手机业务高峰期的容量预留与扩容触发条件落实到监控、扩容和回收三个环节，才能兼顾可用性与成本。
常见问题
只有CPU告警时就应该扩容吗？
不一定。先检查内存、网络、排队和应用本身；若瓶颈来自单实例规格，增加实例可能无法改善单个用户的体验。
预留量应该按平均并发还是最高并发计算？
基础预留可参考稳定并发，另为可预测峰值安排弹性余量。最高值若只是短暂尖峰，不必自动按满额长期预留。
什么时候缩容更稳妥？
需求连续回落并低于设定阈值后再分批缩容，同时确认实例没有活跃会话或未完成任务；具体观察时间应按业务周期和退出机制确定。