?1、緊急修復(fù)故障

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

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

2、資源動態(tài)擴(kuò)容

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

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

3、資源騰挪調(diào)整

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

如果資源調(diào)無可調(diào)，那就繼續(xù)往下走。

4、調(diào)整優(yōu)先級別

如果資源騰挪不現(xiàn)實(shí)，比如短時(shí)間內(nèi)難以在資源層面進(jìn)行精細(xì)化的調(diào)度，那就對所有任務(wù)的優(yōu)先級進(jìn)行排序，把核心任務(wù)的調(diào)度優(yōu)先級提升，調(diào)低其他任務(wù)的優(yōu)先級，確保核心任務(wù)的生成時(shí)間滿足要求，當(dāng)然前提是對所有任務(wù)的重要程度、相互依賴程度和對業(yè)務(wù)的影響有比較清晰的認(rèn)識，這些功夫都在詩外，臨時(shí)倉促的去調(diào)整任務(wù)優(yōu)先級可能會導(dǎo)致嚴(yán)重的后果。

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

5、任務(wù)代碼優(yōu)化

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

如果代碼優(yōu)化的空間仍然有限，那就繼續(xù)往下走。

6、降低任務(wù)依賴

數(shù)據(jù)倉庫建模通過模型的復(fù)用可以有效提升上層應(yīng)用的整體支撐效率，但回歸到單個(gè)應(yīng)用的任務(wù)，由于需要依賴倉庫模型的生成，反倒影響了生成速度，這就是局部和全局最優(yōu)的矛盾。通過剝離核心任務(wù)對數(shù)據(jù)倉庫模型的依賴，為其量身定做一套數(shù)據(jù)處理邏輯，則可以大幅提升效率，后果是造成了資源的浪費(fèi)，加劇了數(shù)據(jù)倉庫整體資源的緊缺狀態(tài)，當(dāng)然非常時(shí)期非常手段，有時(shí)候?yàn)榱丝己吮Ｕ暇筒坏貌贿@么做。

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

7、核心任務(wù)容災(zāi)

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

這已經(jīng)是最后一招了，下面就講講管理手段。

8、做好解釋工作

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

能做到這一步，我想已經(jīng)超越了大多數(shù)人，因?yàn)檫@不是簡單的技術(shù)問題，對于處理人員的綜合素質(zhì)要求挺高。

9、轉(zhuǎn)危機(jī)為機(jī)會

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

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

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