如果你遇到了某個重大的運維問題，采取什么樣的措施才是正確的呢？搞清楚這一點相當重要，如果出現策略選擇錯誤，那很可能會丟飯碗的。前幾天和一個經歷過十年前一次十分著名的大故障的DBA聊天，最后難免會問到那次事故。我十分喜歡聽別人談教訓而不是談經驗，因為成功的經驗往往大同小異，唯有教訓才是金錢也買不來的。雖然回顧慘痛的教訓對于當事者而言有些殘酷，不過這種回顧往往是價值的提煉。

他回顧完這個事件后說，當時我們的最大錯誤決策是按照廠家的建議去停了那個第三方復制設備，其實在這種業務高峰疊加設備性能故障的場景中，很多因素是不確定的，對于第三方設備的特性我們也是知之甚少，當時不應該做這種操作，而是應該先通過業務限流的方式讓系統能維持運行，等營業廳下班后，非業務高峰期再去做高風險的動作。如果那樣，那次事故可能能避免了。

他談到的這個問題就是我今天要談的第一條原則，在各種處置策略中，先選擇最為簡單的，風險小的處置策略；在承擔的責任中，要選擇責任小的責任來承擔，比如說系統運行性能雖然大幅下降，但是還在業務能忍受范圍內，并無惡化跡象的時候，我們可以選擇承擔這次性能故障的責任。如果我們不想承擔這個責任，非要在短時間內解決問題，那么也要盡可能在自身能力范圍內去做優化調整。如果當時的故障已經超出了自身的能力范圍，那么寧可承擔這個小一點的責任也不要冒險去犯錯誤，從而承擔更大的責任。

在實際工作中，能夠想明白這一點，并按照上面的原則去做并不容易，我們在實際工作中看到的往往是一些更小的運維故障因為處置不當而導致超級大故障的案例。比如說Oracle RAC有一個節點故障宕機了，這時候我們應該做什么操作呢？大多數朋友可能會選擇重新啟動一下，也有些朋友會選擇觀望，什么都不做。

實際上，如果是一些負載較高的核心業務系統，那么我們應該首先檢查活著的節點的日志，看看是否存在異常，是否存在也宕機的風險。然后去觀察活著節點的活躍會話數、會話數、負載、等待事件等，看看有沒有風險。如果存在風險，先通過殺會話把系統穩定住。等一切穩定后，才去分析宕機的原因，并判斷重啟故障實例的風險。

如果你無法判斷風險，而當時正好是業務高峰，那么你可以選擇暫時不重啟故障節點，等業務高峰過去后再去處理。最為忌諱的是，RAC故障切換后不久，業務還沒有穩定之前就去重啟故障節點。采取這種做法的慘痛案例比比皆是。

第二個原則是不要以為一切都在你的掌握之中，作為DBA ,數據中心里你不了解的東西太多了，因此考慮問題的時候必須要留有余地。不要選擇看似最佳的解決方案。

大概是十五年前吧，某企業的數據中心經歷了一次機房雙路停電的事故。雖然數據中心是兩路供電的，但是供電公司的兩路電同時故障。這種故障是因為數據中心建設時選擇雙路供電時為了省錢導致的，雖然兩路電來自于兩個220KV變電站，但是上位變電站是同一個，上位站故障兩路電就都沒了，而且供電公司無法給出明確的修復時間。

在應對這個問題的時候，我和他們的IT主管通電話討論策略，我的策略是先把核心業務系統和存儲都停了，外圍系統先跑著。我的理由是適逢盛夏，如果三四個小時不來電，UPS雖然能撐得住，但是機房溫度會過高，把核心系統停了，也就是幾個小時的停機。但是IT主管不同意這個方案，他認為如果把外圍系統都停了，八個小時內能恢復供電，他的UPS也都撐得住，保住了核心系統，那就是大功一件。對于機房溫度的事情，他立即找到了制冰公司，讓他們送冰塊到機房降溫。

最后的結局機房溫濕度超標導致核心存儲系統自動保護，有損自動關機。核心系統數據庫出現大量壞塊，ADG備機存儲同樣故障，磁帶庫磁帶損壞，無法恢復。最后我們通過BBED幫他忙強行拉起了數據庫，把數據導出后重新建庫、補充丟失數據。核心系統2天后才恢復對內服務，一星期后才恢復對外提供查單業務，給企業聲譽造成了很大的影響。

在一些特別嚴重的運維故障發生時，以自己的能力范圍來選擇采取的措施，先考慮那些風險與危害較小，自己比較擅長的方式去處置，是DBA保命的重要原則。這種事故一旦變成大故障，肯定是要有人出來擔責的，DBA是最好的替罪羊。