📚 课程目录第4章资源规划基础

4. 资源规划基础：容量规划、需求预测、资源生命周期管理

4.1 核心原理：从“被动扩容”到“主动规划”

基础设施成本失控的起点，往往不是某一次采购决策失误，而是长期缺乏系统性的资源规划。大多数团队采用“告警驱动”的被动模式：CPU 达到 85% 才加节点，磁盘将满才扩卷，流量高峰前临时采购。这种模式看似稳妥，实则将成本决策权交给了瞬时流量，而非业务增长曲线。

资源规划的本质，是在“供给成本”与“业务风险”之间寻找动态平衡点。其核心原理包含三个相互咬合的环节：

容量规划（Capacity Planning）：回答“未来需要多少资源”，将业务指标（如订单量、API 调用量）转换为基础设施规格（vCPU、内存、存储 IOPS）。
需求预测（Demand Forecasting）：回答“业务何时增长、增长多少”，基于历史趋势、季节性、营销日历建立预测模型。
资源生命周期管理（Lifecycle Management）：回答“资源从创建到回收的每个阶段如何控制成本”，包括采购、部署、运行、扩缩容、回收五个阶段。

三者构成闭环：预测驱动容量规划，容量规划产生资源实例，生命周期管理反馈实际用量数据，再修正预测模型。缺少任何一环，都会导致成本黑洞——要么过度预留造成浪费，要么预留不足引发故障后紧急加购，支付溢价。

关键认知：成本优化的最高杠杆点不在“砍掉闲置实例”，而在“规划阶段就避免创建不必要的实例”。一个未被创建的实例，其节省的成本是 100%；一个被回收的闲置实例，节省的是 70%（因为已支付了部分周期费用）。

4.2 方法流程：四步建立资源规划体系

资源规划不是一次性的“年度预算会议”，而是一个持续运转的流程。推荐按以下四个步骤落地：

定义业务指标与资源映射模型：明确每个业务单元的关键驱动指标（如“每秒订单数”“日活用户数”），并建立到资源规格的换算关系。例如：每 1000 订单/秒需要 32 vCPU 与 64GB 内存（含 20% 安全余量）。
采集基线数据并建立预测：至少收集 6 个月的历史监控数据（业务指标 + 资源用量），识别周期规律。使用移动平均或指数平滑法预测未来 3-6 个月的需求曲线。
制定容量计划与预算：将预测需求转换为各资源池（计算、存储、网络）的容量计划，区分“刚性需求”（必须预留）与“弹性需求”（可按需扩缩）。据此生成采购预算与预留实例策略。
执行生命周期策略并持续校准：为每个资源打上生命周期标签（如 env=prod、owner=payment、expire=2025-12-31），设置自动回收与降配规则。每月对比预测与实际用量，调整模型参数。

阶段	关键动作	输出物	常见工具
需求预测	历史数据清洗、趋势分解、季节性识别	未来 3-6 月业务量预测曲线	Prometheus + 自研脚本、AWS Forecast
容量规划	业务量→资源规格换算、峰值叠加	各资源池容量计划表	Excel/Google Sheets、Terraform 计划
预算编制	按需/预留/Spot 组合优化、折扣测算	月度/季度云成本预算	AWS Cost Explorer、Azure 成本管理
生命周期执行	标签管理、自动扩缩容、闲置回收	资源清单 + 回收报告	AWS Lambda + Tag Editor、Kubernetes HPA

4.3 案例：电商平台“双11”容量规划复盘

某电商平台在 2023 年“双11”大促前，基于 2022 年同期数据进行了资源规划。2022 年“双11”当天峰值订单量为 120 万单/小时，实际消耗计算资源 480 vCPU。2023 年业务预期增长 40%，因此初步估算需要 672 vCPU。

规划团队没有直接按 672 vCPU 采购，而是进一步分析了流量特征：

大促流量集中在 0:00-0:30 和 10:00-12:00 两个窗口，其余时段仅为峰值的 30%；
2022 年实际峰值出现在 0:05，但系统自动扩容有 8 分钟延迟，导致短暂限流；
购物车服务和订单服务对 CPU 的消耗比例不同，不能简单按总量扩容。

最终方案是：预留 500 vCPU 作为基线容量（覆盖非峰值时段），配置 200 vCPU 的定时扩容（提前 30 分钟在峰值窗口前扩容），剩余部分依赖弹性伸缩（响应时间 < 3 分钟）。同时将购物车服务与订单服务拆分为独立的伸缩组，避免相互挤占。

# 弹性伸缩配置示例（伪代码）
scaling_policy:
  service: order-service
  baseline: 500 vCPU    # 预留实例
  scheduled_actions:
    - time: "2023-11-10 23:30"
      add: 150 vCPU     # 提前扩容
    - time: "2023-11-11 00:30"
      remove: 100 vCPU  # 峰值后收缩
  dynamic_rules:
    - metric: cpu_utilization
      threshold: 70%
      add: 20 vCPU
      cooldown: 300s

实际运行结果：峰值订单量 168 万单/小时（增长 40%），实际最大消耗 640 vCPU，未触发限流。相比“直接预留 672 vCPU”的方案，节省了约 15% 的预留实例成本，同时避免了 8 分钟扩容延迟导致的流量损失。

4.4 误区与复盘：资源规划中的常见陷阱

误区一：预测越精确越好。预测模型复杂度越高，对历史数据的“过拟合”风险越大。某团队引入机器学习预测模型，准确率达到 92%，但模型每次重训练需要 3 天，且对突发流量（如社交媒体爆款视频带来的访问激增）毫无反应。实际生产中，“70% 准确率 + 快速弹性伸缩”往往比“95% 准确率 + 僵化的容量计划”更经济。

误区二：只规划计算资源，忽略存储与网络成本。一个典型的微服务应用，其存储成本（云盘、数据库、对象存储）可能占总基础设施成本的 40%-60%。但多数容量规划只关注 vCPU 和内存。某 SaaS 公司发现，其数据库存储空间以每月 15% 的速度增长，但 80% 的数据是超过 2 年的日志，从未被读取。通过建立数据生命周期策略（热数据保留 30 天，温数据 6 个月，冷数据转归档存储），存储成本降低了 55%。

复盘要点：每次大促或业务高峰后，应进行“规划 vs 实际”的差异分析。重点关注三个指标：预测偏差率（实际用量/预测用量）、资源利用率峰值（反映预留是否过度）、弹性伸缩触发次数（反映动态策略是否有效）。将这些数据归档，作为下一轮预测的输入。资源规划不是“一次性工程”，而是需要持续迭代的运营能力。

资源生命周期管理的关键在于“终态思维”——在创建资源的那一刻，就应该明确它的过期时间、负责人和回收条件。建议为所有资源强制添加 ttl（生存时间）标签，并由自动化任务定期扫描，对即将过期的资源发送提醒，对已过期且无流量的资源直接回收。只有将“回收”作为与“创建”同等重要的操作，才能真正实现成本的可控与可持续优化。