听云科技首席科学家高级副总裁赵宇辰先生分享：

　　大家下午好，我来自于听云。讲之前我先切个题，今天下午的主题分为两块，一块叫AI相随，一块叫云相伴，我这个场正好是AI相随的最后一场，又衔接着云相伴，大家如果看我们这个公司的名称听云也正好跟云相关，其实听云一直是从事AI赋能于云生态的一个厂商，具体我们做什么呢？可能很多在座的伙伴没有听过听云，听云是做应用性能监控，英文叫APM，我们这个应用是指广义的应用，比如手机端的APP，包括网页到后端的JAVA、程序等等，只要是数字化相关的东西，在我们看来都是为了辅助业务而做的应用，我们听云的职责就是把这些业务上的应用正常的维持下去，保障我们业务的正常运行。

　　其实在APM领域，在应用性能监控方面，听云作为国际权威榜单GartierAPM魔力象限里中国唯一入围的公司，2015年到2018年也和国际厂商进行了很多次的交流，也受到了很多的认可。在Linux基金会的CNL榜单中监控类中国公司中，听云和阿里、华为等等一起进入了这个榜单。

　　同时听云是一个有十二年成长经验的公司，在这十二年中我们服务了非常多的企业，比如金融支付、运营商及云服务、能源交通、科技制造、电子商务等等，小到几十人的公司大到BAT，从互联网到传统的企业我们都服务过。

　　结合我们今天的话题，十二年前我们刚开始的时候服务了很多互联网的企业，现在我们发现服务了越来越多传统的企业，这是微软的Satya说的一句话，现在不管你是高科技还是传统企业还是互联网，很多企业都运行在软件或者应用之上，所有的软件、所有的应用都依赖于数字化，我们正是服务好这些数字化。

　　我们也发现数字化带来了很多挑战，以前我们去银行直接去柜台就可以了，现在我们都通过手机APP来进行操作，这时候挑战就来了，如果它的体验不好的话，很多用户可能会留下很多不好的印象，比如我们看苹果APP市场里面，就会有很多评论，为什么这个APP打不开，为什么体验这么差。

　　对于数字化来说带来这么大的挑战，但是一旦我的后端程序或者前端的APP不能正常工作了，直接影响了我后端业务的表现，直接影响到今天的贷款量，今天到底有多少业务中断了，所以应用的性能直接影响到业务的表现。举一个国外银行的例子，大家可能都听过巴克莱银行的例子，是欧洲一个很大的银行。在2017年某一个下午突然服务器崩溃，崩溃时间不长，只有90分钟，但是这个崩溃造成了什么样的影响呢？它造成的影响是用户无法操作ATM，他在ATM取款的时候客户很难正常操作，数千上万客户受到了影响，这个时候社交媒体就涌出了大量的客户愤怒的抱怨，同时在媒体上面也有相应的报道。对于巴克莱银行的直接经济损失可能达到了上千万元，有人说我就花17美分去购买一个香蕉它都不让我去购买，我感到很羞愧。

　　我们看到应用是否正常运行其实直接影响到我们的业务，在数字化的情况下对我们运维产生了非常大的挑战，比如我们简单的在手机端查询余额或者进行转帐的简单操作，在我们看来很简单，轻触一下手机转帐成功。但其实在后端我们看下来它有非常多的不同的数据的操作，数据的交互在进行，可能我们轻轻的点击后端生成了上千条的数据。现在我们也看到很多新的技术也引入进来，比如云计算、敏捷开发、大数据、人工智能、微服务等等，这些新的概念也涌进来，各行各业都受到了影响，不光是银行。

　　如何在这些新的东西引入进来的时候，能让我们把运维服务做好，同时把我们的业务做好，这是一个非常难的难题。整体来说我们听云的解决方案是什么呢？在我们左边看起来，左边是真实的用户，比如说它可能是通过APP去访问这个业务，也有可能是通过浏览器去访问这个业务，他经过了一系列网络之后来到了右边，基于云的基础架构，私有化的基础架构之上有一些自己的业务系统，这些业务系统可能访问不同的程序。

　　听云做的第一件事儿是什么呢？就是在全球有几十万的布点，在中国覆盖了所有主流的乡、市、镇，听云这款产品叫Network是模仿真实的用户访问情况，主动的访问后面的应用情况，来判断是不是应用正在正常的进行当中。同时光有这个也不够，我们还想知道真实用户是怎么样的，所以我们看到在真实用户这儿有一个听云APP产品，它可以监控真实用户APP的使用场景。在国内我们现在大概有6亿终端，可能后面都嵌的是听云的SDK，可以获取到真实的APP的响应情况，有没有崩溃，对于业务是否正常操作等等。这个只是覆盖了用户的前端，从用户的角度来看这个问题。我们看看是不是能从后端也把它监控起来。在基础架构之上我们也有一个听云Sys的产品，覆盖整个基础架构的监控，同时在这个上面具体的业务，我们有听云的Server来覆盖这样的产品，所以整体来说我们打造了一个全平台的产品，希望从用户端一直打造到最后的服务器端或者云上，或者私有化各种场景下我们都能把相应的数据采集到。

　　具体我们能干什么呢？第一个，辅助研发测试，第二个，日常运维，第三，体验改进，第四，运营优化。我把这四点稍稍展开一点，讲一些细节。研发测试其实痛点是什么，可能大家做业务的时候偶尔也会给研发测试的进行沟通，会发现研发测试很难去完整的测试出APP，我这个应用系统到底是否正常，它总会出现一些异常的情况。刚上线之后可能会出现大量不可控的bug和故障，IT团队时时刻刻都处于救火的状态，给用户带来不好的体验，甚至严重影响业务的正常运行。面对这样的挑战，我们通过兴业银行的一个落地案例来体现听云如何应对类似的研发测试场景。

　　在兴业银行这儿我们可以快速的定位排查，比如我们的代码中有没有BUG，手机APP有没有崩溃，有没有各种异常，同时我们覆盖了兴业各种主流的APP包括我的网银、家庭银行、信用卡包括一些小程序等等。

　　我们再看一个具体的实际的能力，刚刚也看到了，比如我们看到了一个后端的程序可能是跨过了多个服务器或者多个组件进行的，如何把这些服务器、组件统一的综合的看起来，我们会有一个全栈溯源式问题追踪，能快速的知道到底具体是哪个服务器或者哪个具体的代码出现了问题。同时我们也具有代码级的根源分析能力，以前需要一些专家级的人员来进行长时间的判断，现在我们可以很快的把具体每一行代码，哪一块具体的错误给查找出来。

　　日常运营的时候其实我们发现对于一些正常出现的业务失败，比如无法登录，APP闪退等等，很多时候我们是被动的解决问题，比如用户投诉或者社交网络上有人抱怨了，或者APP市场里面有人提意见了，这个时候我们才被动的解决问题。同时这个问题很难去有效的定位，比如可能会进到网络部门，网络部门可能会觉得网络没有问题，那就流转到数据库部门，数据库觉得数据库也没有问题，一看好像各个部门都觉得没有什么问题，这就造成了一个非常耗时去解决真正问题的问题。

　　举一个兴业银行的例子，这边我们应用到了网络金融部，覆盖了多个渠道的服务器，当这个事情真正发生的时候，比如有一些故障真正发生的时候不需要用户主动来找我，而是我通过一些报警的机制主动的发现一些问题，这些报警会主动指出一些错误，我可能还能通过报表到底是哪个指标出了错误。甚至我能看到每一个网络请求，甚至每一个设备它们到底是哪里出现了问题，可以快速、精确的定位到具体的问题。

　　我们再举一个模仿落地的例子，这个是用听云Network主动去探测寻找问题的案例，这条线明显跟其他线不太一样，讲的是三大运营商，说明网银业务的可用性突然下降了，同时三大运营商的客户都受到了影响。我们再仔细下降一点，发现大量的线上任务超时，很多页面超过60秒都不能打开。这个时候我们就要分析问题了，要通过一些比较偏技术的，比如说Ping、Tracer去看。最后我们发现是数据库的变更造成的，那可以很快的去确定这个范围，不在网络部，在数据部门，可以尽快的去解决这样的问题。其实我们碰到了很多这样的场景，同样是三大运营商受到了影响，但是后来发现根本不是数据库的问题，而是DNS被劫持了，那我们就需要去那个城市或者那个省份去解决DNS劫持的问题。

　　同时我们发现类似的场景还很多，背后的原因可能是多种多样的。再举一个例子，突然某一个运营商的波动特别大，它的延时特别长，那我们的建议是什么呢？赶紧联系这个运营商，跟这个运营商探讨一下到农行的线路是不是有什么故障。

　　所以我们看到一个简单的问题，一个网银慢的问题，可能它发生的根源是多种多样的，只有通过数据和工具的手段能让我们更好的服务好我们的客户。这个例子也是20%的资源加载不出，可能在我测试这儿看来没有问题，我的网站打开都没问题，但是就有20%的客户投诉说慢了，为什么呢？最后我们发现是适配的问题。

　　第三点，如何用听云来提升今天的体验和客户成功。在满足客户的基本需求之后，我们很难去进一步提升客户的体验，比如说很多客户会投诉慢、响应时间长、效率低等等，怎么去解决这个问题呢？我来举一个在光大银行落地的实例，光大银行大家看，左边是光大银行的网络和APP，右边是他们后端的架构，同时我们就把听云的APP产品听云的Sys产品部署在广大上，一边是监控用户端，一边是监控后端。当用户发生响应时间慢，加载不出来的情况怎么办呢？这个时候我们会联系研发人员，去看到底崩溃、慢请求是什么原因。甚至我们能够做到个性化的判断，可能个别的用户他不能访问这个网站，但不代表所有客户不能访问这个网站，所以我们可以进行个性化的用户体验，具体的去排除潜在的原因，然后把这个原因提交给业务人员，同时业务人员再把类似的信息提交给客服人员，这时候客服人员可能就可以确定确实刚刚发生了这样的问题，问题可能出在什么地方，我们可能会用什么样的方式来去解决这样的问题。

　　为什么刚刚说可以个性化呢？我们可以把具体的用户定位出来，比如根据他的手机号或者唯一标识符可以具体定义到它发生的崩溃，比如在崩溃之前他进行了哪些操作，可能查了余额又提交了一个贷款申请，突然崩溃了，这个操作轨迹我们都能还原出来，以及相应的技术方面的代码归栈等等我们都可以拿出来，第一是帮助客服人员去确认确实有这样的问题，更快的把这些错误信息传递到后端，让开发人员去解决这样的问题。

　　第四个，运营优化。在银行内部经常会进行一些营销活动，比如需要拿一些用户画像，线上的营销活动的跟踪，精准营销等等。我们也可以把相应的数据拿下来，不管是从APP端还是网页端，我们都可以做漏斗转化、留存分析、用户体验包括最后的用户路径，包括打用户行为溯源等等。

　　刚刚讲四大场景，研发测试、体验改进、日常运维、运营优化，我们讲了三个例子，农行、光大、兴业。听云在成长过程中也在不断的发展，我们立足于应用性能监控也做了多方面的拓展，一方面希望能做到横向拓展，能拓宽业务边界，不光是我们知道有哪些代码错误，哪些报错，404，网页错误等等，这些是给研发人员看的。在业务层面看是需要知道业务的可能性是怎么样的，手下可能有几十个业务，业务下面可能还有子业务，它们的表现怎么样，有多少业务今天已经完成了，有多少业务出错了，这是我关心的事情。如何用业务的信息跟IT的信息结合起来，帮助我们的业务做更好的决策。

　　另一方面我们希望能做纵向扩展，利用AI人工智能的技术，希望能帮助客户提高效率，减少解决问题的时间，尽量能帮助他们更好的实现业务上的发展。

　　一个是我们如何结合业务运维，这是南方电网的案例，可以把南方电网的业务建模成N层的构建，比如它有它的营销体系、4A平台、资产管理等等，这些业务之下还有他们的子业务，可能是呈树状结构。对于每个业务流程怎么去分析，他们的业务操作有哪些，对于全栈的业务，各种指标如何做分析和判断，做数据挖掘，这个是我们业务运维的场景。

　　同时在AI方面，一个是智能警报，传统上来说，可能很多时候我要做报警，我要去手动设置非常多的东西，去指定我要去什么东西做报警，上限是什么，下限是什么，阈值是什么，在现在看来我们希望把产品做的尽量简单。用户几乎不需要进行任何的输入，背后我们有多个算法在同时进行各种操作，判断出来是不是当前的场景异常，然后提醒客户。

　　其实我们发现异常之后这只是第一步，我们告诉你可能你现在APP有点问题，你的整个业务受到一些影响，但是客户得解决问题，他得知道到底这个错误在什么地方，怎么去定位这个问题。比如我们看到这边有一个波峰，在那段时间可能整个响应时间变长了，对于业务方来说用户体验就下降了，对于运维来说也很难去挖到具体的根源是什么。

　　我们做了一键根源分析的系统，结合了大数据和实时计算，能够快速的一键定位到真正的根源。比如这个例子，可能某一个城市的主站网络发生了问题，或者新的Android版本发生了问题，定位这个问题我可能需要几天甚至几周的时间去把这个问题，现在我只需要轻轻一点，通过后台大量的数据我可以分析出这个异常的潜在的根因是什么。

　　在我们听云看来，整个数字化分为五步，从一开始的IT是独立成本中心，后来逐渐成了IT支撑业务，到后来成了竞争优势，我们听云希望帮助客户在转型当中让数字化成为业务的本身，同时可以让我们的数字化和IT从一个成本中心变成它真正的竞争优势。