capacity-planning

容量规划技能

为服务编写完整的容量规划文档。容量规划并非要精确预测未来，而是要了解当前的余量、建模增长情况，并确保团队在资源限制演变成事故之前采取基础设施行动。

一份好的容量规划应回答：什么资源最先耗尽？多久会耗尽？解决问题的成本是多少？由谁决定何时采取行动？

所需输入

如果尚未提供，请询问以下信息：

• 服务名称和描述——服务的用途，以及依赖该服务的对象
• 当前流量和使用指标——每秒（或每天）请求数、活跃用户数、数据量等，选择最适合该服务的单位
• 当前资源利用率——CPU 使用率、内存使用率、磁盘使用量、连接池利用率、数据库查询吞吐量
• 增长率或预测——历史增长率，或已知的近期事件（产品发布、销售周期、季节性高峰）
• 技术栈和基础设施——云服务提供商、计算类型（虚拟机、容器、无服务器）、数据库、缓存层、CDN
• 成本限制——当前基础设施支出、可接受的成本上限，或目标流量单位成本

输出格式

---

容量规划：[服务名称]

服务： [名称] | 团队： [团队名称] 作者： [姓名] | 最后更新： [日期] 规划周期： [12 个月——[月份 年份] 至 [月份 年份]] 审查频率： [每季度]

---

1. 执行摘要

[用 3–5 句话概述：当前状况、最关键的容量限制、该限制成为风险前的时间、建议采取的行动，以及成本影响。面向需要了解关键信息、无需阅读全文的工程经理或副总裁。]

关键发现： [例如：“按当前增长速度，数据库连接池将在 6 周内达到 90% 的利用率。如不采取行动，正常流量下将导致请求排队和延迟飙升。”]

建议立即采取的行动： [例如：“在接下来的 2 周内提高连接池上限并添加一个只读副本。”]

预计成本影响： [例如：“建议的更改将使基础设施支出每月增加约 $[X]。”]

---

2. 当前基线

除非另有说明，所有指标均为 30 天平均值。数据采集日期：[日期]

流量

指标	数值	峰值（7 天）	备注
每秒请求数（平均）	[X req/s]	[X req/s]	[高峰时段 / 星期几]
每天请求数	[X M/day]	[X M/day]	—
活跃用户数（DAU/MAU）	[X] / [X]	—	—
[服务特定指标——例如每小时处理的任务数]	[X]	[X]	—
[服务特定指标——例如每天摄取的 GB 数]	[X GB]	[X GB]	—

计算资源

资源	当前利用率	实例类型	数量	备注
CPU（平均）	[X%]	[例如 c5.2xlarge]	[X]	峰值：[X%]
内存（平均）	[X%]	—	—	峰值：[X%]
网络出站流量	[X Mbps]	—	—	—
容器 / Pod 数量	[X]	[例如 2 vCPU / 4 GB]	—	自动扩缩范围：[X–Y]

数据库

资源	当前利用率	规格	备注
CPU	[X%]	[例如 db.r5.2xlarge]	峰值：[X%]
内存	[X%]	[X GB RAM]	—
已用存储	[X GB]（共 [Y GB]，[Z%]）	[已预置 X GB]	增长：[每月约 X GB]
IOPS（平均）	[X]（共 [Y 个已预置]）	[Y IOPS]	峰值：[X IOPS]
连接池	[X]（共 [Y 个上限]，[Z%]）	最大连接数：[Y]	[ORM 连接池大小：X]
查询 P99 延迟	[X ms]	—	[最慢查询：X]
读写比例	[X%] 读取 / [Y%] 写入	—	—

缓存

资源	当前利用率	规格	备注
已用内存	[X GB]（共 [Y GB]，[Z%]）	[例如 cache.r6g.large]	驱逐率：[X%]
命中率	[X%]	—	未命中率：[Y%]
连接数	[X]	上限：[Y]	—

存储 / 对象存储

资源	当前用量	增长率	备注
[S3 / GCS / Blob]	[X GB / TB]	[~X GB/month]	[是否已设置生命周期策略？Y/N]
磁盘（如适用）	[X GB] / [Y GB]	[~X GB/month]	[RAID / EBS 类型]

成本基线

组件	当前月成本	占总成本比例
计算（应用服务器）	$[X]	[X%]
数据库	$[X]	[X%]
缓存	$[X]	[X%]
存储	$[X]	[X%]
CDN / 带宽	$[X]	[X%]
其他（[描述]）	$[X]	[X%]
总计	$[X]	100%

单位经济效益： 每 [1,000 次请求 / 1,000 名用户 / GB 处理量] $[X]

---

3. 增长预测

假设

假设	值	来源	置信度
月流量增长率	[X%]	[历史趋势 / 产品预测]	[高 / 中 / 低]
季节性峰值系数	[[月]增加 +X%]	[去年的数据 / 预期发布]	[高 / 中]
即将到来的活动	[例如：营销活动 — [月份]，预计流量激增 +[X]%]	[营销计划]	[中]
用户增长	[每月新增 X 名用户]	[销售管道 / 增长模型]	[中]
数据增长	[X GB/month]	[当前趋势]	[高]

流量预测

时间范围	Req/s（平均）	Req/s（峰值）	DAU	数据量（累计）
现在（基线）	[X]	[X]	[X]	[X GB/TB]
+3 个月	[X]	[X]	[X]	[X GB/TB]
+6 个月	[X]	[X]	[X]	[X GB/TB]
+12 个月	[X]	[X]	[X]	[X GB/TB]

增长公式：[基线] × (1 + [月增长率])^[月数] + 季节性调整

容量余量分析

按当前利用率和预测增长率，各项资源何时会耗尽？

资源	当前利用率	安全上限	剩余余量	达到上限的月数
应用 CPU	[X%]	70%	[X%]	[X 个月]
应用内存	[X%]	80%	[X%]	[X 个月]
DB CPU	[X%]	70%	[X%]	[X 个月]
DB 存储	[X GB] / [Y GB]	80% = [Z GB]	[X GB]	[X 个月]
DB IOPS	[X] / [Y]	80% = [Z]	[X IOPS]	[X 个月]
DB 连接数	[X] / [Y]	80% = [Z]	[X]	[X 个月]
缓存内存	[X GB] / [Y GB]	75% = [Z GB]	[X GB]	[X 个月]
存储（对象存储）	[X TB]	无硬性上限 — 成本触发阈值	—	[成本触发阈值：$X/month]

风险提示（将在 3 个月内触及上限的资源）：

• [资源]：[当前值]% → [X 周]后达到上限 — 需要采取行动
• [资源]：[当前值]% → [X 周]后达到上限 — 需要采取行动

---

4. 资源需求

计算资源需求

时间范围	所需实例数	推荐实例类型	自动扩缩范围	备注
现在	[X]	[type]	[min: X, max: Y]	当前配置
+3 个月	[X]	[type]	[min: X, max: Y]	[是否需要更换实例类型？]
+6 个月	[X]	[type or upgrade]	[min: X, max: Y]	[考虑[更大规格 / 水平扩展]]
+12 个月	[X]	[type or upgrade]	[min: X, max: Y]	[水平扩展与垂直扩展决策的进展]

内存余量目标： 平均负载下保持 ≥30% 可用内存；峰值时保持 ≥20%。 CPU 余量目标： 平均负载下保持 ≥30% 可用 CPU；峰值时保持 ≥15%。

数据库需求

时间范围	实例类型	存储	IOPS	只读副本	备注
现在	[type]	[X GB]	[X]	[Y/N]	当前配置
+3 个月	[type]	[X GB]	[X]	[Y/N]	[升级存储 / IOPS]
+6 个月	[type or upgrade]	[X GB]	[X]	是	[到此时建议添加只读副本]
+12 个月	[type]	[X GB]	[X]	[X replicas]	[达到此规模时考虑分片 / 分区]

存储增长管理：

• 当前增长： [~X GB/month]
• 存储自动扩展：[已启用 / 未启用 — 在 [date] 前启用]
• 归档策略：[将超过 X 个月的记录移至 [冷存储 / 归档层]]

缓存需求

时间范围	节点类型	节点数	内存	备注
现在	[type]	[X]	[X GB]	当前
+6 个月	[type]	[X]	[X GB]	[横向扩展或升级]
+12 个月	[type]	[X]	[X GB]	[若需要的内存 >Y GB，则使用集群模式]

---

5. 扩展策略

计算 — 横向扩展

决策：[横向 / 纵向 / 两者兼用]

[说明扩展策略及其原因。例如：“应用是无状态且受 CPU 限制；优先采用横向扩展。纵向扩展仅作为短期备用方案。”]

自动扩缩配置：

Scale-out trigger:  CPU > [X%] for [Y minutes] OR memory > [X%] for [Y minutes]
Scale-in trigger:   CPU < [X%] for [Y minutes] AND memory < [X%] for [Y minutes]
Min instances:      [X] (ensures HA across [X] AZs)
Max instances:      [Y] (cost ceiling)
Cooldown period:    [X seconds]
Warmup time:        [X seconds] (time for new instance to be healthy)

横向扩展的限制：

• [例如：数据库连接池是当前瓶颈——如果不增加数据库连接，增加更多应用实例也无济于事]
• [例如：WebSocket 连接需要会话亲和性——这会限制纯无状态扩展]

数据库 — 读扩展

策略：[只读副本 / 通过 PgBouncer 进行连接池管理 / 查询缓存 / 暂不需要]

添加只读副本的时机：

• 数据库 CPU 持续超过 60% 且超过 30 分钟，或
• 读查询 P95 延迟超过 50ms，或
• 连接池利用率超过 70%

连接池管理：

• 连接池工具：[PgBouncer / RDS Proxy / 应用级 / 未配置]
• 连接池大小：[每个应用实例 X 个连接 × Y 个实例 = 总计 Z 个]
• 最大数据库连接数：[配置为 Z + 20% 余量]

缓存策略

缓存策略：[旁路缓存 / 写穿 / 写回] TTL 策略：

数据类型	TTL	失效方法
[例如：用户个人资料]	[5 分钟]	[更新时显式失效]
[例如：产品目录]	[1 小时]	[TTL 到期——可接受最终一致性]
[例如：会话数据]	[24 小时]	[注销时显式失效]

缓存未命中处理：[说明缓存未命中时会发生什么——是否能平稳回退，还是存在惊群风险？]

---

6. 成本预测

基础设施成本预测

组件	现在（月度）	+3 个月	+6 个月	+12 个月
计算	$[X]	$[X]	$[X]	$[X]
数据库	$[X]	$[X]	$[X]	$[X]
缓存	$[X]	$[X]	$[X]	$[X]
存储	$[X]	$[X]	$[X]	$[X]
CDN / 带宽	$[X]	$[X]	$[X]	$[X]
总计	$[X]	$[X]	$[X]	$[X]
月环比增长 %	—	[X%]	[X%]	[X%]

单位经济趋势：

时间范围	每 1k 次请求的成本	每用户每月成本	备注
现在	$[X]	$[X]	基准
+6 个月	$[X]	$[X]	[改善 / 恶化——原因]
+12 个月	$[X]	$[X]	[目标：每 1k 次请求 $X]

成本优化机会：

机会	预计节省	工作量	时间安排
[例如：为基准计算资源预留实例]	$[X/month]	低	立即
[例如：S3 生命周期策略——将超过 90 天的对象转移至 Glacier]	$[X/month]	低	本迭代
[例如：调整 [instance] 规格——当前配置过高]	$[X/month]	低	本迭代
[例如：优化排名前 5 的慢查询——降低数据库计算需求]	$[X/month]	中	下个季度

---

7. 容量触发条件与操作

定义需要采取明确行动的阈值，而不是在事件发生后再补救。

资源	关注（黄色）	行动（红色 — 安排工作）	紧急（存在事件风险）
应用 CPU（持续平均值）	>60%	>70%	>85%
应用内存	>70%	>80%	>90%
DB CPU	>55%	>65%	>80%
DB 存储	>65%	>75%	>85%
DB 连接数	>60%	>70%	>85%
缓存内存 / 驱逐	命中率 <90%	命中率 <85%	命中率 <75%
错误率	>0.5%	>1%	>2%
P99 延迟	>基线的 2 倍	>基线的 3 倍	>基线的 5 倍

超过关注阈值时：

• 发现问题的工程师创建带有容量标签的工单
• 在下一次 Sprint 规划中审查工单

超过行动阈值时：

• 值班工程师创建标记为 P2 的工单
• 技术负责人在 24 小时内审查
• 在 1 个 Sprint 内记录并安排行动计划

超过紧急阈值时：

• 视为潜在事件 — 通知值班人员
• 立即执行紧急扩容操作（参见运行手册）
• 在 2 小时内开始根因调查

紧急扩容运行手册： [容量事件的 oncall-runbook 链接]

---

8. 基础设施行动路线图

立即行动（接下来 2 周）

行动	负责人	工作量	理由
[例如：将 DB 连接池上限提高至 X]	[姓名]	[2 小时]	[DB 连接数已达 X% — X 周后将触及上限]
[例如：在 RDS 上启用存储自动扩缩]	[姓名]	[30 分钟]	[存储已达 X% — 可防止 X 个月后出现紧急情况]
[例如：为 [bucket] 添加 S3 生命周期策略]	[姓名]	[1 小时]	[存储无谓地以每月 $X 的速度增长]

本季度（3 个月内）

行动	负责人	工作量	理由
[例如：为生产 DB 添加只读副本]	[姓名]	[1 天]	[预计 2 个月后 DB CPU 将达到 65%]
[例如：将自动扩缩上限从 X 提高至 Y]	[姓名]	[2 小时]	[当前上限与预期峰值过于接近]
[例如：配置 PgBouncer 以进行连接池管理]	[姓名]	[3 天]	[降低每个连接的开销；为增长预留空间]

下季度（3–6 个月）

行动	负责人	工作量	理由
[例如：升级 DB 实例类型 — [当前] → [下一档]]	[姓名]	[2 小时 — 蓝绿部署]	[预计到 Q[X] 时 DB CPU 将达到 70%]
[例如：为 [高读取量端点] 实施缓存]	[姓名]	[1 周]	[预计将 DB 读取负载降低 [X%]]
[例如：评估 DB 水平分片]	[姓名]	[2 周（试验）]	[按 12 个月预测，单个 DB 将触及上限]

远期（6–12 个月）

行动	说明	触发条件
[例如：多区域部署]	[在 eu-west-2 设置主备部署]	[DAU 超过 X 或 SLA 要求达到 99.99%]
[例如：数据库分片或迁移到分布式 DB]	[评估 CockroachDB / Vitess]	[预计单节点 DB 将触及上限]
[例如：扩展 CDN]	[在 [region] 增加 PoP]	[[geography] 的延迟 SLO 未达标]

---

反模式

• 不要在不了解基线的情况下设定容量触发阈值 — 如果不知道正常情况是什么，“CPU > 70%”警报就毫无意义
• 不要只针对平均流量做规划 — 不对峰值负载建模的容量规划，会导致在最重要的活动期间发生事件
• 不要混淆垂直扩缩和水平扩缩 — 只增加应用服务器而不解决数据库连接数限制，无法消除瓶颈
• 不要把增长预测说成确定事实 — 所有预测都存在不确定性；应说明置信度，并提供保守和乐观两种情景
• 不要在没有指定负责人和具体日期的情况下推迟行动事项 — 没有负责人的路线图只是一张愿望清单

质量检查

• 每项资源都注明当前使用率和预计达到上限的月数，并量化说明，不得含糊其辞
• 在执行摘要中指出最关键的约束，并给出具体时间线
• 增长预测说明其假设和置信度，不得将预测表述为确定事实
• 容量触发条件明确规定黄色／红色阈值，并说明各级别由谁采取行动
• 成本预测包含单位经济效益，而不仅是总金额
• 基础设施路线图列明负责人和工作量估算，而非仅仅罗列愿望
• 自动扩缩配置同时包含扩容和缩容触发条件，以及最小值／最大值范围
• 按紧急程度排列行动事项；真正紧急的事项应列为立即处理，而非充数的待办项

示例触发语句

• “规划基础设施容量。”
• “预测资源需求。”
• “建模流量增长。”
• “制定扩缩策略。”
• “为某项服务编写容量评估。”