4. 容量规划流程：需求收集→基线建立→预测建模→规划决策→实施与验证的完整闭环
容量规划不是一次性的估算活动，而是一个持续迭代的工程闭环。本节将拆解从需求收集到验证反馈的五个核心阶段，确保每一阶段的产出可度量、可回溯、可驱动下一轮优化。
核心原则：容量规划必须与业务节奏对齐，避免“过度规划”造成资源浪费，也避免“规划不足”引发稳定性事故。闭环流程的核心在于“验证”环节反向修正预测模型。
4.1 五阶段闭环总览
完整的容量规划流程包含以下五个阶段，每个阶段都有明确的输入、输出和关键活动：
| 阶段 | 核心活动 | 关键产出 | 参与角色 |
|---|---|---|---|
| ① 需求收集 | 业务指标对齐、历史流量分析、未来活动计划 | 需求清单、增长假设、SLA/SLO 要求 | 业务方、产品经理、SRE |
| ② 基线建立 | 当前资源利用率、性能基准、瓶颈识别 | 容量基线报告、热点资源列表 | SRE、运维团队 |
| ③ 预测建模 | 趋势分析、回归模型、场景模拟 | 预测曲线、风险区间、扩缩容建议 | SRE、数据工程师 |
| ④ 规划决策 | 方案对比、成本评估、审批与排期 | 容量规划方案、预算申请、变更计划 | SRE、财务、技术负责人 |
| ⑤ 实施与验证 | 资源交付、配置变更、压测验证、监控反馈 | 变更记录、验证报告、模型修正项 | SRE、基础设施团队 |
4.2 阶段一：需求收集
需求收集是容量规划的起点，决定了后续所有工作的方向。此阶段的核心任务是将业务语言转化为技术容量需求。
- 业务指标对齐：与产品、运营团队确认未来 6-12 个月的业务增长目标（如 DAU、订单量、API 调用量）。
- 历史流量分析：提取过去 12 个月的峰值流量、日均流量、季节性波动模式。
- 特殊事件清单：大促、新品发布、营销活动、合规迁移等计划性事件。
- SLA/SLO 确认：明确各服务的延迟、可用性、吞吐量目标。
实践建议：需求收集阶段最容易出现“需求膨胀”或“需求遗漏”。建议使用三层确认法：业务方提出 → 技术团队评估 → 双方签字确认。避免口头承诺。
4.3 阶段二：基线建立
基线是容量规划的“标尺”。没有准确的基线，预测就是空中楼阁。基线建立需要覆盖以下维度：
| 维度 | 关键指标 | 采集工具/方法 |
|---|---|---|
| 计算资源 | CPU 利用率、内存使用率、Load Average | Prometheus + Node Exporter |
| 存储资源 | 磁盘 IOPS、吞吐量、容量使用率 | Grafana + 云监控 |
| 网络资源 | 带宽使用率、连接数、延迟 | Netdata、eBPF |
| 应用层 | QPS、RT、错误率、GC 频率 | APM（SkyWalking、Datadog） |
| 中间件 | 队列积压、连接池使用率、缓存命中率 | Redis Info、Kafka Burrow |
常见陷阱：基线数据采集周期过短（如只采集一周）会导致遗漏周末峰值或月末结算峰值。建议至少采集 3 个月的全量数据，并标记出所有异常事件（如故障、变更）以便剔除噪声。
4.4 阶段三：预测建模
预测建模是容量规划中最具技术挑战的环节。常用的建模方法包括：
- 线性回归：适用于增长趋势稳定的场景，如日活用户线性增长。
- 时间序列分析：使用 ARIMA、Prophet 等模型处理季节性波动和周期性模式。
- 场景模拟：基于“最坏情况”假设（如双倍流量、单机房故障）进行压力推演。
- 机器学习预测：对于复杂非线性模式，使用 XGBoost、LSTM 等模型。
4.5 阶段四：规划决策
基于预测结果，SRE 需要制定具体的容量规划方案，并推动决策落地。此阶段的核心产出包括：
- 资源扩缩容方案：明确新增/缩减的节点数、规格、时间窗口。
- 成本估算：对比不同云厂商、不同实例类型的成本差异。
- 风险预案：如果预测偏差超过 20%，应准备备用方案（如弹性伸缩策略）。
- 审批与排期：将方案提交技术委员会审批，并纳入变更排期。
决策矩阵示例：假设预测 QPS 增长 150%，现有集群最大承载 200% QPS。决策选项：① 提前扩容 50% 节点（成本高，安全）；② 依赖弹性伸缩（成本低，有延迟风险）；③ 混合方案：提前扩容 30% + 弹性伸缩 20%。推荐③。
4.6 阶段五：实施与验证
实施与验证是闭环的最后一环，也是最容易忽视的一环。没有验证的规划只是“纸上谈兵”。
| 活动 | 具体操作 | 验证标准 |
|---|---|---|
| 资源交付 | 通过 IaC（Terraform/Pulumi）创建或释放资源 | 资源状态与预期一致，无配置漂移 |
| 配置变更 | 更新负载均衡、限流阈值、HPA 策略 | 变更后服务无降级，错误率不上升 |
| 压力测试 | 使用压测工具模拟预测流量峰值 | 延迟在 SLO 范围内，无 OOM/CPU 打满 |
| 监控反馈 | 持续观察 48 小时，对比实际指标与预测曲线 | 偏差 < 10% 视为模型准确；偏差 > 20% 需修正模型 |
验证失败处理：如果压测发现容量不足，应立即执行弹性伸缩预案，同时标记预测模型为“需修正”。禁止在验证阶段“强行上线”并寄希望于后续优化——这违背了闭环的初衷。
4.7 闭环反馈机制
容量规划闭环的最终价值在于持续改进。每次闭环完成后，SRE 团队应输出一份《容量规划复盘报告》，包含以下内容：
- 预测准确率：实际峰值 vs 预测峰值的偏差百分比。
- 资源利用率变化：规划前后 CPU/内存/带宽利用率对比。
- 成本变化：实际支出 vs 预算的差异分析。
- 模型修正项：哪些假设需要调整，哪些数据源需要补充。
- 流程改进点：需求收集是否充分？基线数据是否完整？
推荐工具链：需求收集 → Jira/Confluence；基线建立 → Prometheus + Grafana；预测建模 → Jupyter Notebook + Prophet；规划决策 → 内部 Wiki + 审批流；实施验证 → Terraform + Jenkins + K6。将整个流程工具化、自动化，减少人工操作带来的偏差。