前言：因为今天将两天的工作rm -rf掉了，所以吃了海鲜压了惊。
最近在整理资料，并重新编写新的售前、交流活动、培训等各种类型的PPT。所以在有些时候和一些人讨论了性能测试分析优化的范围。
即便是在7D Group内部讨论的时候，也有人说，我把性能测试分析优化的范围扩大了很多，并且并不是测试人员的职责范围了。
不得不说，其实我在考虑性能调优的时候，并不是从测试的视角出发的。纯从性能测试的角度来看，底子还是薄弱的偏多，也达不到架构级思考的能力。但是从性能问题出现的范围来看，涉及到的范围也太多了。我们不能说因为测试人员的能力不足，所以这个问题就不考虑了。
所以性能其实是个大话题，不应该只做为测试的角度来思考。我们经常会碰到有人拿一个TPS或RT的图就开始问，这个系统的瓶颈在哪里？这样的问题应该绝大部分人都不清楚。如果有人回答了，并且对了。那肯定是猜的。
如上图所示（图是我随便画的，不要太认真）。如果如果测试关注的是性能测试工具这部分，那无疑就只能受别人指挥了（画外音，喂，那个谁，点一下）。当然测试中还有像测试方法策略、业务/数据模型之类的工作要做，但是也都技术含量不太高。
而不这样又如何呢，下一步就是加了监控的内容。说到了监控，我觉得就能刷下去一部分人了。因为有很多人都是知道性能是要监控才能有数据分析的。但是到底到监控什么，拿什么来监控是蒙的。我曾经见过一开始启动压力就直接上profiling工具的。也曾见过看了OS资源就说这个服务器是没问题的。甚至，我见过一个DBA见到硬解析高达数百，也不知道是和CPU消耗有关的。
所以说，监控其实是个学问。
一直在我布道的时候，都说，先看overview，再定向定量分析。但是什么是overview，什么是定量定向分析。就比较难说清楚了。拿OS举例，会看TOP的人很多，但是TOP中的某个值高了应该如何进入下一步分析，就有点为难了。
PS：Top本身也不是高性能的指令，它的循环读数据会消耗较高的CPU。就像下面这些。
定向定量其实是一个性能分析工程师的必修课。
前几天我在整理OS层面的监控分析、剖析调试工具的课件。发了几个图到7D Group的群里，有人说，现在很少有OS层面的问题了，还搞这些干啥。我竟黯然伤神。
因为很少有，所以就不用关心了？其实OS层能看出来很多东西，只是要看你有没有用心去看。
另外，在各个性能测试圈相关的讨论中，我很少有人讨论架构的。这是个严重的问题。就像上面说的，有人拿一个TPS就出来问题系统瓶颈在哪的。我看到有人在瞎蒙一通的时候自己暗暗无语。其实这是个顺腾摸瓜的思路。但是这个思路的建立却需要有各个层面都需要思考到的，所以需要一些基础知识。
（以上图也是随手画的，所以也不要太认真。）
这其实是个技术范畴的东西。在这个范畴里，所以和我们做的性能相关的角落都应该被思考到。有人说性能的问题99%在开发的代码里面。其实从我的经验上来看，不是如此。开发占不少的比重是没办法的，毕竟，那是一个个天天加班加点的疲惫工程师敲出来的，老是在变动的东西出现问题的可能性必然大。
我要说，性能问题有大部分是因为不懂基本知识、合理的配置造成的。
社会的舆论容易把做得最好的企业当成行业的现状，其实远远不是那样。现在技术人员的参差不齐造成的问题远远大于那些主流舆论营销的现状。
有人说性能比较高级的是会分析定位问题。像剖析工具呀之类的。其实仔细想一下，剖析工具的使用要多长时间学会呢，任何一个工具，其本身的学习成本我觉得超过一个月的都很少很少。更重要的是一些知其所以然的理解。如果有这些理解功底，纵然工具不会，也是可以尽快适应的。谁能说linux的的命令以及各参数都能记得住呢？常用的也就那几个而已。包括工具也是一样。
所以从overview的视角思考性能，是一个成熟的团队该做的事情。也是一个想深入学习性能的人该做的事情。
到此。rm -rf
