有人会因为半夜报警爬起来查问题。
有人会因为出了线上事故拿不到绩效。
甚至整个部门都可能会因为一个事故全体拿不到绩效。
更甚至有人会因为造成重大事故被开。
下面讲几个令我印象深刻的事故：
01 红包活动被薅
这个事故实在太过久远，以至于我完全记不起具体细节了。但我印象最深的是，这是我第一次见到这么严重的线上事故，有一个QA被开了。说起来这个事故其实是开发的代码逻辑造成的，但是有的公司在流程上会这样认定：QA是最终保障环节，只要不是上线后开发又修改了东西，那么出了线上事故QA背首要责任。
02 因为一个ab实验导致所有用户app不能启动
ab实验，是指该功能是个实验功能，只圈一部分用户对其开放功能进行对照，比如可能只先对10%的用户开放。但是有这么一个事故，ab实验代码写的不合理，结果导致所有用户都无法启动，显然把不该影响的用户也给影响了。不仅如此，这个ab实验本来只是一个二级页面上的功能，结果连应用都启动不了，显然把不该影响的步骤也给影响了。所以尽量保证自己所写代码的影响范围是必要的。
03 开屏广告下发数据错误导致app启动崩溃
这个开屏广告刚上线的时候其实是没有问题的。运行了一段时间后，产品人员提出了新配置，后端开发人员上线了新配置。但是后端开发新上线的配置数据有问题，上线后也没有通知QA回归测试，然后app并没有对这种错误数据做容错，就大面积崩溃了。这个事故让我印象深刻的点在于①上线新东西一定一定要通知QA测试，不然真的可能就墨菲定律了②您不妨猜猜这个事故背首责的是谁，首先肯定不是QA，因为产品和后端改完咔咔就上了，都没通知到QA，甚至连自测也没有，然而最后背首责的是客户端。理由是客户端容错机制不够。经历的越多，就会有很多时刻，觉得这个世界就是草台班子。
04 直接往用户账户送钱了
钻石提现功能，QA在测试环境测试提现功能时，将虚拟钻石对应的 money 全部提到一个叫123456XX@XXX.com 的 fake 邮箱，测试环境时只看提现的动作是否 ok，真正的 money 是不会真发到邮箱账户里的。然后到了线上环境测试运行了一段时间，才发现 123456XX@XXX.com 居然不是个 fake 邮箱，它是个真实存在的邮箱，线上环境测试提现时候的那些 money 全都打给 123456XX@XXX.com 这个账户了。这很难评。劝所有在做和资损搭边的项目的伙伴，多长点薪眼吧。
以上事故只是万千事故中的九牛一毛，给大家看个乐。简单总结一下：
①程序员生存之道：尽量保证自己所写代码的影响范围是必要的。而且别人写过的已经work的代码，能不动就不动，搞不好你觉得看不顺眼改了下，结果改出了问题。。。
②珍爱生命，远离资损项目。。。
