• 预期流量上涨，但系统容量上限不清晰。
• 线上出现延迟、错误率或资源饱和迹象。
• 团队需要有数据支撑的扩容和优化决策。

• 通过k6 压测脚本与指标分析评估系统在不同负载下的表现。
• 识别应用、数据库、外部依赖的瓶颈位置。
• 产出容量基线和优化优先级。

1. 先定义性能目标（如 P95、错误率、吞吐目标）。
2. 设计贴近真实业务的负载模型与数据分布。
3. 分阶段执行：基线、爬坡、稳态、峰值。
4. 联合分析接口指标与资源指标。
5. 定位瓶颈并验证根因假设。
6. 输出阈值、失效模式和整改建议。

输入：

• 目标：P95 < 300ms，峰值 1200 RPS，链路：搜索+结算

输出：

• 1050 RPS 开始 DB 连接池饱和，P95 上升至 340ms
• CPU 平稳但 DB 等待时间显著升高
• 建议：先扩池并优化热点 SQL，再做复测

输入：

• “跑一下压测”

输出（问题）：

• 没有目标、没有负载模型、没有瓶颈证据
• 结果无法用于容量决策

• 不用脱离真实流量特征的假负载做结论。
• 不只看平均响应时间。
• 不跳过依赖层诊断。
• 不在环境基线不一致时横向对比结果。
• 不在缺少阈值证据时给容量通过结论。