当产品发生重大事故时，正确的姿势是什么？（小明可别怂了）

互联网运营多多少少都会遇到一些事故，事故有大有小，影响不一，有些微乎其微，但是有一些却举足轻重。系统发生重大灾难难道只能“删库跑路”？本文作者列举了互联网公司一些比较重大的事故，并总结了自己的几点建议，与大家分享。

一、什么是重大事故？

删库跑路？还是系统奔溃？重大事故让人沮丧、肝儿颤、似乎又无可奈何？

近来所在的部门和产品发生几次大事故，用户大量涌入，在峰值时刻导致系统瘫痪，造成不可估量的经济损失：原有线上活动不能正常进行，除此之外，无论是对产品本身还是品牌形象的损害更是无法估量，所谓创业难、守业更难。

当然重大事故在任何产品和任何公司都有发生的可能，比如——

1. 拼多多优惠券BUG事件

2019年1月20日凌晨，拼多多遭遇了成立以来的最大BUG事件：当日凌晨，有用户发现可以领取100元无门槛券，切换微信、QQ等账号可以多次领取，且兑换券可直接用于充值话费、Q币、购买商品时抵扣。

该BUG于凌晨被发现，随之被扩散开来，凌晨五点传遍全网，吸引了大批羊毛党进入，至早上九点拼多多才反应过来，下架了相关优惠券，10点左右BUG被修复。由于有羊毛党进入，众所周知其作战能力彪悍，开启了嘻唰唰模式。传言该BUG使拼多多一夜损失200亿。

2. 携程瘫痪门事件

2015年做互联网行业的人应该都耳闻过携程“瘫痪门”事件，那天是5月28日，突然之间携程官网和APP双双崩溃，访问不了。一时间谣言四起，两个小时后，携程发布声明说服务器受到不明攻击，正在努力恢复中。

但是据坊间流传，说携程的数据被怀恨在心的一个工程师物理删除，数据全部丢失。互联网公司最核心的就是数据了，若用户数据丢失，公司会成为一个空壳，变的一文不值。次日携程发布官方声明，说是由于员工操作失误，误删除了生产服务器上的代码所致，就此事件结束，受此事件影响，携程盘前股价*11.67%。

3. 王者荣耀test邮件事件

如果你不知道玩什么，就玩王者荣耀吧。如果你不知道朋友去哪了，就去王者荣耀找吧。

2018年12月3日王者荣耀不少安卓QQ区的用户收到了标题为“test”的邮件，打开后里面是英雄沈梦溪、棒球奇才、英雄李信和灼热之刃四个永久道具。价值有多大呢，这次邮件内容被用户戏称为“天美史上最强福利”。

邮件发出后，全网沸腾，微信群、QQ群关于邮件内容的截图满天飞，然而不到1小时，进入游戏提示：停服维护。官方动手了，对已经使用了道具的账号，强制进行了回收。未打开邮件的账号，邮件被删除。按照游戏出 BUG 必补偿的原则，事后官方对全服玩家发放了每人10个英雄碎片和2000个铭文碎片补偿。

二、一分为二看待“重大事故”这件事情

1. 第一个“一分为二”：主动还是被动

通过上边的案例我们可以看到，重大事故的发生分为人为的、故意的，和非人力可以控制的、意外的，前者如程序员删库跑路，后者如活动大量流量访问时系统的暂时性奔溃（此处应该有一个泪奔的表情）。

2. 一分为二看待“重大事故”这件事情的生命周期，挑战还是机遇

首先我们应该庆幸，我们能够遇到和处理、解决这些“重大事故”，因为一定程度上说明了我们做的产品到了一个比较大的用户量阶段，对系统的高并发有了比较高的要求，这无论是对产品还是对技术来讲，都是一次在压力中成长的机会。

就像一个孩子的成长一样，一路上的跌跌撞撞、磕磕碰碰之后，才能成长为一个身体和心理都较为强壮的人，而系统也因此变得越来越健壮。

三、重大事故是事实和性质双重严重的问题，怎么办？

这总归不算事一件特别好的事情，至少不值得炫耀。

这是项目或者产品冒着拼尽洪荒之力的重压给参与者的一次成长的机会，风险永远不可消除和避免，但是我们还是有章可循尽量能预防，从而降低风险和损失。

（1）对于人为原因的事故，我们只能从人的角度多关注，关注每一个参与者的幸苦付出，让大家感受到参与的热情和价值，做好团队的心理建设

（2）对于非人为的原因造成的事故，大概有以下一些处理方案，主要是一些在用的方案，坊间通用的以后用到再谈。

首先，产品的功能和压力测试要做、并且要做好。很多次事故的发生，除了不可以预估的问题之外，很多都是所谓的“小问题”导致的，比如一行代码写错、代码编写的不规范、需求逻辑的漏洞等等；
第二点，针对大型活动的紧急预案怎么做也很关键，比如服务器的动态扩容，如果没有动态，那么让运维的同学现场支援行不行，我们要想尽一切办法和可以动用的资源去保障活动过程中尽量将损失降到最低；
第三点，持续的性能优化。我们在产品从0到1点阶段往往会一定程度上降低对产品性能的要求，加上不同的人由于经验和能力的不同，往往会不能够兼顾到“以后”，我们很多时候总是满足“当下的需求”而忘记了看远方的路。因此，我们要找机会，对做过的东西不断的优化，一种是纯技术层面的，比如代码逻辑和编译上的优化；更好的方式当然是要在战场去验证，产品做出来一定要在不停的实战使用中、在一次次的峰值跳跃间，找到问题，优化问题。
活动过程中的实时监控。在业务线上使用的过程中，我们也不断增加了一些实时监控工具，可以实现在活动作业过程中对服务器压力、CPU性能、数据库压力等的实时看板监控，做到秒级的实时监控。
一比一模拟线上活动，功能自动化脚本测试和性能脚本压测。永远没有万全之策，但是我们可以离安全再近一点。每次活动之前我们按照业务预估的访问量进行模拟环境的功能测试和性能测试，当然这一切都要形成脚本，进而可以变成自动化，这样一方面可以节省时间，另一方面也可以不断丰富监控库。
活动策划的时间把控和活动报备，同时段多个活动同时在线时怎样错峰处理。其实很多时候系统奔溃的问题会出现在活动运营的整体时间把控不足，对活动效果估计不足或者乐观估计等问题上。比如，我们预估活动只会有20万人参与，但是实际访问量却是100万；我们认为一切万无一失，但总是马失前蹄。还有，同时段如果有多个活动同时进行，这种多线程的压力就会被放大多倍。
多系统联动而导致的关系复杂度提高问题。除了我们自己单独的系统会遇到瓶颈而导致系统问题之外，如果我们跟多个系统进行多次联动，那么发生问题概率会大大提升。比如，一个业务规则在我们自己的系统是OK的，但是保不齐上下游关联系统会发生什么“意外”，这个时候出了问题大家就只能一起背锅（请叫我背锅侠）。
很有很多，这次先写这么多……

四、性能优化与用户体验的永恒博弈

刚刚讲了很多实际处理重大事故的方案和预案，但是当我们透过现象看本质我们会发现，在基本的功能问题处理完毕后，后续我们将面临的是系统性能和用户体验的艰难博弈。

简单来讲：比如我们减少一个炫酷交互的操作，可以提高页面打开效率的1%；为了方便用户筛选，我们将筛选做的层级分明，极为细致，但是这样的设计系统接口间的询问次数就会变得多了起来。

在处理这部分问题和工作的时候，小胖发现一个很有意思的点：技术同学往往想让产品降低一些操作和搜索类逻辑的使用，从而可以提高一部分系统的性能，但是产品同学往往对用户体验细节要求极高，所以很多方案都是大家尽量沟通达到所谓的“中和”点，但是这样的中和是否就是完全对的呢？

五、怎么进行事故的解释和汇报