性能瓶颈分析 Skill：压测、指标和 Trace 对不上时从哪里下手
CPU 高不一定是根因，数据库慢也可能只是上游重试的结果。瓶颈分析需要沿着请求路径寻找最先限制吞吐或放大延迟的环节。
性能瓶颈分析 Skill 结合追踪、饱和信号和受控对比，区分相关性与真正应修复的限制因素。
本文通过具体场景说明如何收集、连接和解释证据，让结论能够服务下一步的工程或业务决定。
性能瓶颈分析 Skill 用来做什么
性能瓶颈分析适合需要把压测结果连接到资源和服务行为的性能团队。它用同一负载模型对齐尾延迟、资源曲线和 Trace，帮助团队验证限制资源是否真的移动。
先回到源 Skill
这个 Skill 的完整执行规则在 性能瓶颈分析 提示词。源目录还包含 3 个评测用例，用于验证输出是否遵守契约。
它要求特别注意：
- 先确认负载模型有效
- 瓶颈结论需要多信号交叉验证
- 不要把高利用率自动等同于根因
用一份项目材料开始
先把当前拿得到的材料摆上来。缺口可以保留，状态必须说实话。
| 材料 | 这次填什么 | 缺失时的处理 |
|---|---|---|
| 目标与范围 | 根据压测报告、服务指标与 trace 找出订单链路的限制资源和优化优先级 | 标出不在本轮判断内的链路 |
| 版本与环境 | 压测 run ID、负载模型、实例规格、部署版本和时间窗 | 运行条件不一致时先拆分比较 |
| 证据 | 火焰图、trace、CPU/内存、数据库等待和队列指标 | 只有单一指标时只列候选瓶颈 |
| 决策边界 | 优化假设、复测指标、容量影响和技术 Owner | 每项优化关联可观察的验证信号 |
可以这样调用：
请使用 performance-bottleneck-analysis Skill。
任务：根据压测报告、服务指标与 trace 找出订单链路的限制资源和优化优先级
输入材料：[版本、链接、日志或报告路径]
范围：[本次包含和排除的对象]
限制：[时间、数据、权限、合规要求]
先审计输入，再按风险和证据强度排序。材料没有证明的内容标为假设，并列出验证方法。性能瓶颈分析要交付可验证的限制资源
| 产物 | 要回答的问题 | 最低证据 |
|---|---|---|
| 负载条件 | 哪种用户节奏触发问题 | 到达率、业务比例和数据量 |
| 延迟分解 | 时间花在哪里 | p95/p99、排队和下游调用 |
| 资源关联 | 哪个资源与退化同步变化 | CPU、内存、连接池、队列或磁盘 |
| 修复验证 | 资源瓶颈是否真的移动或消失 | 同模型复测和前后基线 |
没有同一负载模型和对照基线时，只能列出候选瓶颈，不能宣布根因。
在项目里跑一轮
先用一个边界清楚的小回合启动——根据压测报告、服务指标与 trace 找出订单链路的限制资源和优化优先级。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处；然后把每个判断连回具体材料；最后只安排一项能改变结论的验证动作。
瓶颈结论必须关联负载阶段、资源曲线和可验证的改动假设。这一轮交付应当包含：可复查的证据索引、仍然成立的假设、以及下一位同事可以直接执行的动作。这样做很朴素，也很有效。
进阶使用：把一次分析变成持续机制
瓶颈结论必须关联负载阶段、资源曲线和可验证的改动假设。
每次性能瓶颈分析都保存负载脚本、构建号、监控窗口和环境规格。脚本、资源或依赖变化后，重新跑同一模型，避免用不同压力比较前后结果。
三段式 Skill 链
performance-result-analysis → performance-bottleneck-analysis → capacity-planning-analysis
| 交接 | 传递内容 | 接收方要检查什么 |
|---|---|---|
| 上游到 performance-bottleneck-analysis | 来源版本、范围、风险、未决项 | 输入是否过期，冲突是否标记 |
| performance-bottleneck-analysis 到下游 | 判断、证据索引、残余风险、待办 | 产物是否可执行，Owner 是否明确 |
| 下游回写 performance-bottleneck-analysis | 执行结果、缺陷、事实变化 | 是否更新基线与回归范围 |
交接时传摘要、证据索引和原始材料的位置。信息量足够，结论出了问题也能回到来源。
团队门禁
| 门禁 | 检查内容 | 未满足时 |
|---|---|---|
| performance-bottleneck-analysis 输入门禁 | 版本、环境、证据来源和 Owner | 停止生成，列出缺口 |
| performance-bottleneck-analysis 产物门禁 | 关键结论带依据、状态和影响 | 退回补证据 |
| performance-bottleneck-analysis 执行门禁 | 命令、查询或验证路径可复现 | 标记基础设施或测试问题 |
| performance-bottleneck-analysis 决策门禁 | 残余风险有接受人与日期 | 不进入下一阶段 |
容易踩的坑
- 只看 CPU 使用率，漏掉连接池、锁、队列和下游服务。
- 用不同到达率或不同数据量比较两次压测。
- 看到相关曲线就下根因结论，没有做资源隔离或实验。
- 修复后只看平均响应时间，不复核尾延迟和错误率。
相关 Skill
性能瓶颈分析需要把压测数字和运行时因果链接起来：
交付前复核：把判断落到证据
Skill 输出拿到手后，先核对四件事：输入版本是否明确，范围是否完整，每条结论能否回到证据，下一步由谁执行。少一项，报告就容易变成漂亮的猜测。
| 项目 | 需要留下 | 缺失时 |
|---|---|---|
| 输入边界 | 版本、环境、时间窗口和本次范围 | 标记假设，不写成事实 |
| 证据索引 | 日志、报告、Trace、截图或命令输出 | 标记 evidence_pending |
| 结论状态 | verified、assumption、blocked 或 pending | 停止扩大结论 |
| 后续动作 | 最小验证命令、负责人和截止时间 | 交付为待办，不进入门禁 |
source_version: [版本或提交]
scope: [本次包含和排除的对象]
evidence: [日志、报告、Trace 或命令输出]
status: pending
owner: [负责人]
next_action: [最小验证动作]分析类 Skill 要保留查询条件和时间窗口；执行类 Skill 要保留命令、退出码和失败产物。人工修改也要记录，下一次复核才知道结论从哪里变化。
安装与调用
安装这个 Skill：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/performance-bottleneck-analysis -g安装后，直接使用下文的 performance-bottleneck-analysis 调用词，并附上本次的真实材料。
常见问题
输入还不完整，能开始吗？
能。先交付受限初版：列出已知事实、假设、缺口和最小验证动作。环境、数据或权限缺失时，不写执行结论。
什么时候需要人工确认？
范围取舍、风险接受、生产操作、数据权限和发布决定必须由对应负责人确认。Skill 负责整理证据与选项，不替团队做授权决定。
先用一份真实材料跑通 性能瓶颈分析，把输入、产物、人工修改和验证证据留在同一个工作链里。下一次变化发生时，才有东西可以复用。
参考
- 性能瓶颈分析 提示词：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/performance-bottleneck-analysis/prompts/performance-bottleneck-analysis.md
- Awesome QA Skills：性能瓶颈分析 Skill 源文件：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/performance-bottleneck-analysis
- Awesome QA Skills GitHub 项目：https://github.com/naodeng/awesome-qa-skills
- 性能瓶颈分析 Skill 详情页：https://inaodeng.com/zh-cn/qaskills/performance-bottleneck-analysis/