互联网运营或多或少会遇到一些意外。事故有大有小，影响也不一样，有些是微乎其微的，但有些是非常重要的。重大系统灾难只能“删了数据库就跑”吗？笔者列举了一些互联网公司的重大事故，总结了一些建议与大家分享。
1.什么是重大事故？
删库跑路？还是系统崩溃了？重大事故令人沮丧，肝脏颤抖，似乎很无助？
最近公司所在的部门和产品发生了几起重大事故，大量涌入的用户造成了高峰时段的系统瘫痪，造成了不可估量的经济损失:原有的线上活动无法正常开展，除此之外，对产品本身或品牌形象的损害也是不可估量的，创业难，保持难。
当然，任何产品、任何公司都可能发生重大事故，比如——
1.拼多多优惠券BUG事件
2019年1月20日凌晨，拼多多遭遇成立以来最大的BUG事件:当天凌晨，有用户发现可以领取100元无门槛代金券，通过切换微信、QQ等账号可以多次领取，代金券可直接用于充值话费、q币以及购买商品时抵扣。
这个BUG是在凌晨发现的，然后在凌晨五点的时候扩散到全网，吸引了大量的羊毛党。直到早上九点多，拼多多才反应过来，相关优惠券已经下架。十点左右修复了BUG。随着羊毛党的进入，众所周知其作战能力强悍，并开启了Xi-shua模式。传言这个BUG一夜之间让拼多多损失了200亿。
2.携程瘫痪事件
2015年，互联网行业的人应该都听说过携程的“门瘫痪”事件。那天是5月28日，突然携程官网和APP都崩溃了，无法访问。谣言到处传播。两个小时后，携程发布声明称，服务器遭到不明来源攻击，正在努力恢复。
但根据传闻，携程的数据被一个苦逼工程师物理删除了，数据全部丢失。互联网的核心是数据。如果用户数据丢失，公司就会变成空空壳，变得一文不值。第二天，携程发布官方声明，称是由于员工操作失误，导致生产服务器上的代码被误删。导致携程股价盘前暴跌11.67%。
3.王者荣耀测试邮件事件
不知道玩什么，就玩王者荣耀。如果你不知道你的朋友在哪里，那就去王者荣耀吧。
2018年12月3日，王者荣耀安卓QQ区多名用户收到一封标题为“测试”的邮件。打开后，有四个永久道具:英雄沈、棒球奇才、英雄李新和灼热之刃。有多值钱？这封邮件的内容被用户戏称为“梅田史上最强福利”。
邮件发出后，全网沸腾，微信群和QQ群的邮件内容截图满天飞。然而不到一个小时，就进入了游戏提示:停止服务维护。官方已经对使用过道具的账号进行了强制回收。打开没有邮箱的账号，邮箱会被删除。按照游戏中的bug必须赔偿的原则，事后官方为每位全服玩家发放了10个英雄碎片和2000个铭文碎片赔偿。
第二，分两部分看“重大事故”。
1.第一个“一分为二”:主动还是被动
从以上案例可以看出，重大事故的发生分为人为的、故意的和不可控的、偶然的。前者就像程序员删库跑路，后者就像大量流量访问时系统暂时崩溃。
2.把“重大事故”的生命周期一分为二，挑战还是机遇。
首先，我们应该庆幸能够遇到、处理、解决这些“重大事故”，因为这在一定程度上说明我们做出来的产品已经到了一个比较大的用户量阶段，对系统的高并发性有比较高的要求。这是产品和技术在压力下成长的机会。
就像一个孩子的成长，只有一路磕磕绊绊，磕磕绊绊，才能成长为一个身心更强大的人，系统也越来越强大。
3.重大事故既是事实上的严重问题，也是性质上的严重问题。我该怎么办？
毕竟这也不算什么，一个特别好的东西，至少不值得炫耀。
这是参与者在项目或产品的压力下成长的机会。风险是永远无法消除和避免的，但我们还是有规则尽可能的防范，减少风险和损失。
对于人为造成的事故，只能从人的角度多关注，关注每一个参与者的贡献，让大家感受到参与的热情和价值，做好团队的心理建设。
对于非人为原因造成的事故，大概有以下几种解决方案，主要是一些在用的方案，市场上比较常用，后面会讨论。
首先，产品的功能和压力测试要做，做好。除了不可预知的问题，很多事故都是因为所谓的“小问题”造成的，比如一行代码写错了，代码写的不规范，需求逻辑有漏洞等等。第二，如何做好大型活动的应急预案也很关键，比如服务器的动态扩容。如果没有动态，有运维的同学现场支持可以吗？我们应该想尽一切办法和可用的资源，以确保在活动中损失最小；第三，持续的性能优化。我们倾向于在产品从0到1: 00的时候，在一定程度上降低对产品性能的要求。另外，由于经历和能力的不同，不同的人往往无法顾及到“未来”。很多时候，我们总是满足了“当下的需求”，而忘记了看远方的路。所以要找机会不断优化自己做过的事情，一个是纯技术的，比如代码逻辑和编译优化；当然，更好的方法是在战场上验证产品。产品做出来，就必须在不断的实际使用中，在一次次的峰值跳跃之间，找出问题，进行优化。活动期间的实时监控。在业务上线使用过程中，我们也不断增加了一些实时监控工具，可以实现对服务器压力、CPU性能、数据库压力等的看板实时监控。在主动操作过程中，实现秒级实时监控。一对一模拟线上活动，功能自动化脚本测试和性能脚本压力测试。永远没有完美的解决方案，但我们可以离安全更近一步。每次活动前，我们根据业务预计的话务量，进行模拟环境的功能测试和性能测试。当然这些都要形成脚本，可以自动化，这样一方面可以节省时间，另一方面也可以不断丰富监控库。活动的策划时间要控制并向公众报告，多个活动同时在线时的高峰断层如何处理。事实上，很多时候，系统崩溃的问题会出现在对活动运行的整体时间控制不足、对活动效果估计不足或乐观估计不足的问题中。比如，我们估计只有20万人参与活动，但实际参观人数是100万；我们认为一切都是万无一失的，但它总是达不到要求。还有，如果同时有多个活动，多线程的压力会放大很多倍。多系统联动导致关系复杂度增加的问题。除了我们自己的单个系统会遇到瓶颈，导致系统出现问题，如果和多个系统多次联动，出现问题的概率会大大增加。比如一个业务规则，在我们自己的系统里是可以的，但是不能保证上下游的相关系统会有什么“意外”。如果这个时候出了问题，大家只能一起承担责任。这次有很多很多要写...
第四，性能优化与用户体验的永恒博弈
我们刚刚讲了很多应对重大事故的预案和方案，但是透过现象看本质，就会发现在基本的功能问题处理完毕之后，我们将面临一场系统性能和用户体验的艰难博弈。
简单来说:比如我们减少一个很酷的交互操作，可以提高1%的页面打开效率；为了方便用户的筛选，我们把筛选做得层次分明，极其细致，但是这个设计系统的界面之间的查询次数会变得很多。
在处理这部分问题和工作时，小胖发现了一个很有意思的点:技术生往往希望产品减少一些操作和搜索逻辑的使用，从而提高一些系统的性能。而产品生往往对用户体验的细节要求极高，所以很多方案都是为了大家尽可能的沟通，达到所谓的“中和”点。但是这种中和完全正确吗？
五、如何解释和报告事故？
1.下一个政策:报道好消息，但不报道坏消息。
许多人喜欢报道好消息而不是坏消息。即使出了大事故，这种做法其实也不太明智。毕竟老板不是傻子，最初的一两次忽悠还是可以蒙混过关的。但路遥对马的力量的认识，长期以来赢得了人们的关注，诸君无不鼓励他。
2.中国战略:报喜不报忧
有些人胆小，但他们只承认自己的错误。灾难已经发生。承认错误是对的，但是光承认是没用的。而且如果只说不好的部分，相关人员会不高兴，无疑会让事情变得更糟。
3.上策:往往绝望就是机会。
小胖子可以做到的方式是，主动认识到问题的严重性，并迅速定位问题来解决；也要找到问题的转折点，化悲痛为力量。比如你可以抓住机会提出产品的优化资源需求，要钱要资源；当然，更好的方式是一场灾难能否转化为一场好的公关。
比如有一次发现某汉堡品牌的肉有问题，媒体管了一段时间，但后来公司想到了一个面向社会的活动，继续帮助该品牌找出用餐过程中的重大问题。一段时间后，不仅有更多的人知道了这个品牌，也知道了这是一个敢于担当的品牌。人也一样，承担责任非常重要。
以上，从意外中总结出来的，也希望如果有一天你能用上，我能给你一些有用的思路和参考。
爱你的小胖子。2020年夏天。
参考资料:
http://www.woshipm.com/operate/2903465.html/comment-page-1
#专栏作家#
本文由人人作为产品经理原创发布。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
