先抗住,再优化

工作中我们难免会遇到各种各样的系统故障,在遇到问题的时候,相信读者们一定是想刨根究底找到原因,并且彻底解决。这是正确的做法,也是责任心的体现。但是我们难免会遇到一些难啃的骨头,彻底的解决需要较长的时间,那么应该如何处理呢?

腾讯微博的技术总监曾经说过:任何一个系统不可能刚开始做得非常精细,可以先不要性能那么的优化,性能差一点可以用堆机器或者运维的手段扛过去,然后再优化。这里是针对性能问题。小编认为,当我们遇到系统故障时,也是一样的道理。

这里列举一个真实的案例:

某大型系统重构上线,上线后发现某一重要的站点无法运作,只要运行7到8分钟,页面就会卡死。后来从进程监视器中发现,站点存在内存泄漏的情况,站点对应的进程内存一直暴涨。因为该站点是非常重要的站点,系统所有涉及到的业务收入都需要经过这一站点,其无法使用就直接导致了整个系统的瘫痪。

出现问题后,团队马上查看代码,解决内存泄漏的问题。但是马上该问题并不是那么快解决的,系统代码也非常庞大。如果等彻底解决,可能系统的收入就要损失很多了。那么怎么办呢?当时团队出了一个“馊主意”,IIS里面站点对应的应用程序池有一个自动回收功能,如下:

这里,就将这个站点的回收时间设置为5分钟回收一次,这样程序就可以放心运作了。当然读者会说,在5分钟回收的时候,进程强制回收,那一定有数据丢失的。没错,但是这样也比无法运作好,而且出现问题的数据的比例很少。

这样开发同事就赢得了一步缓冲的时间,在两天后,通过程序的彻底优化,减少对象的新建,在必要环节强制回收,终于解决了该问题,5分钟的回收时间也相应取消。在这两天,业务收入影响非常的小,基本上算是正常运作。

当时在出此下策时,有一些外部门同事觉得是掩耳盗铃,但是在事后,都非常理解这一决定,因为必要的救急策略是一定需要的。出了重大的问题时,一定是先抗住,再优化,目的就是减少业务损失。

另外一个案例:

同样是在这个系统上线时,因为系统涉及到一个虚拟货币的交易。后台有一个已销售货币的表,存放已销售的货币。虚拟货币在数据库中用数据库自建的算法加密存放,而当时由于大家的疏忽,有一个后台查询已销售货币的页面,对应的传送的是货币的明文。因为数据庞大,这样的话查询就无法用到索引,导致查询速度相当的慢,客服部同事的工作严重影响,必须在1小时之内解决该问题,否则就会引起大量的用户投诉。

这里如果要对已销售的虚拟货币的表进行修改,将密文字段修改为明文字段,那么影响的代码是很多的,所有涉及到的存储,以及查询的代码都要修改,一个小时肯定改不完,光是测试就需要半天,所以只能想临时办法。

当时虚拟货币的销售是非常频繁的,团队想到,在数据库中临时加一个字段,存储货币的明文,并对这个字段加上索引。新插入货币的存储过程,加一个update更新语句,每一次插入一个货币,就检测这个表中货币的明文这个字段为空的数据,将其更新。这样插入的速度影响不大,因为加了索引,而且由于该字段就是存储明文的字段,原对应的查询已用货币的页面也改为从这个字段查询,速度也快了。

但是由于存储明文不是一个好的办法,不安全。所以系统进行了优化,只存储货币的MD5加密字段,对应的所有更新和查询也都进行了修改,大概在3天后进行了线上更新。

但是在这一周的时间内,客服同事的工作就没有任何的影响。

以上两个案例,都是说明了一点,遇到重大的问题时,彻底解决问题是需要的,但是更重要的一点是考虑到问题的严重性,如果会有较大的影响,并且彻底解决需要一定的时间,那么就要先另辟蹊径,快速找到缓解之道,在最大化减小故障影响的同时,再彻底解决问题。先抗住,再优化,这里“再优化”是必须的,但是“先抗住”在很多时候更重要,这不是投机取巧,而是明智的决策。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180706G026TI00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券