中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
工行银行测试部高级经理李雁南于性能可视化专场发表了题为《传统架构下性能测试的方法探索和实践》的演讲，现场解读了针对快速增长的性能测试需求的解决方案，以及所选择了构建性能监控体系的方式。
以下为演讲实录：
各位好，我叫李雁南，来自中国工商银行数据中心。首先非常高兴能有这么多同学在这儿，我也知道现在其他三个屋都是大师级的人物，我从小也是看他们书长大的，我希望到结束的时候依然能看到很多小伙伴没有离开。
我的演讲的题目是《传统架构下的性能测试方法探索和实践》，首先解释一下传统架构是什么概念?因为这个概念相对来说比较模糊的。可能现在所谓的先进架构过了两年也就成为了传统架构。我个人理解，所谓的传统架构就是竖井式架构，每个应用都有自己单独的操作系统、数据库、中间件，我们的应用程序是部署在数据库和中间件上的。应用与应用之间是通过中间件进行交互的。
一、功能测试，性能测试需求，性能测试
在一开始，我想跟大家分享一句话，这是我在刚入职的时候，从一位做性能测试的前辈那儿听到的，对我启发很大：他说业务流经所有的单元，当压力增大时，必然会导致存在效率问题的单元堵塞，并体现在资源使用率的异常上。我们性能测试所要做的就是利用各种手段发现背后的异常和原因。这句话高度概括了性能测试活动的目的和方法，也指导着我们过去很多年的性能测试活动。但是最近一两年，我们发现这句话不这么准确了，后面我介绍的时候，大家可能也会有这种感觉。
说说以前到底是什么样的，上图这三个颜色分别代表了功能测试、性能测试需求和性能测试活动。大家看到，在以前性能测试需求其实只占功能测试的一小部分，我们的性能测试活动，基本上能覆盖我们绝大部分的性能测试需求，但是随着近几年互联网的兴起以及我们技术的快速发展，我们的用户量在不断的增长，我们的业务种类在不断的丰富，我们的系统规模也越来越大。我们的数据量也呈现了一个几何级数的增长，这就导致了我们的功能也在快速的增长，对于性能测试的需求也是爆发式的增长，但是对于性能测试活动资源的投入，以及性能测试本身的方法却没有一个很大幅度的提升，这样就导致了我们现在的性能测试活动，不能完全覆盖我们实际的性能测试需求。
每次版本投产以后，大家都有这种感觉，有很多性能问题会流入到生产，而这种性能问题，它不像是功能问题，性能问题会影响到整个系统不可用，会产生一个全局性的影响，这样带来的风险是非常大的。怎么解决这个问题?最简单的一个方法，就是说我们能够增加我们的性能测试需求的场景，不断的投入人力加班，或者投入更多的资源。灰色的过程是一个很真实的写照，就是说我们性能测试人员每天都在干什么，与功能测试协调资源，准备测试数据，白天调脚本，晚上跑压测，但是问题发现的非常少，而且每次投产以后，有很多性能问题流入到生产，感觉到很累，而且很没有成就感，感觉身体被掏空了一样。
那怎么办?现在的问题主要有两方面的矛盾：像下图绿色部分写的，版本周期越来越短，但是资源投入却没有相应的增加，因为测试毕竟是一个有限投入的活动，不可能无限制的增长。
第二个矛盾，覆盖率和性能测试活动成本之间的矛盾。在要求覆盖率不断的增长的同时性能测试的成本却没有相应的降下来，这两个矛盾直接导致了性能测试活动无法正常有序开展，或者说无法起到应该有的作用。我们也想了很多办法，能不能对测试整个环境做一个全方位的监控，把数据采集下来，通过对于数据的处理，能够从中发现我们的性能问题。
就像上图那样，我们定了几个目标：
•第一，系统要能够支持海量的管理对象。因为我们的测试环境应该有7000多服务器
•第二，重点关注数据库层面的性能表现。
•第三，不侵入系统，这也是一个最基本的要求，保证测试环境上所有的版本与投产之后的版本是一样的。
•第四，也是非常头疼的一个问题，做过测试的大家都会有这个问题，应用的异构性和资源差异的问题。每个应用和应用之间的特点是不一样的，对于性能的需求也是不一样的。测试环境的资源投入有限，不可能做到跟生产环境投产以后做到一比一的比例，有的只是生产了五分之一，甚至十分之一，二十分之一，这都有可能。如何在如此巨大资源差下面发现应用的性能问题，是非常巨大的挑战。
•第五，能够采集问题发生时刻的数据。我们需要有足够多的数据支持去分析、定位性能问题，正常情况下，大家也知道采集性能相关的数据对于被监控系统的资源还是有一定消耗的，我们不能7乘24小时都采集这个数据，而且这个数据量也是非常庞大的量。
•第六，就是说我们的性能测试活动要迁移到功能测试中，性能测试活动不再是自己的迭代周期，是在功能测试开始以后，就立刻能够开展性能评估的工作，这样能够把我们整个的工作平均分布到整个版本测试的周期中。
二、测试监控1.0
基于以上几点目标，我们也是抱着试试看的想法，建了一个测试监控，我们称为1.0。主要方法是和现在大部分的监控没有什么区别，我们定义监控指标，针对这些指标设置阀值报警。第一个用的是ZABBIX，第二个是DBMON，我们能够在被监控的实地上部署监控程序，按照不同的时间段，不同的频率向服务端推送它的性能数据，在服务端对数据进行统一分析和处理;第三个是NAGIOS，对中间件监控的工具，这些都是开源的工具。
那么过程是怎么做的呢?首先定义监控指标，覆盖所有生产上已有的全量监控指标，同时能够支持发现问题所需要的特有指标。第二个就是事件触发细粒度的采集，当报警发生的时候通过报警事件触发在被监控端收集性能数据，可以保证问题发生时段我知道被监控端的性能表现是什么样的，具体是什么引发了被监控端的报警，后续也会做一个介绍。
大概的效果是怎样的?结果就是性能测试场景比以往会少了很多。以往真正的精力是关注实际存在的需要做高并发的，或者非常复杂的性能测试需求的场景。性能测试工作，也可以开展到功能测试中去，在功能测试开展以后，就可以开展性能评估的工作了。但是出乎我们的意料的是工作量没有下降，反而增长了很多，主要原因是报警量非常大。大家可以从下图看到，这就是一个ZABBIX的报警图，很短时间内就出现了大量的报警。我们不可能针对每一条报警都要具体分析，这样浪费了大量的人力和物力，那怎么办?这就是1.0监控体系的一个最重要的问题。
我们先来看一看1.0是怎么工作的，这个就是刚才说的细粒度事件采集的过程，可以看到左边是CPU的运行图，出现报警的时候，被监控端做一些性能指标的数据采集。采集到日志，通过邮件推送给应用测试的负责人。
上面这张是我们一个传统的分析流程，比如说右上角这个图，推送给我的邮件，可以看到蓝色部分呈现持续增长的趋势，肯定是存在问题的。然后我们就去看它的细粒度采集的日志，当时跑了哪些内容。基本上都是在Oracle进程占用了大量CPU，我们可以看SESSION的图，发生异常等待事件的进程也在不断增长，我们初步判断就是由于异常等待事件，造成CPU冲高。
到了第四幅图，采用的异常等待事件的统计结果，大量的索引分裂等待事件出现，是因为等待事件出现CPU冲高，再查具体的程序设计，发现了CPU的冲高。
通过问题分析流程，一步一步走下来，问题分析过程所需要的数据都已经采集到了，能不能把流程倒过来，直接从根源进行监控或者报警，这样是不是可以省略了从第一步到第二步，到第三步的过程，这就是我们监控体系2.0的设计思路。
三、测试监控2.0
我们都知道面对的问题我们监控分析量非常大，误报率非常高，对策就是说对这个问题产生的根本原因进行一个监控。怎么监控?我们首先对过去两年存量发生的生产性能问题进行了一个分析，我们发现很奇怪的现象：92%的生产性能问题都是由9个根源问题所引发的。我们为了发现或者准确的定位这9个根源问题，需要27个监控指标和检查模型。针对27个监控指标和检查模型，我们定义了一个报表输出，针对这些报表输出，定期的去看这些报表，回顾整个测试过程，去看它有没有命中我们所说的这几个模型以及9个根源的问题。
当我新增了一些没有被发现的生产问题，或者典型的测试性能问题以后，我们再去更新监控指标和检查模型，就这么做了一个版本以后我们发现问题分析量要比之前通过传统的阀值报警减少了40%左右，这是一个非常大的进步。
上图就是我们的一个模型清单，说大一点就是发现问题的方法论。最左侧可以看到，它是由定义的监控指标的需求方，比如说为了发现生产问题定义的指标，或者说为了满足版本测试定义的一些指标组成的。
第二列是发现的9个根源问题，包含连接数高、连接不释放，索引过程失效，每次需要重新解析等等。
第三列是分析这个指标的判断标准，比如说索引分裂，如果要定位索引分裂的根源问题，需要捕捉到数据库层面发生的异常等待事件，比如用到了顺序增长的值作为我的索引值。
第四列用到了指标代码。
第五列是选择监控指标。
第六列是定义策略，这就是我们初步的模型。
最后一列是一个辅助分析的模型，也就是说可能这两个指标不足以100%帮助我定位到这个问题，还需要其他指标帮助定位这个问题。为了发现这个问题，还需要参考哪些指标，这是我们模型分析的清单，根据这个清单，定义了一个报表输出。
大家可以看到，跟之前的模型清单基本上结构是一样的，内容也是一样的，最右边这列换成了测试过程中实际的运行情况的一个值的统计。进行这个报表输出，帮助我们能够聚焦性能问题究竟发生在哪，而不是说每天都是忙于处理那些表象的报警，而是直接关注问题发生的根源。
三、测试监控3.0
到了3.0的时候，我们发现结果还是不能完全满足我们的测试需求，因为我们用了一段时间，发现它还是存在着大量的重复报警和误报的现象，为什么?最早说的资源的差异引起的。测试环境与生产环境的资源差异，生产环境一套体系跑得很正常，但是到了测试环境，就能触发一些各种各样的报警。这种问题我们怎么办?我们想到了能不能通过测试环境建立一个基线的方式，来帮助我们过滤这些无效的报警。
主要方面就是建立一个基线，针对这个基线，对我们报警事件按照严重程度进行一个分级，包括系统和数据库层面性能的基线，按照版本的最小值、平均值、最大值和最大值的1.3倍进行分级，大于最大值和大于最大值1.3倍的是一个非常严重的问题。我们并不是说它比最大值小，这种问题就完全忽略掉，而是说我们等到有精力，或者有时间的时候，再去仔细分析它。
第三个方法是建立一个持续增长的模型。持续增长的模型是非常简单，就是用了一个线性拟合的公式，采样三个点，只要呈现一个持续增长的态势，就把它纳入到报表里。虽然非常简单，但是是对我们帮助最大的一个模型。持续增长必然导致性能问题，这是有定论的。在过程中，我们也发现增长模型筛查出来的结果命中率相当高。
第四个是引入生产运行情况。生产运行的挺好的一个语句可能是用了一些看上去有风险的执行计划，但是运行的很好而且运行的很长一段时间没有问题，我就把它纳入到测试来，用来过滤测试发生的这些异常的事件。
第五个，我们的主要精力要重点分析高风险的语句、那些问题。
第六个，基线的持续更新，每期版本结束之后，重新把存量线打一遍，做下一次测试用。
通过上述方法，问题分析的量比最开始的阀值报警减少了大约60%左右。
以上就是我们大体的一个监控的速度，总结一下它的处理流程：
•第一步是数据采集，抓操作系统数据库中间件的数据;
•第二步是时序编排，按照时间纬度，重新安排各个报警指标，为什么做这一步操作?因为测试环境，一个应用有很多套环境，每套环境为了满足不同的测试任务，可能有不同的测试日期，基本上很少有一套完全跟自然日期保持一致的。怎么能够把这些报警平时出来的这些监控指标，能够按照统一的时间轴做一个编排，能够关联分析，按照时间纬度关系分析数据库操作系统中间件层面的问题，确实是一个很头疼的问题，我们想了很多办法，最后选取了一个被监控端时间的监控指标作为计算的依据。
•第三点是基线分级，还有模型分析，事件报警。监控系统驱动着我们的响应系统，做一些比如报警触发的自动化的操作，和一些报警推送的工作。
细心的同学，可能发现我之前讲的很多内容，都是只针对于操作系统跟数据库层面的，但是中间件很少涉及，因为我们用的中间件产品主要是IBM的产品，缺少对中间件监控方法的掌握。我们监控的指标更多的可能也就是几个比较简单的指标，比如说大对象的调用。因为缺乏一个业务的视角，大部分的业务交易或者业务逻辑定义在中间件层面，这样我们无法通过业务的角度评估系统的性能表现。第三个是单点监控的问题，业务流经所有的单元，我们监控只是针对单元进行监控，而没有针对业务流经的过程进行一个监控，怎么办?
我们其实也想了很多办法，我们想到能不能通过APM的产品，帮助我们去解决这个问题。我们也联系了很多厂商，包括国外的、国内的，最终我们还是选择了听云公司的产品，有几个原因：第一个是听云对于我们需求的响应还是非常及时，非常有效的;第二个，确实这款监控产品能够帮助我们分析和定位问题，能够满足我们需求;第三个，它毕竟是国产软件，所以说我们尽量能够要支持一下我们自己本土的软件行业。
下面这几副图是我们使用的产品效果图，这可能已经介绍过了，我这里就不仔细说了，主要针对一些应用过程，一些数据库的调用，以及涉及第三方的调用的监控，能够都做到非常细粒度的监控。
四、测试监控4.0
所以到了测试监控4.0，我的系统慢，究竟慢在哪?我们已经有一个比较完整的体系去监测了。
这其中每个功能块覆盖的面不一样。
五、测试监控X.0
到了监控X.0这几件事在其他公司或者在一些互联网公司很多都已经实现了，对于银行来说，可能还是刚刚起步。
端到端的监控数据管理 ，我们希望能够按照第一句话所说的那样，业务流经所有单元，把所有的过程监控下来，把数据采集下来。
事件触发的运维自动化在我们这儿刚刚起步，现在只能做到基于一些比较普通的报警事件去触发一些自动化操作，比如说一些日志清理，比如说一些进程的重启之类的。
测试资源的按需分配 ，因为要管理7000多台服务器，要为这7000多台服务器分配合理的资源，确实是一件非常头疼的事。我们天天都在喊没资源，但是资源究竟浪费在哪还是没有一个比较直观的认识，我们希望通过监控系统或者监控数据的分析，真正把有用的资源投放到真正有用的环境中去。
常规业务交易基线的性能管理 ，希望能够对重点的或者常规的交易定义一个基线，从业务的角度看待性能的问题。
关联应用特点的模型， 大家可以看到，刚才所说的模型分析更多还是类似于一刀切的方式，每个应用和每个应用的模型基本上是一致的。每个应用和每个应用之间功能不一样，对性能的需求不一样，如何能做到针对不同应用的不同监控策略的管理，这是我们后续需要进一步解决的问题。
交易路径和覆盖率的检查 ，通过交易拓扑或者日志采集、分析的方式实现。
日志检查和规范化，也是为了配合日志采集的开源架构做的。
客户端浏览器性能，也是想借助APM的产品，发现一些类似图片比较大，过度渲染的问题。
最后是我们现存的问题。
第一条是与生产的数据交流，这在很多公司已经不成问题了。对于银行来讲，因为制度或者数据安全性的要求，我们现在与生产的数据交流还是相对来说非常少的。如何能够把生产运行过程中的数据拿过来，作为指导测试环境性能测试的一个依据，其实是一个很有重要的工作。
第二个是与外界的交流学习。这次来也是抱着丢人的心态来的，希望在丢人的过程中找到自身的问题，能够做一些改进和优化。
第三个是对于开源产品的接纳和研究，这一块银行通常给人的一个印象，喜欢买商业化的软件。过去几年一直是这样的，但是随着成本压力的不断增大，以及开源产品的不断成熟和发展，我们也要抱着开放的心态，接纳开源的产品。
第四个是优秀商业软件引入测试环境。我们接触了很多国外的公司，国外公司普遍的通病就是对于我们需求的响应非常不及时，有时候甚至很鄙视我们的需求，但是这些需求确实是我们需要的。相反本土的一些软件，对于这些需求响应非常及时，这块也是我们后续想做的，能够把优秀的商业软件引入到测试环境中，帮助我们解决很多问题，让更专业的人做更专业的事情。
以上就是我的一个简单的交流内容，大家如果有问题，或者如果有一些意见建议，或者有指教，大家可以在微信上联系我，谢谢大家!
Q&A
Q1：我听了您的报告发现你们用了非常多的第三方的东西，不管是商业的还是开源的，比如说像听云还有很多工具之类的。我自己公司里面对外面的东西都有安全性方面的考量，所以很多时候，我们自己更偏向于自己去做，或者其他部门比如说有一些技术支持部门来做，尤其像你们是工商银行，你们的数据安全性应该是要求非常高的吧?在这方面，你们是怎么考虑的?
李雁南：首先中国工商银行对于数据安全的要求是非常非常高的，也就是说我们刚才还在说，我们的生产数据，我们测试环境都看不到，对于开源产品，或者说第三方产品这块，我们还都是通过私有化的方式去做的，包括听云这款产品，我们也是在测试环境搭建了私有化的环境，第三方的产品也都是在测试环境本地部署的。通过网络层面和外界做一个隔离，不会存在数据安全上的问题。包括生产数据到测试环境都是做过严格的变形。
Q2：我们用一些外部的产品，尤其端到端应用性能产品，我不知道里面是不是有涉及埋点，在代码里增加一些东西。你们作为一个测试单位，跟研发部门怎么去协调?因为涉及到代码修改的一个东西。我们很多成型的产品已经在运行了，你们是怎么解决这个事的?谢谢。
李雁南：我想应该公司来回答这个问题。因为APM这个产品最大的特点，就是说不侵入这个系统，只不过是在我们启动的时候，加载了一个探针，其他数据库层面的监控，都是严格的独立用户去管理的，不会动程序的。这也是我们一开始所说的不侵入系统的原则，要保持我们测试环境的版本与投产以后的版本严格一致，不能有任何变化。
提问2：国内做APM的厂商挺多的，咱们选择听云作为中间件层次的监控，是出于什么样的考虑?
李雁南：就像刚才所说的，我们试了很多的厂商，包括国外的厂商，他们做得非常专业但是对于我们的需求应答不是非常及时。因为任何一个企业，不可能通过一款产品解决所有的问题，可能是要针对自己企业的软件或者系统架构的特点做一些个性化的处理，所以说这块就需要与厂商不断协调，满足我们这些个性化的需求，在这里边，我们也试过，比如说在听云之前，我们交流过很多公司，包括APM的、NPM的，总体感觉下来，还是听云相对来说更好一些。现在我们还在不断的磨合，不断的合作。
