嘉宾 | 高楼
编辑 | 李慧文
很多人眼里的性能，不过是开发的边角料，看待性能工程师，天然就戴着一副有色眼镜。其实，一个可以独立做性能分析的人，在市场上抢都抢不到。可是，怎么才能成为这样的性能工程师呢？InfoQ 深度采访盾山科技 CEO、7DGroup 创始人，从底层为你揭秘性能高手的思维模式，以期帮助大量性能工程师们拨开职业的迷雾，登上身价百万的台阶。
1 我选择测试是因为它需要完善的逻辑思维能力
InfoQ：您是为什么会选择性能这个方向的？
高楼：在我 2005 年刚毕业那会，IT 还是个很好的就业方向，薪资高，而软件测试尚处于萌芽阶段，新潮且未知。那时很多人选择测试是因为不用写代码就可以拿到高薪。而我选择测试是因为我觉得测试是需要完善的逻辑思维能力的。它包括的范围不仅是代码，从操作系统到上层应用、数据库等等。
具体来说，我的第一份工作是路由器测试，不仅包括功能测试，也包括性能，可以写代码做，也需要用到硬件测试仪。这份工作中并不是把功能验证一下、代码能跑起来就行了，关键的是得懂各种协议。对协议的深入理解，才是测试的前提。我觉得非常有意思，也学习到了不少知识。
我第二份工作是在一家外企做无线产品的测试，就是测试界面上的元素，像颜色、布局、文本框之类的，对照定义好的规则就可以了。做了一段时间之后，我就放弃了，因为没有技术的提升。
在分析对比了之后，我觉得上层应用的性能测试对技术的要求范围大的，从我在第一家公司做路由器测试同时也兼做售后问题处理的经历来看，上层的应用的问题是很复杂的，需要从上到下所有的知识细节，这样定位问题才能快速，所以我选择了性能分析工作。
这个选择确实如我所想，从上层应用的视角来看的时候，会涉及到完整的技术栈，包括操作系统、网络、中间件、数据库、缓存、队列等等。我进入到了一个每天都会面对新问题的状态，新问题会不断带来新鲜感，让我保持学习的状态。
InfoQ：择业后，很多人初次上手性能项目，往往会手忙脚乱，能不能请您用一个项目为例分享一下作为外部专家解决系统性能问题的经验呢？
高楼：我说一个物联网的项目，当时 TPS 在 100 左右，并且硬件资源也没有用完。客户方还需要我们给出容量评估，即对应业务量的增长需求，应该准备多少硬件资源。
我一开始先让他们把性能场景执行起来，监控分析各类数据。这种 TPS 低、响应时间长的现象可能会包含着很多性能问题，所以我们不得不细细地排查。经过一个星期左右的分析并优化，我们调整了中间件、数据库等的参数，还做了表结构、索引、业务代码的修改，对一些具体的实现方案也做了架构调整。
最后在同样的硬件环境中，我们把 TPS 优化到了 1000TPS，硬件资源也都用起来了，还做了扩展性测试，查看了增加节点之后产生的损耗，给出了容量评估的结果。
做为一个第三方、甚至第四方到现场工作，对项目掌握的不可能比项目中的人更多，时间也是有限的。所以我的逻辑就是：首先要快速掌握项目中的技术栈，列出来架构图，看有哪些环节是在自己的知识体系范围里的，哪些是自己不清楚的。对不清楚的部分，立即去查资料。
查资料的时候，对于技术组件的功能部分先不用看，性能相关都要看，比如说：线程数、超时、队列、内存等等。但是对不熟悉的软件平台，也一样是要先看架构图，再分析系统的实现逻辑以及性能相关的配置，迅速找到性能瓶颈点。而做这一套操作是需要有知识背景的，从操作系统、数据库到代码功底，都是需要自己慢慢累积的。
2 性能项目本该体现出的价值是给出一个系统明确的容量结论，给出容量对应的硬件规模
InfoQ：现在性能相关需求普遍非常混乱，您认为造成这种现象的根因是什么呢？性能真正的价值应该是什么呢？
高楼：我觉得性能的需求不应该用混乱来形容，而应该用未开化来形容。现在的性能需求，大部分都还处在懵懂未开化的阶段，主要表现在这些需求并不合理，而且常常会出现概念误用。
比如说，我们在做项目时经常得到的一类性能需求是：系统要达到 10000TPS，响应时间要求在 1 秒以内。这样的需求没有背景约束说明，如在什么样的业务模型、业务数据量、系统环境之下要达到的，显然是不合理的。
还有就是概念上的错误引导。在我写完第一个专栏的时候，有人问我：性能测试、压力测试、峰值测试等等这些不算是合理的性能策略吗？这些都不能算是，因为我在性能项目中从来没用过这样的策略来指导落地的过程。拿最基础的性能中的关键概念 TPS、并发用户、在线用户、资源使用率等来说，在性能报告中，有很多人不清楚它们的真正作用而在张冠李戴。
这些现象，主要是由于在性能方向上，市场的需求引导有偏差导致的：我们为了快速扩张或心理上的安全感，经常拿硬件来堆容量。
举一个我亲身经历过的项目来说，一个买了几百台高配置的硬件资源的企业，在经过性能优化之后，最后只需要 60 台左右就满足了容量需求，然而硬件已经买了，还带来了其他成本问题。而这些本来只需要一些很少的性能投入就能解决，但事实上性能的投入却少得可怜。我记得在一个项目中，有两三百个开发，二三十个项目并行，只有一个半的性能测试人员，这显然是对性能应该做什么如何做都没有概念。
而有些对成本控制得特别严苛的企业，由于经费的不足，不得不在少得可怜的测试环境中来推导生产上的容量，不得不面对各种局限导致的问题。
这一弛一张之间，导致的结果就是性能的价值根本得不到体现。只有一种情况下，性能会被非常明确地提到桌面上来，那就是当生产出现性能问题的时候。前阵子，我处理过一个项目，涉及到硬件厂商、软件厂商、数据库厂商三家企业，系统总是出现问题，而这三家厂商相互推诿了两个月居然是因为一个工程师拿了个同步读写 IO 的命令测试了一下，就说硬件资源支撑不了应用系统的 IO 需求。这里面有立场的问题，也有技术能力的问题。
产生这种现象的原因是性能项目本该体现出的价值没有体现出来，即给出一个系统明确的容量结论，给出容量对应的硬件规模。这就导致了大企业更相信堆硬件，而小企业的性能只能查查软件层面的问题。
要想解决性能相关的乱象，在我看来只有一个出路，那就是做性能分析的人要有系统的、严格的性能工程思维，从需求到场景到分析到运维的过程中都可以覆盖完整的性能工程思维。
3 一个可以独立做性能分析的人，在市场上抢都抢不到
InfoQ：您认为性能工程师相比其他工程师最大的区别在哪？需要怎样的能力？为什么选择从事性能分析的人比较少呢？一些毕业生、求职者的心中，存在职业鄙视链，您怎么看待这个现象呢？
高楼：合格的性能工程师，必须学会的是性能瓶颈分析定位。既然要定位问题，在一个系统运行的过程中，涉及到的所有技术细节都是要掌握的技能。这是性能工程师和其他最大的区别，知识面要足够广的同时也需要足够深。
我们不是写代码的，但我们要能迅速找到代码慢在哪里。我们不是数据库工程师，但我们要能迅速找到一个具体的 SQL 或配置的不合理。这样的能力要求，应该说不是基于对个人能力的要求，而是对一个团队的要求。不过当你一个人能干过一个团队的时候，想想就知道你的位置也会高起来。
而现在，市场上做性能分析的人比较少的最大的原因就是，很少性能工程师花大量的时候去弥补知识的广度和深度。同时，还有一个重要的原因就是性能分析是要靠项目来历练的，就是见多了自然就懂得多。只做脚本和简单监控的性能工程师可以定义为走流程的工程师，不涉及到性能分析的部分。
关于开发和性能行业，其实，当把职位调侃成鄙视链的时候，这已经是一种误导了。当我带团队的时候，我想的是这个事情要有人来做，至于这个事情要的技术功底是什么样子，需要多少成本，其实是和市场有关，而人的成本取决于供需关系。
技术人员是真实地存在鄙视链的，当一个问题，我能搞得定，而你搞不定的时候，我就可以鄙视你。
现在市场上认为开发比性能“牛逼”的感觉应该来源于薪资，而薪资是市场供需关系决定的。如果你只是做一个性能脚本开发工程师，给个 CPU 使用率之类的报告，确实不值什么钱。而性能工程师的价值在于把性能项目做好，保证线上的稳定运行。如果一个性能工程师可以拍着胸脯说：这系统上线因为性能出现故障，我负责！这样可以独立做性能分析的人，在市场上抢都抢不到。
在我之前的项目中，带过一个架构师。作为性能出身的我带一个团队，还带工作十年以上架构师的角色，自然会有人觉得我是带不动的。在技术的正面冲突中，当问题出现时，我们同时去分析判断，他会给出建议，我也会给出建议，在不断地推演判断分析的过程中，他们发现我这个做性能出身的似乎也不是软柿子可以鄙视的，之后就沟通顺畅了很多，个中关键不是谁能胜了谁，而在于能不能正面地对话。
在我看来，这其实只是技术人员（也可以说是知识分子）的清高而已，只是一种人际交往的状态。这种清高也很容易打破，不用技术的话，其实撸个串、喝个酒也可以打破。
4 精心沉淀 动手实践是成为以一敌万的性能工程师的唯一捷径
InfoQ：很多初入性能行业的人，还处于职业上的迷茫期，您对他们有什么建议吗？性能工程师该如何自我成长呢？
高楼：我先谈性能工程师的成长路径吧。如果想成长为一个好的性能工程师，路径是比较明确的：
·首先，要学 IT 基础知识，架构、操作系统、数据库、缓存、队列、网络、语言等的基础知识，当然基本的操作也是要会的； ·其次，要学工具。性能工具、监控工具、分析工具等等，有了工具才是有了操作的对象； ·最后，要学原理，一定要理解原理才能真正学会性能。
这里我要强调一下，一定要理解原理才能真正学会性能。举个例子来说，前几天跟我项目的一个小伙子说会用某个性能工具做脚本，也相当熟练，于是我就问了几个和工具相关的问题，结果近十个问题他几乎一个没答上来。因为他并不清楚原理。不懂原理，遇到问题只知道现象，而不知道如何分析解决。
接着我来探讨迷茫和成长。这两个问题是一体两面的。不成长你就会迷茫，去忙着成长了，就没时间迷茫了。在当前的市场上，很多人的知识点都是片面的，市场人员的流动性大，导致求职者不得不总是学一些新的技能，而学会了又可能要面对下一个新的技能，而想积累个人技术素养需要很长的时间。所以我特别想强调静心沉淀的作用。
其中，看书是成本最低的一种沉淀方式了。前阵子因为项目的需要，我需要把微服务分布式架构的很多内容系统地整理一遍，于是我就一次性买了三十几本和微服务分布式架构相关的书，一本本翻，觉得好的就仔细看完。当然，无所谓获取知识的途径，耐心最重要。
我还有一个习惯，就是会把自己会的东西都记录下来，当我一字一字输出的时候，就觉得这些会的东西已经告诉别人了，自己也就不会守着已知的东西，而去学习一些未知的内容了。
此外，多动手实践也是重要的成长方式。这句话看起来是句废话，但是可以统计一下技术人员在接触到一个新技术时，自己花了多少时间动手实践呢？
最后我想说，如果连学习这件事情都进行不下去，那就不止是职业上的迷茫了，人生也会迷茫。
嘉宾介绍
高楼
性能专家，架构级性能解决方案资源专家，盾山科技 CEO，7DGroup 创始人，性能标准撰写人，网名 Zee。拥有 16 年性能测试分析调优经验，致力于架构级性能测试、容量水位规划、性能瓶颈分析、性能异常等技术方向，注重性能测试之后的调优过程和如何将性能测试与分析的结果在生产环境中体现。他带领过 300 人以上的国内外混合团队，完整做过 40 项目，做为出品人和讲师参加过多次技术大会。目前，工作重心在微服务分布式架构级性能规划、全链路压测等具体落地实施方面，主要做企业咨询、培训、实施等工作内容。
