性能基线建立：定义基线指标、选择基准场景、基线数据采集方法

说实话，性能基线这事儿，我见过太多团队栽跟头了。

有的团队一上来就猛跑压测，数据攒了一大堆，结果回头一看——咦？这数据到底能不能信？还有的团队，基线建得倒是挺早，可版本一迭代，基线就没人维护了，成了摆设。

我个人习惯，把基线建立分成三步走：定指标、选场景、采数据。这三步走稳了，后面的回归分析才有根。

一、定义基线指标

基线指标不是越多越好。你想想看，指标一多，维护成本就上去了，而且容易抓不住重点。

我一般会从三个维度来选：

• 吞吐量——系统每秒能处理多少请求。这是最直观的指标。
• 响应时间——用户从发请求到收到响应，花了多久。我习惯看P50、P90、P99三个分位值。
• 资源利用率——CPU、内存、磁盘IO、网络带宽。这些是排查瓶颈的线索。

举个例子。我之前帮一个电商团队建基线，他们一开始列了20多个指标。我说，停，先砍到5个。最后定的是：QPS、P99延迟、CPU使用率、内存使用率、错误率。够用，而且好维护。

二、选择基准场景

场景选不对，基线就是废的。

我见过最典型的错误：拿一个简单的「Hello World」接口当基线。结果线上真实流量一上来，系统直接崩了。为什么？因为那个接口根本没经过业务逻辑处理。

选场景，我建议遵循三个原则：

1. 覆盖核心链路——用户最常用的那几个功能，必须覆盖。比如登录、搜索、下单。
2. 包含典型负载——不能只测低负载。要测正常负载、峰值负载、甚至极限负载。
3. 可重复执行——场景要能稳定复现。每次跑出来的结果才有可比性。

我曾经帮一个金融项目选场景。他们核心链路是「用户登录→查询余额→发起转账」。我们就定了这三个接口，再加上一个「并发用户数从100到1000」的阶梯压测。这个组合，基本能覆盖日常和高峰两种情况。

三、基线数据采集方法

数据采集，说白了就是「怎么把数据拿到手，并且保证它是准的」。

我常用的采集方式有三种：

采集方式	适用场景	注意事项
压测工具采集	接口级性能测试	注意工具本身的性能开销
APM工具采集	全链路监控	采样率别设太低
日志采集	自定义指标	注意日志格式统一

嗯，这里要注意一个坑：采集工具本身会影响性能。我之前用JMeter压测，结果发现JMeter所在机器CPU先爆了。后来改成分布式压测，才解决了这个问题。

数据采集完，我会做一次「数据清洗」。怎么洗？三步：

• 去掉明显异常值（比如网络抖动导致的超时）
• 检查数据一致性（比如QPS和响应时间是否矛盾）
• 计算统计值（均值、分位值、标准差）

最后，把清洗后的数据存到数据库里。我习惯用时序数据库，比如InfluxDB。查询方便，而且能直接画趋势图。

核心逻辑图

下面这张图，是我自己总结的基线建立流程。你看一眼，基本就明白整体脉络了。

你看，整个流程其实不复杂。但每一步都有细节。指标定错了，后面全白干。场景选偏了，基线就没参考价值。数据采不准，分析就是瞎猜。

我个人经验是：第一次建基线，宁可慢一点，也要把每一步做扎实。因为基线一旦建好，后面几十个版本的回归分析，都靠它来对比。地基歪了，楼盖得再高也危险。

好了，这一章就聊到这儿。下一章我们聊聊怎么用这些基线数据做回归分析——那才是真正出活儿的地方。