本文整理自 GOPS • 2017 北京站演講《運維團隊的一種選擇 簡、智、深》，高效運維社群致力於陪伴您的職業生涯，與您一起愉快的成長。

作者:趙建春

編輯:畢巨集飛

新時代下的網際網路運維正在經歷了一場場風雨洗禮，當前時代下有多少運維人處在迷茫和無助之中，交流和學習所積累下來的是更清晰，還是更迷茫，騰訊社交網路運營部助理總經理趙建春在迷茫中探尋答案，尋找到了”致簡”、”致智”、“致深”的幾種路徑。

作者簡介

趙建春
騰訊社交網路運營部助理總經理、技術運營通道會長、專家工程師。04年加入騰訊，先後從事過研發、運維、大資料方面的建設和管理工作。

前言

在過去三年多時間裡，我因為工作的原因負責了一些和機器學習、AI推薦、自然語言處理相關的工作，系統性的學習了這塊的知識。之前可能做了多年開發和運維的關係，我非常希望能把這兩個東西結合在一起，所以有一些自己的感受和想法，希望把這塊跟大家分享一下。

其次，因為 DevOps 在這兩年發展非常迅猛火爆，尤其咱們這個社群。但是也看到裡面有一些緊張或者是憂慮的成分，這一塊也可以講講，在AI智慧化、自動化的大背景下，我們的同事應該怎麼樣來發展，也有自己的一點小觀點跟大家分享。

運維團隊的踐行之路“致簡”

織雲（Cloud Operations Console）是騰訊的企業級運維管理平臺，為了更好的運維管理我們設計了這個系統，這個系統裡面非常重要的一個設計理念點：“簡”，化繁為簡。做產品要簡單，解決這麼複雜的使用者環境、場景的情況下，其實“簡”是非常重要的。

通向致簡–研發結構分析

由於各個公司的組織架構不同，研發架構也不同。比如有些公司是中心型的，整個公司裡非常強的中央研發機構，可以把整個公司架構都解決。有些公司是不同的小的技術團隊，做一些不同的產品，可能是分散型的結構。也有一些公司整個就是散的，沒有特別明顯的中心化。

但是對於大多數公司來講，研發一般都是先行於運維的，系統上線之後才會考慮運維的事情，上線之後發現好多運維的工作跟不上。

不同公司的結構不同，運維團隊的影響力也不一樣，你有很多好的想法但是苦於你的團隊推動力不行或者團隊技術能力儲備不夠，所以無法推動。

通向致簡–管理方式分析

可能的管理方式：

• 第一種，全域性設計整體考慮
  這個公司有很強的研發結構，可以從全域性設計一個非常強大的研發體系，它在這個研發體系裡就可以把整個運維環境裡所要面對的擴充套件性、一致性、排程等等這樣一些東西全部考慮進去。
• 第二種，靈活適配效率優先
  公司已經發現了非常分散，針對每種情況做適配的工具，短期效率可能非常高；
• 第三種，標準規範持續改進
  
  通過強制的規範和約束，以及通過模組化的規範和標準，讓業務變得逐漸統一，短期可能效率低，但長遠來看可能會帶來長期的收益。

工具可以帶來效率提升，而標準和規範有時候很難感受到或者能夠衡量帶來的效率。兼顧全域性目標與短期需求，短期可以開發滿足需求的高效工具，長遠可以進行系統的模組化和標準化。

通向致簡–環境分析

上面的圖是以我們團隊的案例給大家做一個介紹。

我們團隊在1999年的時候釋出QQ，2002年QQ秀上線，2005年QQ音樂上線，QQ空間是在2005年6月正式釋出，在2006年我們才做了D/O分離。

上面幾個產品都是海量的服務，每一個都是不同的團隊研發的，在不同的年代全部上線了，而且每個產品都有大量的使用者群體、大量的伺服器，研發結構可能也會有差異，這時候運維再接過去改進它、管理它，其實有很大的挑戰。

2009年QQ農場上線，這是一個全民的遊戲，短期內我們幾個月時間布了四五千臺伺服器上去。

多中心型研發組織，規模大、增長快、研發架構不統一、變更頻繁、持續online、沒有維護時間，較強的系統耦合，這些都是QQ的東西，對QQ平臺的服務都有一些依賴。

最後是長生命週期，上線之後，除了農場這樣遊戲類的東西可能慢慢淡化了，但是其他業務是多年運營的，需要長期維護它。

通向致簡–需求分析

這兩年在個性化推薦這一塊有個觀點，從千人一面到千人千面，這塊我們的做法是從千人千面到千人一面，要讓運維同事全部掌握，難度是非常高的。

我們做的是把這個框架全部獨立出來，把 TCP/IP 通訊協議裡的網路層和效能相關的東西全部脫離出來，做成一個框架，包括穩定性、空中海量連線等全部放在框架裡。

使用SO的方式編寫，這樣的方式讓我們編寫的程式碼基本上都是一樣的。

程式編寫出來之後，你要上線可能會涉及到配置檔案、啟動命令、啟動引數、log儲存路徑，我們全部用包的思想把它裝在包裡面，對安裝路徑寫到這個log的格式，寫到log的大小，還有啟動、關閉、安裝、刪除等等全部進行了約束，做到了程式交付千人一面，對我的環境來講逐漸進行規範和約束。

通向致簡–確定工作目標

從架構及分工上簡化，歷史原因，不可能說之前就有非常好的名字服務，所以我們做了一個L5系統，希望我們的程式出故障以後，我們不像硬體廠商提供給我們的服務一樣，兩週之後再來給你處理。

當時的目的就是希望做到這個程度，基本原理是我們有一箇中心的伺服器，DNS伺服器，上面包含所有的名字服務的註冊，在每個機器上都會有一個 Agent ，就是本地的共享記憶體。從伺服器上拉下來一個名字，然後IP地址，拉下來以後就可以了，如果網路中斷，隻影響下發，不影響歷史資料。

我們每一次請求都會把成功、失敗、延遲上傳到伺服器，這樣可以做到判斷哪個機器的成功率、失敗率多少，延遲多少，可以做一個負載均衡的設定，從而達到負載均衡和名字服務的作用，做完這個以後就可以把架構從上到下進行統一。

接入層剛才沒仔細講，我們叫 Qzhttp 的接入元件，把進入層全部進行標準容錯。我們中間加了一層 access 層，記錄之後，由L5和 access 進行容錯， access 層對下面的資料層進行容錯。

剛才說的千人一面的元件全部在元件運維組維護，接入運維組現在3-4個人，元件運維組是9個人，儲存運維組是9個人，我們總共是10萬臺級別的伺服器，2/3以上的是這三個組維護的，標準化之後大家的效率提升非常明顯。

我們做了一個基於CMDB的虛擬映象。

通向致簡–建立標準倉庫

我們把一個模組要提供完整服務的時候，通常是多組程序，加一些基礎服務，甚至裝一些指令碼，會依賴一些命令一些許可權。

這個使用者有沒有開通會員、開通遊戲，這個是需要許可權的，我們把它也當做一種資源，我們把它登記到這個模組以來執行的二級 CMDB 裡。

映象包、配置、檔案、許可權、指令碼、測試工具，全部記錄在中間，類似於 Docker 映象一樣，通過這樣的方式，我們形成了一個運維和開發的交付介面，拿到以後，運維開發我們可以共同維護這個交付頁面，從而達到非常高效的運維過程。

通向致簡–梳理流程

我畫了一個簡單的圖，我們把一個程序需要的相關資源打到一個包了，把包放在資源倉庫裡，資源倉庫裡的東西如果有模組要運轉，需要哪些資源在我們的CMDB記錄下來，包括許可權。

在我們的監控系統中，發現某個模組需要擴容，或者我們日常決策需要擴容的時候，通過流程進行排程下發，排程執行把它從資源倉庫裡放到我們業務模組A上去，然後進行註冊，註冊之後我們就可以通過灰度的方式進行上線，上線之後還會有一些自動化測試。

通向致簡–注重規律

很多人會講，規範推動起來非常困難，確實是，但是沒有大家想象的那麼困難。

運維環境中的60%法則，規範這東西對整個團隊是有幫助的，但是短期是有困難的，你最重要的是保持耐心去推，推的時候有一個60%法則，你推過60%以後，剩下的就慢慢靠過來了。

我們也花了很多天把我們可信的東西做了推廣，一般是一年時間推，推完之後一年時間到60%，慢慢到80%、100%。

約束趨於規範，靈活帶來效率。你可能做了很多工具改進它，一個規範，其實這些問題都不存在了。

騰訊運維實力案例

• 紅米空間首發
  織雲效果還是不錯的，比如說我們在紅米空間首發的時候，雖然小米這兩年勢頭沒有那麼猛了，但是早期他們上線的時候還是非常猛的。在紅米空間首發，單秒有14.8萬搶購，90秒賣了10萬臺，超過1億點贊。
• 天津大爆炸2億排程
  大家都知道兩地三中心做多地分佈，但是真正發生過地震或者掉電、火災這樣的事情在國內沒怎麼聽說過，但是我們遇到一次，天津大爆炸，爆炸過程中這麼厚的鋼板被打成了V字型，很多牆都倒了，都停電了，只有機房有保障。平時我們調一個set，天津有好幾個set，全部要調會深圳和上海，我們做了大量的擴容工作。
• 春節紅包
  春節紅包這塊我們也做了好多次的支援，春節紅包對使用者量的拉動，大家會帶動訊息量，整個鏈條，這麼多模組同時需要擴充套件，這也顯示了我們千人一面或者按層來管理的優勢。

  最近幾年流行的一些工具和方案

• 運維元件級服務

這兩年修改很多開源的系統，譬如 Zookeeper 、 Puppet 、 Docker ，這些是運維元件級的服務。

類似於 Docker 映象管理這方面不是很完善，同時安全性方面可能也會有一些小問題，比如用SSH通道下發同時建很多互信關係。

• 輕量級整體解決方案
  整體解決方案有 Ansible 、 SaltStack ，這個是輕量級的運維解決方案。
• 重量級整體解決方案
  重量級整體解決方案中比較好的，如： K8S 和 OpenStack。
• 即使有這樣的開源工具，標準規範一樣不能少。比如說把 Docker 和 Puppet 做比， Puppet 更偏向於檔案級， Docker 更偏向大的集裝箱級，實際過程中也發現很多公司把它作為類似於虛擬機器一樣的，把整個的服務全放在裡面，包可能更小一點。

  如果只是把運維和開發的介面寄託於 Docker 來解決，就好比把開發的所有東西都裝進 Docker 裡，線是亂七八糟的，但出問題的時候，受力的還是運維。因為這個線是無數的開發在裡面布的，找一個人過來解決不了這個問題，但是運維把它布得很清晰的時候，出了問題一樣可以解決的。

  Puppet包Docker及規範

織雲系統早年一直是服務於我們內部，也受制於我們的人力，所以一直沒有開發出一個對外的版本。

在去年底我們也下決心把它做成一個可以獨立部署的第三方部署版本，我們最近也把它交付給了幾個網際網路金融公司和在雲上支援房地產公司的客戶。

7月份我們剛剛出了第二個版本，做了很多改進，特點是基於規範化、標準化理念。

第二是長期讓業務趨於一致，其實裡面還有很多細緻的東西，然後較少的定製開發。大家互相知道你的模組之間怎麼維護怎麼管理，大家都是同一個理念，會更加標準更加高效一點。

運維團隊的踐行之路“致智”

接下來我們分享一下AI浪潮下的運維：智

我負責這塊工作也做了很多實踐，我們在推薦這個領域也做到每天170億次的推薦量，做的是通用推薦場景，20多個業務，400多個場景，用了大量的機器學習的演算法和支援。

另外做了一些文字處理的東西，社群和自然語言處理的東西，所以這一塊天然有我們的責任感，把運維的工作解決一下，做了一些思考。

機器學習,我們先看一下機器學習，十大機器學習演算法。

C4.5:做分類用的；
K-means:主要是聚類；
SVM:做分類用的；
Apriori:是頻繁項類；
EM:最大似然估計；
PageRank:做搜尋用的；
AdaBoost:分類用的；
KNN:分類用的；
貝葉斯：分類用的；
CART:分類和迴歸；

裡面有七個是和分類相關的。

推薦類如邏輯迴歸、決策樹、矩陣分解、CF、Word2Vector、強化學習等。大多數情況下也都是一種分類問題、二分類問題，最多是多分類，多分類問題也可以轉化為二分類問題。

深度學習，DNN、CNN、RNN，CNN裡面有一個叫卷積和池化，卷積就是用一個視窗去提取一些圖片裡小的特徵，比如線條或者編譯，池化就是把這個東西再進行一個最大值或者是平均值。

簡單來講，加入一個圖片以1024×1024，這麼大的畫素點，這個畫素點就是特徵，這個畫素點其實沒什麼意義，都是一個的，通過這樣的方式把它大量匯聚。比如車的輪子、方向盤或者燈，說白了就是提取一些特徵，通過人為的標註，判斷是不是車、是不是人、是不是你。

分類演算法的應用

分類演算法本質上是通過大量資料的“線索”找到分類依據，“線索”就是特徵，分類演算法大多數對特徵有較強的依賴。比如指證分解和隱含特徵，他不需要把特徵明確提取出來，但是大多數對它都比較有強的依賴。

其實我們運維環境中有大量的資料，只要這些資料你能記錄下來，我們就能通過我們的技術和累計的經驗，知道哪些特徵對這個問題進行一個分類有幫助。

其實我們在過程中就應該把這些資料想辦法記錄下來，把這個特徵儘量保證得更加清晰，不要放在一個連續的字串裡，應該隔斷。

可能有些人有誤解，我們把資料交給深度學習網路，它就可以把這個東西分析出來，其實不是這樣，如果把一個圖片的1024連續的資料分享給神經網路，他也分不出來。

運維和AI可能結合的點

AI和運維的結合，某種程度上講有點像無人駕駛，可以服務大家，但是短期內還是比較困難的。我們在很多決策，雖然裡面叫做AI機器學習，但是在這個裡面有個問題，他有很多場外資訊你可能並沒有納入到這個角色裡，這個場外地區是很難補齊的，有很長的路要走。

做得更加智慧和AI化，是短期內可以挖掘很多實踐的。對資料的特徵建設和歸檔中走向智慧，解放自己的雙手。

運維和AI可能的結合點：智慧告警、網路異常分析、程式異常分析、關聯異常分析、變更體驗報告、硬體故障預測、投訴文字聚類、諮詢客服機器人。

有很多的資料場景，我們通過一個歸類統計數，再和異常進行標註，異常行為有什麼樣的特徵？正常情況下有什麼樣的特徵？這種資料就可以採集下來進行一個分類。

對於網路異常，各種不同的網路異常，表現狀態不一樣，可以把這個東西進行一個分類。

關聯異常分析，發現異常以後，哪個最終是導致異常最根本的原因，底層的故障會導致上面多處告警，如果能夠最終定位出來，當然我們可能有一個故障單，這個故障單定位出來以後，你就知道哪裡是。然後你把這個長期的關係，以後的工作就會變成一種類似於標註，標註出來這是一個什麼異常，是一個分類。

因為分類演算法都要進行樣本集，日常的故障單處理就可以變成樣本集。變更體驗報類似的及遇見故障預測，很多談對已經在研究，通過系統log，判斷這個硬碟會不會出現一些故障。

文字聚類投訴，諮詢服務機器人，這是我們最近剛剛做出來的，運維團隊來講有非常大的諮詢服務，諮詢量很大，但是內容很固定。

針對一個系統的，其實可以提升我們效率的，或者說我們運維的構成進入到一個新的不同的領域裡去。

運維團隊的踐行之路“致深”

還有一個選擇，你成為每一個細分的領域最頂尖的人。我也在我的團隊裡經常說你能不能做到在我們團隊裡任何一個領域出現故障的時候，所有的人都第一時間想到你，找你來解決這個問題。

第二個感受，大學裡的課程，我們運維同事很多都是對計算機行業對IT行業有很大的熱誠，但是很多人都是相關專業的，他很多基礎知識是有缺失的。想做 DevOps ，我覺得有些基礎知識是確實需要的，學習起來也並沒有那麼困難。

在大學裡面和你相關的課並不多，相關的課就那麼幾門，一門課一年就二十個學時。你要對它進行深度的學習，給自己一個定位標籤，在這個團隊裡你就扎準一個方向，深度學習、深度原因，做到讓團隊所有人遇到這個地方的問題肯定就找你。

同時你可以把一個東西做好以後做第二個，第二個做好以後做第三個，把整個課程體系全部摸一遍，基礎非常牢靠，這時候你再去做 DevOps Master 。

第一你在技術上有影響力，第二你對所有的細節非常清楚，第三你有這個資歷和影響力，別人也信任你，你有這個眼界可以達到這個程度。

原文來自微信公眾號：高效運維