关于淘宝内测故障风波:为什么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。

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

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

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

最后,问大家个问题:如果这件事发生在你身上,如何力挽狂澜?

延伸阅“毒”

你可能感兴趣的:(关于淘宝内测故障风波:为什么P1故障?3.25又是啥?)