我叫顏小云，來自百度系統部，我在百度主要負責百度數據中心基礎設施監控和運維系統的研發工作。我今天想給大家分享的題目叫數據中心基礎設施故障管理最佳實踐，這個也算是2016年ODCC數據中心基礎設施運維最佳實踐項目的延續。副標題是論告警收斂和監控架構，東京主機 日本代理服務器，這是想強調一下，故障和告警是2個不同的概念，因為并不是所有的告警都是故障，因為很多告警可能是數據中心的正常操作引起的。因此我今天的分享可以用一句話來總結：就是如果通過對數據中心原始告警的處理，來產生真正有意義的故障，從而做好數據中心基礎設施的故障管理工作。

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

第一， 數量確實太多了，這么多數量我們很難逐條處理，有很多運維同事直接批量確認了，這樣批量確認可能會遺漏掉一些重要告警。

第二， 這種告警不能直接定位根因故障，特別是在一些重大故障的時候，會有很多告警上來持續刷屏，造成一些我們剛剛入職的新同學覺得比較恐慌，不知道發生了什么事情。

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

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

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