负载区间组合为云服务安排容量时，长期稳定的需求和短时波峰不宜用同一种方式处理。前者需要可预期的基础资源，后者适合按实际负载扩展；但弹性能力受启动时间、数据库承载和应用架构限制。小型团队可以先读懂自己的负载曲线，再决定底座大小和扩缩容边界，而不是根据单日峰值或平均值拍板。📈
汇总多个完整业务周期的CPU、内存、请求量、队列长度、延迟和错误率。将常态时段、促销或结算峰值、定时批任务分开标注。平均利用率可能掩盖短暂饱和，最大值又可能来自异常或监控噪声。可以用每小时分位数据观察“多数时间需要多少容量”和“高峰持续多久”，并确认采样期间是否包含业务高低峰。
示例：一个内部API工作日白天负载稳定，夜间只有短时导入任务。不要因为夜间低谷就缩到无法处理导入，也不要按导入瞬时峰值长期保持全部副本。先确认任务是否可以分批、延迟或由独立工作节点执行。
基础容量通常要承担常态流量、必要故障余量、滚动发布期间的副本，以及最低可用性要求。规划时不仅看CPU，也看内存、连接数、磁盘IO和下游限制。若单机故障后其余实例无法接管正常负载，底座就不是仅按平均流量计算的简单数量。
对全天运行、使用曲线长期平稳的服务，可评估固定实例或长期容量安排。比较前先确认承诺覆盖的地域、规格、操作系统、使用期限、调整条件和退出限制。把相同服务在实际账单口径下的基础容量费用，与当前按需运行情况作对照；考虑未来架构变化，避免为尚未稳定的需求锁定过多容量。
baseline_replicas可以表示常态副本数，但实际规划还需考虑故障时的可用余量。容量使用率持续偏低时，应查明是否规格过大或流量迁移；使用率长期偏高且延迟恶化时，先评估扩容或优化路径。不要把资源承诺本身当成业务容量策略。
选择能较早反映压力的信号，例如持续CPU、内存、请求延迟或队列积压。设置触发持续时间、冷却期、最大副本数和最低副本数，避免短暂波动造成频繁扩缩。新增实例的启动、镜像拉取、缓存预热和健康检查都需要时间；如果请求在扩容完成前已经超时，可提前配置最低容量或采用队列缓冲。
关键检查：弹性增加的是应用容量，数据库、外部API、文件存储配额和网络连接也必须能承受同步增长。
短时计算任务可以使用弹性资源，但任务要能安全中断、记录进度或从检查点恢复。重试前处理幂等，避免部分完成后重复写入。对于保存会话、上传临时文件或依赖本地磁盘的服务，要先把状态迁移到共享存储或数据库，不能因为实例可以扩缩就默认请求可任意切换。
设置任务并发上限，避免扩容让更多作业同时争抢同一数据库。若峰值由数据库查询造成，继续增加应用实例可能会让故障更严重；先查看慢查询、锁等待和连接池指标，定位瓶颈所在。
在代表性的平稳时段和高峰时段进行压测或安全回放，记录固定底座的常态延迟、扩容启动时间、队列排空速度和下游利用率。模拟一台实例故障、滚动升级和缩容过程，确认核心功能在容量变化期间仍可使用。测试数据应接近真实访问模式，但避免对生产依赖造成负担。
误区一：按平均CPU配底座，忽略峰值延迟。误区二：把弹性当作无限资源，未设置上限。误区三：扩了应用副本却没有计算数据库连接。误区四：一次短峰后立即扩大长期容量安排。建议每月比较基础容量利用率、弹性运行时长、服务指标和账单；遇到增长或流量结构改变，再重新校准组合。
提醒：弹性只解决可扩展的容量部分，启动耗时、数据库瓶颈和状态管理仍需独立设计。调整后持续观察服务指标与实际费用。
把每次调整的假设、观测周期和结果记入容量记录。即使规模不大，清楚知道哪些资源承担常态、哪些用于波峰，也能让成本变化和故障原因更容易解释。⚙️
