?1、緊急修復故障

公司集群機器下線，肯定是出了故障，那第一優先級當然是盡快核查集群機器下線的原因，然后給出針對性解決方案，如果短時間內集群問題沒法解決，也要盡快升級領導，把對業務的影響講清楚，如果上級重視了，可能就會幫你協調到更高端的技術資源，這個工作一定要同步進行，一定要給集群支撐方足夠的壓力，這叫對癥下藥，也是治本的方法，其他方法說起來都是曲線救國。

這一步做到位了，如果時間的確緊急，那就走到下一步。

2、資源動態擴容

既然是集群，按道理資源是有冗余的吧，那么臨時動態擴容是最基本的方法，這也是云計算存在的意義吧，如果這一步都做不到，至少說明系統規劃沒做好啊，難不成現在數據倉庫還是單機？如果是這樣，就要考慮數據倉庫云化的方法，現在hadoop大數據平臺架構已經很成熟了。

這一步如果做不到，那就記下來跟規劃部門秋后算賬，然后繼續往下走。

3、資源騰挪調整

集群資源的使用也存在2/8現象，既然是核心任務，肯定有很多非核心任務，那就把其他非核心任務的資源騰挪部分給核心任務，假如是hadoop集群，可以采取調整隊列的方法來快速增加資源，當然前提是要能夠大致判斷調整后的業務影響，不過這種搶別人資源的方式還是比較簡單粗暴。

如果資源調無可調，那就繼續往下走。

4、調整優先級別

如果資源騰挪不現實，比如短時間內難以在資源層面進行精細化的調度，那就對所有任務的優先級進行排序，把核心任務的調度優先級提升，調低其他任務的優先級，確保核心任務的生成時間滿足要求，當然前提是對所有任務的重要程度、相互依賴程度和對業務的影響有比較清晰的認識，這些功夫都在詩外，臨時倉促的去調整任務優先級可能會導致嚴重的后果。

如果任務有成千上萬，互相之間有千絲萬縷的關系，短時間不具備梳理清楚和操作的條件，那就繼續往下走。

5、任務代碼優化

核心任務一般是比較復雜的，消耗的資源也比較多，意味著有較多的優化空間，原來家里有余糧的時候可能不太會關注代碼的質量和效率，現在不得不去做優化了，這就看開發人員的能力了，技術大拿在這個時候往往顯示出了價值，我們以前就通過將hive換成spark取得了不錯的提速效果。

如果代碼優化的空間仍然有限，那就繼續往下走。

6、降低任務依賴

數據倉庫建模通過模型的復用可以有效提升上層應用的整體支撐效率，但回歸到單個應用的任務，由于需要依賴倉庫模型的生成，反倒影響了生成速度，這就是局部和全局最優的矛盾。通過剝離核心任務對數據倉庫模型的依賴，為其量身定做一套數據處理邏輯，則可以大幅提升效率，后果是造成了資源的浪費，加劇了數據倉庫整體資源的緊缺狀態，當然非常時期非常手段，有時候為了考核保障就不得不這么做。

如果這樣也不行，那就繼續往下走。

7、核心任務容災

既然核心任務這么重要，而單集群也不可信任，那就不能把所有雞蛋放在一個籃子里，容災或者應急是常規做法，比如我們為了確保某些作業萬無一失，常常會采取異地異構（核心任務分別放在hadoop和MPP集群）的解決方案，前提是核心任務規模不大，否則投資和成本都吃不消，數據倉庫由于數據量大的特點，一般都不會做容災方案，雖然集群垮掉是極小概率事件，但集群性能下降是很大概率事件，比如hadoop一個參數調整就可能大幅降低數據處理的效率。

這已經是最后一招了，下面就講講管理手段。

8、做好解釋工作

核心任務延遲肯定影響了業務，面對這種情況，一方面要及時跟上級做好溝通匯報，協同各方做好故障的分析，給出可以落地的解決方案，如果下屬能拿著這7個方案來讓我決策，我會很滿意，另一方面，要做好核心任務延遲對業務造成的實際影響的評估，做到心中有數，同時跟業務方做好解釋工作，適當降低業務的預期。

能做到這一步，我想已經超越了大多數人，因為這不是簡單的技術問題，對于處理人員的綜合素質要求挺高。

9、轉危機為機會

出故障對于數據倉庫來講既是挑戰，其實也是機會，平時沒出問題的時候業務感受不到數據倉庫的價值，要爭取些資源還挺難的，如果故障真的對業務造成了較大的影響，可能會讓公司重新審視數據倉庫的價值。

記得以前某次IT系統掛了，造成了較大的社會影響，后來分析出來的原因是容量不足，然后公司對規劃部門、市場部門、IT部門的負責人各打50大板，說規劃部門沒規劃好容量，少投錢了，說市場部門亂提需求，沒做好業務規劃，通過這次事件，IT反倒受到了更多重視，并且獲取了更多的資源來保障生產，各種容災系統拔地而起，然后就沒有發生過整個系統掛掉的情況。

其實還有一點我沒說，就是最終靠的還是人，臨時抱佛腳也沒啥用，希望對大家有所啟示。?