淘宝3.25弹框技术分析，不只是程序员的事

点击蓝色关注，回复“职级”获取知名互联网公司职级定义
每月开展上个月读者阅读、转发、在看、留言各前三名（冠、亚、季军）评选活动，次月初开奖！欢迎参加，有惊喜。
两周前的3月25日，手淘iOS团队，发生了一起非常严重的首页弹框故障。最终通过发布新版本解决，算上加急审核时间，至少耗费8-12小时。
由于淘宝已经封口，故障最终定级到P几，也只有内部同学才知道了。
是一个和阿里考核3.25巧合的bug？
要不要杀一波程序员祭天？
从这件事故背后，有什么值得学习和思考的？
以下将从「事故现象和结论、弹框必备知识、对策以及规避」三部分展开讨论。
—1—
事故现象和结论
1、现象：
1）App启动时弹框必现。
2）热修复（hotfix）后弹框依然一闪而过。
2、热心读者的思维导图和分析结论：
（在公众号对话框回复关键字“9527”，获取上面ppt高清图）
1）首页弹框的优先级非常高。
2）hotfix的代码初始化过于靠后
3）hotfix后弹框文本内容已发生改变。
3、结论：
猜测弹框关闭后，涉及到的接口内容对下文有强依赖，在hotfix阶段采用先展示后关闭的方式，进行必要的数据传递，因此只能接口改造并更新版本解决。
—2—
弹框必备知识
1、用途：看过325弹框的同学，应该有非常深的印象了。那么这个弹框通常被用在App启动页，其目的是用来告知用户进行一系列的操作，比如软件更新、营销广告、浮层引导等提示引导。
2、运行机制：保证弹框在首页需要的特定场景，可以弹出即可。由于电商、社交、游戏等类型的App弹框的业务类型差异性，因此各类弹框的时机也会有差异，这里不再赘述。
3、技术实现：由于业务的差异化，技术选型也会存在差异。举个栗子，隐私弹框在App第一次打开的时候只显示，那么就需要考虑这个弹框在App端是否需要写入一次，多次读取，既然涉及到了缓存，那么就得考虑缓存的写入判断及缓存清理等操作，不要小看了这个问题，曾经遇到过因手机磁盘空间满，而无法写入导致弹框反复出现，相信在一些用户体量小的情况下，这条测试用例是多余的。
4、弹框可配置：由于运营、风控、安全、隐私、评价等业务的团队都会用到这个弹框，因此做好弹框的类型、优先级尤为重要。重点交互接口必须做到可回滚、可降级且增加权限判断（可以参考银行的交叉业务鉴权/授权进行设计），弹框的频率控制也要考虑，通常关注维度不局限在次数、时间上。
另外弹框文案、颜色、字体及路由目标地址，必须可配置化并增加规范性检查，必要的时候风控介入（请对弹框内文案的合规检查，亲身经历曾经某平台发布了违规物品信息、导致收到警方要求提供发布者IP）。
5、数据监控：大胆设想一下，如果这次淘宝325的弹框有预期值，并且设置警报阀值，也许解决的速度会更快，毕竟0点到6点苹果的审核速度还是可以保证到的，大厂们通常都会和苹果保持一定特殊审核通道。
如果是权限控制类弹框，还需要注意业务逻辑混淆，避免被脱壳后快速注入的尴尬，优秀的产研人员都会通过分析数据，从而对其进行调整。
6、缺陷：以手淘325为例，光阻塞级别的用户体验就能让普通用户莫名奇妙，再加误导文案引起的卸载量，就能让增长、运营哭晕在厕所。
试问在没有更新AppStore版本之前的hotfixed，有多少用户知道杀掉进程后再启动？其实我更想看到的是淘宝客诉电话量及接通率，这是一个服务性行业的硬指标。
如果此时竞对盯着这个点不放，可能大阿里在商海中也要打个哆嗦。
7、上述仅仅只是对外的表现，如果没有对弹框做好业务规划，并对弹框分类、优先级及权限设置做系统化的梳理，那么无论是产品经理、技术负责人还是像我们这种活在最底层的小开发、小测试，都将是一场噩梦。
我身边做过相关弹框的产品，换了一波又一波，吐槽的研发测试也不在少数，曾经一个被定级为P1的故障，就因为层级配置错误，导致弹框无法被关闭，虽然通过hotfix快速修复，一查数据15分钟内影响到了4w+用户。
—3—
对策以及规避
1、技术层面
1）Code Review：请不要过度依赖代码检查工具，规范性检查无法验证业务逻辑是否正确，除非团队实施单元测试，重点业务逻辑请尽量团队或交叉Review，git权限做好管控，避免灰犀牛事件发生。
这里推荐一个代码比较工具BeyondCompare，如果版本基线管控得当，这是一个神器，当然git也非常好用。
2）由于影响面非常大，因此首页弹框功能设计必不可少，尤其是要做好权限管控，做到研发测试权限隔离、生产环境权限申请，涉及到的敏感操作需要二次审批或确认。
如果公司内部能像银行那样做好二次审批授权的话，应该可以有效的避免类似之前微盟的运维事件。
网传手淘也有因iOS研发被325，才搞出这等骚操作，针对此事不做过多的猜测，权当娱乐新闻搏君一笑，毕竟写代码还是非常枯燥的事情。至少故障发生时，AppStore半年前的iOS版本9.1.1是没有这个问题的：）
3）热修复(hotfix)尽量在有能力的前提下自研一套，经历过两家公司，从打仗的高速业务竞争期到合并中的蜜月期，你会发现在此期间有个hotfix方案兜底，走路都带风，说话声音都大了。
hotfix独特的下发和触发机制，会因为网络问题（无法下载）、手机内存问题（无法保存）和一些用户不知道如何冷启动（即杀掉淘宝进程再重新进入app），导致无法快速覆盖到所有被影响到的用户。
做好RN或h5页面降级这样的伪动态化方案。flutter长期看好，目前github上已有flutter基于JIT在iOS下热更新的方案（性能略差），当然能否过审先在这里打个问号。
说了这么多hotfix，咱还是低调点吧，毕竟之前大神Bang的JSPatch之前被苹果爸爸打得鼻青脸肿，滴滴的DynamicCocoa更是被苹果爸爸吓得在github仅靠README.md就获得1.3k的Star，lol~
4）前面提到的数据监控，在Jenkins阶段就可以开始介入，用好定时job，类似Infer和OCLint扫描不能走形式主义，直接发送到各自业务模块负责人限期整改并kpi考核。
5）动态化、A/B、灰度、降级等策略是非常棒的实施手段，如果有精力，请记得一定构建这种能力体系。
6）最后，也请关注故障复盘、故障演练，毕竟这是「团队成长」的一部分。
2、其他层面
身为研发、测试，不能只管好自已的一亩三分地，问题发生时请同步运营、公关、法律、风控、财务、人事、行政等进行相关的处理，做好故障安抚及灾后重建工作。
题外话：要在阳光灿烂的日子里修屋顶，不要等到下大雨去修屋顶。
——乡村教师马老师。
抛个问题供大家讨论：「客户端」的高可用体系该如何建立？
祝愿所有读完本文的人都不会被325！
最后的话
以上就是一位热心读者的投稿内容，希望你喜欢！
我相信文中的方法论不仅仅适合移动端！
抛一个问题，除了移动端，后端或者其他有啥线上事故？请留言分享！
「产品经理程序员、职场困惑找军哥。」关注后回复w，获取微信与我建立连接和互动。另还有高质量技术、产品、技术管理群。——-
以往热文推荐：为什么工作很卖力，最后还晋升不了？
更多精彩，关注我公众号，一起学习、思考、成长
▲长按关注军哥手记，一起学习、思考、成长