移动社交时代 如何打造酷炫的用户体验
大家好，我是来自听云的常旭，今天我带来的内容是不体现无未来，如何打造酷炫的用户体验，相信各位还记得在以前我们在做转账这个动作的时候，可能要去到银行的柜面，而慢慢出现了ATM机，而再往后大概在2003，2004年的时候又有了网银那套系统，在那个年代我们认为网银就是一个面子工程，但后来通过现在的视角再回看的时候我们会发现银行大部分的业务都是来自于网银，而今天我们更多的动作是通过一个移动的APP做转账，那在这个过程中我们会发现实际上每一个时间点都会有不同的应用出现，而在一个应用刚出现的这个过程中它会有很大量的一个下载的过程，但不得不说大量的下载真的就等于您的应用，你的质量，你的用户体验效果是非常完善吗？很显然不是的。根据听云我们的统计大概是在74%以上的用户在出现了应用性能瓶颈的时候它会选择沉默，忍耐甚至于离开，而一个网页在打开超过10秒的时候有将近5%的用户他都会选择不再使用你这款产品。
下面我会带来两个数字，更加震撼，首先对于IT运维人员他们发现的问题有73%都是来自于最终用户的，也就是说最终用户如果不告诉他们的话，他们不知道出现了这个问题，而第二组数据所谓的好坏快慢它是一个形容词，每一个人针对于不同的环境他所当时的心态都是不一样的，对一个体验。比如说我现在在地铁里面，可能我认为打开一个页面5-10秒钟很正常，但是今天如果我要连在WiFi或者通过4G在大街上的话，我相信一个页面打开超过秒我都是没有办法接受的。而为了屏蔽或者说为了平衡这样一个不确定的因素，我们的采量通过了200万的客户，最后发现这200万的用户通过一款应用他们的体验效果是78%认为是可以接受的，而22%认为不可以接受，而22%就意味着有44万的用户他们不能接受，而这44万里面只有2%的用户会把这个问题反馈给您，换句话说我们很难能知道应用真的出了问题。
下面是我们听云2015年中国移动应用性能报告的一个白皮书，在这里面可以看到影响一个应用的前10个罪魁祸首都有哪些，下面就是针对于不同行业，不同的这些崩溃的参数，网络错误，首报时间进行了展示，如果有兴趣各位可以细看一下这个参数。再往下如果我们要想解决这个问题，要先知道它发生了在哪，以一个手机客户端为例，我们通过4G连到了…，再到了移动的GSN这套体系，在这里面如果一个运营商它本身有开始缓存，我们的业务可能在一个运营商里头就搞定了，如果不行的话，它可能还要跨运营商访问，进到了我们的互联网，在互联网里面我们的业务到底是在CDN里面还是在一个数据中心里面，如果说在云上头是公有云私有云，如果说数据中心的话，您是自己建的一个单数据中心，还是一个主备的数据中心，还是一个两地三中心的架构。好不容易进入到了一个数据中心里面它又有路由器，交换机，防火墙，IPS，IDS一串的网络设备，后面又分成了WEB，APP，数据库，存储，而在整个的这个过程中只要有一点出现了任何一点点的问题，都可能导致您的应用变慢。
而今天如果说您的用户在出现了变慢的这种情况，您是希望把您的数据中心给拆开了，一层一层地去做一个…，还是希望借助一个小的工具一个平台化的管理工具去帮助您快速发现并且定位这个问题。相信我们现在构建的是以用户体验效果为中心的一套新的监控平台，所谓用户体验效果，像我这个PPT里面右边所展示的包括很多的东西，比如说你操作是否方便，你是不是有互动的环节，你的内容是不是很吸引人很美观，而听云主要解决的是快和可用性两方面。
而今天如果说您的用户在出现了变慢的这种情况，您是希望把您的数据中心给拆开了，一层一层地去做一个…，还是希望借助一个小的工具一个平台化的管理工具去帮助您快速发现并且定位这个问题。相信我们现在构建的是以用户体验效果为中心的一套新的监控平台，所谓用户体验效果，像我这个PPT里面右边所展示的包括很多的东西，比如说你操作是否方便，你是不是有互动的环节，你的内容是不是很吸引人很美观，而听云主要解决的是快和可用性两方面。
所以，今天我们要想解决这个问题，一套监控平台应该是从最终用户的视角作为一个发起点，做到客户端到服务器端全方位的性能监控。下面您看到的这张图就是我们听云的一套全产品线的解决方案，相信您可以常用的连接网络的方式包括APP，有H5，WEB6，页面等等这些技术。而产品包括了像手机、平板、PC机，以及我们常用的像笔记本电脑，在这里面我们可能通过一个网络连到互联网，而在每一个节点我们对应的产品是听云的APP，是监控手机这个层面，包括平板电脑。
还有就是监控于浏览器，就是听云的…，而在网络这边我们的产品叫做听云net book，再往后是听云的服务器，就是server，在整个的解决方案里面包括两个大的方向，一个是主动式的，一个是被动式的，我们先从被动式简单地说起，所谓的被动就是我们通过真实用户的视角，比如说我当前一个小的APP在使用的过程中出现了问题，那这个时候我们会把一个手机它的全方位的性能，包括你的CPU，你乐观入网方式，你的型号，你的系统版本，所有信息技术收集，收集完了以后进行切片式分析，然后拿到这个信息跟后面的信心做匹配，这是主动式的监控平台方式。也就是说通过用户您现有的用户他的访问方式来看您业务本身是否出了问题。
第二个方式是我们主动式的方式，主动式的方式就是说我们可能在一个时延点或者一个特殊业务，白天业务量很大，而晚上访问的量是很小的，那在这个晚上的过程中您的数据中心是否也需要做监控呢？您的业务系统本身是不是也需要做监控呢，而这个时候我们的听云…就会协调我们全国几十万的会员节点向您的业务发起一个流量的探测，流量的请求，来帮助您判断您所关心的一个具体的城市，一个运营商，一个用户，他访问您的业务是否正常，这是我们两个解决方案。
下面我们来细介绍一下这两个解决方案实现的4个步骤，其实非常简单，第一个部分我们就是要做一个用户体验的评分系统，所谓好坏快慢它是一个形容词，每个人都是不一样的，而今天我们可以针对于应用交付过程中的每一个事件给您做一个切片化处理，把每一个点都拿出来，比如说我针对一个用户他出现的崩溃次数或者一个版本出现的崩溃次数给您做一个系统的统计，本身我们在行业里面，本身我们在中国大概有将近8亿的终端的嵌马量，而通过大量的信息我们可以组成一个海量的数据，通过这样的数据我就可以分析出您当前的业务，您当前的这个版本业务它的系统的评分到底是多少，行业的均值又是多少，您是在行业均值以上还是做均值以下，这是第一个动作，性能的一个评估，数字体验效果的一个量化标准。而第二部分就是做网络层面的切片，以前我们在做一个切片的过程中可能就是一个抓包的过程，而今天我们实际上帮您把整个的DNS解析的时间，您的TCP建连的时间，您数据包传输的时间，甚至于您服务器往回回传数据包的时间都给您做一个切片的处理。
在以前我们去医院的时候更多是找一个中医用听诊器的方式去帮助您听您身上到底有什么问题，而今天我们实际上是通过X光片的方式把您整个身体切成各种层面的不同，而我们网络切片也是采用了这样的方式，去把您整个应用交付的每一个过程做切片化处理，来帮助您分析到底网络层面是否出现了问题。
第三个动作，就是后端应用的拓扑，相信您肯定非常清晰在以前我们一台服务器上可以扛住一个业务了，而一台服务器上可能包含了WEB层，APP层，包括后面很复杂的一套东西。而随着业务的变大，这个一台服务器性能扛不住了，我们应用的三层架构出现了，WEB层，APP层，以及后面的数据库层。再往后我们的WEB层可能扛不住了要加负载均衡，这个时候一套业务系统就变得非常复杂，没完，随着SOA，ESB的这种方式出现，应用之间调用变得非常非常的烦琐，现在很少有一家公司的一个人能把一个应用的所有说清楚，而我们听云第三个动作就是帮助您把后端的数据，后端的调用关系做成一个动态化的自动的一个拓扑的方式，一个应用在执行之间相互调用了谁，谁又调用了谁的几次相互的关系是什么样，调用的关系又是什么样，给您自动地拓扑出来。
而第四步的时候您就可以针对应用访问过程中的每一个过程，每一段代码做时间的偏移量，来看看到底是由于哪行代码之间出现了问题，还是由于一个应用之间的调用出了问题，通过这样的方式您就可以轻松地找到到底是问题发生在哪。下面我通过一个小的视频来给大家做一个展示，你可以看到这是我们听云现在的一个界面，现在我们通过主动的方式也是通过听云…这款产品来帮您做一个性能的追踪。
在这边我们可以看到这边有一个性能指标的评分，它的分数是57显然是非常低的，因为满分是100分，再往后您可以把57这个分式进行拆开，看看到底是由于什么原因。
下面您看到的这个页面就是我们听云的一个界面，实际上它是通过主动的方式network这款产品来帮助我们定位问题到底发生在哪。首先您看到的是一个跨硬追踪的演示这样一款业务，在这里面有一个分数实际上也就是57分，不得不说这个分数是非常非常低的，我们正常的分数是100分为一个最高，0分是最差，实际上它是在中间，那在这里面我们就会把它进行摘开，到底是由于什么样的因素导致了它的分数非常低，相信您可以看到包括像连接数，首包的时间，连接的时间，建连的时间，下载速度，以及错误率。在这里面首包的时间是0.473，显然是非常慢的。而下载速度更是达到了90.251KB/秒，当然这个时间也是不可以被接受的。
下面我们就针对这个问题做一个向下探索的问题，看看到底是由于什么环境，什么样的问题导致了这个问题的出现。我们的第一个动作先是通过全国我们把一个应用全国的访问量做成一个小的地图，在这里面会有蓝色，黄色，颜色会有绿色，浅绿色，还有橘黄色，甚至于红色，随着颜色不同的加深，它的体验效果就会变得非常差。这里面河北和天津实际是很慢的，达到了7秒左右，下面我们就针对这两个省做性能剖析，我们只需要一个鼠标点进去，点进去之后我们就可以找到当时的会员他的节点，包括他的IP地址，总的下载时间，错误的代码等等相应的信息，以及他到底是哪个城市的。
点击这个点我们就可以看到它整个应用的网络层面的性能的剖析，页面点进去以后您可以在图片偏下的位置看到元素的加载图，而在针对每一个uil里面会有一个性能的展示，在这里面会展示出您的监测时间，监测节点，包括您的ID，以及您的DNS解析服务器分别是什么，这些信息展示完了以后会有一个条，也就是咱们屏幕中间的这个位置，您可以看到有包括首包的时间，包括DNS建连的时间等等这些信息，那可以清晰地看到DNS解析的时间实际上有点偏长，但是可以接受。而把这个信息打开以后我们可以看到一个HTP头，在这里面的信息可以看到它当前的版本是否走了压缩，包括一些…这些功能是否开了，而返回里面它有哪些信息都可以清晰地展示。
而在这个里面我们可以看到一个DNS解析时间大概是在1.4秒左右，建联时间是7毫秒，显然这个问题变慢并不是网络的原因导致的，而这个动作我们就可以通过一个向下的按钮来看看服务器端是否有任何的问题。点击这个按钮以后我们就可以清晰地把每一个组件进行剖析，在这里面最慢的组件会有一个清晰的展示，我们可以看到实际是一个数据库查询的速度变慢。下面我们就通过追踪详情的方式来看看它到底是什么样，在这个拓扑里面我们可以往下找有一个蓝条，这个蓝条就标记了我们当前最慢的组件到底什么原因造成的。
如果您想知道这个信息或者这个数据库它具体的调用，您可以点击这个放大镜就可以看到具体的语句，那显然实际上这是一个没有加索引或者一个没有做优化的动作所造成的。而这个就是我们整个的落地方案，当您在发现问题的时候您不需要通过客户端或者是通过您的真实用户去拨打400电话，也就是客服中心的电话，而这个时候我们通过一套集中的管理平台，通过客户端最终视角，在用户发生问题的第一时间就帮助您反馈这个问题，帮助您去解决，而这个时候我们帮您做的就是把客户，把您的客服，把您的运维人员，网络运维，系统运维，以及您的研发人员构建在一个平台上，做一个集中化管理平台的处理，这个人，这些人组成在一个平台里面，通过这样一个报告，一个平台，就可以做清晰化的展示。
在以前相互之间每个人之间都是隔着一堵墙的，这个墙是没有办法磨灭的，因为让一个网络人员去懂它的代码是不现实的，让一个代码人员去懂网络底层也是不现实的，而今天这套平台就会帮助您把这个墙给打消掉。下面您可以看到一张图是关于听云对于没有使用跟使用以后的一个对比，相信在座的各位，电视机前的各位，视频前的各位，咱们都是CTO，是吧？
相信各位都会有这样的一个经历，实际在发现一个问题的时候我们最长的时间是卡在等这个问题的时候，以前我在银行做服务的时候经常会出现一个业务变慢了，而在我们变更完大概是夜里两点，真正用户反馈过来有可能就已经是第二天上午11点了，而这个过程从2点到11点就是一个空白的时间，我们完全是在等。而在座的各位您会出了问题以后联系吗，显然不会，拿到这个问题以后，客服拿到这个信息告诉了后台说一个业务变慢了，而网络的人从这到那发现没有问题，在以前我的工作方式就是从这到那做一个动作，发现网络层面没有问题，而这个时候我们就会把这个问题抛给到后端的系统人员，对于IBM也好，对于Oracle也好，他们也是非常专业的，也能很清晰地就把这个问题给抛开，跟他们也没有太大关系。
但问题到底出在哪呢，如果问题解决不了业务就没有办法进行正常对外提供，这个时候运维的时间修复时间就会变得非常长，而今天听云给您的一套解决方案就是在让我们的运维人员跨出去，通过真实用户的一个视角来先找到这个问题，先发现这个问题，发现这个问题以后不用做更多的处理，先按照刚才动作做一个评分，看看评分到底有什么样的问题，针对这个问题我们再做时间的偏移量，再做后端服务器的一个拓扑，来找到到底是哪的问题，这时候不论是网络也好，研发也好，还是运维也好，拿到这个信息谁的问题谁做处理，而最后对于您而言我们给您所带来的价值就是整个的排除时间大大缩短。
而这样的一套体系通过这样的一个采用平台化的工具，各位您认为它应该是自己建还是采用一套平台化的工具，好坏快慢这是一个形容词，对于您而言您采用这样一个平台您能确认的是您的业务系统本身是没有问题的，但是好坏快慢这个字是由用户来评判的，您需要根据您的竞争，您的竞品做一个分析以后，您才能得出您的业务在您的行业里面到底是好的还是不好的，而听云通过几十万的监控终端，每一年每个行业不断的信息采集，通过我们8亿终端的嵌马量，我们有海量的数据库，我们可以通过这种数据的分析来定义出每一个行业的行业均值是什么样，它的竞品是什么样，您的对端竞争对手它的业务到底是什么样，而您拿到这个信息怎么去提升，如何去优化，显然这样的一个行业的均值并不是任何一家公司所能做的。
第二，以我们用户为例，我们以前有一个集团它通过30个人这样的团队，耗时一年开发了一个java层面的开发，而这个里面也只实现了自己买点的方式，直接买也没办法实现，所以可想而知这样的一个平台化的工具实际上是非常难实现的，而最重要的一点实际上对于您而言您会发现，还记得刚才我有一个非常复杂的拓扑图吗，在那张拓扑图里面我们客户端到后端出了问题的时候可能要经过N多个节点，首先你需要对手机一个业务非常熟，安卓IOS系统也很熟，其次您需要对移动的建造，移动网的建造，或者运营商的建造也非常熟，到了互联网您还需要对互联网层面非常非常熟悉，而到了数据中心网络层面搭建，业务层面的搭建，数据库以及存储您都需要非常熟，而这样的人显然是不存在的，即使存在他的薪资也非常高。而您正常情况下80%是不会出问题，真正出问题只有那20%，而在这20%的问题里面80%您都是可以处理的，另外的20%才会用到这样的牛人，所以您为了解决20%的20%，您需要请这样或者说雇佣这样一个团队吗？显然如果把这个费用挪给到您后端的研发，您只需要关心您自己业务逻辑，而应用性能这个工作交给听云里做就OK了。
对于可以确认的是，在互联网里面唯一不变的就是不停地在变化，用户可以确认的或者说互联网可以确认的一句话是用户体验效果永远是这互联网过去十年一直没有改变的，而听云一直在这个行业里面，在整个互联网里面，在应用体验里面一直在不断学习，不断在优化。目前来看…全国的排行前100用户里面有80家用户都采用了听云的部署方案，而在去年2015年的时候我们也正式进入了Gartner评测的一个象限，下面我会给各位介绍一些我们如何像Google，苹果，BAT这样大的互联网企业，或者像一些政府机关单位，给他们搭建了几个业务的模型。第一个就是我们上线前的测试，其实在测试这方面以前我们的做法更多是通过这种…做一个内部网的探测，一个测试，来看看服务器到底能扛多大链接，能扛多大压力，在大压力下它的服务到底是不是稳定。
但是，不得不说这样的一个结果拿到了线上真正上线的时候并靠谱，原因很简单，互联网的时候会有抖动会有延时，会有用户因为某个原因造成塞时变长，而这个时候您链接都会卡在您的服务器上，而听云实际是通过几十万的监控终端去帮助您模拟一个真实用户的发起方式来探测通过互联网的方式来探测您后端服务器到底能扛多大压力。同时，通过server的探针去帮助您优化您整个服务器，这是第一个业务场景。
而第二个场景就是我们在线上的一个性能监控，在去年也就是春运的时候我们一个很大的用户它有一个线上卖票的业务，而在这个线上的卖票在12月4日左右突然发现云南和贵州两个省访问量变得非常非常低，可用性下降到了30%左右，意味着10个人里面只有3个人能访问。显然对于这样的一个用户而言，如果这个问题不能被解决掉，它很有可能就上了头条新闻了。而我们听云在第一时间就能帮助它把整个的应用体验效果以一个地图的方式进行展现，一旦这个地图颜色变深我们就知道这个点出了问题，下面只需要按照视频的方式一步一步往下去走，看看到底是网络层面的问题，还是一个服务器的问题，最后定位了原来是SL卸载这一块采用了软卸载造成了服务器性能不够所引起的问题。
而下面我再给大家介绍一个电商平台的APP层面的问题，在双十一的时候有一个非常大的电商它某一个页面突然访问量，它的性能变得非常差，总下载时间从以前的1秒变成了20秒，意味着总下载时间增长了20倍以上，当时用户还开玩笑说在我们这边看来没有任何的报警，没有任何的信息报错，而你们这边只有IOS出了问题，那显然你们自己出了问题。而在当时的环境我们的驻厂工程师拿着这样的一个信息跟着CDN，跟着我们的用户一层一层找最后发现确实是由于某两个城市的两台服务器性能变慢了而导致IOS整个的页面变慢了，这是我的第三个案例。
最后我给大家总结一下，所谓的好坏快慢它是一个形容词，而今天听云做的就是把整个形容词给您做一个量化的标准，而拿到这个量化标准您可以去跟您竞品，或者跟您同行业做一个比较，在这个比较里您可以看您是在这个线以上还是在这个线以下，如果在线以下如何去做提升，如果在线以上我们如何做更好的优化。而第二个过程，如果出现了在线下的这个过程，我们如何去找这个问题，把时间做偏移量，把后面的服务器做拓扑，把每一个的时间做一个清晰的展示，每一个偏移量最一个很清晰的展现，最后帮助您快速发现并定位这个问题，相信这样的一套体系出现了以后您肯定还需要一个专人去帮助您去做分析的动作，而听云下面就为您提供的是一套主动客服的服务，来帮助您做相应的优化，我们的目的是希望您通过这样平台加服务的方式来降低您整个IT运营成本，来提升您的IT运营的效率，在您的用户投诉之前帮助您发现并定位这个问题，帮助您快速解决这个问题。
以上就是我今天全部的内容，感谢各位的收看，谢谢。