淘宝App惊现“内测版本弹屏”P0级事故！5张淘宝架构PPT，剖析事故始末

点击“技术领导力”关注∆ 每天早上8:30推送

作者| Mr.K 编辑| Emma

来源| 技术领导力(ID：jishulingdaoli)

老K跟朋友开玩笑：今天的心情和手淘App，你永远不知道哪一个先崩溃？

老K使用的是手淘IOS版，今天打开淘宝App的那一刻，它弹出个提示框，“您使用的程序是内测版本，将于3-28日到期。。。”原来用了好几年的手淘，竟然是个测试版！难道我不配用正式版吗？必须差评！

正当一脸懵逼的时候，看到社区群里大家都在讨论这个事，才知道这是个淘宝史无前例的BUG。如下图所示，打开淘宝后，立刻有个弹屏提示。

老K手机截图

事故原因还在调查，微信群里流传着一个说法：某个IOS开发小哥哥，绩效被打了3.25分，于是为了报复，埋下了这个BUG，于是3月25日全网大爆发。。。

还不好说这个传言有几分可信度。3月25日下午，阿里就出来微博辟谣了，孰是孰非，我等屁民就不得而知了，搬好板凳吃瓜吧。

老K测试发现，手机时间调到3月29日，手淘App直接闪退，也就是说，留给淘宝团队的时间不多了，如果3月28日之前，这个BUG没有修复，全球的用户将无法登录淘宝，这对于刚刚经历疫情考验的淘宝商家来说，无疑雪上加霜。对于淘宝来说，损失更是无法计量啊。

从目前了解的情况来看，可以得到以下信息：

1、这个BUG出在IOS客户端，并且埋得比较深。如果是有人故意为之，这位IOS程序员跟公司是有多大仇恨啊，日防夜防，内鬼难防。

2、IOS客户端技术团队在code review上，有重大疏漏。这次恐怕手淘IOS客户端技术团队要全体3.25了，阿里这样一个世界级技术公司，研发流程、制度、工具一定是完善的，这次大概率的原因是团队执行不到位。

3、修复这个问题，需要重新发版，用户重新安装App。由于IOS禁止了热更新机制，所以没法像安卓那样，实现热修复。但是，IOS有静默更新机制，所以淘宝App重新发版后，用户在连wi-fi时会自动更新，对用户来说是无感知的，前提是用户之前同意静默更新（这点，在淘宝的官方声明中得到了印证，淘宝已发版修复，只要连上wi-fi就会自动更新）。

4、目前看来最佳方案是：在3月28日前，发布强制更新版本。因为静默更新总有遗漏的，后面造成用户投诉，甚至删除APP，影响就大了，索性牺牲一点用户体验，一步到位解决根本性问题。

5、敲个警钟，要有法律意识啊。前有微盟运维员工删库，现在淘宝程序员埋BUG。奉劝大家要遵纪守法，对法律要有敬畏之心。

下面我们结合淘宝的5张技术架构图，对这次事故做更深入的分析：

从阿里技术架构，来定位BUG所在

下图是阿里巴巴的技术栈全景图，从2015年开始，阿里在全集团推行“大中台小前台”战略，从图中可以看到，移动中台、业务中台&数据中台，支撑着前端的手机淘宝、手机天猫、优酷、菜鸟、高德等业务板块。

图片来源@阿里巴巴技术团队

注意一个现象，只有手机淘宝App出现这个问题，手机天猫没有这个问题，就说明问题不是出在业务中台和移动中台，否则手机天猫App也应该出现这个BUG，因为整个生态的App都共享一个中台，在下一张图中可以看到，几百个业务应用，共享的是一个技术底座。

中台架构，一定程度作了故障隔离

中台的一个好处是，大家的业务边界划分得比较清晰，架构上解耦，可用性更高。换句话说，你想搞个整体破坏也比较难。

策划了这次S1级事故的程序员小哥，绝对是个聪明人，只可惜才华用错了地方，一时气不过，酿成了大祸，丢工作是小事，搞不好这次要进去蹲几年了，出来再去找程序的工作，怕是没有哪家公司敢收了。

图片来源@阿里巴巴技术团队

阿里绩效考核的原罪：

不管做得多好或多坏，总有人会被3.25

从组织架构维度上看，“大中台小前台”的组织架构下，淘宝隶属电商事业群，该事业群里有完整的技术团队，包括：开发、产品、测试、运营等职能。绩效考核也是从上至下，逐层打下去，比如逍遥子给电商事业群总经理蒋凡打了3.5，那么蒋凡给淘宝网、天猫、1688这些事业部负责人分别打分，层层打到下面，肯定要有人背3.25的，阿里内部是强制排名，所以那位IOS程序员，可能运气不好，被打了3.25。

图片来源@阿里巴巴技术团队

除了手淘App团队，还有哪些团队需要背锅？

其它部门有没有责任呢？严格说来，支撑部门还是有点关系的，如下图所示，共享部门有没有提供好的支撑？比如，工程效能团队，有没有提供代码安全漏洞扫描工具。但是从这个BUG来看，如果隐含在业务代码里，其实也很难能被自动扫描出来。所以这个锅，还是负责Code review人背定了，本来就是他的责任所在啊，制度流程肯定都有，你执行得不够严格，怪不得别人了。