我叫顏小云，來自百度系統(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)，東京主機(jī) 日本代理服務(wù)器，這是想強(qiáng)調(diào)一下，故障和告警是2個(gè)不同的概念，因?yàn)椴⒉皇撬械母婢际枪收希驗(yàn)楹芏喔婢赡苁?a href="http://www.qzkangyuan.com/cnidc/dc/mkh/20160910/2076.html">數(shù)據(jù)中心的正常操作引起的。因此我今天的分享可以用一句話來總結(jié)：就是如果通過對數(shù)據(jù)中心原始告警的處理，來產(chǎn)生真正有意義的故障，從而做好數(shù)據(jù)中心基礎(chǔ)設(shè)施的故障管理工作。

數(shù)據(jù)中心的可靠性是最重要的，因此我們在建設(shè)初期就會做很多的2N或者N+1的架構(gòu)，到了運(yùn)維的時(shí)候，我們也會做數(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萬臺服務(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)可能會遺漏掉一些重要告警。

第二， 這種告警不能直接定位根因故障，特別是在一些重大故障的時(shí)候，會有很多告警上來持續(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í)對于我們發(fā)現(xiàn)它的故障來講其實(shí)并沒有直接的影響。另外1個(gè)例子是水泵，我們也和我們的水泵供應(yīng)商聊怎么能夠提前發(fā)現(xiàn)水泵的故障，他給我們反饋是看它的振動信號，如果振動超標(biāo)了，發(fā)現(xiàn)逐漸變大了，說明這個(gè)水泵有問題。但是同樣的情形也是一樣的，水泵的監(jiān)控信號里面是沒有振動信號的。所以這些都是當(dāng)前數(shù)據(jù)中心遇到監(jiān)控遇到的問題。

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

但具體怎么落地呢？第一個(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í)候要再去升級軟件的時(shí)候，就會遇到一些困難，因此現(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è)問題都需要解決。