做好移动APP质量保障工作你需要知道哪些?

原创
移动开发
由51CTO举办的WOT2016互联网运维与开发者峰会上,来自阿里巴巴的高级技术专家杨强做了以《移动APP质量保障工作》为主题的演讲。本文章是把本次分享干货亮点的整理成文字形式,呈献广大的用户。

本文是WOT2016互联网运维与开发者大会的现场干货,新一届主题为WOT2016企业安全技术峰会将在2016年6月24日-25日于北京珠三角JW万豪酒店隆重召开!

我叫杨强,在阿里巴巴负责的事情比较杂,从线下研发管理、发布流程,到质量保障,到线上客户端的监控运维等等方向。今天想向大家分享的是我们在手机淘宝端上所做的一些运维以及优化的相关工作。

[[166240]]

从2012年加入手机淘宝以后,我发现APP实在是比PC端有太多的痛苦,***是闪退,闪退就导致手淘不可用。第二个,响应时间太慢,有时能长达五六秒钟,这对用户来说是很不可接受的一个时间。还有就是耗电和耗流量的问题。还有一些是和PC上类似的问题,比如页面加载异常或者一些安全上的问题。

面临这么多困难要解决,解决的思路肯定是发现,发现然后解决,然后再看问题有没有存在。说起来比较容易,但是端上还是有很多的复杂性。

首先是机型复杂。据不完全统计,线上市面上存在的的机型已经超过两万种了。如何保证我们的APP在这两万种机型上都是可用的一个状态,对于我们来说是一个非常困难的事情。我们曾经接到用户的反馈,说手机淘宝下单不能用,我们在线下试,什么机型都试过来了,线下都可以用,为什么他不能用呢?***客户拿出来一款黑莓的手机,说黑莓上也可以兼容安卓的APK来使用。

再一个问题是网络。各位移动开发者可能对网络这个问题都感到比较头大,因为这个网络***个是移动网络,第二个用户使用的环境非常多,他在高铁上,在地下室或者在比较偏远的山区等等地方,我们都要保证这些场景下软件的高可用性。

有了以上两种特点以后,再加上一些其它的原因就产生了另外一个问题,小概率问题特别多。因为我们手淘可能是很多亿的用户,但是有问题的东西,有时候有些问题只有几百个用户有或者十个用户有。发现问题了,就要重现与定位,这个手段不像服务端,在服务器上Bug一下,看一下服务器的日志就可以了,还需要了解手机当时所处的环境。

再有一个问题是修复手段,客户端是通过应用市场发布交付出去的,但如果出现问题的时候怎么样解决。现在一个APK可能30M、40M,这样为了解决一个小Bug而推一个30兆、40兆的包下去,这个成本和代价是相当大的。

那么,针对以上这些问题,我们是如何处理如何解决的?首先是保证客户端的稳定性。我们做了一下几个事情:定制各种各样的聚类算法、多维度的分析和分发、按照业务维度进行告警、监控等。

下面说一下比较常见的错误监控。错误监控大概分几类:***个肯定是网络层,各种超时,各种检验失败等情况。接口调用就是网络上的接口这种调用的,不管是网络层的失败还是业务层的失败都会有相应的监控。业务错误就是在端上,其实你的端有时候也有很多业务这种逻辑,所以我们会把这些逻辑加上一些监控的点。数据错误就是说数据本身可能有些都是人为的,本身会由于代码的修改产生一种格式的变化或者数据量的变化,所以我们对数据本身也要进行一些分析与监控。

本着节约成本办大事的原则,我们就把这些东西划分开。首先实时告警可能到分钟级别,也有到秒级的,它是保证这些关键的错误点,比如说Crash率、网络的错误,一些业务的错误,下单失败等等各种各样的这种错误类型。然后我们可以用阿里云的大数据的计算服务,达到了一个小时级别或者半小时级别的监控,就是每半个小时或者每一个小时跑出来一份指标,然后与之前的数据进行对比。

有了上面的监控、指标度量等等这种东西以后,可以展开一些专项的工作,去推动一些问题的修复,甚至推动架构的一个变化。当然,我们会有一个主动监控的系统来进行这种功能上的、网络层面上等等这种主动的监测,说白了就是在线上不断去跑自动化case,case失败了就告警。

说完技术上的监控,其实我想说的最重要的一点,用户的反馈是非常非常重要的。举一个简单的例子,比如说APP出现了一个在启动阶段最早的问题,可能它压根装上就启不起来,你什么都感知不到,怎么办?那只能通过用户的反馈,用户在各大市场上他反馈了什么。

舆情系统我们做了几个事情,当然这个是仅仅针对用户反馈这一块。首先我们进行了分类达标,我们把它分为系统故障、体验问题、产品问题、客户咨询。我们就通过舆情系统进行发现,然后进行干预、进行排查、进行修复。

当遇到一连串非常严重的业务逻辑错误时该怎么办呢?我们会进行动态部署。对比原来老的包生成一种差量,然后下发到端上。***如果所有手段不行,只能重新发版,当然重新发版也是有策略的。所以我们有一整套发布策略,可以对发版,也可以对发动态部署、Hotpatch配置等等。

智能的放量人为控制,就是说在发布的过程中APP量级非常大的时候,不可能一次性全发的。先放一版,看指标,系统指标合格了,然后再次往上放,不断放量,是一个逐渐灰度的过程。

***就是全量,用推拉结合的一种方式。拉就是拉接口,推是从通道推一个消息下来,然后接收这个消息。时效性高可能对服务端的压力也是非常大的,所以这个推拉结合的方式可以提高我们的到达率。

总结上面说的,我们会有实时告警、离线分析,有用户反馈这种分析,有实时日志分析,还有服务端分布式调用链路的分析,也有一整套故障解决方案。不断去优化线下质量保证的系统,发布策略、发布流程等等。现阶段虽然做了一些工作,但可能也不是那么***,我们一直努力在打造一套端上的运维分析的工具。

我讲完了,谢谢大家!

本文整理自,由51CTO传媒主办的WOT2016互联网运维与开发者大会上来自阿里巴巴高级技术专家杨强主题为《移动APP质量保障工作》的精彩演讲。

演讲视频:http://edu.51cto.com/lesson/id-100756.html

讲师简介:

[[166245]]

杨强,2012年加入阿里巴巴,负责无线产品的研发支撑与无线线上监控运维相关平台相关工作。支持了手淘、天猫、聚划算、钉钉等阿里巴巴内部APP的研发支撑和线上监控运维相关工作。

 

责任编辑:李英杰 来源: 51CTO
相关推荐

2016-04-18 17:52:43

2019-02-01 10:23:05

2015-07-27 17:54:49

Windows 10升级

2013-08-16 10:07:28

用户界面设计如何设计界面

2018-09-10 09:26:33

2011-09-20 10:56:35

云计算PaaS

2023-01-30 11:43:04

开源代码

2022-04-29 09:00:00

Platform架构内核线程

2022-08-10 09:03:35

TypeScript前端

2018-02-08 08:08:12

2019-10-23 10:36:46

DevSecOpsDevOps

2018-05-30 15:15:47

混合云公共云私有云

2017-03-28 15:47:17

数据治理数据库

2020-03-27 12:30:39

python开发代码

2018-05-16 09:41:13

神经网络NN函数

2022-04-28 12:17:26

浏览器连字符hyphens

2014-07-31 17:13:50

编码程序员

2013-03-04 09:34:48

CSSWeb

2019-09-19 09:44:08

HTTPCDNTCP

2023-02-10 08:44:05

KafkaLinkedIn模式
点赞
收藏

51CTO技术栈公众号