• 欢迎访问web前端中文站,JavaScript,CSS3,HTML5,web前端demo
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏web前端中文站吧

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

JavaScript web前端中文站 7个月前 (04-25) 442次浏览 已收录 0个评论

一、发生了什么?

 

更多精彩内容请看 web 前端中文站
http://www.lisa33xiaoq.net 可按 Ctrl + D 进行收藏

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 个。
记一次重大生产事故,在那 0.1s 我想辞职不干了!记一次重大生产事故,在那 0.1s 我想辞职不干了!

五、其他问题

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

六、今后如何避免?

(1)上线前一定要做压测。(后来多方都进行了接口压测。)
(2)为避免忘加索引,建议每张表的高频查询都加上索引,不论今后数据量是多还是少。
(3)前端高频操作,需要做节流

七、到底辞职不?

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

 不喜勿喷~~

 

作  者: Jackson0714
出  处:http://www.cnblogs.com/jackson0714/
关于作者:专注于微软平台的项目开发。如有问题或建议,请多多赐教!
版权声明:本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。
特此声明:所有评论和私信都会在第一时间回复。也欢迎园子的大大们指正错误,共同进步。或者直接私信我
声援博主:如果您觉得文章对您有帮助,可以点击文章右下角【推荐】一下。您的鼓励是作者坚持原创和持续写作的最大动力!

【注:本文源自网络文章资源,由站长整理发布】

公众号:悟空聊架构

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

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

 


web 前端中文站 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:记一次重大生产事故,在那 0.1s 我想辞职不干了!
喜欢 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址