深色模式
容量报告模板
容量报告的作用是把一次性的计算变成可复审、可交接的资产。本文给出标准模板，复制改数字即可用。
适用环境
- 已有监控数据与压测结果
- 服务负责人明确、业务增长目标已知
- 需要按月/季度向团队同步容量状态
bash
# 报告所需的原始数据，建议统一存到一个目录
mkdir -p capacity-report/2026Q4 && cd capacity-report/2026Q41
2
2
操作步骤
1. 建立报告目录
bash
capacity-report/2026Q4/
├── README.md # 报告正文（用下面模板）
├── metrics/ # 导出的监控数据
│ ├── qps-90d.json
│ ├── cpu-90d.json
│ └── disk-90d.json
└── benchmark/ # 压测原始输出
└── wrk-20261009.txt1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
2. 复制模板正文
markdown
# 容量报告 - <服务名> - <2026Q4>
## 1. 基本信息
| 项 | 内容 |
| --- | --- |
| 服务 | order-api |
| 负责人 | <姓名> |
| 报告日期 | 2026-10-09 |
| 复审日期 | 2026-12-09 |
| 架构 | 无状态，8 实例，跨 2 可用区 |
## 2. 业务需求
| 指标 | 当前 | 3 个月后 | 依据 |
| --- | --- | --- | --- |
| 日订单 | 500 万 | 650 万 | 业务方目标 +30% |
| 峰值 QPS | 2900 | 3770 | 负载模型推算 |
| 目标 P99 | 300 ms | 300 ms | SLO |
## 3. 现状水位（近 30 天峰值）
| 资源 | 峰值使用 | 总量 | 水位 | 判定 |
| --- | --- | --- | --- | --- |
| CPU | 12.4 核 | 32 核 | 39% | 正常 |
| 内存 | 42 GB | 64 GB | 66% | 关注 |
| 磁盘 | 1.2 TB | 2 TB | 60% | 正常 |
| DB 连接 | 180 | 300 | 60% | 正常 |
| 出向带宽 | 620 Mbps | 1000 Mbps | 62% | 关注 |
## 4. 单机能力（压测结论）
| 项 | 值 | 条件 |
| --- | --- | --- |
| 单机 QPS 上限 | 600 | P99 < 300ms，错误率 < 0.1% |
| 线性区 | ≤ 85% CPU | 超过后延迟陡增 |
| 单机安全 QPS | 420 | 上限 × 70% 水位 |
## 5. 容量结论
| 项 | 计算 | 结果 |
| --- | --- | --- |
| 理论实例数 | 2900 / 420 | 7 台 |
| 加 N+1 冗余 | +1 | 8 台 |
| 现状 | 8 台 | 匹配 |
| 3 个月后需求 | 3770 / 420 + 1 | 10 台 |
## 6. 瓶颈与风险
| 风险 | 影响 | 概率 | 缓解措施 | 负责 |
| --- | --- | --- | --- | --- |
| DB 连接池 60% | 扩容应用后打满 | 中 | 引入连接池复用 | <姓名> |
| 出向带宽 62% | 大促打满 | 中 | CDN 卸载静态资源 | <姓名> |
## 7. 行动项
- [ ] 引入 pgbouncer，降低连接数 50%（截止 2026-11-15，<姓名>）
- [ ] 静态资源接入 CDN，目标降低出向 40%（截止 2026-11-30，<姓名>）
- [ ] 压测复测单机能力（截止 2026-12-05，<姓名>）
## 8. 上次预测复核
| 项 | 上次预测 | 实际 | 偏差 |
| --- | --- | --- | --- |
| 峰值 QPS | 2600 | 2900 | +11.5% |
| 实例数 | 7 | 8 | +14% |
| 结论 | 模型可用，峰值系数从 5 调为 6 | | |1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
3. 用脚本自动生成水位表格
bash
#!/usr/bin/env bash
# gen_watermark.sh - 生成 CPU/内存/磁盘水位
PROM=${PROM:-http://localhost:9090}
q() {
curl -s -G "$PROM/api/v1/query" --data-urlencode "query=$1" \
| jq -r '.data.result[0].value[1] // "N/A"'
}
cpu=$(q 'max_over_time((1 - sum(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) / count(node_cpu_seconds_total{mode="idle"}) by (instance))[30d:5m])')
mem=$(q 'max_over_time((1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)[30d:5m])')
disk=$(q 'max_over_time(((node_filesystem_size_bytes{mountpoint="/data"} - node_filesystem_avail_bytes{mountpoint="/data"}) / node_filesystem_size_bytes{mountpoint="/data"})[30d:5m])')
printf '| 资源 | 30天峰值水位 |\n| --- | --- |\n'
printf '| CPU | %.1f%% |\n' "$(echo "$cpu * 100" | bc -l)"
printf '| 内存 | %.1f%% |\n' "$(echo "$mem * 100" | bc -l)"
printf '| 磁盘 | %.1f%% |\n' "$(echo "$disk * 100" | bc -l)"1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
bash
chmod +x gen_watermark.sh && ./gen_watermark.sh1
4. 定好复审节奏
text
月度：自动跑水位脚本，超过 70% 才出报告
季度：完整报告（含压测复测）
大促前：专项容量评估
架构变更后：重新压测并更新单机能力1
2
3
4
2
3
4
验证
报告完成后自检 6 项：
bash
# 1) 水位数字来自脚本而非记忆
# 2) 单机能力有压测输出文件支撑
# 3) 需求数字有业务来源备注
# 4) 每个风险都有负责人和截止日期
# 5) 有上次预测 vs 实际的复核
# 6) 复审日期已写
ls capacity-report/2026Q4/1
2
3
4
5
6
7
2
3
4
5
6
7
常见坑
报告只写结论不写依据
三个月后没人记得 2900 QPS 是怎么来的。每个关键数字后面都要注明来源（监控/压测/业务方）。
只写当前不写预测
容量报告的价值在于提前量。必须包含未来 3 个月的需求预测和对应的行动项。
没有复核上次预测
不复核就意味着模型永远不会变准。每次报告都要对比上次预测与实际的偏差，并据此修正系数。
行动项没有负责人和截止日
"后续优化"等于不会做。每条行动项必须写成「动作 + 截止日期 + 负责人」。