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

　　作为一个爱学习的吃瓜群众，淘宝内测风波中，我们关心的不是程序员的恩怨情仇，不是各种猜测谣言，而是：P1故障是啥？3。25又是啥？
　　01：
　　3月25日注定不平凡，在阿里的新财年前，手淘APP爆出惊人的bug。用户打开手淘时，提示弹窗：您使用的程序是内测版本，将于当地时间20200328到期，到期后将无法使用。
　　此事，迅速在朋友圈传播，众说风云。网友毒唐推断该事故为s1级别，有员工被打3。25报复性的可能。在微博上，淘宝内测版本话题在8个小时有8097w的阅读，传播范围非常广。
　　与该日期相对应的是阿里的绩效体系。3。25代表最低绩效，拿到3。25，相当于宣布自己近一年的付出都将付诸东流，不会拿到任何收益，包括奖金，股票或晋升资格。
　　后续淘宝回应称，已经和技术GG沟通弹窗事宜，目前已经修复bug，更新最新版即可。网友毒唐的猜测纯属谣言。
　　这个事件，是开发GG上传安装包时出现了bug，该弹窗仅ios9。5。7版本才会出现，其他版本并不会复现弹窗。所以，很多网友并没有看到弹窗，影响范围相对可控。
　　毒老湿的淘宝也是9。5。7，内测提示弹窗会被其他消息弹窗顶掉，然后消失不见。在AppStore查询了手淘APP的更新记录，发现该版本是在一周前更新，但却在3。25日弹出，是否是人为故意就不得而知了，但至少是有人操作“失误”导致了bug的出现。
　　截止到发文时间，毒老湿仍未收到最新更新提示，9。5。15版本为10小时前的版本，目的并不是修复bug，而是为了直播节。可能是推送的时间问题，很多同学已收到更新的弹窗提示，强制更新。
　　虽体验很差，但却不失为一种办法。一般情况下，手淘不会强制用户进行更新，因为可能会造成大量舆情，这是无法接受的，也会被定故障。
　　02：
　　根据阿里巴巴2020年财报显示，截止到2019。12。31，移动月活跃达8。24亿，年活跃的消费者（一年内有过确认订单的用户）达7。11亿，表现出极强的潜力。
　　拥有如此大体量的产品，产品经理对待任何功能都会小心谨慎和敬畏，尤其是弹窗。手淘首页DAU在2019年双11前已经达到2。89亿，首页的弹窗会直接触达2。89亿，无一例外。
　　毒老湿曾经在阿里做过双11互动项目，就是大家常见的红包雨玩法，会在每天的12点在淘宝首页弹出红包雨。持续15分钟，会发放6000w的红包。
　　即使现在回忆起来，心理也会突突的蹦蹦跳。虽然只有15分钟，但是瞬时流量达到了2000w。刚把玩法投放出去，就会触达2000w用户。
　　如果手淘崩了怎么办？如果权益没发出去，会不会被投诉？如果文案出问题，会不会造成负面影响？
　　常在河边走哪有不湿鞋啊。做了几十次红包雨后，某一次运气比较差，在15分钟内，没发出一枚红包，白白浪费几千万的流量。
　　手淘弹窗的申请是非常严格的，需要大大大大老板审批，你懂的，不是随便就能操作，这虽然不是事故，但毒老湿内疚。
　　几十场的红包雨，需要配置手淘弹窗。不是你想弹就弹，是需要审批后再去后台配置。
　　这么大个蛋糕谁都想用，阿里那么多业务，怎么也要有个先来后到，轻重缓急。所以，会在控制弹窗的弹出顺序和弹出时间。
　　比如红包雨和签到提醒两个弹窗，红包雨的优先级是100，签到是89，在同一时间时，只能是红包雨弹出之后，才会再次弹出签到提醒弹窗。
　　好在是，手淘的技术牛x的很，不需要发版即可弹出弹窗，节省时间，提高效率，这也是各位同学可以借鉴的。
　　3。25事故弹窗的优先级，应该属于最高优先级，而且弹窗停留时间无限，着实浪费用户资源和精力。不过好在是只有一个版本的用户受到影响。
　　03：
　　事故是否是有人故意为之，大家没必要过多关注，但流程中的确存在问题。整个过程，是否经过审核？是否有测试发现？终究会有人担责任，有功者奖励，有过着惩罚。
　　阿里故障定责机制其实比较清晰，举个蚂蚁金服例子，定责有三大原则：
　　等级无下限，只要出现技术问题导致业务损失，就算故障。无论下跌多少，如点击率从90下跌到80，播放时长从10分钟降到8分钟。
　　影响可用率的故障，定级最严厉，是p1级别。谣言的p0事故根本不存在，p0是需求优先级，p1最高等级。s1代表上半年，s2代表下半年。
　　p2故障升级到p1故障，小于60分钟。比如影响人数从5w到10w小于60分钟，就算故障升级。
　　故障时间分为两段，从故障发生开始到发现属于故障发现时间，从发现到完全解决的时间，两段时间的加和为故障时间。按照325事故的影响，时间延续至少12h。
　　还有一种定故障级别方式，按照影响人数定故障级别。其中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。
　　假设，天气持续暖下去，还会有更多人来买羽绒服，保暖内衣吗？KPI是没办法达成的了。
　　但如果身上背了故障，3。25会自然而来降到头上。无论是之前做了多少的贡献，即使卖了4个亿，也不会手软，这是原则。
　　现在只能为开发GG祈祷了，挺住，明年还是个好汉！
　　05：
　　这件事情，给我们很多启示，希望大家引以为戒，不要犯这种低级错误。
　　认真，仔细对待每一行代码，每一个操作。3。25是小，失去人心是大。
　　对产品抱有敬畏之心，不要让用户去发现问题，主动要有报警机制，随时提示异常情况，相信淘宝技术GG会去自省。
　　对自己都不负责，还要指望别人吗？细节要抓紧，多次review。
　　低绩效也无所谓，心态很重要，失败乃兵家常事。
　　一定要去大厂，感受淘宝教科书版的故障自救流程，既长见识，又长心！
　　如果自己犯了错，别连累你的老板，他可能也要养家糊口。
　　最后，问大家个问题：如果这件事发生在你身上，如何力挽狂澜？