量化用户体验 企业需从三方面入手

  1. 云栖社区>
  2. 博客>
  3. 正文

量化用户体验 企业需从三方面入手

寒凝雪 2017-07-03 14:43:00 浏览547
展开阅读全文

互联网的发展使技术创新形态正在发生转变,以用户为中心、以人为本越来越得到重视,用户体验也因此被称做创新2.0模式的精髓。

对于企业来说,成也用户体验,败也用户体验。相关数据显示,一家未经任何优化的交易网站,20%的交易体验是负面的,这些负面的体验中又仅有2%的客户会进行投诉,另外98%的用户则在网站不知情的条件下,悄悄地流失了。而这些问题对于那些投入了大量人力、物力、财力用于宣传的企业来说,损失是巨大的。

Dynatrace大中华区资深技术顾问马伟表示,随着企业前端用户数量的迅速增长,业务规模不断扩大,同时,很多应用的开放程度不断提高,应用系统的架构、部署、交付也是越来越繁杂。在这种情况下,对企业业务性能的影响点也变得越来越多。

马伟认为,企业运维要摆脱被动救火的局面,必须具备以下三方面的能力:第一,足够高效敏捷以满足企业数字化业务;第二,能够清晰地了解到应用的整个运行状态和健康程度;第三,能够对应用出现的问题做快速的反应和处理。

以下是访谈实录:
ZD至顶网:用户体验这个词相信大家都不陌生了,尤其是在“互联网+”、数字化转型的大趋势下,围绕着用户体验产生的应用越来越多,前端应用的这种变化会对企业现有的IT有一些影响和挑战,以及企业如何应对这些挑战,带着这些问题我们邀请到了APM的专家Dynatrace大中华区资深技术顾问马伟,请他来给大家分享一下这方面的内容。

马伟:大家好,市场大环境的改变,对企业的传统运维其实有一个很大的挑战——前端业务不断的更新、迭代,对企业后台应用提出了更高的要求。

在现在新技术发展的领域,企业IT技术的变化深刻改变了包括政府、企业等各类组织的运转模式,传统的IT技术已经由原来的业务支撑逐渐演化为到与业务融合。在这些融合过程中,企业的运维角色已经发生了很大的变化。传统来说我们运维主要工作内容是保障我们基础架构的稳定,保障我们中间件运行的一些稳定,去做这个应用的支撑。

但是,其实随着企业前端用户数量的迅速增长,业务规模不断扩大,包括一些应用的开放程度不断提高,应用系统的架构是越来越复杂,它的部署、交付也是越来越繁杂。其中越来越复杂的情况下,就会对它的业务性能的影响点变得越来越多。

企业如何对这些做管理,其实现在也是面临一个很大的挑战,无论是现在互联网也罢,还是物联网也罢,通过云计算、大数据,包括智能终端对我们提供各种的信息服务。其实我们每个人既是信息的消费者,也是信息的传播者和获取者,应用、APP已经深入到我们每个人的日常生活中了,就像我们的手机看新闻,微信,我相信现在很多的年轻人如果没带手机可能不一定是因为电话接不到,而是因为他很多的APP用不上。

在这种大环境下,我们的企业会遇到哪些挑战呢?我跟大家在这里分享一个简单的数字,据我们统计在一个未经优化的在线交易网站大概有20%的用户交易体验是负面的,在这20%用户里面只有大概不到2%会产生投诉。

换句话说,负面体验的用户中有98%是不做任何的动作,他会怎么样?他会悄悄走掉,也就是说这部分用户会流失,其实我们企业花了大量的金钱、人力和物力去做线上或者线下的活动推广,一切的目的就是为了增加我们的用户数量。但是,当我们的终端用户去访问应用的时候,差的体验会造成非常大的客户流失,并且,这一切都是在这种不知不觉的情况下发生的,对企业来说这是一个非常严重的问题。

在这种情况下,我们企业的运维会面临一些什么样的挑战呢?我认为有三个方面:
第一,新环境下的运维能否足够高效敏捷来作为我们数字化背后的一个支撑,也就是说现在这种用户至上、体验为王,以及共享经济的提出,对企业用户提出了更高的要求,我们应用的版本更迭更快,新的应用上线速度也更快,测试周期更短,新的功能点要更多去满足用户的体验需求。

这些需求从前端应用传递到后台的运维部门,其表示为上线的业务越来越多,部署的结构也更复杂了,跨平台的各种终端的交互也会越来越频繁,应用之间的相互调用也会越来越复杂,也就是说我们的运维平台,包括我们的运维支撑部门能否去满足企业现在的数字化的支撑,这其实是第一个问题。

第二,运维部门能否清晰地去了解到应用的整个运行状态和健康程度。如果不以应用为主导,一切的运维都是偏底层的,对业务来说并没有非常正面的影响。能否通过一体化的图形或者图表的展示快速了解到应用的状态,其实是摆在企业面前的第二挑战。

第三,运维能够对应用出现的问题做快速的反应和处理,这里面其实就有一个很重要的一点,首先要对它去做应用问题的快速故障预定位,判断是网络问题,还是应用问题,还是前端终端的问题,还是应用程序数据库的问题,或是那种类似于内存泄露的问题。前端越敏捷,后台的反应和响应就会越快,就是说要找到具体的问题点要查看到故障的一些返回代码,这样你才能给解决后台各种问题提供强有力的支撑。

ZD至顶网:三方面的挑战,还是比较多,有了问题我们想解决办法,Dynatrace有没有比较好的办法来解决这些问题?

马伟:其实Dynatrace浸淫在APM的领域已经很长时间了,我们也发现整个市场的变化对于我们运维挑战的变化,Dynatrace对于我们的运维来说有什么样的支撑呢?是这样的,现在企业的运维也有很多的问题,比如说工作效率比较低,在日常的维护中其实我们经常会出现一个问题,发现问题之后他开始着手处理,这使得我们的运维人员处于一种被动救火的状态,人工排障包括处理都需要不少时间,这种救火的方式也会使我们的运维工作质量很难得到保障。

第二点就是我们的人员更替会更快捷,在现在来说业务结构和整体逻辑结构都越来越复杂的情况下,由于人员更替的原因导致了企业很多新的运维人员很难快速去说清楚或者理顺公司业务之间的逻辑关系。这样在出现问题的时候就会更多依赖于这种日志分析或者靠个人的经验,这其实是一件很痛苦的过程。

我们都知道看日志其实要看每一台机器的日志,要针对每一台机器的日志抽出它的关联关系,如果要靠纯粹的人工方式来做,这其实是一件非常影响效率,非常浪费时间,而且非常不可控的一件事情。

第三点就是(责任)分离,我们经常会在运维工作中碰到,出现问题之后我们第一个先不是说去寻找更好的解决方案,而是先排查这个问题应该由哪个团队负责,这其实是一件很糟糕的事情,因为没有一个很好的工具去帮你做支撑,你很难去迅速判断问题故障率,问题到底在哪,这个时间如果不可控,其实交给我们后台处理问题的时间就更不可控了。

第四,自动化程度也比较低一些。没有自动化的管理模式,系统的设备、软件,包括中间件,硬件,也会让我们的运维人员疲于应付和奔命,他就会没有更多的时间和精力去处理具体的这种问题上面。

所以说,Dynatrace针对这些问题和这样的现状我们提供哪些解决办法,第一点就是Dynatrace提供了一个完整的应用生命周期的监控平台,它可以涵盖整个应用从开发、测试、上线到迭代全过程,整个过程都可以去做可视化的展示,可以非常清晰和直观去告诉给用户整个应用的情况,这样对运维人员来说只要这一个平台就能看到整个应用的运行情况。

第二,Dynatrace利用了自身它的专利技术,对应用进行端到端的性能问题的排查。由于许多应用都是分布式的部署框架,完成一个交易会有很多的节点。在做性能问题分析的时候,其实我们是不能将每一个节点单独来看的,而是依据这种应用交互的逻辑,运行整体的分析。Dynatrace会利用专利技术,自动去生成业务交易的逻辑拓扑图,通过真实用户访问的视角来去做问题排查,这一切可以通过Dynatrace非常人性化一步一步的视图进行详尽分析,这样就可以非常大去提高我们运维的工作问题排查和准确度。

第三,Dynatrace也提供了第三方压力测试工具的结合,其实我们在应用上线前要经过很长时间的测试,这个测试周期往往是整个应用开发周期的一部分,如果开发周期过长,相应来说留给测试时间就会很短,测试时间一旦太短,没有充分对应用去做测试,没有充分去将它的问题暴露出来,而匆忙上线,那不可避免会遇到很多问题。Dynatrace可以集成我们第三方测试工具,即使在这种应用测试时间很短情况下,也可以很好将我们应用的性能去体现出来,这样就可以由被动的问题排查而变成主动的问题分析,可以大大提高这种应用的迭代效率,而且缩短开发测试的周期。

最后一点,Dynatrace是一个代码级的应用数据平台,所谓的代码级就是我们可以精确去定位到应用,URM,具体调用的一些代码,包括故障点的一些排查、返回和信息。有这些数据之后,其实在这种海量的数据里面,我们去分析也是一件挺有挑战的事情,Dynatrace有这些数据之后我也可以提供这种自定义的统一的仪表盘,可以帮你将这些数据做图形化的展示,比如说我可以根据我们关注的一些业务的指标去做一些定义,响应时间、访问量、CPU和内存的负载,包括单位时间的事务处理量,包括一些错误或者报警的一些情况,甚至不同区域的用户访问质量等等,都可以在这种统一的平台和面板里面帮你展示出来,也就是说你可以在一个仪表盘里面一目了然可以看到我所关注的所有指标,这样我们的运维人员就不用再深入到不同的监控单元去分别查看了,一个屏幕就可以一目了然。

本文转自d1net(转载)

网友评论

登录后评论
0/500
评论
寒凝雪
+ 关注