我叫顏小云，來自百度系統(tǒng)部，我在百度主要負(fù)責(zé)百度數(shù)據(jù)中心基礎(chǔ)設(shè)施監(jiān)控和運(yùn)維系統(tǒng)的研發(fā)工作。我今天想給大家分享的題目叫數(shù)據(jù)中心基礎(chǔ)設(shè)施故障管理最佳實(shí)踐，這個(gè)也算是2016年ODCC數(shù)據(jù)中心基礎(chǔ)設(shè)施運(yùn)維最佳實(shí)踐項(xiàng)目的延續(xù)。副標(biāo)題是論告警收斂和監(jiān)控架構(gòu)，這是想強(qiáng)調(diào)一下，故障和告警是2個(gè)不同的概念，因?yàn)椴⒉皇撬械母婢际枪收?，因?yàn)楹芏喔婢赡苁菙?shù)據(jù)中心的正常操作引起的。因此我今天的分享可以用一句話來總結(jié)：就是如果通過對(duì)數(shù)據(jù)中心原始告警的處理，來產(chǎn)生真正有意義的故障，從而做好數(shù)據(jù)中心基礎(chǔ)設(shè)施的故障管理工作。

數(shù)據(jù)中心的可靠性是最重要的，因此我們在建設(shè)初期就會(huì)做很多的2N或者N+1的架構(gòu)，到了運(yùn)維的時(shí)候，我們也會(huì)做數(shù)據(jù)中心的巡檢和維保等等，除了這些以為數(shù)據(jù)中心的監(jiān)控系統(tǒng)可以說是幫助我們發(fā)現(xiàn)數(shù)據(jù)中心監(jiān)控狀況的眼睛。但是在我看來，現(xiàn)在數(shù)據(jù)中心的這個(gè)“眼睛”其實(shí)有不少問題，而其中最主要的問題，恰恰是因?yàn)檫@個(gè)“眼睛“看到的東西太多了。舉個(gè)???????子：這里有1個(gè)實(shí)際的機(jī)房，大概有8萬臺(tái)服務(wù)器，我統(tǒng)計(jì)大概了有兩個(gè)多月的告警數(shù)據(jù)，大家可以看到上面有很多點(diǎn)，在一個(gè)點(diǎn)表示12小時(shí)里面這個(gè)數(shù)據(jù)中心收到的告警量，一共有160個(gè)點(diǎn)，160×12小時(shí)，這樣算下來就是2個(gè)多月的時(shí)間。每個(gè)點(diǎn)代表這12小時(shí)之內(nèi)，我們數(shù)據(jù)中心所收到的告警數(shù)量，最多的時(shí)候12小時(shí)收到5800多條，平均每個(gè)小時(shí)610條，中位值是300多條。這是我們數(shù)據(jù)中心一個(gè)真實(shí)的案例，所以在我個(gè)人看來像這樣的告警量是很難滿足數(shù)據(jù)中心運(yùn)維要求的，我認(rèn)為現(xiàn)在告警至少有三個(gè)方面的問題。

第一， 數(shù)量確實(shí)太多了，這么多數(shù)量我們很難逐條處理，有很多運(yùn)維同事直接批量確認(rèn)了，這樣批量確認(rèn)可能會(huì)遺漏掉一些重要告警。

第二， 這種告警不能直接定位根因故障，特別是在一些重大故障的時(shí)候，會(huì)有很多告警上來持續(xù)刷屏，造成一些我們剛剛?cè)肼毜男峦瑢W(xué)覺得比較恐慌，不知道發(fā)生了什么事情。

第三， 我覺得現(xiàn)在數(shù)據(jù)中心很多告警系統(tǒng)，往往并不能反映數(shù)據(jù)中心現(xiàn)在真實(shí)的健康狀態(tài)。舉兩個(gè)例子，我們用了很多高壓直流模塊，模塊也有不少壞件，所以我們也和我們的供應(yīng)商去聊，問問他們有什么方法幫助我們提前發(fā)現(xiàn)模塊的故障，而廠家的反饋是最有效的方法是看高壓模塊的內(nèi)部溫度，如果它的溫度比較高，說明它的功率件可能有問題。但是很遺憾????是，高壓模塊里根本沒有溫度點(diǎn)的監(jiān)控，它給我報(bào)了很多的電壓、電流、功率，到那時(shí)對(duì)于我們發(fā)現(xiàn)它的故障來講其實(shí)并沒有直接的影響。另外1個(gè)例子是水泵，我們也和我們的水泵供應(yīng)商聊怎么能夠提前發(fā)現(xiàn)水泵的故障，他給我們反饋是看它的振動(dòng)信號(hào)，如果振動(dòng)超標(biāo)了，發(fā)現(xiàn)逐漸變大了，說明這個(gè)水泵有問題。但是同樣的情形也是一樣的，水泵的監(jiān)控信號(hào)里面是沒有振動(dòng)信號(hào)??????以這些都是當(dāng)前數(shù)據(jù)中心遇到監(jiān)控遇到的問題。

遇到這些問題以后，我總結(jié)了一下大概有兩個(gè)方面的做法可以幫助我們?nèi)ソ鉀Q這些問題，一個(gè)是告警過濾，通過設(shè)定合理的閾值，會(huì)過濾掉不少的垃圾告警，對(duì)于我們的一些正常操作，可以根據(jù)情況提前屏蔽掉一些垃圾告警。另外是告警定位，可以幫助我們識(shí)別告警根因，發(fā)現(xiàn)故障，比如我們數(shù)據(jù)中心的專家，如果他站在我們數(shù)據(jù)中心配電單線圖上，他看到這個(gè)開關(guān)跳閘，那個(gè)開關(guān)跳閘，基本上可以看出來現(xiàn)在是什么情況。其實(shí)這種規(guī)則我們是可以抽象出來的，然后把它固化到軟件上，在下次還有這種情況的時(shí)候，我們的軟件就可以自動(dòng)判斷。

但具體怎么落地呢？第一個(gè)想法是讓廠家去做，我們招標(biāo)的時(shí)候，讓廠家按照我們要求做到標(biāo)書里面，落地的時(shí)候讓廠家按照標(biāo)書實(shí)現(xiàn)這個(gè)功能。但是現(xiàn)實(shí)往往有一些困難，首先它不是那么靈活，廠家通常做的都是標(biāo)準(zhǔn)品，他們提供給我們落地的產(chǎn)品并不是所有功能都能實(shí)現(xiàn)的。另外就算一些比較負(fù)責(zé)任廠家按照我們要求做了一些定制的東西，但是做完了之后，特別是各種管理系統(tǒng)，其實(shí)我們后續(xù)還有很多維護(hù)要求，這個(gè)時(shí)候要再去升級(jí)軟件的時(shí)候，就會(huì)遇到一些困難，因此現(xiàn)在包括我們公司，包括騰訊，我們上層的管理系統(tǒng)都是自己研發(fā)的。如果我們要自己做研發(fā)的話，其實(shí)有兩個(gè)途徑，不管是百度也好，騰訊也好，基本都是從這條路來走的。第一，基于廠家告警自己做加工收斂，我們通過廠家的接口，把這些信息收集上來以后我們自己???????告警收斂，還有一個(gè)途徑是我根本不信任廠家的告警，廠家告警，系統(tǒng)告警一個(gè)都不看，我只采廠家實(shí)時(shí)數(shù)據(jù)或者設(shè)備狀態(tài)，然后根據(jù)采集到的數(shù)據(jù)，我自己做告警引擎來判斷。不管是哪種途徑，都有兩個(gè)重要問題要解決，一個(gè)是基礎(chǔ)數(shù)據(jù)的準(zhǔn)確性、時(shí)效性，必須非常及時(shí)告警，而且不能漏掉掉數(shù)據(jù)，不能說一千條告警，你傳給我的時(shí)候只有八百條，這樣是不行的，所以這??個(gè)??題??需要解決。

先說說數(shù)據(jù)的時(shí)效性和可靠性問題。有一句話說得好，如果你不能測量，你就沒法管理，如果你不能管理，就無法改善。傳統(tǒng)的數(shù)據(jù)中心架構(gòu)就是這樣的，廠家在數(shù)據(jù)中心本地有一套監(jiān)控系統(tǒng)，下面有一些采集器，把被監(jiān)控設(shè)備抓上來，廠家再通過一個(gè)接口把信息傳給我們上層管理系統(tǒng)。這個(gè)接口每天大概要傳好幾百條告警，這么多告警，不可能一條一條人工去比對(duì)，我們沒有統(tǒng)計(jì)之前，我們也會(huì)收到很多告警，我們也認(rèn)為接口不會(huì)有問題，但是我們真正做統(tǒng)計(jì)的時(shí)候發(fā)現(xiàn)這個(gè)情況還是比較嚴(yán)重的。結(jié)果我們和供應(yīng)商直接開一個(gè)數(shù)據(jù)庫示圖，我們上層再做一個(gè)軟件，從數(shù)據(jù)庫里面直接抓底層的告警，再和接口抓到的告警進(jìn)行對(duì)比，結(jié)果一對(duì)比發(fā)現(xiàn)，情況遠(yuǎn)比我們想象得要糟糕。但不管怎么樣，有了這樣的機(jī)制，就建立了我們持續(xù)改善的基礎(chǔ)???????所以我們接下來也和運(yùn)營商一起發(fā)現(xiàn)了很多接口問題，我們前前后后大概處理了半年時(shí)間，基本上現(xiàn)在可以說我們把接口的問題處理掉了。有一天我們電池在一個(gè)小時(shí)內(nèi)上報(bào)了有4萬條告警，但是都沒有遺漏。

另外怎么做告警收斂，我們現(xiàn)在告警收斂有兩個(gè)途徑做，比較通用的是告警收斂引擎，我們把所有原始告警收集以后，我們會(huì)做三重合并，基礎(chǔ)合并是把告警開始和結(jié)束的告警進(jìn)行合并，第二是設(shè)備級(jí)別的告警，同一個(gè)類型的告警會(huì)合并在一起。還有系統(tǒng)級(jí)別的告警，在里面配了很多規(guī)則，一條一條的根據(jù)告警順序，告警規(guī)則生效以后，系統(tǒng)會(huì)自動(dòng)判斷當(dāng)前是說在做UPS還是空調(diào)的輪換，判斷以后最后會(huì)出來一個(gè)根因告警，。還有一種做法叫故障預(yù)判引擎，我們會(huì)用機(jī)器學(xué)習(xí)算法看它的半個(gè)小時(shí)、一個(gè)小時(shí)的數(shù)據(jù)，比如溫度，包括水泵振動(dòng)信號(hào)采到之后，我們根據(jù)它的學(xué)習(xí)數(shù)據(jù)，基本可以預(yù)測到這個(gè)點(diǎn)位在半小時(shí)一小時(shí)之后它的數(shù)值之后，根據(jù)預(yù)測數(shù)值和實(shí)際采到的數(shù)值做對(duì)比，如果發(fā)現(xiàn)兩個(gè)之間差額達(dá)到一定程度的時(shí)候，我們會(huì)判斷這個(gè)點(diǎn)???????有問題的。

最后說兩個(gè)呼吁，希望能利用ODCC這個(gè)平臺(tái)聚合行業(yè)力量，共建產(chǎn)業(yè)生態(tài)。一個(gè)是我們希望廠家在系統(tǒng)里添加數(shù)據(jù)層功能，可以做到數(shù)據(jù)標(biāo)準(zhǔn)化，故障預(yù)判引擎和故障收斂引擎，這樣我們只專注于這里面的規(guī)則，我們就不用自己開發(fā)引擎，并不是所有用戶都有自己開發(fā)引擎的能力。另外希望我們接下來能夠更多的在接口、監(jiān)控架構(gòu)做到扁平化，統(tǒng)一采集器接口。????樣用戶管理系統(tǒng)可以從采集器這個(gè)級(jí)別直接到采集到監(jiān)控?cái)?shù)據(jù)，而不是一定要通過北向接口去采集。這就是我今天主要分享的內(nèi)容，謝謝大家！