大家下午好，我是來自騰訊的王鎮(zhèn)，今天給大家?guī)淼姆窒碇黝}叫“海量服務器監(jiān)管控最佳實踐”。

前面分享的是硬件相關的，下面我分享的是和軟件系統(tǒng)相關的。

回顧一下騰訊服務器的發(fā)展歷程，回溯到2007年，這個階段我們的服務器只有幾千臺的數(shù)量，我們依靠人力和一些自動化腳本，搞定了基礎交付和基礎監(jiān)控。當我們的服務器起量，進入到5萬或者10萬這個級別之后，光靠人力已經不能完全滿足，必須要依靠我們的自動化和工具平臺。再到現(xiàn)在業(yè)務快速發(fā)展，現(xiàn)在我們機房運營的服務器體量已經有超過50萬臺。

介紹一下我們怎么定義服務器的監(jiān)管控。騰訊服務器都是以OEM為主，從OEM的廠商，從服務器出廠到騰訊的機房商家，整個周期我們都會進行精細化管理，這里面包括三個階段，第一是資源準備階段，第二是資源生產階段，第三是資源運營階段，第三個階段是最為關注的，這個生命周期里時間是最長的，而且和我們的業(yè)務是緊密綁定在一起的，這階段里服務器有任何異常都會直接反映到業(yè)務進程里，這 我們整個管控平臺在這塊投入的精力、時間、人力都是最多的。

跟大家分享一下，因為騰訊的業(yè)務跟其他互聯(lián)網公司有一些不一樣的地方，騰訊的業(yè)務種類非常多，部署在我們服務器上的業(yè)務、進程、數(shù)據(jù)也非常復雜。在研發(fā)整個管控平臺，在研發(fā)整個系統(tǒng)的時候，對塊的考量也是特別多。例如說在海量服務器上部署Agent，再下來是整個海量服務器環(huán)境也是非常復雜多變的，有些周期是一天，有些周期是一周，總的來說，我???????的系統(tǒng)架構首先要考慮到我們的系統(tǒng)是可分布式的，在應對不同的業(yè)務峰值的時候，我們的管控策略在不同的場景下，我們要考慮到很平滑的對我們的管控系統(tǒng)進行擴容和縮容。

下面看看整個管控平臺在系統(tǒng)化工具化這方面我們是怎么進行建設的。我們整個管控平臺建設有那么長時間，整個過程中我們遇到的問題非常多，在不斷總結的過程中，總結那一下我們整個管控平臺開發(fā)的幾個設計理念，最想跟大家分享的是第三點，管控平臺要提供一個底層能力和對外開放的API，這樣我們的業(yè)務和前就可以很放心的和我們的底層來進行解耦，他們就可以很容易的來做上層的一些業(yè)務架構。我們的系統(tǒng)平臺，我們借鑒微信開放接口的設計理念，把我們所有接口都按照完全獨立的設計理念對整個接口進行重構，在有限的資源、有限的人力下來對外提供底層架構管控的能力。

簡單介紹一下整個管控體系的功能框圖，可以看到整個管控的基礎架構，包括網絡設備、服務器設備，這些設備經過數(shù)據(jù)采集管控之后，經過一輪的數(shù)據(jù)清洗，在上層分為三個大的模塊，分別是BME，基礎管控引擎，還有集成監(jiān)控、集成告警模塊，在完成這些邏輯處理之后，通過統(tǒng)一的API對外提供服務。在過去我們只有海量系統(tǒng)的時候列了一個API來對海量系統(tǒng)、海量用戶直接提供我們的底層服務能力，讓運維人員和運維系統(tǒng)可以直接對接進來。業(yè)務發(fā)展起來以后，業(yè)務對這塊的功能需求，個性化需求非常多，我們也提供了獨立的API來對這個業(yè)務提供單獨的個性化的服務。以上這些服務，功能模塊非常多，每一個功能模塊單獨拿下來我們都可以獨立成為一個系統(tǒng)。

簡單跟大家分享一下監(jiān)控模塊邏輯框圖。首先介紹服務器，對服務器的管控、監(jiān)控主要有兩條路徑，第一個是帶內，第二個是帶外，帶內通過服務器上面開發(fā)一個Agent，去采集服務器上面的信息，再通過轉發(fā)來匯集到后臺數(shù)據(jù)分發(fā)中心。在帶外，通過BMC采集這些基礎信息，這些基礎信息采集到之后，通過Jobsvr，把這些信息匯聚，匯報到數(shù)據(jù)分發(fā)層。在數(shù)據(jù)分發(fā)層???????了一個Redis cluster有了這一層之后就可以很好應付當這些上報峰值來的時候，先把這些數(shù)據(jù)存進來，在后來再慢慢處理。再上面一層是告警集群，解析邏輯，這個解析邏輯大家可以注意到這里面有非常多的節(jié)點，這里面都是可以水平進行擴展的。解析出來之后有兩條路徑，第一條路徑是直接通過派單系統(tǒng)/流程系統(tǒng)，直接上報到業(yè)務運維系統(tǒng)這邊跟他們進行對接，這樣業(yè)務運維系統(tǒng)就可以根據(jù)服務器當前的狀態(tài)來對它們數(shù)據(jù)進行遷移或者搬遷。還有一個方面，我們跟騰訊服務器的供應商的接口進行了打通，我們的監(jiān)控系統(tǒng)發(fā)現(xiàn)告警之后，直接可以通過這些接口來進行報障，不像以前是通過線下來進行的，這個接口打通極大提高了我們服務器故障處理的效率。

前面講的都是帶內采集的工作，這里也介紹一下近一兩年我們在帶外這塊也有一些發(fā)力，從我們整個服務器監(jiān)控的經驗來看，帶外數(shù)據(jù)跟服務器硬件更貼合，上面能獲取到一些信息更能直接反映到整個服務器硬件上的狀態(tài)。從帶外主編主要利用這幾個方面，第一個方面是我們對帶外進行重啟操作，整個重啟操作，10萬次是比較老的，最新的應該是遠遠超過10萬。????二個方面是采集的數(shù)據(jù)，包括服務器上面帶外的SDR、SEL這些信息，這些數(shù)據(jù)采上來之后第一對這些數(shù)據(jù)做分析，看看這上面能不能拿到一些告警和異常的信息。第一個內容是用來做告警。第二個方面是做數(shù)據(jù)分析，通過分析這些信息的曲線，再反饋到機房這邊，也可以做很多方面的應用。對功耗的一些處理，整個PUE怎么降低，很大程度上取決于服務器能耗合理的管控，如果把這部分的能耗能夠控制下來，我相信整個綠色機房PUE降低也是有非常大的幫助的。

這里有一些問題，這也是我為什么要反復提標準化的原因所在。第一，現(xiàn)在我們一些服務器硬件部件都是從OEM廠商二次購物的，這樣我們的廠商匯兌它進行二次封裝，這樣導致我們在采集的時候，采集商量的并不是原始的信息，導致我們采集的PN還有手民信息出現(xiàn)很多不準的情況。第二，隨著服務器運營的歷史加長，而且整個服務器在機房停留的時間越長，上面???????服務器、OS版本越舊，造成我們服務器不兼容的情況越來越多。

隨著我們運營有那么多年的歷史，我們積累的數(shù)據(jù)越來越多，我們大概從4年前開始建設數(shù)據(jù)平臺，有了數(shù)據(jù)平臺建設之后，我們才能對后面的數(shù)據(jù)化運營、對我們的機器學習、對我們的AI才能有原始的數(shù)據(jù)。數(shù)據(jù)業(yè)務分析這塊，從內圈里來看，從數(shù)據(jù)的生命周期來看，我們把數(shù)據(jù)分為四個類別，數(shù)據(jù)生產、數(shù)據(jù)接入、數(shù)據(jù)分析和數(shù)據(jù)應用。在外圈這一層是具體到數(shù)據(jù)分析的業(yè)務，我們對CPU、網絡、IO這些數(shù)據(jù)進行分析，就可以知道我們的業(yè)務對我們服務器利用的情況怎么樣，通過對利用率的分析我們可以很好的在下一代平臺里對這些CPU進行合理的選型。

跟大家分享一下我們整個數(shù)據(jù)平臺的功能框圖，采集服務器上的信息分為兩個路徑，一個是帶內，一個是帶外，這些數(shù)據(jù)采集上來之后都會經過統(tǒng)一的消息隊列kafka，從消息隊列里經過簡單的數(shù)據(jù)主力，這里面也會把這個數(shù)據(jù)吐到兩個地方，第一個是存儲平臺，分成不同的數(shù)據(jù)類型，分別用了HDFS/Hbase/tsdb。第二個方面，把我們的數(shù)據(jù)吐到三個處理模塊，第一個是???????時數(shù)據(jù)處理模塊，用到storm、Ssark，這些數(shù)據(jù)實時性要求非常高，第二個是數(shù)據(jù)批量處理，第三個是出庫和入庫。這些數(shù)據(jù)處理完也有兩條路子，第一個路子是數(shù)據(jù)上報的環(huán)節(jié)，最近我們針對一些日志類型的數(shù)據(jù)也引入了Elasticsearch，通過不同的業(yè)務系統(tǒng)，通過統(tǒng)一的API，就可以獲取到數(shù)據(jù)服務了。還有一塊是內部的應用，包括硬盤故障預測，批次問題分析，服務器健康管理，機房溫度管理，能耗管理。

下面是講機器學習和AI，這里跟大家分享三個業(yè)務，第一是故障告警，我們通過這個應用，把更多的非明確的告警把原因分析出來，我們通過OS內核日志還有帶外的日志進行分析，通過機器學習的方法，把這個原因分析出來，再通過人工翻譯，翻譯成業(yè)務看得懂的原因，附在告警單里，讓業(yè)務對我們這些機器會有更多的信心。第二個方面是故障預測，跟大家公布????下硬盤故障預測最新的效果，我們在全網用得量最多的一款硬盤上，提前30天預測的準確率可以達到90%上，覆蓋率可以達到80%以上。第三塊是健康度管理，有這樣一個業(yè)務背景，騰訊的服務器體量比較大，現(xiàn)在已經有超過半數(shù)的服務器過保了，針對這種情況，把全網所有的服務器分不的維度來對這些服務器的健康度進行等級的劃分，分為健康、亞健康、故障等這樣一些等級，這樣?????????資源分配還有資源交付的過程中，根據(jù)這些不同等級的服務器，可以做更多可選的選擇。

這里講的是數(shù)據(jù)平臺建設情況，今年AI確實非?；?，大家可以在不同場合、不同論壇里都可以接觸到。這個是我們之前做的單機版。最近我們有了經驗積累之后，把所有的算法做成平臺，包括反類、聚集、神經網絡。最后一塊是深度學習平臺，得益于近期GPU的廣泛利用，我們在這塊也會有一些投入。

一路走來，騰訊在整個服務器監(jiān)管控這塊遇到的問題非常多，今年我們也跟各個服務器廠商一起推動了多個標準的落地，最終的目的都是為了推動整個服務器在后面運營階段可以更順暢的進行。我們推出了標準化，包括帶外命令、軟件配置、監(jiān)控工具還有帶外采集這樣的一些標準化。這個事情不是一蹴而就的，需要在座各位和業(yè)界上下游廠商大家共同的努力，如果把這個事情做成了，絕對是一件功在當代、利在千秋的大事。作為國內服務器運營成熟度較高的互聯(lián)網公司，騰訊愿意跟大家一起努力，謝謝大家！