摘要：清華大學數據中心運維那點事兒我徐葳顯然是個科研人員，同時還管理很多行政事務等，但有些人命不好，就是系統管理員的命。最后，數據中心現在如此復雜，怎么能再利用一些人工智能的東西放在數據中心里幫助運維。

嘉賓介紹：徐葳，清華大學交叉信息研究院助理院長，青年千人學者，博士生導師，UC Berkeley 計算機系 PhD，曾供職于 Google。主要方向為基礎架構的監控，日志等，目前以分布式系統以及人工智能等方向為主、包括人工智能、隱私保護、反欺詐等內容。

以下為徐葳在數人云PaaS Innovation 2017，構建靈動新IT大會上的演講實錄。

我（徐葳）顯然是個科研人員，同時還管理很多行政事務等，但有些人“命不好”，就是系統管理員的命。所以花了很多時間去管一個IT系統，學院的機房、云平臺，基本上夜里大家都睡了，還要登陸上去看看日志，該修點什么就修點什么，我這個人有個毛病，就是看不得機器壞了，看不得什么東西不行，就得馬上修好。

清華有系統管理員，就如同我一樣都有系統管理員病，很喜歡做系統管理，但他們都是白天上班，因為沒有加班費，所以不好意思讓人晚上加班，所以晚上一般都由我來管。

這個數據中心做的是人工智能，現在人工智能很熱，科研領域清華做的非常前沿，這是最最聰明的應用，但是跑在最最傻的基礎架構上。

因為曾經供職于Google，非常想在清華復制一套Google的架構，但這并非一兩個人就能開發出來。所以，即便在Google，唯一不能用的地方就是系統運維領域，這是燈下黑，這也是本次講演的主題叫：“數據中心與智能”。

今天給大家分享幾個方面：

首先，數據中心運維，這是和百度合作的一個數據分析的事情，會給大家展示幾個有意思的結果。

其次，討論下現在的新架構，Deep Learning深入學習，如何維護這個框架，怎么把數據中心改造成可以進行支持。

最后，數據中心現在如此復雜，怎么能再利用一些人工智能的東西放在數據中心里幫助運維。

首先，這是和百度合作的一件事，百度有很多的機器，有個部門叫硬件運營部，他們收集了很多故障報修，各種產品線，各種不同的產品報修了硬件，硬件運維部就派人去處理一下，大部分處理的方法就是找廠商換新的。所以叫做出了問題的Ticket，幾年內積累了29萬個，我們可以幫助它的地方是，到底什么東西壞了，拿出來看看，什么時候報修的，大概什么故障，什么部件壞了，這里有很多結果，但因為時間關系，就不挨個贅述了。

報修了一個故障，多長時間會修？如同百度這樣管理非常好的公司，報修之后多長時間會有人去處理？不是說修好它，修了不一定能夠修好，但至少是去修了，該換什么就換什么，硬盤報錯，壞了，就換一個硬盤。

具體時長看起來會非常奇怪：平均需要42天報完錯可以修，中位數的修理時間是6.1天，其中有10%的是140天之后仍然沒有修，但是沒人修并不代表永遠都不要這個東西了，過了200天以后仍然有人去處理它，而并沒有忘記。

感覺這個時間過長，到底是因為什么？因為機器太多了？又或者系統管理員太忙了？其實未必。

因為如百度、Google這樣的公司，系統架構非常容錯，硬件出問題是不可避免的，它壞了，既然能容錯，就像四個轱轆掉了一個還能跑，為什么要去修呢？所以邏輯是有一個超級容錯的系統，在運維時對故障就沒有那么敏感。從好的方面來說，可以省錢，因為一次修一個也得跑一趟，修若干個也得跑一趟，因此還不如一次批量的修。

當然硬件損壞無法避免，是否能降低一些容錯的復雜性呢？大家目前越來越多的都在討論這件事，就是三者的平衡，運維的可靠性、軟件的成本、硬件的成本之間的三者平衡，現在越來越重要了。

另外，不管如何運維，運維的系統都是非常重要的，任何運維都不是登到界面上去敲幾行命令，然后就派出一一件事，這個都是無法做到的，所以不管如何，系統的運維，從一個地方生成這樣配置的操作，從一個地方生成的部署，都很重要。

以上講的是硬件、軟件、運維，這三個部分成本如何平衡，現在這個狀態下，尤其是大規模的數據中心，有可能和過去小的企業數據中心不同。

現在深度學習火了，每個人都想要深度學習的機器。最開始一個人要的時候，沒關系，從桌面虛擬機集群拆出兩臺來，裝上GPU，自己去用?，F在這樣的人多了，裝了60幾塊GPU仍然不夠，所以這種集群如何共享這60幾塊GPU，非常麻煩。

后面做了一個什么事情呢？找數人云做GPU虛擬化，雖然GPU支持虛擬化但太貴所以不買，買的都是消費者級別的GPU，因為便宜。當它不支持虛擬化時聯合容器，所以將GPU集群上放上了Docker，又找了數人云，幫助開發一個數人云的管理系統，是基于Mesos的開源軟件。同時寫Mesos的人是我在伯克利的同學，因此對它的印象很好。

將來的就是這樣的架構，好處是解決了一個問題，即服務封裝，DeepLearning這事真的不復雜，如果你玩過，會發現很簡單，其實就是找一個開源的軟件框架，上面有很多模型，將其下載下來，都是開源的，這些模型甚至都是訓練好的，可以跑人臉識別應用，或者跑其他的什么識別應用，雖然沒有專業跑的好，但也不會太差。

但它的問題在于是基于框架，尤其在中國，版本不一樣，升級版本升級的特別快，隨便動一個升級，其他人都爛了，而不同人就要不同的版本，為什么，因為它下的那個模型是基于某個特定版本開發的，在別的版本上跑不出來，所以在這種情況下，大家去到無數多個配置好的鏡像和環境，這個場景挺好，Docker、數人云有它的界面，將這個東西配置好，這種Docker配置的這種Docker，只有這個Docker里面用的是那種版本的東西，因為Docker是一層一層的，不用做那么多鏡像，只有一點點區別沒有關系，那么多借點有一點點區別，占不了那么多空間，好多鏡像，各自用各自的Docker。

所以這解決了一個叫軟件分發部署的問題，但有一個問題，總得有訓練數據，有點什么東西在里面，完成后改了配置等等，這些東西不可能存回到那個鏡像里頭去，就想那怎么辦呢？可能過了兩個星期之后還用呢？所以就不上Docker，留著，等兩個星期后再說，但兩個星期后做別的項目去了，機器就卡在那里，所以這是個問題，存儲它的周邊結果存在哪里，是個好大的問題。

簡單的方法，有OpenStack，集群上500塊硬盤總是有的，掛上NFS，每臺機器上面有一個Ceph的NFS，把這些東西對接好，想把這個東西存在那個上面保證安全的，關了以后重啟時再掛回來，設計了這樣一套存儲。

那有什么問題呢？DeepLearning的模型也很大，有些人直接在上面跑，本想讓它存儲一個備份數據用，跑到上面做一下其實還是存在本地。

所以后來自己改造了存儲的架構，做了一個開源項目Alluxio，也是伯克利實驗室的一個同學做的。

Alluxio緩存非常有用，它還為Ceph和NFS適配了一個接口，還有Hadoop集群，HDFS里面也有幾百塊盤，將這三種東西適配城了兩個借口，適合放在Docker里面，也適合放在Hadoop里面，且它加了些緩存，這樣用機器人內存吸收了很多流量，上圖就是大概的基本架構。

HDFS也可以支持，同時也能順便支持Hadoop，但是如果有一些大的文件，愿意用HDFS的，就用HDFS。

有寫機器內存還蠻多的，就是當年趁內存時買了一些內存，還是很有用的，可以將內容緩存住。分布式內存很有意思。

最后說一下很多做DeepLearning的程序，這張圖片解釋了一個詞“復雜”，OpenStack覺得自己很干凈，為什么？拿個筆都能畫出來，但是這張圖很復雜，復雜的原因不光是因為有這么多圖，凡是看見的都是數據庫，數據庫是一個持久性的狀態，每個組件里都有自己持久的狀態，那如怎么保證一致？討論了這么久分布式系統的一致性，它一旦跨了組件，尤其是跨了開源項目，誰也不會再說這件事。

但若組件壞了，里面還有一個復雜的結構，它一層一層的封裝起來，所以什么東西壞了，你可能根本不知道，沒壞的時候什么都特別好，但壞了就會很麻煩。

我是個很好的系統管理員，這點特別有信心，但是搞不定這個，因為我不是每天都在配這個，記不得這些東西到底在什么地方，隨便查一個什么東西，后面的參數那么長，咱們記不住，但別人天天都在做當然可以記住。

那么，如何能動呢？我們說通過挖掘日志、系統里的狀態、跑一些系統里的命令、看一些系統里的數據庫，在里面找一些相關的事情，這是純從樣子上找到的，跟語義沒有關系。比如ID長那樣，那個ID就是ID，IP地址就是IP地址，將這些東西都找在一起，把這些關聯性插在一起，就能生成知識圖。

另外，為什么三臺機器一起壞了，有可能用戶只看到一臺機器壞了，但其實另外兩臺也是如此，因為它壞的原因是一個物理機，要壞肯定是三臺一起壞，所以都可以找到系統里的一些東西，這有多少個節點？看這個系統看三天，120臺物理機不算大，待該有60多個存儲的借點，120多個虛擬機的節點，大概出來的結果是幾千萬個狀態，如上圖所示，所以可以想象為什么這東西老壞。

最后總結一下，運維是個什么樣的過程？剛才說到DevOps，過去的系統管理員如何適應DevOps是一個非常大的挑戰，因為DevOps，運維的人是靠開發程序來自動化運維數據中心的，這是必然的趨勢，聽起來都對。但DevOps推廣起來非常難。

DevOps想要推行，一定要把DevOps這些東西的接口配置到過去的系統管理員能懂的那些地方，基本的意思是，預生幾個命令行，別說那么多分布式的東西，感覺就是幾個配置文件，點點什么東西，這個接口怎么配置，是一個非常大的挑戰。

以上是小數整理的徐葳教授在PaaS Innovation 2017上的演講實錄，后臺回復“1116”即可下載本次大會的PPT資料。