容量规划是贯穿架构演进全过程的动态校准机制，需按标准化、云化、解耦架构三阶段分层建模，匹配不同资源约束与粒度；演练须覆盖真实业务链路依赖，健康度指标应聚焦碎片率、弹性衰减指数和演进适配度，以暴露架构断点而非仅验证资源余量。
容量规划不是一次性算数，而是贯穿架构演进全过程的动态校准机制。它必须与基础设施的阶段性能力匹配，不能用单点模型套用全生命周期。
按架构层级分层建模
不同演进阶段的资源约束差异巨大，需对应不同建模粒度：
- 标准化阶段（物理/虚拟化）：以服务器CPU核数、内存插槽数、SAN端口带宽为基本单位，结合历史负载曲线做线性外推，预留20%冗余；重点验证IO吞吐瓶颈是否出现在HBA卡或存储阵列前端口
- 云化阶段（IaaS/PaaS）：转向服务实例维度建模，例如每100个并发用户需1个中型容器实例+20GB对象存储+500 IOPS块存储；需接入监控系统实时采集Pod CPU request/limit比值、节点内存水位、API网关响应延迟P95
- 解耦架构阶段（如戴尔Disaggregated方案）：容量不再绑定整机，而按计算单元（CPU模块）、内存池、NVMe资源池独立建模；此时要关注跨资源池调度延迟对SLA的影响，例如GPU推理任务若跨NUMA节点调用内存，时延可能上升40%
演练必须覆盖真实业务流而非单纯压测
传统压力测试只验证峰值吞吐，但现代架构演进中的容量风险更多来自链路依赖和状态迁移：
- 在同城双活切换演练中，同步验证数据库主从延迟、缓存穿透阈值、服务注册中心节点重发现耗时——这些指标共同决定RTO是否真能控制在分钟级
- 升级至云原生平台后，演练需包含“灰度发布期间突发流量涌入”场景：观察Service Mesh中sidecar CPU占用突增是否触发自动扩缩容，以及新旧版本服务间mTLS握手失败率是否超阈值
- 桌面云从VDI向Cloud PC演进时，演练重点不是并发登录数，而是GPU切片资源争抢下，CAD用户与AI训练用户的帧率抖动是否超出可接受范围（如>15ms）
建立容量健康度指标闭环
避免只看“是否够用”，要识别“是否可持续”：
- 碎片率：虚拟化环境中已分配但未使用的vCPU比例＞35%，说明资源调度策略失效，需检查DRS规则或VM规格模板是否过粗
- 弹性衰减指数：同一业务在云平台连续三次扩容响应时间超过基线值2倍，提示底层存储或网络存在隐性瓶颈，需触发CMDB关系图谱分析（如某类应用总关联到特定存储网关）
- 演进适配度：新引入的解耦硬件在6个月内被用于承载核心交易系统比例＜10%，反映抽象层设计未对齐业务关键路径，需回溯IaC模板中资源标签策略
容量规划的价值不在预测绝对数值，而在暴露架构断点。每次演进前用容量模型反推当前瓶颈，比直接堆资源更能逼近真实韧性。
