视频访谈： 刘国强：APM的5个层次及其核心价值

刘国强： 云智慧核心是三块，一个是销售团队，主要是分成互联网和大客户。互联网主要是偏互联网客户，大客户比较偏向传统的大客户，银行、电信甚至是一些大的企业，这些企业我们更专注在他的互联网业务上。像传统的封闭的电力这些可能不是我们最专注的，但是也分情况而定，原则上我们建议这个企业有“互联网+”趋势的业务可能是跟我们最切合的客户群，这是第一块销售团队。第二块是技术中心，就是我这个部门，技术中心做的是产品推向市场的过程。我们部门分几个部分，一个部分是售前，主要是和销售配合去打单子，包括见客户、做方案、做测试，都是售前的事情。第二部分就是售后。分几个部分，一部分是onsite实施，用户买了解决方案，我们是SAAS产品，但是也可能有些大的企业需要做onsite实施，因为他自己的人力不够，可能就外包给云智慧帮他onsite做实施。做实施之后还有些客户需要我们做onsite support,就是实施后的平台整个的运维。第三个就是实施之后的远程support。这是售后分的三个部分。我们部门还有第三个部分就是产品培训，比如产品推向市场，包括推向合作伙伴，这个过程中肯定要知识传递。这是我们技术中心，是云智慧第二大块。第三大块就是云智慧的研发中心，这是我们最核心的部门。所有的产品线都处于研发中心，研发中心又分成两大核心的部门，一个是专门做尖端研究的，比如说核心技术难点，包括技术方向把握，新产品原形，它有点科学家团队的概念，由这个部门去做。第二个是工程团队，就是从科学家团队这边做出来的原形、设计包括一些技术难点攻克之后要转向客户市场，这个时候用合理的界面和很好的体验传递核心价值，让客户感觉比较好用，用起来比较简单,确实也能看到这个产品的价值。这是我们工程团队做的，这是我们第三个核心的团队--研发中心。云智慧大体是这三个部分构成。这样我们做好了为大型客户、中型客户甚至互联网客户这样的准备。

2. 团队规模大概是多少人左右？

刘国强： 目前规模是160人左右。

刘国强： APM市场发展我接触是在2006年，真正发起产品的是WILY，是原来CA收购的。我以前在CA工作时就接触了这个产品，2006年APM真正的首创者是WILY来做的，到现在已经是九年到十年的时间，这十年以前都面向大型客户。但是我认为大型客户用的面不是特别广泛，原因就是有一些大型客户的IT系统基本都在内部，系统迫切性和紧急性，除了银行、电信比较紧急之外，其他的企业不是那么迫切，他们觉得OA系统、ERP系统未必一定要监控的那么严格细致，这是第一个问题。第二个问题是这个软件以前的研发迭代速度很慢，一年可能一个版本甚至稳定之后不再去改，那时对它的迫切性要求不太高，就算代码出问题了，一旦改掉以后就没有这个问题了。所以当时APM市场发展很缓慢。

4. 它的概念是不是更偏单点一些？

刘国强： APM我认为维度包括内容也挺多，大家听起来应用性能管理是很focus，很清楚，但其实不完全是这样。APM本质目标就是让application变得可用，性能和体验比较好。一个application依赖的环境非常复杂，依赖网络、依赖前端设备，依赖移动设备，依赖于PC机，依赖于网络的传递，依赖云平台，云平台上的虚拟机，虚拟机里面的OS，OS里面的服务，还依赖于你的代码，依赖于数据库，还有负载均衡，依赖环境非常多，在这个依赖环境上要把APM做好不是非常简单的事情，你要从前到后。APM核心定位就是做两件事儿，一个就是提供很好的用户体验，想办法帮助用户把体验提高。第二件事情就是做应用性能优化，一个是前端一个后端。本质上听起来是做两件事儿，但是两件事儿非常复杂。举个简单的例子，现在用户体验比较关注移动端用户体验，移动端IOS还好，型号版本加起来十几个，但是安卓得有两三百个，我最近做一个项目，用户把所有的移动终端做兼容性测试，你会发现很多软件装上去以后，老版本或者内存不够的设备，装上去就不能打开。这是常见的。这还只是安装问题。用户安装使用之后，我们做sdk切入去拿到用户的使用性能和体验，包括他的位置，包括他的网络和接入方式，有没有出错，有没有crush，这个过程量非常大，而且不同的用户需求不同。比如有些用户希望说拿到之后马上知道是哪个设备，哪个用户出的问题，crush是什么，我能查询出来马上帮他解决。有时候拿到这个东西不是很简单的事情，而且不同的设备版本也会升级，这是不断迭代的过程。这是从体验端。后端要更复杂，后端各种开发语言，JAVA，.NET，PHP，python，node.js的，这些平台有很多，你要解决这个又不太容易，还有各种开源架构，中间件架构，后端数据库，还有大数据架构，如何解决这个问题，其实工作量非常大，因为我在这个行业我比较了解。经常国外的发展很多年了，一定认为是国外最先进，这倒不一定，我总体认为它是先进的，但是如果细分到某一块，某一个平台，某一个环境，那就未必。因为依赖环境太高了，要求企业有很强的市场敏感度，第二个很强的研发能力，能快速迭代，快速满足互联网用户，和转型互联网+的用户的需求，所以APM本身是范围很广的。

刘国强： APM我们刚刚说解决了两件事情，一个是用户体验，这是它第一个真正的核心。我们主要还看开它到底能做什么，这是它真正的价值。里面具体用什么手段，用探针还是SDK都是为了拿到数据来分析，这是目标。用户体验我们觉得是两种手段，一种手段是主动了解用户体验，从全国各地甚至全球各地发起对应用系统的访问，比如访问端口、访问接口、访问网页，访问关键交易，看用户首先第一个能不能访问。能不能访问是多简单的问题，不一定，不仅是内网能访问，是在全球各地能访问，因为很多互联网客户都是面向全球的客户，全球客户能访问全国客户就能访问，一定要了解，要在客户有问题之前发现，我们管它叫主动的用户体验管理。用户打电话来的时候我们已经解决了，而不是在用户打来时很诧异的说是吗真坏了，我赶紧解决，这已经落后了。所以我们建议用户体验第一件事情就是主动的了解用户体验。第二件事情是真实用户体验。我们全国各地部署了很多机器人，机器人帮我们每隔一段时间访问核心关键的业务系统。我想知道用户真实在使用的时候到底是什么体验，我们把它叫真实用户体验。真实用户体验我们分两个大分支，一个是移动端，一个是PC浏览器，现在很少有CS架构，移动我们可以叫CS架构，但是它是新时代的架构，还是偏BS，就算用native开发出来app，但是其实它都用的HTTP协议，或者web API，我在两年前就写过一个API经济学，但是两年前很少人说。

8.

刘国强： 简单说一下API，大家尤其是程序员很多都理解API就是程序之间的接口，其实已经不是这个概念，API已经变成服务入口，变成微服务化的概念，API本身可以带来价值，带来收入，它是一个API经济本质的问题，它是一个入口，是一个接口，是一个服务的接口，是面向TO B更多一些的接口，甚至是面向TO C。简单来讲微信公众账户就是这个概念，包括我们的压力测试平台，都是通过API去调用。提供API这个服务的人本身是可以收费的，API变成业务后端的支持量是很大的，这样他就可以基于你的次数计费，可以分不同的级别，比如白金的合作伙伴，一年交不同的钱开放不同的接口，不光是接口，访问量也不一样，这就把它变成可量化、可经济的服务。

9.

刘国强： 我们自身后台系统分两种部署模式，一种是我们最推荐的模式是SAAS模式，我们在后台用了很多大数据架构，比如用到了HADOOP，用到了快速搜索引擎的开源框架，也写了自己的逻辑的代码，我们本身在后台考虑了高可用性，而且SAAS面对的是一堆用户，所以我们在数据存储上，每个核心组件的高可用上都是复用的，不会是单点，也不会出现单点故障，这是在平台架构设计上我们做到一点。私有模式也是类似的，私有模式主要看被管系统的量有多大，如果量很小就不需要做非常庞大的后台，每个地方能做到两两复制基本上就够用了。主要是看采集的数据量有多少，application和以前的基础架构监控最大的不同是application是做监听，而不是主动抓取。以前基础架构就是监控CPU加内存，频率不同数据量不同。但是application是交易量多少就抓多少。我们专门成立了试运行服务部，在试运行过程中发现问题会帮用户在数据层面及时调整，我们有严格的算法根据用户被管环境和业务大小来告诉他数据存储量有多大，这就完全考虑到它的存储，包括整个的高可用性。

11. 对，尤其是日志那么多。

刘国强： 对，数据量也很大。在这里面提一下APM的采集方式和其他的区别，日志是APM数据来源之一，狭义的apm一般不去拿数据，不去拿日志信息，我认为是出于三个分支。我们主要抓的是核心交易，不是抓流量，流量是属于NPM范畴（network performance management），它是旁路去抓流量。我们是嵌入它的中间阶段，它运行过程中我们抓他的代码上下文执行效率和性能。

12.

刘国强： 这个肯定是要抓，但是我们最重要抓的是订单执行过程中他的代码执行的A和B、C之间的调用关系，每个关系之间的调动时间，还有调用的参数，有没有异常和错误，这和网络、日志有很大的不同，是真实的抓到所有数据，只是选择抓还是不抓的问题。但是日志是要吐出来的，不吐全就抓不全，网络如果没有这个流程也抓不全。所以我认为这是三个分支，互为补充，也要看用户本身的业务形态来决定哪一种模式是最适合的。

刘国强： 真实用户体验其实和您刚刚说的虚假数据没有关联性，对于系统来说，它并不知道是人为造假还是真实的，它只是说人在有意无意的使用它，拿到你使用当时的体验。什么叫体验？体验就是使用过程中有没有异常发生，比如点一个按钮应该出结果但是没有出来，这就是异常，我们是抓这个数据的，异常是什么，怎么导致的，这是APM想解决的问题。第二个是成功了，但速度不够快，我希望一秒钟出来数据，但是转了10秒钟，这时候体验不好，我想知道这10秒钟到底消费在哪儿了，这是系统开发者，使用者和运营者，甚至运维后台想解决的问题，体验不好的话，用户就会不用。比如着急买股票，你下载一个股票软件，点了股票半天买不了，等到能买的时候股票没了或者涨价了，这就直接影响到客户不会用它了，就会换一家，这是客户直接流失，损失很大。这就是体验经济。刚刚您说的数据那个是另外一个维度，是从业务角度看，我们更偏向从系统角度和application管理角度看，更偏it角度，虽然我们想做的更业务，但是我们还是属于application的技术层面上的内容。

刘国强： 我以前就做devops，它是development和operation两个词的合并，这个是方法论，以前这两个部门之间有很厚的墙，研发是研发，运维是运维，上线时有严格要求，不满足要求就不能上线。但是现在是由业务驱动，业务要求尽快上线，尽快满足部分需求让客户能使用，再后续迭代满足更多的需求，这时devops应运而生。它的宗旨是什么，宗旨就是两个部门之间的紧密合作。你中有我我中有你，简单说就是你在开发的时候想着运维，做运维的时候想着开发，两个互为融合，互相思考，所以它会出现新的职业，运维开发人员，开发运维人员，有新的融合性职业出现，甚至还有devops经理，两年前你去搜索国外的职位，专门有devops经理，已经把这个融合在一起了。我们再讲一下devops和APM的差异，我们认为devops的ops是偏向生产，dev是开发和测试环节。Devops分三个部分，持续集成，持续发布，持续监控，或者叫做敏捷监控，这三个组成devops。但是每个人解读不一样。

15. 甚至有人把它解读为全栈工程师。

刘国强： 这又是另外一个解读，我觉得只要不是和文化冲突的都是对的，但是你要知道devops方法论的由来是什么，只强调全栈开发就有偏颇，一定要想到开发和运维在一起，开发制作过程和上线过程两个紧密融合在一起。持续集成是什么，做开发的时候一旦开发完马上把它Build出来部署到不同的环境里去，大家知道现在开发的代码会运行在不同的地方。持续发布是什么概念，你一出来build完就能把它发布到不同的环境里去，一个按钮就可以做得到，并不要人去做。这样的好处就是不断的验证代码在不同的环境下的健壮性，比如生产环境，准生产环境， QA环境，健壮性是不一样的，同样一套持续发布的流程或者脚本，在这个环境试了一遍，在另外一个环境下又试了一遍，这套脚本是可验证、可重复的。程序和人类最大的不同就是程序可重复，而且每次结果是相同的你才信它，如果每次结果都不同你也不敢相信，这代码里面一定有问题。这第二部分就是持续发布。第三步就是敏捷运维，敏捷运维讲的核心就是APM，只有APM才是当之无愧的敏捷运维的核心内容，我们常说提纲挈领，领在哪里，纲在哪里，其他所有环境都是为APM而生，为它服务的，这么一讲你就更清楚了。APM是devops的一部分，我们公司在devops已经做了很多工作，举个例子，我们生产环境有apm，在开发测试中也有。我们做了两个核心，持续的测试和自动化测试。移动端大家测试都是人去点，现在人工成本非常贵，而且人最大的问题是不可靠，人是有创造性的，但是他最大的问题是因为情绪而变化，他今天点的按钮很全，明天就不见得能点得全。最好的做法是你点全一次，我把你录下来，不断的回放，也就是持续可重复地做一件事情，移动自动化测试我们现在有这样的解决方案。第二个就是持续的压力测试，以前压力测试都是在实验室做，它和真实环境差别很大。真实环境是一百，实验室可能做到50。

16. 因为怕在生产环境里会出事儿。

刘国强： 对，现在我们提倡持续的压力测试，我就在云端帮你测试，在云端部了点，在云端按需测试，所有新版本上线，大小版本上线或者活动都可以做测试。而且很多压的都是生产环境，更真实。所以我们同事很辛苦，经常半夜要做压力测试，因为用户要停了的业务开放给我们做压力测试，而且压力测试经常和预期的差异非常大。举个简单的案例，我们两三周前做的一次测试，客户希望说这个业务系统压到3万并发，我们说没问题，因为我们也是根据这个收费的。我们在后台帮他准备了3万并发的资源，但是最后到了3000并发机器就不行了，不能用了。人自己的想法和真实是有很大差距的，为什么我们提持续测试，一定要多测才知道差距在哪儿，不要想当然，每个人都会往好的方面想，这是好的事情，如果想的和最终结果差距太大就是你太理想化。这是devops和APM的关联关系。

18.

19.

刘国强： 谢谢！