先抗住，再优化

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

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

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

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

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

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

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

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

另外一个案例：

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

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

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

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

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

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