用户133749265
这个问题并不会开掉员工背锅.
事故级别S1
首先普及下最通用软件故障级别：
S1：致命（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失， 与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数 据库发生死锁、重要的一级菜单功能不能使用、内存泄漏、严重计算错误、无法登录、无法正常退出、功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出， 关联程序间调用冲突等。
S2：严重（不影响其他功能测试的情况下可以继续该版本测试）
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用 但是不影响其他功能的测试。安全问题、稳定性等。如：软件中数据保存后数据库中显 示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等
S3：一般（实际测试中存在最多，解决率关系版本的优化程度）
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多、容错性不好、大数据无响应或没有滚动条等
S4：建议（测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢 失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等
事件分析
本次故障主要是IOS用户受到影响，虽然本次故障已经超过了24小时。在淘宝的历史故障时间中也是非常耀眼。
通过网友爆料，故障在3月25日凌晨出现，这个时间点，正常人都已经休息了。这个时刻人的精力本身就受到影响，而且阿里加班非常厉害，本次升级研发不知加班多长时间了呢。
人力终有穷尽时。
其实，小编也是程序员，在刚毕业入行时。项目上线，晚上通常都是10点，在上线的第二天，就因为自己写了一个脚本，项目涉及的12个数据库用户数据清理了一遍，而且当天数据还没有备份。作为一名始作俑者，那种滋味....
总结
虽然本次事故持续时间比较长，但是也形成了热点。小编已经把淘宝卸载了很长时间，为了这次事件，又重新下载的淘宝。但其实对淘宝的影响并没有那么严重，难不成有用户就因为这次体验问题，就彻底卸载淘宝。主要是卸载淘宝，其替代产品呢？
全世界就一个淘宝，用户选择性很少。
并不要因为一次问题，就对相关人员直接抹杀。人才成长需要经历些事情，内心才能成熟。
bug级别严重，但不至于开除人员。
极客架构
內部来说肯定是重大事故，属于管理有漏洞，流程有问题；
可能会导致短期內卸载率增加，用户口碑损失；
但是放在历史的车轮下碾压，这消息活不过；
最重要的但是是某宝的直接竟争对手不具备因为这一次事件改变市场格局的能力，至少现在没有看到攻关下手，所以没啥没啥……小事儿；
至于会不会开掉一部分人，这要看内部具体调查结果了；
开人是惩戒措施，先应该是找到原因和补救措施。
