建立性能基线的实践方法
前几天语雀服务宕机了，我写了一篇关于服务稳定性保障的文章，分享到知识星球内部群后，群里很多同学分享了各自公司关于线上服务稳定性保障的实践案例，其中有个词提到的频率很高，那就是：性能基线。
相比于性能测试中的其他名词比如并发、TPS等，性能基线很少被提及到，在能搜到的资料里，性能基线也往往被解读为基准测试，或者基准监控。从我个人的实践经验来说，这样的解读是存在一定偏差的。
这篇文章，我会结合自己的实践经验，分享一些我对于性能基线的理解，以及建立性能基线的实践方法。
如何理解性能基线
基线的英文为baseline，翻译过来就是基准线，简单理解它的意思即：假设我们做了某种实验，实验的结果得到了提升，这个提升的对比对象就是所谓的基线，在数学上基线可以理解为参照物。
基线评估方法是一种基础的科学评价方法，主要用来评估目标及其相关内容的发展变化情况，这个方法有四个特点：
- 能直观反应需要解决的问题；
- 用有限的几个指标跟踪反应目标进展情况；
- 进展情况反应的变化应该是连续的，且容易通过测试得到具体数值；
- 数值所代表的变化在测试阶段应较为明显，为得到结论提供比较判断的基础；
在软件研发领域，基线代表软件在某个阶段的稳定状态，是进入下一个环节的准入基础(质量门禁)。因此当基线形成后，可以视为当前软件状态较为稳定，可以通知相关同学进行评估判断，进入下一个环节(冒烟测试通过正式提测)。
基线可以看作是比较正式的标准，建立初始的基线后，后续的每次测试得到的数据都需要进行记录(存在差值)，直到这些数据在统计区间内(一个大版本或一个季度)形成新的基线。因此在性能测试领域，性能基线具备这几个特点：
- 性能基线可以直接表示当前阶段的性能表现(高了还是低了)；
- 性能基线的指标应该可以直接反映出性能的变化趋势(趋势变化取决于数据统计区间)；
- 性能基线展现出来的变化趋势应该是连续的，且指标容易通过测试得到(指标需要是大家都认可的)；
- 性能基线只是数据展示，变化趋势需要通过分析得到结论(测量数据存在误差，应该有合理区间的正负值)；
性能基线解决了什么问题
在项目管理和软件研发工作中，我们会经常听到检查点、里程碑这两个词。检查点(按先后顺序制定)可以看作是最小模块的准入准出标准，里程碑(按关键成果制定)则是比较重要的检查点，而基线(按一组关键成果制定)，则可以看做是重要的里程碑。
传统的性能测试，往往是项目制的，即把每次性能测试实施看作一个项目，评估性能测试结果是否符合预期指标，达标后出一份性能测试报告。下一次有性能需求，重新开始分析需求，写脚本，准备测试数据，重复之前的动作。
这样做的好处是工作量很好衡量，按项目和接口数量度量产出，简单粗暴。但不足之处是对系统整体性能变化没有直观的连贯性的展示，且对系统性能的认知往往是局部的，没有全局视角，自然线上的稳定性保障会出现各种挑战。
性能基线的优势在于，一方面提供了直观和连续的系统性能变化趋势，便于对系统长期的性能变化快速了解；另一方面则是代表性能基线的指标更通用，即形成了一种标准，这种标准化体系的建立可以降低管理和沟通的成本，为系统整体的稳定性保障提供了很好的基础。
建立性能基线的实践方法
按照建立性能基线的先后顺序，下面是我自己的实践方法：
1、选择较为稳定和核心的业务模块(比如电商的导购搜索商品库存订单支付物流业务)；
2、测试场景的覆盖范围按照优先级分批覆盖(比如优先P0场景，然后P1/P2场景逐步覆盖)；
3、选取能直观表示性能变化结果的指标并在团队内达成共识(比如QPS、TPS、99RT及对应服务的资源使用率)；
4、覆盖场景对应的脚本和数据应跟随迭代实时更新(在编码阶段跟进变化，并及时进行联调并更新对应的测试数据)；
5、性能测试的执行动作尽量做到自动定时执行(自动执行时出问题或者测试结果异常可以手动执行并实时观察，异常数据和日志也应该快速记录下来，便于后续的排查和优化)；
6、性能测试执行的结果数据最好通过自动记录+手动调整来记录并展示(展示可以通过饼图/折线图/柱状图等形式来展示，并提供分组筛选和对比功能)；
7、每次性能测试结果都会存在一定误差(假设一切条件不变，每次执行的结果也存在误差，误差正负值可以取1%-5%)；
8、性能基线的展示和统计区间可以按照版本号和季度等不同维度来展示(如果业务复杂且团队大，可以加上业务域甚至BU的的展示和筛选项)；
9、性能基线的初始版本可以选取某个大的版本迭代或者标志性项目的结果为基准，后续性能基线的更新则根据具体情况来变更调整(比如业务需求大幅度变化/系统重构)；
10、切记：性能基线一定要在独立稳定的环境开展，且环境的服务硬件配置最好和线上环境保持等配等比缩容！
