「淘宝网」关于淘宝内测故障风波：为什么P1故障？3.25又是啥？( 二 ) |程序员|跳槽那些事儿|MacAppStore|

手淘弹窗的申请是非常严格的，需要大大大大老板审批，你懂的，不是随便就能操作，这虽然不是事故，但毒老湿内疚。
几十场的红包雨，需要配置手淘弹窗。不是你想弹就弹，是需要审批后再去后台配置。
这么大个蛋糕谁都想用，阿里那么多业务，怎么也要有个先来后到，轻重缓急。所以，会在控制弹窗的弹出顺序和弹出时间。
比如红包雨和签到提醒两个弹窗，红包雨的优先级是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 。