你所不知道的淘宝 325 秘密



①引言

2020年3月25日对于手淘iOS团队来说发生了一起非常严重的首页弹框故障。最终通过发版解决，算上加急审核时间，至少8-12小时已经过去了。由于公司已经封口，故障最终定级到P几，也只有内部同学才知道了。





②现象



“您使用的程序是内测版本，将于当地时间2020-03-28到期，到期后将无法使用，请尽快下载最新版本”，这个bug第一次修复的成为了一闪而过弹窗口，有兴趣的话可以点击【淘宝325视频】查看具体现象。



怀着对线上问题的敬畏之心，以粗略的脑图记录下了当时的思考过程，关注作者并评论区留言关键字“脑图”即可获得高清脑图，希望大家能在评论区展开讨论。





③分析和结论

现象：

1.App启动时弹框必弹。

2.热修复（hotfix）后弹框依然一闪而过。



抽丝剥茧：

1.首页弹框的优先级非常高。

2.hotfix的代码初始化过于靠后。3.hotfix后弹框文本内容已发生改变。



结论：

猜测弹框关闭后涉及到的接口内容对下文有强依赖，在hotfix阶段采用先展示后关闭的方式来进行必要的数据传递，因此只能接口改造并发版解决。



④首页弹框

一、用途：看过325弹框的同学应该有非常深的印象了，那么这个弹框通常被用在App启动页，其目的是用来告知用户进行一系列的操作，比如软件更新、营销广告、浮层引导等提示引导。大家打开App时展示的隐私协议、更新提示及相册、通讯录、麦克风等使用权限其实就是非常典型的首页弹框使用场景。



二、运行机制：保证弹框在首页需要的特定场景可以弹出即可，由于电商、社交、游戏等类型的App弹框的业务类型各不一致，因此各类弹框的时机也会有一些差异，具体业务具体分析，此处不再赘述具体流程。



三、技术实现：由于业务的差异化，技术选型也会存在不一致的地方。举个栗子，隐私弹框在App第一次打开的时候只显示，那么就需要考虑这个弹框在App端是否需要写入一次，多次读取，既然涉及到了缓存，那么就得考虑缓存的写入判断及缓存清理等操作，不要小看了这个问题，曾经遇到过因手机磁盘空间满而无法写入导致弹框反复出现的问题，相信在一些小公司或伪互联网公司里，这一条测试case是比较难贯彻的。



四、弹框可配置：由于运营、风控、安全、隐私、评价等业务的团队都会用到这个弹框，因此做好弹框的类型、优先级尤为重要。重点交互接口必须做到可回滚、可降级且增加权限判断（可以参考银行的交叉业务鉴权/授权进行设计），弹框的频率控制也需要考虑在内，通常关注维度不局限在次数、时间上。



另外弹框文案、颜色、字体及路由目标地址必须可配置化并增加规范性检查，必要的时候风控介入。必要时请对弹框内文案的合规检查，亲身经历曾经某平台发布了违规物品信息导致收到警方要求提供发布者ip。



五、数据监控：大胆设想一下如果这次淘宝325的弹框有预期值并且设置警报阀值，也许解决的速度会更快，毕竟0点到6点苹果的审核速度还是可以保证到的，大厂们通常都会和苹果公司保持一定的不正常审核通道关系：）



六、缺陷：以手淘325为例，光阻塞级别的用户体验就能让普通用户莫名奇妙，再加误导文案引起的卸载量，就能让增长、运营哭晕在厕所。试问在没有更新AppStore版本之前的hotfixed，有多少用户知道杀掉进程后再启动？其实我更想看到的是淘宝内部客诉电话量及接通率，这是一个服务性行业的硬指标。如果这个时候竞争对手再盯着这个点不放，如果不是疫情之下电商强大的生命力得以绽放，可能大阿里在商海中也要打个哆嗦。上述仅仅只是对外的表现，如果没有对弹框做好业务规划，并对弹框分类、优先级及权限设置做系统化的梳理，那么无论是产品经理、技术负责人还是像我们这种生活在最底层的小研发小测试，都将是一场噩梦，身边做过相关弹框的产品换了一波又一波，吐槽的研发测试也不在少数，曾经一个被定级为P1的故障就是因为层级配置错误，导致弹框无法被关闭，虽然通过hotfix快速修复，一查数据15分钟内已经影响到了4w+用户。



⑤对策

一、技术层面1.Code Review：

请不要过度依赖代码检查工具，规范性检查无法验证业务逻辑是否正确，除非团队实施单元测试，重点业务逻辑请尽量团队或交叉Review，git权限做好管控，避免灰犀牛事件发生。这里推荐一个代码比较工具BeyondCompare，如果版本基线管控得当，这是一个神器，当然git也非常好用。

2.由于影响面非常大，因此首页弹框功能设计必不可少，尤其是要做好权限管控，做到研发测试权限隔离、生产环境权限申请，涉及到的敏感操作操作需要二次审批或确认。如果公司内部能像银行那样做好二次审批授权的话，应该可以有效的避免类似之前微盟的运维事件。



网传手淘也有因iOS研发被325才搞出这等骚操作，针对此事不做过多的猜测，权当娱乐新闻搏君一笑，毕竟写代码还是非常枯燥的事情。至少故障发生时，AppStore半年前的iOS版本9.1.1是没有这个问题的：）3.热修复(hotfix)尽量在有能力的前提下自研一套，经历过两家公司从打仗的高速业务竞争期到合并中的蜜月期，你会发现在此期间有个hotfix方案兜底，走路都带风，说话声音都大了。



hotfix独特的下发和触发机制，会因为网络问题（无法下载）、手机内存问题（无法保存）和一些用户不知道如何冷启动（即杀掉淘宝进程再重新进入app），导致无法快速覆盖到所有被影响到的用户。



说了这么多hotfix，咱还是低调点吧，毕竟之前大神Bang的JSPatch之前被苹果爸爸打得鼻青脸肿，滴滴的DynamicCocoa更是被苹果爸爸吓得在github仅靠README.md就获得1.3k的Star，lol~



4.前面提到的数据监控，在Jenkins阶段就可以开始介入，用好定时job，类似Infer和OCLint扫描不能走形式主义，直接发送到各自业务模块负责人限期整改并kpi考核。



5.动态化、A/B、灰度、降级等策略是非常棒的实施手段，如果有精力，请记得一定构建这种能力体系。



最后，也请关注故障复盘、故障演练，毕竟这是成长的一部分。



二、其他层面

做为研发、测试，不能只管好自已的一亩三分地，如果组织架构足够复杂，那还需要考虑问题发生时同步通过运营、公关、法律、风控、财务、人事、行政等进行相关的处理，做好故障安抚及灾后重建工作。题外话：要在阳光灿烂的日子里修屋顶，不要等到下大雨去修屋顶。------乡村教师马老师



最后祝愿所有读完本文的人都不会被325。