[Day 1]上海CNUTCon全球運維技術大會2017實錄

前言

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

開篇

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

那麼AIOps是什麼？

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

AIOps的數據來源：

1. 業務
2. 操做系統
3. 運維平臺
4. 硬件

AIOps的應用場景：

• 性能優化
• 故障分析
• 預測硬盤故障
• 流量調度
  等

AIOps的落地企業

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

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

王棟老師

百度的業務繁雜這個咱們都清楚，可是看到百度前幾年運維平臺ui也是那麼簡潔，我仍是蠻驚訝的，原來大公司也會有一些比較low的界面。固然啦，做爲程序員不應以顏值來判斷系統的好壞，背後的代碼及架構纔是咱們學習的地方。

GUI運維

大概用了十年，百度基礎運維平臺從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相比，都絕不遜色，甚至超越了原有的框架。

實踐中的經驗：

總結

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