前言

CNUTCon連續2年都是以docker容器為主的技術峰會，今年改名全球運維技術大會。你可能會想，我可能去了一個假的CNUTCon，其實，不是。CNUTCon一直專注於運維，而前兩年比較docker比較火，所以主推docker；而這兩年人工智慧比較火，便主推AIOps。
本文融合了一些本人思想，如有理解錯誤，請指正，謝謝。

開篇

首先，是InfoQ主編徐川先生指出本次主題為《智慧時代的新運維》，運維平臺的演變逐漸由工具化、web化、自動化轉向智慧化。

那麼AIOps是什麼？

AIOps：通過人工只能的方式，進一步提高運維效率，包括運維決策、故障預測、問題分析等。

AIOps的資料來源：
1. 業務
2. 作業系統
3. 運維平臺
4. 硬體

AIOps的應用場景：
- 效能優化
- 故障分析
- 預測硬碟故障
- 流量排程
等

第一場：AIOps-百度的思考與實踐

主講：王棟，百度基礎技術體系主任架構師，聽主持人介紹他是清華大學博士生，曾在谷歌工作7年，14年加入百度。

百度的業務繁雜這個我們都清楚，但是看到百度前幾年運維平臺ui也是那麼簡潔，我還是蠻驚訝的，原來大公司也會有一些比較low的介面。當然啦，作為程式設計師不該以顏值來判斷系統的好壞，背後的程式碼及架構才是我們學習的地方。

大概用了十年，百度基礎運維平臺從GUI->API->智慧運維平臺。

百度在運維中統一了很多環境，王棟老師借用始皇帝的書同文、車同軌、行同倫來定義百度AIOps的出發點。不得不說，在我的工作過程中，我覺得這個的確很有必要，不同的伺服器機房、叢集如果不能夠統一，會浪費大量的維護工作。而反覆的造輪子也會造成差異越來越大。

王老師先將運維自動化分為5個等級，目前百度在3-4的過度階段。

在王老師的理念之下，建立運維體系下，極大的減少了運維人員流動造成的交接成本，每位同事都可以通過運維知識庫去解決問題，每位同事都可以建立運維知識庫，並且平臺會根據schema管理起來，使得維護、交接都很容易。

我覺得百度畢竟是大企業，有力氣做那麼的活，而對於中小企業，先把執行環境統一起來，再去折騰書同文、車同軌吧。

當然，百度還有一套故障模擬系統，可以輕鬆摸你各種硬體、軟體上的故障。的確，對於開發人員而說，很多時候，不容易製造硬體故障的條件來檢測自己的指令碼是否ok，畢竟現在伺服器都比較穩定，很少出問題。而有了這套系統，可以對自己指令碼反覆測試。

第二場 DevOps知識體系與標準化的構建

主講：張賀 南京大學 軟體學院教授
說實話，能力有限，我聽得不是很懂，但是現場還是有很多小夥伴去找他交流，這裡我就選幾張圖作為本場介紹

第三場 從自動化到智慧化的阿里運維體系

阿里在探索智慧化的道路上走的還是比較遠的，從阿里在監控領域效果對比圖中可以看出誤差極小。
當然這期間阿里組織架構也發生了一些改變。
- 工具研發團隊+運維團隊 ->
- 工具研發同時做運維 ->
- 工具研發和運維融合 ->
- 日常運維交由研發，徹底DevOPs

曾經我在公司內部提出將部分運維交給開發的思想，剛開始很多反對聲音，但面對各種各樣，運維很難解決的問題，我還是硬著頭皮推進這件事情，當聽到阿里的這段組織結構改變，讓我更加堅定了我的理念。當然啦，我們公司自部分運維交由研發後，效率高了很多

他吐槽在運維過程中，經常由於各種情況，變更機房，他們不得不去解決快速遷移機房帶來的各種問題，他還給我們開了個玩笑“不要讓遷移機房成為阿里的核心競爭力”。
我作為阿里雲的忠實使用者，看著阿里雲從創立時幾個開放節點，一直髮展到現在節點遍佈全球，看著這龐大的後臺，使用智慧化，機器學習去解決了，機器比例問題，還是給與我們很多參考價值。

攜程容器雲優化與實踐

在不瞭解運維人的開發人員眼裡，他們能看到的只是水上的服務，而水下是運維人員不斷建造的地基，而強行將這些水下的知識傳授給開發是不明智的選擇，所以攜程儘可能將其封裝，儘可能使開發無需熟悉水下的基礎。

然後攜程自己研發了一套Framework，處理了網路、cpu、日誌連續性等問題。

對於cpu核心的回收以及分配，攜程做到合併請求來處理單次釋放核心不足以提供下一次需求的問題。

當然攜程還有一套監控體系，來監控各個宿主機器物理機及docker容器的健康檢查。
還是那句話，對於小公司自研Framework層是一個不明智的選擇，而攜程自研的動機是什麼呢？
- 輕量化，專注需求
- 相容性，適配原有中介軟體
- 程式設計師的天性，改不如重寫。

攜程還提出一個理念：誰開發，誰執行。
這一點其實，我沒太懂，這裡的執行具體指什麼，生成環境的執行嗎？我沒好意思問主講老師。當然，我覺得生成環境執行還是交給運維部門出問題的可能性小點。

我們都知道在tomcat作為主程序的docker體系中，tomcat啟動失敗，則容器停止。為了解決這個問題，攜程給每個每個容器中增加了多個程序，而不以tomcat作為主程序，此時程序列表如下：

docker容器中沒有hook，而攜程去做了一個程序來處理hook問題。
攜程還提到一個問題，有些時候java開發會線上程中讀取cpu核心數來確定開的執行緒數量，而在docker容器中，得到核心數目是物理機的數量。造成了建立過多執行緒造成資源耗盡，程式OOM。當然了，採用cpu quota，java也無法獲取準確的cpu數量。
於是他們在運維中，預設推薦配置，但支援開發複寫配置，對於那些不可被修改的配置，採用強制配置。

dockfile優點：

• 不同的測試環境不同需求
• 課定製image
• 簡單易懂，上手快

暴露的問題：

• 無法執行條件運算
• 不支援程序
• 如何維護dockfile
• 就是個後門，環境標準化被破壞

於是攜程以plugin外掛的形式去解決配置問題，我覺得問題有點被搞複雜了，大部分場景可能不需要。

騰訊遊戲容器雲平臺的演進之路

騰訊入場就給我們說，騰訊絕大部分的應用都執行在容器裡，大概23萬+的處理器，但是在交流期間，當我們聽眾提出具體有哪些遊戲、哪些模組執行在這個體系下。我們的講師顯得有點藏著噎著，隨後我們這位聽眾直接問，王者榮耀是不是也在裡面，騰訊給的回答是，他負責的是平臺，具體業務他不過問，就這樣成功的繞過了問題。

不得不說，如果這組資料是真的，騰訊在容器應用上還是蠻拼的，數萬臺物理機組建出的容器平臺，效能之強大無法想象。

畢竟有些時候機器學習需要耗費大量的GPU，所以在部分伺服器中GPU也成為了核心。

騰訊在容器ip影響傳輸效率的問題中，給出了一個解決方案，我的理解是，他們從網橋形式分配ip地址轉向為物理網絡卡分配容器後，再分配ip。來使得網路中間層更精簡，來提高傳輸速度。但是，就我而言，在傳統網橋的生產環境實踐中，暫時並未發現網路傳輸上存在效能問題。當然，畢竟是騰訊，像王者榮耀這種遊戲，對網路環境、延遲要求很高，也可以理解。

騰訊的監控系統：

容器日誌問題彙總，統一顯示平臺。

當然，騰訊也有自己的私有映象倉庫平臺，而且使用了P2P方式分發映象，我想也是為了加速同一區域機房部署速度吧。

華為使用Docker支援系統容器的優化實踐

華為做了一件很大的事，居然把容器作為系統級容器，類似於虛擬機器容器，也可以理解把容器改為虛擬機器執行。

系統容器可以像虛擬機器一樣使用，但是資源消耗上，肯定比正常容器好大。

動態掛載資源

使用SELinux系統：

多租戶KUbernetes實踐：從容器執行時到SDN

kubernetes外掛機制

Kubernetes外掛示例


HyperContainer速度、相容性等和docker相比，都毫不遜色，甚至超越了原有的框架。


實踐中的經驗：

總結

說實話，聽了一天感想特別多，整理了那麼多，也有點累了。也考慮到想讓大家早點看到這篇文章，所以先發出去，明天再繼續寫。