合理容量基线应真实反映生产“可接受底线”，需匹配业务sla、历史负载与风险容忍度；明确红线（如tps达标但p99超sla 2倍）、黄线（如cpu峰值达90%超5分钟）、灰线（如gc频率增20%）三级指标；基线须固化测试数据、环境配置、压测脚本及执行过程，并支持可复现、可审计与自动比对分析。
设定合理的容量基准测试基线，核心是让基线能真实反映系统在生产环境中的“可接受底线”，而不是追求理论最优值。它不是越高越好，而是要匹配业务SLA、历史负载和风险容忍度。
明确基线必须回答的业务问题
基线不是技术参数堆砌，而是对具体业务承诺的量化。例如：
- “双11大促期间，订单创建接口在5000 TPS下，99%响应时间 ≤ 800ms，错误率
- “日终批处理任务需在2小时内完成全部10亿条记录清算，CPU平均使用率不持续超过75%”
- “用户登录链路在早高峰3000并发下，平均响应时间稳定在300ms以内，且无连接池耗尽告警”
每一项都对应可验证、可追溯、不可绕过的上线否决条件。
用生产数据反推基线阈值
避免凭空拍定数字。优先从线上监控中提取最近30天的自然峰值作为起点：
- 取业务高峰时段（如电商晚8点、金融早9:30）的TPS P95值，再上浮20%~30%作为基线目标值
- 响应时间参考线上P99值，基线允许放宽至P99.5或增加固定缓冲（如+100ms）
- 资源指标（CPU、内存）以线上稳态均值的1.5倍为预警线，基线设为该值的80%，留出突发余量
没有历史数据的新系统，可基于同类业务模块或竞品公开报告做保守估算，并在首版基线中标注“临时值，上线后1周内校准”。
分层设定基线，区分硬性门槛与观察项
不是所有指标都具备审批否决权。建议划分为三类：
- 红线指标（一票否决）：错误率 > 0.1%、99%响应时间超SLA 2倍、出现OOM或连接池枯竭
- 黄线指标（需专项说明）：TPS达标但P99响应时间超标10%、CPU峰值达90%持续超5分钟、磁盘IO等待时间 > 20ms
- 灰线指标（记录备案）：内存使用率缓慢爬升、GC频率较前版增加20%、网络重传率小幅上升
上线审批只卡红线指标，黄线指标必须附优化计划并经架构师签字，灰线指标仅归档跟踪。
确保基线可复现、可审计
基线无效的常见原因是环境漂移。必须固化以下要素：
- 测试数据：使用脱敏后的真实生产快照（至少保留近7天全量订单+用户关系），禁止合成数据或空库
- 环境配置：记录操作系统内核版本、JVM参数（含GC算法）、数据库buffer pool大小、网络MTU等关键项
- 压测脚本：标注事务定义（如“一次下单=1次登录校验+1次库存扣减+1次支付创建+1次MQ投递”）
- 执行过程：注明加压方式（阶梯式/恒定并发）、持续时长（至少覆盖一个完整业务周期，如60分钟）、监控采样粒度（秒级）
每次回归测试输出的基线报告，必须包含与上次基线的逐项比对表格，差异超5%自动触发根因分析流程。
