我們一起學學遇到重大維運問題時的保命原則

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

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

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

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

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

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

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

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

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

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

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