capacity-planning-analysis git:20260915.bc5a8d6A

Immutable. This exact content never changes and is served at /api/v1/blob/0182a825992a378d.

---
name: capacity-planning-analysis
description: Use this skill when you need to produce a structured capacity planning report with load models, headroom analysis, scaling triggers, and risk assessment; triggers include 容量规划, 容量分析, 容量规划分析, and capacity planning analysis.
---

# 容量规划分析

## 何时使用

- 用户提供业务负载、资源利用率或增长假设，需要生成**结构化的容量规划报告**。
- 需要评估现有方案的风险、识别瓶颈、给出扩容建议。

## 输入要求

| 必填 | 字段 | 说明 |
|------|------|------|
| ✅ | 业务场景 | 核心接口/服务、用户量、流量模式 |
| ⬜ | 历史数据 | QPS、并发、响应时间、错误率 |
| ⬜ | 资源信息 | CPU/内存/磁盘/带宽的当前利用率 |
| ⬜ | SLO 目标 | 可用性、响应时间、吞吐量要求 |
| ⬜ | 增长预期 | 用户增长计划、大促/活动信息 |
| ⬜ | 扩缩容策略 | 当前的扩缩容方式和限制 |

## 执行流程

### 1. 输入审计

- 检查业务场景是否清晰（哪些接口、什么流量模式）
- 检查是否有任何量化数据（哪怕是估算）
- 完全无数据时，先列出「假设」和「信息缺口」，再给出受限初版

### 2. 负载建模

基于输入建立负载模型：

| 指标 | 计算方式 | 说明 |
|------|---------|------|
| 峰值 QPS | 日均 × 峰值系数（通常 3-5x） | 无历史数据时用假设 |
| 并发连接数 | QPS × 平均响应时间 | 估算公式 |
| 单请求资源消耗 | CPU/内存/带宽 per request | 基于基准测试 |
| 容量上限 | 单机资源 ÷ 单请求消耗 | 理论最大值 |

### 3. 报告生成

按以下结构生成容量规划报告：

```markdown
# 容量规划报告

## 1. 任务理解
- 目标、对象、成功标准

## 2. 输入审计
- 已确认事实、当前假设、信息缺口、证据质量

## 3. 负载模型
- 峰值与突发、并发和吞吐
- 平均值 vs 峰值

## 4. 容量估算
- 资源瓶颈识别（CPU/内存/磁盘/带宽）
- 安全余量计算（建议 30-50%）
- 当前容量是否满足需求

## 5. 扩容方案
- 扩容触发条件（阈值）
- 扩容方式（水平/垂直/弹性）
- 扩容时效（冷启动时间）

## 6. 风险与优先级
- P0/P1/P2/P3 优先级
- 阻塞条件

## 7. 下一步
- 最小验证动作
- 待确认问题
```

### 4. 报告校验

生成后必须执行以下校验：

- [ ] 区分了「已确认事实」和「当前假设」
- [ ] 有量化的负载模型（QPS、并发、资源消耗）
- [ ] 容量结论关联了 SLO 和验证方式
- [ ] 有安全余量（非刚好够用）
- [ ] 有扩容触发条件和时效
- [ ] 高风险项有优先级和处理建议
- [ ] 无伪精确数字（无数据时给区间）

### 5. 输出交付物

| 文件 | 内容 |
|------|------|
| `capacity-report.md` | 完整容量规划报告 |
| `assumptions.md` | 假设清单与验证方法 |

## 核心约束

- 没有数据时给**区间**而非伪精确数字。
- 明确平均值与峰值，不混为一谈。
- 容量结论必须关联 SLO 和验证方式。
- 先交付可用初版，再标清缺口，不要停在提问。

## 参考文件

- `prompts/capacity-planning-analysis.md`：详细执行规范。
- `evals/eval.yaml` + `evals/cases/`：评估用例模板。

## 常见误区

- 没有数据就拒绝输出 → 应先给受限版本并标假设。
- 所有数字给精确值 → 无数据时给区间（如 100-300 QPS）。
- 忽略扩容时效 → 扩容需要时间，冷启动可能分钟级。
- 只看平均值 → 峰值才是瓶颈。