BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

刘国强:APM的5个层次及其核心价值
录制于:

| 受访者 刘国强 关注 0 他的粉丝 作者 InfoQ 关注 13 他的粉丝 发布于 2016年3月16日 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点
42:17

个人简介 刘国强,云智慧技术VP,超过18年的IT行业研发、IT管理、服务器和桌面虚拟架构、数据库和云计算专家,企业级方案专家。

全球架构师峰会(International Architect Summit,下简称ArchSummit)是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群,讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后,InfoQ中文站主办的又一次高端技术盛会。

   

1. 各位InfoQ的网友大家好,现在我们是在ArchSummit大会北京现场,今天做客我们专访间的是云智慧的技术VP刘国强先生,第一个问题先请您简单介绍一下云智慧的团队构成。

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

   

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

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

   

3. 这两年APM流行以来,国外比较流行,国内稍微滞后一下,现在整个行业发展现状是怎么样?

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

   

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

刘国强:更偏内部,偏单点,而且很多用户一旦解决问题马上就不用了。但是现在有很大的不同,这几年我也是做APM包括SAAS,我研究了很多友商,包括国外和国内的,见了大量客户,我的感受是互联网的兴起让软件application变成企业的业务,以前说业务好像和软件和it是隔一层的,但是现在软件就是业务,application就是业务,这才是核心。一旦软件变成业务之后,软件和application的可用性、可靠性和性能直接决定企业的业务收入,这是第一个核心变化就是它的业务完全依赖于软件。

第二个变化是软件的更新速度很快,原因是它是直接面向客户的,不管to b还是to c,客户不断的有新的业务要求,包括竞争对手的新功能的推出,不断的更新它。

第三个是移动互联时代,移动用户手机用户更多,以前PC端受众面比较窄,而移动受众面会非常广泛,比如说以前老人用PC最多就会打打游戏,现在老人都会发微信发微博会交互,你会看出移动已经扩展到每个人的每个角落上去了。业务依赖移动互联之后,被迫的要求在界面的更新速度要快,后端整个软件支撑架构更新速度要加快,也就是说迭代加快。比如我们公司做SAAS,基本上可以说小版本小功能每周都有更新,大的feature可能一个月两个月,而且有的客户会有明显的需求,这个需求可能就是我们未来的发展方向,我们就用两周时间就会解决。我们最近有两个案例就是很快签单。因为软件是核心,APM说白了就是监控、了解这个软件的可用性和性能问题,也变成核心了。也就是说APM已经变成一个必不可少的中心和平台,这是目前的现状。所以我认为这个市场比十年前大很多倍,具体数据我看到一些数据是26亿美金在中国市场,但是我认为未来市场会非常大。所以我从外企做了十几年投入到这个市场,我看到这个发展的变化,希望也能在这里发挥自己的价值。

   

5. APM这个行业是不是跟其他行业有不同的地方,比如说一些领域可能会比较容易细分,APM不像其他那样那么容易细分,它其实是一个比较整体的业务?

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

   

6. 这比我们一开始理解的复杂一些,因为一开始大家对APM理解就是它是包含五个层次的系统。您觉得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. 这就是一种云服务了?

刘国强:对,就是云服务,这就是用户体验,我们在用户体验下足了功夫。我们做主动的用户体验的管理。我们还会专门访问用户,帮用户从全国各地发起对它核心API的访问,在全国云智慧是最早做这个事情。比如现在手机端访问后端业务,你是通过web api去做,但是我也可以用全国各地的站点去设置访问你的API。以前大家认为API是调一个函数返回一个结果,但其实API可以做的更商业化和更交易化,API把关联关系做起来就变成业务了,并不需要依赖于手机端的界面,因为手机端界面再大也比较小,操作起来不方便,就算模拟那成本上投入产出也不好。所以我们用全国各地的骨干网直接对api访问,api用不了客户一定不能访问。用户体验做的主动管理是第一个概念。第二个我们做真实用户体验,做移动和PC两个真实用户体验,专注的重点是在移动端,PC端做了很多年,技术相对成熟而且替代品非常多,我们有但是和别人差距不大,我们重点放在移动真实用户体验,做比较有影响力的银行、电信包括互联网金融的客户,用户体验真的很好,而且用户提出新的需求我们很快就满足,这是我们研发中心的价值。

我们说了半天还说的是前端。后端主要是做应用性能的优化。做优化大家觉得就是把代码拿出来让人看效率怎么样,这其实是表象。真正后端要做application层面的东西,我们在自己产品上始终也要求这么做,一个是分层理论,业务要分层,逻辑要分层,拿出来很多数据一定要分层化。分层化就是面向不同的使用者、决策者,你要给他呈现不同的视图,不同的画面。比如CIO看堆栈看不懂,不懂没关系,就是告诉他application健康不健康,第二个不健康在哪儿,是出错了还是性能慢,性能慢也要分析。要面向不同的视角出不同的视图,让别人看到的东西不一样。如果是开发人员看就是到底是什么问题,能不能解决。运维就是告警哪儿交易出问题,哪怕是半夜也得上去解决,因为现在都是7x24小时服务的,数据库管理员又不同,他可能希望数据库本身的测试,表空间也好,阀值包括索引这些问题是否正常,如果发现锁堆积很长,对他来说也是一个问题,这是面向不同的用户。要把它融合在一起,不同的视角去看能看到想要的东西,最终还能优化这个问题。这比较复杂,要把这个逻辑花时间和代价走通。APM在中国刚刚开始,不管是云智慧还是友商,我们都是刚刚开始,真正热起来也就一年多的时间,大家都是发展起来,人员也是不断的发展,新的人员融入,团队管理也面临很多的问题。

   

10. 刚刚您谈到后端,尤其是性能优化这方面,但是它有一个前提,就是要对客户应用有一个很好的监控,这个监控系统怎么保证它的高可用性。无论怎么说,你毕竟是一个旁路的监听,不是系统本身自有的系统,你对信息的抓取只是一个旁路,比如它会有性能瓶颈和带宽限制,你怎么保证监控系统是高可用的?

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

   

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

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

   

12. 比如说是否成功?

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

   

13. 您刚才谈到真实用户体验,我们想了解一下,尤其是移动端在APM上它有哪些比较重要的性能的指标?比如说从有移动开发以来就有刷榜的行为,有可能有为了做数据而去做数据的,这方面无论是对于投资人还是对用户,或者是平台方,都是一个比较大的烦恼吧。您觉得真实用户体验怎么保证一下?

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

   

14. 你如果做了一些优化性能管理,肯定是对devops有影响,特别是一些大的企业有自己的开发能力和开发团队,企业在实施开发过程中APM和devops两者是有什么样的关系?

刘国强:我以前就做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的关联关系。

   

17. 最后一个问题是想问一下APM在易用性和分析的深度这两方面如何取舍?

刘国强:易用性和深度是不同的视角,APM我始终觉得要分析使用者,APM面向的对象是谁,谁会用它。

   

18. 用户嘛。

刘国强:对,但是用户要分成不同角色的用户,角色和易用性和深度就有关系了。比如像我刚刚说的IT应用管理人员或者应用业务人员,应用业务人员他关注的一定是他的用户有多少在线,他的用户有没有问题,有没有反应不好,有没有经常当掉的情况,用户引流有没有引流过来,或者没成功,为什么没有成功,是因为体验问题还是因为引流过程中出错了,这是真正业务人员关心的。你给他的视角是不一样的,以用户为核心给他做的展示。但是应用架构师关心什么呢,是应用拓扑全貌是不是每个点都用到了,每个点的负载是不是平均的,大家都知道现在都是做集群,包括做多冗余,前面一定有负载均衡,不管软的还是硬的,负载均衡后面都是一堆的WEB Service也好,中间件也好,甚至数据库,它都有的。在这样一个情况下用率平不平均跟架构师是有关系的,架构师希望在拓扑图里告诉他每个业务的吞吐量到底有多大,每个吞吐量过程跟它相关的响应时间是不是关联在一起,这是架构师关心的问题。

我们再看运维开发人员,就是devops这种新的角色,他们关心的是程序从前端过来的时候响应时间如果慢在中间件层面上,他想知道慢在中间层面里的堆栈是怎么运行的,代码之间怎么调用,供给关系是什么,我能看到这个代码,能知道这个代码有问题,马上提出来给相关的开发员把它改掉,这就是他的视角,对他来说就是深度的。至于说什么时候该深度,我们建议根据不同的开发语言用不同的方法做,比如有的开发人员可能依赖于很多系统包,系统包非常大,这时我们建议用黑白名单去做,定义你自己的包,把它做成白名单,其他全部是黑名单的,然后再按需的调整黑名单白名单的顺序。所以深和度是实践的过程,我不会建议你马上做什么措施。我以前做IT咨询,帮人做部署系统,我最大的经验就是你一定要和用户深入的探讨,花两到三周时间跟用户谈,包括我这个系统本身,每一项决策的优点和缺点都告诉用户,由他来做决策,他做的决策他是完全理解的,他在运维他的系统时知道为什么那么做,不是简简单单的你让我去搭环境我就帮你搭完,而是我建议每种搭法的优点和缺点,你选择合适的配置方法。这时候你能看到APM对人的功力要求还是比较高的。深度和广度一定要兼顾,但是不同的人、不同的环境兼顾方法又不一样,广度也好,包括视角也好,都是非常重要的,最终就是一个目的,解决用户体验问题,这是APM真正的核心。

   

19. 好,谢谢您。

刘国强:谢谢!

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT