关于淘宝内测故障风波：为什么P1故障？3.25又是啥？

戳上方蓝字“产品毒思维”关注我，不会失望

image

01

3月25日注定不平凡，在阿里的新财年前，手淘APP爆出惊人的bug。用户打开手淘时，提示弹窗：您使用的程序是内测版本，将于当地时间2020-03-28到期，到期后将无法使用。

image

此事，迅速在朋友圈传播，众说风云。网友毒唐推断该事故为s1级别，有员工被打3.25报复性的可能。在微博上，淘宝内测版本话题在8个小时有8097w的阅读，传播范围非常广。

image.gif

与该日期相对应的是阿里的绩效体系。3.25代表最低绩效，拿到3.25，相当于宣布自己近一年的付出都将付诸东流，不会拿到任何收益，包括奖金，股票或晋升资格。后续淘宝回应称，已经和技术GG沟通弹窗事宜，目前已经修复bug，更新最新版即可。网友毒唐的猜测纯属谣言。

image.gif

这个事件，是开发GG上传安装包时出现了bug，该弹窗仅ios9.5.7版本才会出现，其他版本并不会复现弹窗。所以，很多网友并没有看到弹窗，影响范围相对可控。毒老湿的淘宝也是9.5.7，内测提示弹窗会被其他消息弹窗顶掉，然后消失不见。在App Store查询了手淘APP的更新记录，发现该版本是在一周前更新，但却在3.25日弹出，是否是人为故意就不得而知了，但至少是有人操作“失误”导致了bug的出现。

image.gif

截止到发文时间，毒老湿仍未收到最新更新提示，9.5.15版本为10小时前的版本，目的并不是修复bug，而是为了直播节。可能是推送的时间问题，很多同学已收到更新的弹窗提示，强制更新。

image

虽体验很差，但却不失为一种办法。一般情况下，手淘不会强制用户进行更新，因为可能会造成大量舆情，这是无法接受的，也会被定故障。

02

根据阿里巴巴2020年财报显示，截止到2019.12.31，移动月活跃达8.24亿，年活跃的消费者（一年内有过确认订单的用户）达7.11亿，表现出极强的潜力。

image

拥有如此大体量的产品，产品经理对待任何功能都会小心谨慎和敬畏，尤其是弹窗。手淘首页DAU在2019年双11前已经达到2.89亿，首页的弹窗会直接触达2.89亿，无一例外。毒老湿曾经在阿里做过双11互动项目，就是大家常见的红包雨玩法，会在每天的12点在淘宝首页弹出红包雨。持续15分钟，会发放6000w的红包。

image

即使现在回忆起来，心理也会突突的蹦蹦跳。虽然只有15分钟，但是瞬时流量达到了2000w。刚把玩法投放出去，就会触达2000w用户。如果手淘崩了怎么办？如果权益没发出去，会不会被投诉？如果文案出问题，会不会造成负面影响？常在河边走哪有不湿鞋啊。做了几十次红包雨后，某一次运气比较差，在15分钟内，没发出一枚红包，白白浪费几千万的流量。手淘弹窗的申请是非常严格的，需要大大大大老板审批，你懂的，不是随便就能操作，这虽然不是事故，但毒老湿内疚。几十场的红包雨，需要配置手淘弹窗。不是你想弹就弹，是需要审批后再去后台配置。这么大个蛋糕谁都想用，阿里那么多业务，怎么也要有个先来后到，轻重缓急。所以，会在控制弹窗的弹出顺序和弹出时间。比如红包雨和签到提醒两个弹窗，红包雨的优先级是100，签到是89，在同一时间时，只能是红包雨弹出之后，才会再次弹出签到提醒弹窗。

image.gif

好在是，手淘的技术牛x的很，不需要发版即可弹出弹窗，节省时间，提高效率，这也是各位同学可以借鉴的。3.25事故弹窗的优先级，应该属于最高优先级，而且弹窗停留时间无限，着实浪费用户资源和精力。不过好在是只有一个版本的用户受到影响。

03

事故是否是有人故意为之，大家没必要过多关注，但流程中的确存在问题。整个过程，是否经过审核？是否有测试发现？终究会有人担责任，有功者奖励，有过着惩罚。 阿里故障定责机制其实比较清晰，举个蚂蚁金服例子，定责有三大原则：

1. 等级无下限，只要出现技术问题导致业务损失，就算故障。无论下跌多少，如点击率从90%下跌到80%，播放时长从10分钟降到8分钟。

2. 影响可用率的故障，定级最严厉，是p1级别。谣言的p0事故根本不存在，p0是需求优先级，p1最高等级。s1代表上半年，s2代表下半年。

3. p2故障升级到p1故障，小于60分钟。比如影响人数从5w到10w小于60分钟，就算故障升级。

故障时间分为两段，从故障发生开始到发现属于故障发现时间，从发现到完全解决的时间，两段时间的加和为故障时间。按照325事故的影响，时间延续至****少12h。[图片上传中...(image-a1092b-1585291430984-1)]

还有一种定故障级别方式，按照影响人数定故障级别。其中P1最严重，p4最轻。p3，p4故障需要各大影响业务线的TL审批，p1p2则是重大故障，需要bu接口人处理审批。用户反馈是比较重要的评估点，按照当前和上周咨询量环比上升比例进行评估。比如上周咨询量为100，这周突发到4000，这肯定是异常情况。再者，故障咨询的排队数量和故障电话的接入量，也属于故障的评估范围。所以，负责更新安装吧的开发GG，是妥妥的被按在地上摩擦了，会被安排的明明白白的，P1故障没跑。但是财年前节点，绩效已经沟通完成，不确定是否会因为此事更改为3.25。

04

什么是3.25？ 经常会听到阿里人说：xxx今年绩效打了1，真难受。没错，1就是3.25，代表最差绩效。阿里的绩效评估是按照361模型，代表10个人中，3个最优绩效，6个正常绩效，1个最差绩效。最优绩效是3.75，正常绩效是3.5，最差绩效是3.25。每个绩效都会有+或-的区分，比如3.5+，3.5-，代表不同程度的绩效水平。什么时候会打3.75？超出预期时。比如，你负责服装活动，kpi是销售4亿。最后，你不但达成了业绩目标，还和某个品牌签了长期合作协议。这就是超出预期的好，会给3.75。相反，如果你只卖了2亿，还不及去年的水平，这是低于预期，加之平时你的态度不端正，和业务方沟通不畅等综合因素，那自然而然的也会被打上3.25。3.25不代表这个人能力不行，只是因为没有达到目标预期而已。人算不如天算，有时候要看天的。记得18年的双12，服饰重头戏，本来天气很热，御寒的服装很难卖出去。可天公作美，在双12前，突然整个中国都被寒气侵袭。恰好服饰大降价开始，天时地利人和，这波销售远远超越预期，在头3天就完成了KPI。

image

假设，天气持续暖下去，还会有更多人来买羽绒服，保暖内衣吗？KPI是没办法达成的了。但如果身上背了故障，3.25会自然而来降到头上。无论是之前做了多少的贡献，即使卖了4个亿，也不会手软，这是原则。现在只能为开发GG祈祷了，挺住，明年还是个好汉！

05

这件事情，给我们很多启示，希望大家引以为戒，不要犯这种低级错误。

• 认真，仔细对待每一行代码，每一个操作。3.25是小，失去人心是大。

• 对产品抱有敬畏之心，不要让用户去发现问题，主动要有报警机制，随时提示异常情况，相信淘宝技术GG会去自省。

• 对自己都不负责，还要指望别人吗？细节要抓紧，多次review。

• 低绩效也无所谓，心态很重要，失败乃兵家常事。

• 一定要去大厂，感受淘宝教科书版的故障自救流程，既长见识，又长心！

• 如果自己犯了错，别连累你的老板，他可能也要养家糊口。

最后，问大家个问题：如果这件事发生在你身上，如何力挽狂澜？

延伸阅“毒”