记一次重大生产事故，在那 0.1s 我想辞职不干了！

一、发生了什么？

1.那是一个阳光明媚的下午，老婆和她的闺蜜正在美丽的湖边公园闲逛（我是拎包拍照的）。

2.突然接到甲方运营小妹的微信：有个顾客线上付款了，但是没有到账，后台卡在微信支付成功（正常状态是充值成功）。

我第一反应是第三方充值系统挂了吧（之前第三方系统接口经常超时，各种小问题），然后让运营小妹查下后台的异常提示。

3.过了2分钟之后，我还是不放心，用手机（当时没有背电脑出门）登陆后台看了下，发现后台已经进不去了，猜测可能是我的网络不好（公园的移动信号不给力，只有1格信号）。

4.过了10分钟，客服小妹没有用微信联系我，而是直接给我打电话了，反应

  （1）后台登陆不进去了

  （2）前端已经打不开了

  （3）很多用户未充值成功，客服群要炸了！

5.这个时候我意识到我们系统可能挂了。

6.电话挂了后，赶紧给我们运维老大打了个电话，反馈我们的后台不能访问了，是不是系统性能有问题。

7.运维老大过了几分钟回了电话：DB服务器的CPU到100%了，有2个慢查询，先让我解决慢查询问题。

我有点没办法了，我在外面，看不了代码，也提交不了代码改动啊！运维老大说他那边先看看怎么处理。

8.这个时候，甲方拉了个群，将各方项目经理+开发负责人都拨通了，我发现我们项目经理没接入进去（他当时在忙其他事情）。我知道甲方老大肯定会审问我（因为我们系统挂了）。

作为开发负责人，跟我聊这里功能该怎么实现，我可以跟你说清楚，遇到这种特大事故我也不知道怎么处理。

甲方开始追问各方的负责人，到底是哪方问题，语气非常严肃。等问到我们这一方的时候，我说到是我们系统出了问题（我们系统确实挂了），运维老大正在处理。

 

然后甲方就开始斥责了：什么时候能好？

我：这个不好说。运维正在看。

甲方：到底能不能修好？（后面说的脏话我就不在这里提了，大家自己去想吧。）

 

9.那个时刻，我好想怼回去，我哪知道什么时候能好。但我不能怼啊，各方老大们都在呢，而且我不敢惹甲方。有0.1s的冲动 很想跟PM说辞职不干了。

10.这个时候，我们的PM接入了，甲方就转向我们PM了，PM回复大概1个小时能恢复（运维跟PM通过电话了）。

11.然后PM就打电话给我了，问了我怎么导致挂的，我说有慢查询，然后他跟我说运维进行了一定的扩容，但还是不起作用，运维正在升级最高配置，估计1个小时候能好。

12.这个时候我的心算是安定了一点。

13.事情还没完，线上大批客服都付款了，但是没有充值成功该怎么处理？是走手动退款，还是等系统恢复后，自动开始充值？

这里要提一点，我们的系统会将订单存到队列里面，然后从队列里面取一部分订单进行充值，如果贸然退款，可能会出现充值成功，而钱退了的情况。

14.离问题已经过去了半个小时，线上已经有很多顾客开始投诉了，要求退款，运营方和店员都很焦急，而后台系统无法登陆，根本无法进行任何操作。

15.又过了半个小时，PM告诉甲方我们的服务已经恢复，我终于可以登陆后台查看数据了，但是由于手机信号不好，我只能跑到信号稍好的地方登陆后台（也只有2格信号），发现已经有很多笔订单都卡在支付成功那一块，没有进行下一步的充值，而我也不敢轻易进行退款，因为系统会从这些未充值订单中一条条进行充值操作，退款后会导致账不平，那就更麻烦了。

16.等了5分钟后，发现有几笔订单确实在服务器恢复后进行了自动充值，所以我认为所有异常订单都会进行自动充值。于是我跟运营小妹反馈那些订单都会自动冲上。

17.我还是太天真了，过了几分钟后，有很多订单还是卡在支付成功的状态，没有进行下一步充值操作，这个时候我意识到问题的严重性，得赶紧回家了，跟PM说我半个小时能到家，到家后，我来排查这些异常订单。

18.然后走到老婆和她闺蜜旁边，很不好意思的告诉她们，我得回家一趟，而且必须马上，线上出问题了，老婆是见过这种场面的，知道我周末经常需要处理线上问题，闺蜜也很能理解，唯一遗憾的是，她们啥都没玩到就得回去了，感谢老婆和她闺蜜的理解。

19.到家后，我开始排查问题，发现异常订单不可能进行自动充值操作了，只能走手动退款了，然后告诉他们这些订单都需要手动退款。晚上9点能搞定。

20.到9点了，这些订单都处理完了。

21.事情告一段落。

二、那 0.1s 我为什么想辞职?

1.当着那么多供应商的面，有意思？

2.这个世界不平等，那也不用 ma 吧？

3.线上问题不能给出解决时间，就怒了？

三、为什么只有0.1s？

1.赶紧把问题先解决了再说；

2.生活很艰辛，上有老，下有小；

3.事故是我们这边造成的，是我们的问题。

四、什么原因挂的？

其实主要原因就是数据库查询存在慢查询。

开发同事为什么没有加索引？

（1）当时没有考虑到这张表会增长这么多数据

（2）没有加索引的意识

解决慢查询的方案很简单：

第一张表数据量为40w，缺少索引，大量慢查询造成了雪崩效应，连接池里面的连接也耗尽了

第二张表数据量为16w，缺少索引，大量慢查询造成了雪崩效应，连接池里面的连接也耗尽了

加了两个索引后，问题顺利解决。（MongoDB在数据量几十万的级别也会出现慢查询）

这是当时慢查询的监控图，慢查询数量最高时到达500个。

五、其他问题

（1）第三方在他们的前端没做节流，用户频繁点击按钮来调用我们的接口，加快了服务器宕机。

六、今后如何避免？

（1）上线前一定要做压测。（后来多方都进行了接口压测。）

（2）为避免忘加索引，建议每张表的高频查询都加上索引，不论今后数据量是多还是少。

（3）前端高频操作，需要做节流

七、到底辞职不？

其实主要是技术能力不足，想出去找个好岗位好平台的也不好找（怕别人不要），还是多练练技术吧~~~

 

不喜勿喷~~

作　　者：
Jackson0714
出　　处：http://www.cnblogs.com/jackson0714/

关于作者：专注于微软平台的项目开发。如有问题或建议，请多多赐教！

版权声明：本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。

特此声明：所有评论和私信都会在第一时间回复。也欢迎园子的大大们指正错误，共同进步。或者直接私信我

声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是作者坚持原创和持续写作的最大动力！

公众号：悟空聊架构

关注后有书籍赠送！精选 111 本架构师文集。回复 【悟空】领书！