运维工程师被墨菲定律的各种打脸之DXX问题

作者:焦振清
时间:2017-11-24


这次分享的一个case是各家公司都会出现的问题,依然,在问题初期,没有得到足够的重视,直至这个问题的严重性被提升到一定程度后,大家开始救火,蜂拥向前。我总在想,早知如此,何必当初呢。

问题的起因是一个查询功能没有被进行请求频率限制,如果用户发起的查询操作次数太多的话,会导致数据库CPU使用率飙升,进而影响到这个系统的所有用户(我们不讨论为什么查询请求一定要走数据库)。

接下来,墨菲同学要出场了:

第一次:2017-07-12,用户反馈系统功能异常缓慢,经过定位发现,是因为A用户的查询频率较高以及B用户的一些其他操作一起影响了(注意,这个时候,有根本原因,也有一些噪音,因此大家的重视程度并不高,略带侥幸心理)

第二次:2017-07-19,用户反馈系统功能异常缓慢,经过定位发现,是因为A用户的查询频率较高导致的,因为A用户觉得之前的操作没问题,所以查询压力继续翻倍,因此这次,没有噪音,直接一个人把服务干瘫痪了(注意,我们不讨论说如何优化,是否需要隔离,是否需要加访问频率控制这类防攻击功能,降级等等,我们只聊墨菲同学)

因为对服务的影响较大,因此第二次就引起了重视,大家紧急修复,添加了访问频率控制,读写分离,读请求缓存等措施,从而从根本上杜绝了这类事情再次发生的可能性,事实上,从这之后,再也没有发生过类似问题。

但是,回头我们也需要想想,本来,这个问题,在第一次发生的时候,只要添加一下访问频率控制就完全可以解决问题,何苦非要等第二次问题严重了,才投入这么多人力做优化呢,既然早晚都要做,且早做的成本低,影响小,何苦呢,哎,一身叹息!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值