服务器什么时候扩容？容量预测与可执行的触发条件
容量问题应在交付周期之前发现
从决定扩容到资源真正承载业务，中间可能需要采购、创建、配置、数据同步和验证。如果监控到资源耗尽才开始申请，新增服务器再快也可能赶不上业务需求。
Google SRE对容量规划的讨论强调预测需求与准备资源的关系，并考虑满足可用性所需的冗余。实际网站可以采用同样思路：预测应覆盖资源准备周期，而不是只看明天会不会满。Google SRE概述
先记录所用资源的实际交付与上线时间。云实例创建快，不代表数据库迁移或大文件同步也快；物理服务器、额外地址和某些网络资源可能有不同准备条件，应向供应商核实。
选择能够解释业务增长的指标
把业务量与资源消耗建立联系，例如每秒成功请求与CPU、活跃任务与内存、每日新增文件与磁盘。不要只用访问人数预测全部资源，因为不同用户行为产生的负载差异很大。
假设网站增加视频附件，用户数量没有明显变化，但每日存储与下载量显著增长。这时按历史访问人数规划CPU，无法解释真正的容量压力。应跟踪业务结构变化，并重新测量每类请求的资源消耗。
对磁盘可以观察多个时间窗口的净增长，并考虑日志轮换、备份和批量删除。对应用吞吐则应使用测试或运行数据确认可接受延迟下的容量，不应把理论最大连接数当作可用业务能力。
预测至少包含正常和较高需求情景
根据近期趋势估算基础需求，再叠加已知活动、发布和批处理。预测不可能精确到每次请求，应保留合理区间，并注明数据时间范围和假设。
例如假设当前可用存储还有三百GB，近期每天净增长十GB，简单估算约三十天触及当前容量边界。但若月底有一次大规模导入，就不能继续按平滑日增长判断。还应为临时文件、扩容操作和故障恢复预留空间，不应等到数学上剩余零才行动。
Google的可靠上线章节强调在发布前检查依赖与容量准备。活动带来的负载既可能影响前端，也可能落在数据库、身份系统或外部接口，需要一并核对。可靠上线说明
把预测转成触发条件
一个可执行条件应包含指标、持续时间、预计触及边界的日期、负责人和动作。例如“按最近稳定增长预测，剩余空间将在资源上线准备周期内低于业务安全余量，因此启动扩容评估”。这比“磁盘超过八成看看”更容易推动具体工作。
还可以区分预警、准备和执行阶段。预警阶段核对数据与预算，准备阶段创建或预订资源，执行阶段完成迁移与验证。每一阶段应有停止条件，避免一次异常测量引发不必要采购。
扩容不一定增加机器。若瓶颈是低效查询、重复任务或无用日志，修正工作方式可能更合适。容量方案应比较可行改进，但不要在资源即将耗尽时把短期恢复完全押在尚未验证的优化上。
验证新增资源与故障余量
扩容后比较相近业务量下的延迟、错误率和资源压力，确认流量确实进入新资源。应用无法横向分配、共享数据库已满或会话仍固定旧节点，都可能让新增服务器没有解决瓶颈。
同时考虑一台节点失效后剩余资源能否承载关键负载。平时所有节点都接近上限的集群，即使总容量看起来充足，也可能缺少故障余量。具体保留多少应由业务目标和演练结果决定。
保存预测与实际增长的差异，定期修正模型。容量规划的成果是提前完成必要准备，并知道预测哪里不准确，而不是得到一条看起来平滑却没有执行责任人的曲线。