注册 / 登录

阿里移动端高可用性体系演进

分会场:  质量管理/智能运维/DevOps

分享时间: 2017年11月9日 - 12日

案例来源 :

案例讲师

长衿

淘宝 技术专家

花名长衿,淘宝移动技术专家。2008年加入阿里巴巴,2016年开始负责新零售基础平台部移动数据团队高可用产品,见证了手机淘宝和移动技术高速发展的五年,目前主要建设移动端线上高可用运维产品,该产品为阿里全集团集团如手机淘宝,手机天猫,钉钉,优酷等不同类型的应用提供高质量、高效率的移动端线上运维服务。

扫描二维码分享案例

 

案例简述

 

阿里移动端高可用性体系经历了三个阶段,从保障交付前整体可用性,到保障端侧全链路层面的可用性,再发展到目前追求高效精准的体验提升以及问题定位,本案例全面讲述阿里移动如何从移动运维闭环上的关键节点采集、度量(告警)、定位、解决上完整的解决方案以及支撑产品。

 

案例目标

 

传统的大部分企业,在端上保障移动高可用性的方案比较简单,缺乏高效的手段,遇到很多问题,按阶段来分大致包括:
1)测试阶段
传统方案:主要依靠手工和人工进行功能测试和多端适配测试。
问题:A.投入成本高,人力物力大量投入。
B.效果差,用例分析和执行易遗漏。
C.效率低,投入的资源无法沉淀,每次发版本都经历同样的问题。
2)发布阶段
传统方案:通过App Store/应用市场审核之后才能发布,需要用户更新版本。
问题:A.大版本发布之后,总有一些未发现的线上问题需要修复,会紧急发布小版本,用户更新频繁。
B.发版的周期太长,问题的修改需要经过漫长的审核期。发布进度跟不上研发进度。
3)运维阶段
传统方案:线上问题由于移动端的特性,分散在各个用户手机上,缺乏灰度和监控机制。
问题:A.发现问题在正式发布之后,主要通过舆情反馈发现问题,滞后。
B.定位问题困难,需要模拟用户场景进行问题根因定位,往往很难查出问题。
C.问题定位之后,修复成本高,需要发布新版本更新修复,修复周期长,做不到回滚等快速修复。

 

成功(或教训)要点

 

用户角度出发、大数据智能分析、工具闭环

 

案例ROI分析

 

手淘通过此套系统crash率从千分之二下降到万分之二,下降1/10。效率提升超过5倍。

 

案例启示

 

更新中...

 

领取大会PPT

我要参会

大会全套演讲PPT

限时领取

早鸟票8折优惠立减1160!截止9月30日!

我要参会