capacity-planning-analysis · diff
git:20260907.af8ce9d to git:20260915.bc5a8d6
94 added, 41 removed. Audit A to A.
---
name: capacity-planning-analysis
- description: Use this skill when you need to assess capacity demand, headroom, constraints, and planning assumptions; triggers include 容量规划分析 and 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.
---
- # 容量规划分析（中文版）
+ # 容量规划分析
## 何时使用
- - 需要根据业务负载、资源利用率和增长假设估算容量需求与扩容触发条件。
- - 需要对现有方案、结果或证据做风险评审，并形成可执行改进项。
- - 输入不完整，但仍需先给出带假设和信息缺口的可用初版。
+ - 用户提供业务负载、资源利用率或增长假设，需要生成**结构化的容量规划报告**。
+ - 需要评估现有方案的风险、识别瓶颈、给出扩容建议。
- ## 输出格式选项
+ ## 输入要求
- - 默认输出 Markdown，适合评审、执行和持续补充。
- - 用户要求表格、CSV、JSON 或工单格式时，保留同样的风险、证据、优先级和边界字段。
- - 若输出会进入自动化流程，先确认字段 schema、枚举值和必填项。
+ | 必填 | 字段 | 说明 |
+ |------|------|------|
+ | ✅ | 业务场景 | 核心接口/服务、用户量、流量模式 |
+ | ⬜ | 历史数据 | QPS、并发、响应时间、错误率 |
+ | ⬜ | 资源信息 | CPU/内存/磁盘/带宽的当前利用率 |
+ | ⬜ | SLO 目标 | 可用性、响应时间、吞吐量要求 |
+ | ⬜ | 增长预期 | 用户增长计划、大促/活动信息 |
+ | ⬜ | 扩缩容策略 | 当前的扩缩容方式和限制 |
- ## 如何使用
+ ## 执行流程
- 1. 先阅读并遵循 `prompts/capacity-planning-analysis.md` 的输入、执行规则、最低覆盖清单和输出顺序。
- 2. 补充真正影响判断的范围、环境、版本、限制、证据和成功标准。
- 3. 先做输入审计，再区分已确认事实、合理假设和待确认问题。
- 4. 按风险和证据强度排序，产出可直接执行、评审或验证的结果。
- 5. 信息不足时不要停在提问：先交付受限初版，并说明哪些结论暂不能成立。
+ ### 1. 输入审计
- ## 参考文件
+ - 检查业务场景是否清晰（哪些接口、什么流量模式）
+ - 检查是否有任何量化数据（哪怕是估算）
+ - 完全无数据时，先列出「假设」和「信息缺口」，再给出受限初版
- - 每次执行必须读取 `prompts/capacity-planning-analysis.md`；它是本 Skill 的完整执行规范。
- - 需要评测或回归本 Skill 时，读取 `evals/eval.yaml` 与匹配的 `evals/cases/` 用例。
- - 只有目录实际存在且任务需要时，才读取 `references/`、`examples/`、`scripts/` 或 `output-formats.md`，不要假设不存在的资产。
+ ### 2. 负载建模
- ## 核心约束
+ 基于输入建立负载模型：
- - 没有数据时给区间而非伪精确数字
- - 明确平均值与峰值
- - 容量结论必须关联 SLO 和验证方式
- - 不编造输入中不存在的系统行为、字段、数据、指标或根因。
- - 关键结论必须关联证据；证据不足时标记为假设并给出验证方法。
- - 优先级必须说明业务影响、发生可能性或可探测性依据。
+ | 指标 | 计算方式 | 说明 |
+ |------|---------|------|
+ | 峰值 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）。
+ - 忽略扩容时效 → 扩容需要时间，冷启动可能分钟级。
+ - 只看平均值 → 峰值才是瓶颈。