提升业务价值APM应用与整合分享-创新互联

杭州数云 罗兴峰

杭州数云信息技术有限公司成立于2011年，是国内领先的数据化营销软件产品和服务提供商，多年来致力于为消费品牌和零售品牌商提供整合软件产品、数据模型和专业服务的一站式数据化营销解决方案。随着业务的高速发展和产品功能越来越复杂，数云的运维部门常常要花大量时间来排查业务部门反馈过来的问题，为了更效率的解决系统运行时发现的业务问题，数云开始尝试APM。经过近一年的使用，APM不但帮助数云实现了基于业务流的信息自动采集和自动关联，同时改进了运维和技术部门的工作方法，提高了整个团队的工作能力，大家形成了用数据说明事情、说明问题的习惯。

下面是杭州数云信息技术有限公司运营总监罗兴峰以《提升业务价值，创见卓越用户体验——APM应用与整合分享》为主题带来的APM使用经验分享。

罗兴峰：我的分享和前面几位的出发点不太一样，前面大家聊的都是如何实现APM，而我要从APM的用户的角度谈谈APM的应用和整合。

数云作为一家业务型的公司，保证业务能够更好卖是我们选择新技术的唯一原因。今天在签到的时候领到一件很炫的T恤，当时非常想穿上这件衣服进行分享，但试穿的时候发现肩膀太窄，于是就换下来了。生产衣服的厂商经常会碰到类似的问题，但大部分消费者并不会告诉他这件衣服的问题，换一个角度来说，数云在软件行业里面的位置就像衣服的生产商，如果软件里某个按纽总是要30秒以后才出来，通常不会有最终用户为了这种不起眼的“体验问题”跟企业沟通，而是默默放弃这个产品。对数云来说，这种问题虽然非常需要优化，但除非客户的忠诚度非常高，否则没人会主动告诉我们，这种可能对业务造成影响的“小”问题完全值得我们给一大笔奖金， 而APM的价值就体现在这里。

从产品的角度来说，因为数云提供的是复杂的企业级应用，放在互联网上销售，这种应用的架构非常复杂，体量可以用一个数量描述就是JVM大小达到30个G，里面有大量的业务数据在跑，一个客户会创建很多任务，假设并发的任务到一百，那么这一个客户就会有一百个内容在系统里面不停运行，而且时时刻刻都不同，到底哪个出问题了根本不知道，有时候甚至连客户都不知道，因为这些任务在后台是自动跑的，无人干扰，一个任务可能跑两天，可能跑一天，而这个任务如果关系到客户的营销，挂掉了就可能会造成几十万的亏损。系统出了问题却没有主动发现，杭州数云是不是要承担责任？

作为数云的运维，我们不可能针对每一个任务做一个单独的监控和报警，因为大部分故障都是特例。所以大的问题就是这个故障到底在哪里，有多严重，同时这个故障的发生是否是偶发性的，1500家客户里面可能有一家客户在一个月发生一次这种问题，但是这一次到底是什么原因，就需要还原案发现场，比如说刚才说的全数据，当时那次点击或者那个作业的数据绝不能丢，如果丢了就看不了案发现场，就无法知道当时的情况到底是什么，也许外部通道挂了，也许数据平台出现问题，甚至是断网。数云没有腾讯淘宝这么强大，容错那么厉害，不可能做到面面俱到，所以最重要的就是发现问题并把当时的问题记下来，和开发一起解决问题，这都是运维的工作。

我们有一次遇到了性能方面的问题，当时有些客户反映某个功能很慢，但是我们自己测试的时候很快，于是认为是偶发性的，从应用端看确实没有太大问题，追究之后发现问题发生在nginx到app这一层，受到淘宝机房通讯带宽不稳定的影响。这其实只是个简单问题，但却耗费了两个核心程序员，三四个普通程序员，一个月的时间才找到问题出在哪里。通常最容易定位的问题是服务整个挂掉，最不容易定位的是不稳定，这种时候客户找来却无法快速排查当时的情况，需要找各个环节的日志，每个环节的日志都得去看，而且是要关联起来，这一点很难。

所谓关联起来就是把这次点击从前端到后端到数据库的所有性能数据连接起来，如果只有那一次发生了问题，到底是什么样的问题，我们当时关联的方法就是看时间，根据时间点判断日志数据是不是关联的，这要求一个工程师把所有日志数据从头到尾全部都看一遍，而真正能做这个事情的工程师很少，于是大家凑在一起搞了一个月，这是数云在第一年遇到的情况，虽然最后的解决办法挺简单的，但真正发现问题蛮难的。我们还碰到过一次数据库性能的问题，当时某一个点击由于参数没有设置好，读记录要进行八十次数据库扫描，其中有很多操作都是无效的，但光是检查数据库是无法发现问题的。

现在就比较简单了，通过和云智慧近一年的合作，数云建立起一条完整的APM链路，把前端APP到底层应用组件都串接起来，这样做大的好处就是可以准确获得一次访问的所有数据。前面说的某次点击是一次事务，从nginx到app，这次作业里所有环节的表现都能得到，这一点很重要。我们首先能找到访问到底是慢还是快，并且通过阈值设置报警，这也是后来融合到管理里面的一项重要功能。得到报警以后再看到底是哪里慢，原来需要根据数据库的日志来看，而应用的云服务RDS日志获取难度比较大，很多时候拿不到数据库日志，这种情况下通过应用得到接口的情况是比较好的办法。

刚才说了APM是帮我们找问题的一项技术，对一个应用方来说，能真正把APM应用到企业里并产生生产力，还需要很多问题。比如用什么样的方式来管理APM的报警，总不能在APM平台上建立另外一套监控管理平台或报警平台，因为没有人，无法为外部系统建立一个小组，留两到三个人天天看APM的数据。但我们有自己的内部监控系统，云智慧把报警数据接入我们的监控平台里，这样就可以用不变的工作流程来统一APM的监控结果，然后通过统一的API或者是告警短信发送到监控处理人员手上。

得到APM数据以后主要有两个用途，一方面是直接在云智慧的平台上把APM的性能表现数据呈现出来，特别是平台级应用监控数据和关联性数据，当时碰到了一个问题就是数云的数据量太大，关联性很差，通过关于APM数据如何落地的反复探讨，云智慧加强了产品自定义的能力，我们的APM数据逐渐形成一些可定义的报表，整合数云内部运维分析系统，每个星期都可以针对性能数据做相应的分析。就像开始说的T恤的案例，如果通过性能分析发现提供销售的所有小尺码没有任何人买，就说明我的产品设计可能有问题，因为用户需求不应该是偏向一端的，从业务数据的异常发现产品的问题。数云也有同样的例子，线上产品的性能表现是不是能够通过业务分析，发现哪里是慢的或者总是报错超时，把数据反馈给研发，并且持续跟进这个问题是怎么解决的。

我们和大型企业有比较大的区别在于，创业型公司的运维不仅要对本身的事情负责，还要对产品的质量负责、对产品的交付要负责，你要覆盖到功能，甚至要比研发还研发。我们做的报告不但指出这周哪一个地址是慢的，并且要知道哪个方法慢或者是哪个域慢，这种报告的业务价值很高。

APM是一项很炫酷的技术，只要做好了前期的配合，最后落地方式非常简单，因为借助APM，一个毕业一年、完全没有技术背景的小姑娘都能完成报告。这对于创业型公司或应用APM的厂商是非常重要的，我们这边做报告的小姑娘经常拿着报告去找研发拍桌子，这个东西什么时候改，研发都不知道线上有这个问题，但是这个小姑娘知道。通过APM，运维在业务发展过程中承担起更重要的责任，也确实解决了很多问题，而且从发现业务波动到解决问题的速度非常快，两到三天就可以解决掉。

通过这件事，整个运维团队甚至公司的技术团队发现，我们的定位开始向业务运维和运营化运维的方向发展，这非常适合初创型公司和成长型公司。同时我们几个工作了两到三年的运维工程师也在迅速进步，现在都成了非常合格的运维架构经理或者是运营型运维经理，他们成长大的标志是懂得了取舍，非常清楚在一个阶段我们自己要去做的技术是哪些，哪些技术是我们不能做的。

为什么呢？比如在APM方向上我们不会有大量投入，这不是我们自己的业务点，所以这块交给云智慧，而我们要做的是中间的架构，不会有任何公司帮我们。所以我们需要想办法接入所有的严控系统，包括外部的、自建的、还有产品内部的，要把外部资源和自己的资源一样使用，才能获得快速发展。而我们要做的无非就是算帐，我用多少钱自己做，我用多少钱找别人做，找别人做的话用什么样的标准接入进来，这样的话才能实现统一的方法，这个东西是创业型公司的运维需要做的。

专业的人做APM就很厉害，因为我们做不出上面的东西，在最初没有这些×××的点的时候我们很难用一个技术或者一种方法把数据从前到后都串起来，所以我们花的最多的时间就是把所有案发现场的线索进行关联，一个老干警破案都不是依靠单个信息，而是把所有信息汇总起来的能力，APM干的事情很厉害，一方面把所有的信息自动采集，另外一方面把所有的信息自动关联，这一点不是一般的企业能做的，实施过程也花了比较长的时间，但这些时间的花费是非常值得的，因为现在APM已经能够很好的帮助我们发现问题、解决问题了。

我们所有的产品在上线之前都要进行压力测试，就是用大负载把应用打到崩溃为止的压力测试，因为在双十一之类电商大促的时候，产品的压力是平时的一百倍，压测就是要保证产品在极限的情况下也能健康运转。压测时要看哪个系统最先挂掉，哪个位置哪个功能模块最先挂掉，通过APM来测就会比较容易聚焦，这样就可以制定双十一的系统运行方案，如果最后搞不定，零点到四点必须要降级，只要把那个点降下来就可以了，APM可以帮我们发现这个点。

除此之外，我们对人力的需求变少了，而且门槛更低了，同时所有人的有效工作时间变长了，从原来每天都忙于干不太重要的事情（比如前文提到的定位问题），到现在专注于解决问题。过去的运维对于技术水平要求非常高，因为底层的系统支撑都是在平台上跑，所以需要对集团的平台有很深的了解，而现在事情难度降低了很多。原有要被动等到客户来投诉，客户说什么功能已经挂了以后再找问题、解决问题，而现在只要每周都做性能分析和性能报警，客户还没有什么太多的问题，甚至客户还没用的时候，我们就发现新功能哪里有性能瓶颈，哪里报警了，然后告诉产品、研发、运营这个功能马上要调整，这就赢得了很多时间。特别是双十一这种时候，如果没有及时推出某个功能，很可能就会被竞争对手抢得先机，商家不能等就会购买对手的产品，这时我们的产品才姗姗来迟，营销的机会就没了，不管说是研发的责任还是运维的责任，对于公司来说都失败了。

在BAT这种大型的互联网公司工作是非常聚焦，比如做网络协议性能测试，只要测多大的包能把这个服务干掉就好了，而创业公司的运维部门还要让公司更好的发展更好地赚钱，让团队的员工获得职业成就感，职业成就感是超出解决技术问题的成就感，因为公司用你的技术问题赚钱了。同样APM厂商也很有职业成就感，因为他们的技术能够帮助客户解决问题，这种成就感也非常强。

数云从接触APM到现在大概一年的时间，去年我们没有这种东西，开始时双方都只是一个模糊的需求，我们把这个东西落地去实现，然后改进我们的工作方法，提高整个团队的工作能力，中间克服了很多问题，大家形成了新的习惯，用数据说明事情、说明问题，这就是APM大的价值。

最后回顾一下今天的分享，对于不同类型的企业，APM带来的价值不同，帮我们省时间、省人力、加快市场节奏，提升研发能力，提升运维能力，让企业健康成长，是创业公司比较重要的。很多大型公司的业务特点会更复杂，甚至将来APM会成为新的业务增长点，很可能会自己做APM。但我们也看到了新的方向，APM不仅可以做基于IT的应用性能分析，还可以做业务性能分析。有一次产品经理跑过来和我说，你帮我看看产品里面哪个功能点是客户最喜欢用的，然后这个用户用的好或者不好，我们那次做的数据就是来自APM采集的数据。通过与云智慧的合作，我们对APM的了解也越来越深，知道APM采集了哪些数据，能做哪些事情不能做哪些事情，我们不断加深合作，因为APM一定要在系统层面实施，一个业务模块是怎么样、热度如何、客户反应如何、哪个区域点击最多，都是APM能够得到的，未来还可以延展出更多价值点。

APM在各个环节的传感器思路，是一种比较容易实现的思路，有很多公司通过侵入式埋点的方式实现监测和数据获取，但作为第三方服务企业是不适合过度侵入客户系统的，所以通过发起探测的思路获取数据，效果是一样的。我们用传感器的数据也干了很多不一样的事情，比如硬盘的挂载点，因为会碰到不同的机型，网络网卡这些问题，所以可以用一些小的机器人把数据传过来，这些点不一定决定你使用哪个APM产品，但这个思路一定可以让你的工作得到改善。谢谢大家！

Q&A

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

    罗兴峰：之前监测不到后台任务，现在可以了，只不过这个事情还没有在线上大批量的做，因为通过别的手段也能采集到这些数据，但他们确实已经做到了。

    Q：在产品发布初期的问题很多，对APM的依赖会非常强，随着产品的演进，APM的重要程度有没有变化？

罗兴峰：我们现在不倾向于等产品上线，就直接在灰度的时候跑，等到非常稳定了以后我们会把后端APM的探针下掉，因为浏览器特征太多了，无法决定客户是怎么写的，可能会碰到冲突的问题，但是冲突只要能识别，把冲突发现了就是可以调，没有什么搞不定的，无非就是写法的问题。数云的产品有个好处，就是客户是toB的，他们对浏览器端的要求非常低，如果是To C用户就要做大量的兼容测试，经常是发现性能有问题，找后端程序员定位，定位了很久说所有的数据都是好的，结果发现前端的JS有问题，只要稍微一改马上就好了。这就是浏览器监控的重要性，必须真正从客户这一端发起，云智慧这个功能其实还是蛮强的。如果是To  C的产品就必须要做这个事情，我们会尽可能往前端走，产品的用户体验还是非常重要的。数云的产品复杂度太高了，一个客户对于产品的使用率，可能只有其中30%—40%，但是有些客户喜欢这30%，有些客户喜欢另外30%，所以产品必须是能够灵活自定义的，允许不同的方式使用我们的软件，怎样平衡这些产品功能，是我们现在面临的主要问题。

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

另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。