提升业务价值 创见卓越用户体验 ——APM应用与整合分享

Posted 2020-08-11

提升业务价值 创见卓越用户体验

——APM应用与整合分享

 

本文整理自GOPS2016全球运维大会 上海站 APM专场杭州数云运维总监罗兴峰的演讲。

我的分享和前面几位的出发点不太一样，我实际上是APM的用户，前面大家的思路都是如何实现，在腾讯这边他们也是APM的用户，只不过最终自己来解决问题。我自己并不是做互联网技术的公司，我们是一个做业务型的公司，但是我是业务型公司里面的运维，我要保证我们的公司能够很好卖业务的时候才选择了技术。

 

我今天来的时候碰到了一个情况，和我今天讲的这个事情其实有关系。来到运维的大会挺激动的，领了一件衣服，非常想穿着这件衣服来分享，我很开心跑到洗手间换这个衣服，但是这个衣服我能穿上，但是过于性感，大体都够，但是肩膀太窄了，就换下来了。生产这个衣服的厂商可能就会碰到问题，因为不会有人告诉他这件衣服有问题。而换一个角度来说，我可能在软件行业里面的地位就像衣服的生产商一样，不会有最终用户告诉我你的软件里面其中一个按纽总是要30秒以后才出来。但是这个功能我非常想要，如果客户对你的忠诚度非常高，愿意告诉你这个软件这个按纽老是不出来，这已经很好了，这一句话值得我们给大几万块钱的奖金，大部分的客户不会告诉你，只是默默的不用你的产品了。这个时候你根本不知道发生了什么问题，这种情况下APM的价值就非常高了。

 

从产品的角度来说，因为我们做复杂应用，企业级的应用，但是在互联网上销售，这种应用的体量可以用一个数量描述，就是大小是30个G，里面有大量的业务数据在跑。一个客户会创建很多任务，比如是同时并发的任务数会达到一百，这是一个客户，这一百个内容，会在里面不断弄，而且时时刻刻都不同。到底哪个出问题了我根本不知道，而且不会告诉你，其实连客户都不知道，因为这些任务在后台是自动跑的，无人干扰的，这个任务可能跑两天，可能跑一天，他告诉我这个任务关涉到我的营销，涉及到三十万的亏损，杭州数云要不要给我赔一下。

 

这种情况是会发生的，这种情况下我作为一个运维，我们要发现这种问题的时候怎么办，我不可能针对所有的事情做一次开发做一个监控，做一个报警，因为每个情况都太特例了。最大的问题实际上就是这个问题到底在哪里？有多严重？而且这个问题的发生其实是有偶发性的。1500家客户里面，可能有一家客户在一个月发生一次这种问题，但是这一次，到底是什么原因，就需要案发现场，比如说刚才说的全数据，当时那一次点击或者那个作业的数据绝不能丢的，如果丢了就看不了案子，就无法知道当时的情况到底是什么情况，也许由于外部通道挂了，也许由于数据平台出现了问题，甚至是出现了断网，我们还没有像腾讯淘宝这么强大，容错那么厉害，我们整个团队没有多长时间，而且业务规模也很小，再加上我的运维只有几个人，不可能做到这么高级别的事情，最重要的是发现问题并且把当时的问题记下来，和开发一起解决问题，这都是运维的工作。

 

我们当时有过一次性能方面的简单案例，这个案例花了两个核心程序员，三四个普通程序员，一个月的时间才知道问题在哪里。当时有一些客户反映某个功能很慢，但是我们自己点的时候很快，没有任何感觉，偶发性的，我们相当于从应用这一端开始看，觉得挺好的，总是没有什么太大的问题。追究的问题是发生在nginx到app这一层，受到淘宝机房通讯带宽的影响，应该是带宽的问题有的时候非常快，有的时候非常慢，这种情况我们无法知道遭到怎么回事。最容易定位的问题是整个挂掉，最不容易定位的是不稳定。这种时候客户找你的问题你无法排查当时的情况。当时要做的话我们需要找各个环节的日志，每个环节的日志都得去看，而且是要关联起来。这一点很难，关联起来就是这次点击是从前到后到数据库到APM，他们是不是真的是一次，因为只有那一次发生了问题，那一次的问题到底是什么样的情况。我们其实当时关联的手段其实是蛮土的，就是看时间，那个时间点是不是它，是不是从这儿来的，这就要求一个工程师从头到尾全部都得走，但是作为一个创业型公司，我们这个级别的工程师很少，大家凑在这里碰，大概是这样的情况，真的是搞了一个月，这是比较丢脸的一个事情，这也是第一年，但是那个时候的难度就是这样，因为都很土。问题解决掉了，定位在某一个地方，最后解决挺简单的，真正发现问题蛮难的。

 

我们将来肯定会碰到各种各样的事情，各种性能问题各种情况，我们还碰到过一次数据库某一次点击，有一个程序员的参数设的不是非常好，但是要读记录读了八十次数据库扫描，其中有一些废的操作。当时做的检查都是有一些数据库无法发现问题的情况，现在其实就比较简单。

为什么今天讲这个事情，我们和云智慧这边合作做了一年的项目，当时老是说云智慧的产品不是非常完善，但是他们的工程师比较愿意和我们一起建立整个完整的链路，而当时最大的难度是我们采用的app的东西还有就是底层连接件的东西都是他们原来不支持的，他们工程师后来和我们建立了全套链路。这个最大的好处就是我们可以知道一次访问所有的东西。前面说的某一次点击是一次事务，从nginx到app，这一次作业里面所有的环节表现，这一点很重要。我们首先是找到这次访问到底是慢还是快，这个直接可以报警，找到这样的报警以后再看到底是哪里慢。原来我们还需要根据数据库的日志来走，甚至包括因为应用的云服务的IDS日志获取难度其实比较大，我是应用方，我有时候拿不到数据库的日志，因为没有日志接口。这种情况下，通过应用得到接口的情况下又是比较好的点，这种情况下我们比较容易应用问题。

 

刚才只是说APM，我们能够找问题的具体技术，但是从一个应用方来说你能实现这些技术环节，到你真正把APM发挥到企业里面，让它产生生产力的话其实还需要很多问题。因为用什么样的方式来管理这个APM的报警，我总不能在APM的平台上面完全建另外一套监控管理平台，或者是报警平台，其实是很难的。因为为什么？没有人。我无法为外部系统建立一套小组，比如说两到三个人天天看APM的数据，其实很难，这是非常难的事情。我们原来有自己的内部监控系统，他们把报警数据对接到了自己的监控平台里面。这样的话可以用不变的工作流程来统一APM的监控情况，然后我可以通过统一的API或者是报名短信发送到监控处理人员手上，大概是这样的情况。

我们得到了这样的数据以后，想用APM的数据有两点，一方面是说我直接把APM的性能表现数据做在APM平台里，这个时候我们需要和云智慧APM厂商一起讨论，怎样展现我的平台级应用监控数据还有关联性数据。我们当时碰到了一个问题，关联性太惨了，因为数据太大。在这个时候我们一起来探讨关于APM的数据如何落地真实能用的情况，他们在做这种允许你客户自定义产品的角度，你可以规范哪些APM是一个产品，然后让他们能够从一个产品的角度来展现，这是允许客户自定义的。这种情况下，我们的APM数据就可以逐渐的形成一些可定义的报表，因为我自己有内部运维分析系统，如果在系统平台里面能够直接把这种分析的报表做出来我们马上可以用。实际上我们可以通过厂商这边的接口把性能数据抓过来做自己的报表分析，这样有一个好处每个星期都可以针对性能数据做相应的分析。就像刚才我们说的衣服的案例，如果通过性能分析的数据发现提取销售的尺码所有小尺码没有任何人买，所有人的销售都偏向于大尺码的时候说明我的系统我的产品设计可能有问题，因为不可能是偏向一端的，可以从数据的异常角度来看一下自己的产品。

 

我自己就有同样的例子，我自己线上产品的性能表现是不是有哪些方法能够看出来是慢的或者是总是报错超时，这个数据反馈给研发，并且不仅是反馈，要跟进这个问题到底怎么解决解决到什么地方，怎么解决的。在这里面有一个点和前面腾讯老师讲的观点不一样，因为我们是创业型公司，创业型公司没办法只做运维，这是很痛苦的事情，当然这也逼着大家不得不考虑更多的事情，就是说公司给了运维压力其实很大，不仅要对运维本身的事情负责，还要对产品的质量负责对产品的交付要负责，你要覆盖到功能，甚至要比研发还研发。我们当时其实后面做这份报告的人，这周哪一个地址是慢的，并且知道哪个方法慢或者是哪个域慢，这个层面的报告就很厉害了，而且借助APM厂商的威力，我做这个事情的工程师是一个刚毕业一年的小姑娘，完全不是技术背景的人。 APM性能数据分析思路是比较容易传播的，我觉得APM很炫酷的是技术实现，更好的一点是最后落地的方式非常简单。这对于我这样的创业型公司或应用APM的厂商是非常重要的。我现在只要一个刚毕业的小姑娘来做，而且她的成就感非常强，她经常拿报告去找研发拍桌子，这个东西什么时候改，研发都不知道线上有这个问题，但是这个小姑娘知道。后来能做这个事情以后，公司的再下面一层的人，原来运维可以做这个事情，这个还是比较好的一个事情，确实帮忙解决了很多问题，这种问题当发现以后，解决的速度非常快，两到三天问题就可以解决掉。

 

我们其实通过这个事情以后，整个运维团队甚至公司的技术支持团队就会发现，我们团队的定位已经开始向一些特有的方向发展，这个其实是跟运维和运营化运维的方向是有关系的。就是比较适合这种初创型公司或者成长型公司，再到上面又有人拆哪些人做运维哪些人做线上支持，在某些阶段没有这样的资源，这样的话比较容易来做。我的几个成长当中的运维工程师，在这上面的收益非常大，因为他们现在拿出去就是每个人都是非常合格的运维架构的经理或者是运营型运维的经理，都很厉害，他们只是工作了两到三年，而且他们也不完全说是必须需要脱离技术，因为不懂就做不了这个事情，必须要非常懂，我觉得他们成长最大的标志是取舍，他告诉我们在这个阶段我们自己要去做的技术是哪些，哪些技术是我们不能做的，为什么？在APM方向上我们投入不起，这不是我们的业务点，因为我不卖。我们自己要做的反而是中间这块的架构，不会有任何公司帮我们做，如果有公司帮我们做，我们还愿意选择，就是说我需要想办法能够接入所有的严控系统，包括外部自建的，还有内部做到产品里面的，我要把它想成外部的资源也是和我们自己的资源一样使用的方面才能发展，这样可以把外部的资源当成自己的资源，无非就是在算帐，我用多少钱自己做，我用多少钱找别人做，找别人做的话用什么样的标准接入进来，这样的话才能实现统一的方法，这个东西是创业型公司的运维需要做的。

但是专业领域的人做APM这块就很厉害，因为我们做不出来前面的东西，我们在最初的时候没有这些黄色的这些点的时候我们当时想如果有一个技术或者有一个方法能力从前到后都串起来就好了，当时有很多人都是这样的想法，我们花的最多的时间就是把所有案发现场的线索都串起来，一个老的干警，他们破案都不是单个信息采集，而是把所有信息汇总起来的能力，APM干这个事情很厉害，一方面把所有的信息自动采集，另外一方面把所有的信息自动关联，这一点不是我们的企业来做的，但是我们理解了以后觉得这样的用户非常好，我们就把它应用起来了，其实也花了比较长的时间，因为我们上了新的系统，这一块也是花了比较长的时间，但是现在已经可以了。

在这个地方我们其实将来用的时候，刚才我们讲了这些人变少了，而且人变得要求更低了，我们其实找到了一种使用的很好方法，我们所有的产品在线上做测试。有两种测试，一种是压力测试，就是大压力的直到打崩溃为止的压力测试，我们的软件会面临双十一，双十一的零点和一点的压力是一百倍，我们在那个时候我们要看哪个系统最先挂掉，哪个位置哪个功能模块最先挂掉，通过APM来测就会比较容易聚焦，这样就可以制定双十一的方案，最后如果搞不定，零点到四点必须要降级，只要把那个地方一降就可以了，APM可以帮我们发现这个点。

然后我们发现所有的人最有效的工作时间，从原来很少的工作时间都都变了，那个时候真正有效的工作时间非常非常短，大家每天都忙于干不太重要的事情，后来想了很多办法，APM是其中的一点，让我们比较大的解决了性能定位问题，因为我们的运维团队其实是从研发团队里面慢慢成长出来的，在这个时候其实对于研发的自身需要非常强的点，因为底层的系统支撑都用平台的方式走，这样不需要做集团的事情这个难度降低了很多，但是对于创业型公司来说是非常适合的一种情况。在这种情况下，我就让性能分析和性能报警每周都做，就是原有的时候我们等着客户来骂，等着客户来说你的什么什么功能已经挂了，现在很多情况是客户还没有什么太多的问题，甚至客户没用的时候我们发现这个功能刚上去，我们的自己的测一测，自己就报警了，我们告诉产品告诉运营里这个功能马上要调，这样就赢得了很多时间。

再比如，你在双十一这个关键点，我在九月底没有推出这个功能的时候。我可能就失去了推出这个功能的意义，因为竞争对手可能有了。竞争对手已经有了的时候，所有的商家已经买了那个东西，我们到了10月15号才出来已经晚了，营销的机会就没了，这个时候你可以说是研发的责任呢还是运维的责任，但是不管是谁的责任，对于公司来说你都失败了。在这个点上失败了大部分人不一定能够进入BAT，在BAT工作非常聚焦，我老婆做网络协议性能测试，就要测出多大的包能把这个服务干掉，我就是如何让我的公司很好的发展很好地赚钱，然后很好地上我的团队获得职业成就感。运维团队的职业成就感是超出解决纯粹技术问题的，但是解决纯粹技术问题的成就感，如果公司用你的技术问题赚钱了，比如说做APM的厂商他们也很有职业成就感，因为他们做出来的技术能够帮助客户解决问题，这种成就感也非常强。

今天想讲的大概的点就在这里，就是一个实际最近一年的问题，去年我们没有这种东西，我们准备好了这个东西，我们双方都有一个模糊的需求，我们想把这个东西落地去实现然后改进我们的工作方法提高我们整个团队的工作能力，中间克服了很多问题，但是在过程当中我们确实提高了很多，而且工作方法提高了很多，所以大家形成了很多的习惯性的改变，用数据说明事情，用数据说明一些问题，这也是APM比较大的一些点，大概分享是在这里。

 

前面也说的比较多，对于不同类型的企业，APM哪些方面比较重要，刚才说了一些点，帮我们省时间省人加快市场节奏，提升研发能力，提升运维能力，让企业健康成长，是在创业公司里面是比较重要的点。在很多大型公司里面，相对更大的公司，如果业务特点会更复杂，甚至将来APM可能成为业务增长点很有可能也会自己做。

你可能会碰到假设有一天BAT做这个事情你怎么办，也会有这种问题。但是我们也看到了新的方向，APM不仅可以做应用性能的分析，还可以做业务性能的分析，因为我碰到过一个情况就是有一个产品经理跑过来和我说，你帮我看看我的产品里面哪个功能点是客户最喜欢用的，然后这个用户用的好或者是不好，你帮我看看，我们那次做这个数据，就是来自于APM帮我们采集的数据，在合作当中，其实比较好的一点我们对于APM的了解也开始变强了，我们知道APM采集了哪些、能做哪些事情、不能做哪些事情，我们就一起合作。因为APM现在一定必须在系统层面做你的一个业务模块是怎么样热度是如何的，客户到底反映怎么样浏览、上哪个区域点击最多，但是我已经看到有些公司在朝这个方向发展，这个也很厉害。

APM不一定是应用性能会延展出来很多点。APM在各个环节的传感器思路，它是一种比较容易实现的思路，有很多公司自己做也是一种思路，因为像刚才张丹说的，你的网络Wifi的探测，就近那个点，我觉得这个思路特别好，你从端这边发现ping值马上发现数据好坏，因为你无法买点，我就发起探测的思路获取数据。思路是一样的，我们现在用传感器的数据也干了很多不一致的事情，我发现我的数据，我特别关注的这个点，比如说硬盘的挂在点，因为我会碰到不同的机型，网络网卡这些问题，我会用一些小的机器人把数据传过来，这也是我学到的一些点，这些点不一定你使用哪个APM的产品，但是这个思路一定可以让你改善工作这是一些简单的分享。谢谢大家！

    

    

    Q：我想刚刚您分享了很多关于APM所带来的积极的东西，我想更多的了解一下现在您采用了什么东西，您现在遇到的现有的产品可能还没有能够解决你的问题，比如说像后台能不能检测到。

    罗兴峰：之前监测不到后台任务，现在可以了，因为我们当时在合同里面谈了一点，这个功能必须实现，云智慧他们也做了这个事情，只不过这个事情我还没有在线上大批量的做，因为我做的过程当中通过别的手段采集了这些数据，我相当于通过扫描的方式，但是他们确实已经做到了。

   

 

云智慧是业务运维解决方案服务商，旗下产品监控宝（www.jiankongbao.com）、透视宝（www.toushibao.com）、压测宝（www.yacebao.com），已累计为电商、移动互联网、广告传媒、在线游戏、教育医疗、金融证券、政企等行业的几十万用户提供了一站式的应用性能监控、管理及测试服务。