容量规划需建立成本-收益映射关系，按业务域拆解资源消耗，构建三层成本归集模型，以业务指标反推容量阈值，并通过动态校准实现闭环管理。
容量规划要真正落地见效，不能只算“服务器能跑多少QPS”，必须把硬件采购、日常运维和业务实际产出串起来看。核心是建立一个可追踪、可拆解、可回溯的成本-收益映射关系，而不是分别列三张表再简单加总。
按业务单元拆解资源消耗
先打破“整套系统共用资源”的惯性思维。比如一个电商中台，要把订单、商品、用户、营销四个核心域的资源使用单独剥离：
- 用APM工具（如SkyWalking）打标所有接口，按业务域+功能类型（读/写/批处理）归类调用量与响应耗时
- 数据库层面通过schema或逻辑库隔离，结合performance_schema统计各域SQL执行次数、IO量、锁等待时间
- 存储层按bucket或命名空间区分数据归属，自动标记冷热属性与生命周期阶段
这样就能得出“订单域日均消耗CPU 2.1核时、SSD IO 8400次、带宽1.2GB”，为后续核算提供原子单位。
构建三层成本归集模型
把成本按发生逻辑分层归集，避免笼统摊销：
- 直接资源成本：云实例按秒计费明细（含GPU/内存/网络）、本地设备折旧（按5年直线法+实际开机时长加权）、对象存储按访问频次分级计费（标准/低频/归档）
- 运维作业成本：自动化脚本运行次数（如每日备份、索引优化）、人工干预工单量（如扩容审批、故障复盘）、监控告警处理耗时（按SLA等级折算人力单价）
- 业务机会成本：因容量不足导致的订单超时率（每升高0.1%损失多少GMV）、因弹性不足错失大促流量（参考历史峰值转化漏损）、因延迟交付影响客户续约（按合同金额折算）
用业务指标反推容量阈值
不以技术参数为终点，而以业务结果为标尺设定容量红线：
- 订单创建接口P95响应时间≤300ms → 对应数据库写QPS上限=当前值×1.3，再倒推所需IOPS与buffer pool大小
- 大促期间支付成功率≥99.95% → 按历史失败请求特征（如库存扣减超时占比62%），锁定库存服务CPU与Redis连接池瓶颈，定向扩容
- 新功能上线后用户停留时长提升目标15% → 预估新增埋点数据量与实时计算负载，提前配置Flink任务槽位与Kafka分区数
每个容量决策背后都对应明确的业务影响函数，例如“增加1TB SSD存储，预计支撑未来6个月用户行为日志增长，保障推荐模型特征新鲜度，预估提升点击率0.8%”。
动态校准与闭环反馈
每月用实际数据验证模型准确性：
- 对比预测容量与实际峰值偏差（如预测CPU峰值85%，实测92%，则调整安全系数）
- 核算单位业务产出的成本变动（如单笔有效订单的资源成本从¥0.32降至¥0.27，下降15.6%）
- 识别非技术驱动的成本波动（如某次版本上线后慢SQL激增，导致DBA介入工单翻倍，暴露代码规范问题）
把容量规划从年度静态计划，变成嵌入CI/CD流程的常态化动作——每次发布前自动触发资源影响评估，每次复盘会固定分析容量相关根因。
