工作中我們難免會遇到各種各樣的系統故障，在遇到問題的時候，相信讀者們一定是想刨根究底找到原因，并且徹底解決。這是正確的做法，也是責任心的體現。但是我們難免會遇到一些難啃的骨頭，徹底的解決需要較長的時間，那么應該如何處理呢？

騰訊微博的技術總監曾經說過：任何一個系統不可能剛開始做得非常精細，可以先不要性能那么的優化，性能差一點可以用堆機器或者運維的手段扛過去，然后再優化。這里是針對性能問題。小編認為，當我們遇到系統故障時，也是一樣的道理。

這里列舉一個真實的案例：

某大型系統重構上線，上線后發現某一重要的站點無法運作，只要運行7到8分鐘，頁面就會卡死。后來從進程監視器中發現，站點存在內存泄漏的情況，站點對應的進程內存一直暴漲。因為該站點是非常重要的站點，系統所有涉及到的業務收入都需要經過這一站點，其無法使用就直接導致了整個系統的癱瘓。

?

出現問題后，團隊馬上查看代碼，解決內存泄漏的問題。但是馬上該問題并不是那么快解決的，系統代碼也非常龐大。如果等徹底解決，可能系統的收入就要損失很多了。那么怎么辦呢？當時團隊出了一個“餿主意”，IIS里面站點對應的應用程序池有一個自動回收功能，如下：

這里，就將這個站點的回收時間設置為5分鐘回收一次，這樣程序就可以放心運作了。當然讀者會說，在5分鐘回收的時候，進程強制回收，那一定有數據丟失的。沒錯，但是這樣也比無法運作好，而且出現問題的數據的比例很少。

?

這樣開發同事就贏得了一步緩沖的時間，在兩天后，通過程序的徹底優化，減少對象的新建，在必要環節強制回收，終于解決了該問題，5分鐘的回收時間也相應取消。在這兩天，業務收入影響非常的小，基本上算是正常運作。

?

當時在出此下策時，有一些外部門同事覺得是掩耳盜鈴，但是在事后，都非常理解這一決定，因為必要的救急策略是一定需要的。出了重大的問題時，一定是先抗住，再優化，目的就是減少業務損失。

?

另外一個案例：

同樣是在這個系統上線時，因為系統涉及到一個虛擬貨幣的交易。后臺有一個已銷售貨幣的表，存放已銷售的貨幣。虛擬貨幣在數據庫中用數據庫自建的算法加密存放，而當時由于大家的疏忽，有一個后臺查詢已銷售貨幣的頁面，對應的傳送的是貨幣的明文。因為數據龐大，這樣的話查詢就無法用到索引，導致查詢速度相當的慢，客服部同事的工作嚴重影響，必須在1小時之內解決該問題，否則就會引起大量的用戶投訴。

?

這里如果要對已銷售的虛擬貨幣的表進行修改，將密文字段修改為明文字段，那么影響的代碼是很多的，所有涉及到的存儲，以及查詢的代碼都要修改，一個小時肯定改不完，光是測試就需要半天，所以只能想臨時辦法。

?

當時虛擬貨幣的銷售是非常頻繁的，團隊想到，在數據庫中臨時加一個字段，存儲貨幣的明文，并對這個字段加上索引。新插入貨幣的存儲過程，加一個update更新語句，每一次插入一個貨幣，就檢測這個表中貨幣的明文這個字段為空的數據，將其更新。這樣插入的速度影響不大，因為加了索引，而且由于該字段就是存儲明文的字段，原對應的查詢已用貨幣的頁面也改為從這個字段查詢，速度也快了。

?

但是由于存儲明文不是一個好的辦法，不安全。所以系統進行了優化，只存儲貨幣的MD5加密字段，對應的所有更新和查詢也都進行了修改，大概在3天后進行了線上更新。

?

在這段期間內，客服同事的工作就沒有任何的影響。

以上兩個案例，都是說明了一點，遇到重大的問題時，徹底解決問題是需要的，但是更重要的一點是考慮到問題的嚴重性，如果會有較大的影響，并且徹底解決需要一定的時間，那么就要先另辟蹊徑，快速找到緩解之道，在最大化減小故障影響的同時，再徹底解決問題。先抗住，再優化，這里“再優化”是必須的，但是“先抗住”在很多時候更重要，這不是投機取巧，而是明智的決策。

總結

以上是生活随笔為你收集整理的先抗住，再优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。