本文來自騰訊社交多媒體業務負責人@樑定安（大梁）在APMCon2016·聽雲的同名主題演講，解讀了在億級線上使用者和十萬級伺服器的海量運維壓力挑戰下，如何把繁雜的運維工作變成自動化。

今天我跟大家交流的是實實在在的怎麼樣做運維自動化這個主題。

可能之前大家也聽過我介紹織雲平臺怎麼做，我最近想一個事情，像騰訊這種體量（QQ月活量是8.3億，8.3億的DAU）及海量運維壓力下，構建出的自動化運維平臺如果真的放在一些中小企業，是沒有太多的用武之地。

那麼怎麼辦？

我一直在想怎麼樣能夠讓大家沒白來這次的分享，所以我特意把我之前對整個運維自動化分享的內容重新提煉總結，通俗點的說就是更接地氣，我節選了我們這麼多年做運維自動化裡面最重要的一些功能模組。

所以今天不會給大家介紹一個很龐大的系統，我會專門去講自動化裡最核心的環節（CMDB分層、技術架構及後續落地辦法等等），說不定大家做了這些核心環節，就能提升到很高效的水平。

一、運維自動化的能與不能

今天的分享主要有三部分，前兩部分會重點跟大家講一下，我們做運維自動化之前，應該具備什麼樣的理念。無論是運維還是開發這兩個角色，其實都需要去遵循這樣一些俗稱的標準化，我們的規範是什麼？基於這樣的一些規範，我們怎麼把我們的自動化落地。

自動化不是萬能的，並不是所有的場景都適用。運維自動化也是一樣，在騰訊體量很小的時候，我們就一直琢磨著要怎麼樣高效運維。

因為騰訊的社交產品是樹狀結構，小的一些應用特別多。只有核心的幾個像QQ相簿、QQ空間、QQ音樂體量特別大，其他都是很碎片的小應用，如果這些小應用雜亂無章的生長，怎麼規範化它？在它發展的時候我們的運維效率又能跟上。

去年6月份，騰訊整個集團的物理機剛剛突破50萬，我們運維團隊的人增幅遠沒有伺服器增長的快。

我們先來看一下自動化想解決什麼樣的問題？

上面這些挺有意思的話節選於我們團隊內部：比如文件即過期，我們做運維的，老闆整天希望我們寫一些所謂的運維文件，這個文件寫出來的時候其實就意味著它已經過期了。

還有一些資深同事離職，經驗也就消失了，這些都希望在自動化裡解決。還有邏輯的解耦、微服務，寫死IP，或者有必要的切換等，這些肯定是在做運維自動化的時候不希望去觸的雷區，還包括包括人為同時的失誤、架構的失控等等。

我們怎麼樣提出標準化規範？讓我們的研發團隊、運維團隊更高效合作，避免出現誤區？

做自動化不是為了炫酷，不能為了自動化而自動化，20%的工作消耗了我們80%的精力，我們只要集中精力把那20%的工作做好基本上就可以達到很好的狀態了，就可以釋放精力去做大資料、做智慧化運維，而不是說什麼場景都要追求到完完全全的極致。

我們團隊內部，大家都會經常說一句話，任何事情做到80分，我們投入半年就夠了。但是要把另外20分做完，可能要投入的時間遠大於那80分，所以這時候，我也是希望大家在回去規劃自己的運維自動化場景的時候，能夠著重思考這一點，哪個優先去做。

我們給我們的運維自動化下了一個定義，做任何事情之前，首先清楚我們的目標：在大規模運維場景下，將重複度高的工作，基於監控資料智慧決策觸發，實現無人蔘與的自動操作的運維能力，稱之為運維自動化。

這裡很重要的是無人蔘與，目前我們的平臺是可以做到無人職守擴和縮，今天就跟大家介紹怎麼實現的。

再次回到業務場景，在騰訊的社交業務場景下，海量、敏捷、複雜高可用上面都有一些具體的描述，這也是在中國這麼大的使用者群體下所有社交產品的一個普遍表現形態。

二、DEV與OPS：求同存異

在這樣一個海量的業務壓力下，我們怎麼樣跟我們的開發人員、運維人員去共同定製我們能夠落地實現的標準化運維方案？

在2008年、2009年的時候，我們當時提D/O分離，但我一直覺得D/O分離有點自己坑自己的味道，你開發好程式給我你就不用幹了，我含著淚都要把這個幹好。

一個架構很差的程式，我們沒有辦法把它維護得很高效。

在騰訊社交這個產品線，我們現在功能模組有5000多個，底下對應的微服務得上好幾萬個，這種情況是沒有辦法維護一些架構很差程式程式碼的。

在當時2010年的時候，DevOps的概念還沒有提出，我們已經意識到這個問題，所以當時就已經開發了織雲這個平臺，當它真正的跟DevOps這個理念對齊的時候是不謀而合的。

只有合作才能走得更快，才能在激烈的網際網路紅海競爭下取得勝利，怎麼去做？

我們把開發和運維有可能打交道的地方分成四大塊：首先是架構。

運維很關注架構，不然沒辦法評估它的質量好壞跟架構有沒有直接的關係。運維希望開發遵守我們的規範。

之前我跟一些傳統行業的同行也有過交流，他們寫了很多規範開發不能做，這些都是流於形式，沒有辦法實實在在的去要求。

為此，我們帶著這樣的問題，一起來看一下騰訊是怎麼實踐的。

我們推崇的統一架構、運維規範，怎麼作用到開發人員的身上？然後基於這樣的統一的規範，如何能夠去打造運維的工具系統，讓它實現自動化？

基本上所有的網際網路業務架構，我們都是可以用上圖來簡單概括，分為客戶端，使用者用的終端、PC，中間是運營商，然後三層架構：接入層、邏輯層、資料層。

騰訊整個社交，大概是分成這個樣子，針對同樣的架構，我們就開始提出管理理念：框架化、元件化、無狀態、分散式。

我們的框架化是怎麼落地的？

在騰訊社交這邊，我們的業務開發整個技術棧，基本上都是用C為我們的主要開發語言，不是用Java，所以說沒有辦法基於Java無痛注入的方案做APM，我們必須對開發的技術習慣設計更適合我們的框架。

為此，我們針對Socket通訊把CS架構的服務端，按照公共的功能專門用來通訊、收發包，些能力變成一個框架。業務開發只需要專注寫它的業務邏輯，實現我們的框架。

在騰訊基本上我們有支援同步的開發框架、支援非同步的開發框架，還有Web服務的一些應用，都是有通用的框架來支援的。

再講就是元件化，這裡也有一個例項。假設我們現在要上一個網站，必須要有一個Web Server，不同的開發團隊會有不同的選擇，有人說Apache效能好，有人說NGINX比Apache強，有人說我用IIS，有人說那三個都是垃圾，我自己寫的是最好的。

很不幸，這個事情如果在2009年之前在騰訊確實是這樣子的，百花齊放，這就導致我們沒有辦法維護。對運維來說，100個不同的Web Server我就要選擇100次。

為什麼我們不能要求一致？我們站在元件化的高度及要求下，同一種應用場景只能選一個，這次才能針對這種元件化去做到極致。

說完我們的一些框架化、元件化的舉例，通過提出了這樣一些要求，我們運維團隊讓我們每一個業務開發，開發出來的架構都基本上長成上面的樣子了。還有一些元件TGW、L5這些東西沒有介紹到，大家可以在搜尋引擎上查到之前的分享。

今天我特別希望把這個理念跟大家完整闡述一遍。當我們的業務架構的層級都長成這個樣子的時候，我們無論是對它做自動化運維也好，做監控也好，都很方便。

剛剛上一個老師提到一點我覺得很有啟發，一款應用我們應該怎麼樣去度量它？指標是怎麼樣子的？

騰訊內部是直播年。騰訊自己也在做直播，我們社交的直播光是APP估計兩個數手不完，各種開發團隊都在做直播，不同的直播怎麼度量？

所以這時候，運維團隊就佔了很重要的決定性的作用。我出來說直播的質量、體系就應該這麼看，我就給你定好了這種指標。

我覺得有很多事情，不是說技術好或不好，而是看誰來做更合適。這時候運維作為一個公共的支撐的團隊，它更有這種權利或者說它更應該去規範這樣的東西，讓我們對同質的業務場景可度量。

前面兩個部分，把我們的理念講完了。我們要怎麼樣去落地？細節是什麼樣子的？下面有一個全域性的圖。

在我們社交運維團隊，我們主要的運維產品有四大塊：一個是織雲，主要負責運維自動化方向，還有一個天網，還有我們的報表體系，專門用來做我們可度量的。最後還有一個手機運維MSNG，這裡麵包含了很多子的系統，今天主要是講織雲裡面的一小部分。

三、運維自動化的技術細節

今天著重介紹織雲，並且是織雲最核心的功能點。有了標準化以後要做很多事情，才可以很輕鬆的實現運維工作的自動化。

光是在運維自動化裡面，大家都說標準化、運維規範，那究竟是什麼？今天特別想跟大家一起開啟這個黑匣子，看一下騰訊運維的標準化是怎樣的？

我們把業務架構又切分成不同的層，其實就是剛剛那個圖的另外一種表現形式。五層，不同的層級，我們要做的標準化針對的物件不同的。

就像我們的裝置層什麼是標準？統一的機型、計算型的、記憶體型的、SSD，你是用關係型資料庫，要用什麼機型，要用大硬碟的，你是做Web Server的，記憶體標配一個就可以了。

特別是在虛擬化的今天，如果任由一個業務隨意去選擇它的機型，對於我們來說就是多了一種物件。在騰訊這麼大的體量下我們沒有辦法容忍隨隨便便給我多增加一個運維物件。

所以我標紅了幾個字，就是要減少運維物件。像其他的業務層，你是IM型的應用，架構分佈必須要三地、三活，QQ排程方案跟Q Zone的排程方案必須是一樣的。所以我們做的一切的一切都是要減少運維物件。

減少完運維物件怎麼去執行？在開發前，把整個產品的生命週期分成這麼幾塊，在開發前、上線前、上線中、運營中，不同階段，考慮的點不一樣。

開發前，知道業務形態長成什麼樣，可能用到什麼樣的元件、什麼樣的框架，這個時候基本上杜絕了寫死IP的念頭，或者對本地儲存特別敏感的情況。

其實我只是寫出來，在真正運維工作中並沒有說每次上線一個產品我們都去評審，時間也耗不起。

當我們形成了這樣一個開發和運維合作的文化之後，開發團隊自己就會遵守了，並且在不同的階段，我們提出了不同的要求。每個要求都會對應了我們運維的一個工具系統，去支撐它，就是說我們的標準化可以落地了。

再來看基於我們網際網路業務的架構層分層的特徵，針對不同層次的物件去建設對應維護物件的系統，這些系統所產生的資料都把它結構化落地到我們的配置管理CMDB裡面，這個CMDB就在整個運維自動化的過程中扮演了一個很核心的地位。

CMDB層是什麼東西？

我們開發和運維先天性就有一些思考模式的不同。我們在CMDB中提出了一個概念，就是模組概念。為什麼要有模組這個概念？可能開發人員看到他自己寫的一套程式碼，這套程式碼對他來說部署在一個地方和部署在三個地方都是一套程式碼。

但是對於騰訊來說，我們所有核心服務都是三地三中心，對於使用者來說，天津的使用者量跟深圳的使用者量不一樣，北方的使用者跟南方的使用者量不同，容量不同，準備的裝置數量就不同，提前規劃的機房也不一樣。

這時候我們就提出了一個概念，就是模組。這個模組必須要按照運維的命名規則去定義它，存我們固定資產的資訊，硬體配置、軟體配置、運營設定，還有資源配置、流程配置、測試用例等。

存這些東西有什麼用？

如果CMDB一下子就能看到我們整個QQ的某一個功能，分佈在天津、上海、深圳的容量分佈圖，或者說記錄了這個模組的測試用例。那麼，我們在做自動化的時候，我把它部署完就可以自動調它的測試用例，自動測試然後上線。實現這個目的，都是為了自動化做鋪墊。

1、織雲的運維思想

前面我們一直講思想講理念，前面兩個部分介紹了標準化，以及標準化怎麼變成我們的配置化，變成配置化之後最後一步就是實現自動化。

實現自動化的過程，技術上看似很簡單，無非就是把一堆結構化的資料通過配置，通過一些自動化的手段或者寫批量的指令碼，全部傳上機器把它還原就可以了。

現在業界比較流行Docker，Docker的口號是BUILD、SHIP、RUN（構建、傳輸、傳上生產環境執行起來），但是事實上有沒有這麼理想化？

上圖是我們在騰訊每一個釋出要做的事情。事實上我框起來的這些內容Docker並沒有幫我們解決的，編入業務許可權怎麼申請，這個可能很有騰訊特色。

大家都知道，騰訊很多業務都是生長在QQ這樣一個關係鏈體系下的，並不是所有的業務都有許可權去拉QQ關係鏈的。訪問QQ關係鏈必須要經過一個授權，這個是映象部署解決不了的問題。但是我們織雲平臺必須要解決這樣的事情。

此外還有一些Docker解決不了測試的問題，比如有人說我直接在測試環境測好打成一個映象，這可以。

但是，我們QQ有些大叢集上千臺機器，每發一次都重啟一次嗎？這也不現實。測試怎麼解決？灰度怎麼解決？最後怎麼上線？Docker也沒有解決上線的問題。我們網站型的應用，最後還是要加到域外解析，加到DNS。怎麼辦？

為了解決它，所以我們內部整理了一個最適合騰訊社交的流程，如下圖。

我們把整個自動部署的過程抽象成六大步，但其實分解開來是有23步，我們為了相容帶著業務特色的部署釋出，帶著我們運維要求的一些部署釋出，還必須要有一個測試的環節，必須要有灰度的環節，最終完成上線。

我們把我們的自動化的流程抽象成23步放在我們的資源平臺，但是資源平臺究竟起到一個什麼樣的作用？或者說它的特別之處在哪裡？我們是用了七大點把它總結出來，如下圖。

首先它是要能傳承的，所有的運維經驗都是一種配置項資源存在CMBD裡面，並且需要提出了很多標準，這些標準落地在我們管理不同物件的運維繫統裡面，最終是協作的。

這麼多個特徵組成整個織雲的技術架構，我今天都不講了，因為我覺得不需要這麼多複雜的東西。

2、運維自動化的核心元件

接下來想跟大家深入一點的去交流自動化運維最核心的CMDB、流程系統，把我們的一個一個的工具通過我們的傳輸通道能串起來。

只要你實現了這些，你的運維效率就提高很多，不需要完全自動化，不需要無人職守。為什麼要無人職守？本來就500臺機器，10個人，每個人50臺機器是很容易。

上圖是我們最重要的CMDB的技術架構，歸根結底就是一個關係型的資料庫。

我們要存哪些配置項來設計表的結構，並且可以提供介面化，讓我們的工具系統可以排程。

如果要做部署包的系統，首先要知道操作的物件是誰？這個物件的模組名是誰？我剛才提到很重要一點，我們統一了開發和運維的語言，操作這個模組每次部署需要裝哪些包？發哪些配置？近期都存在我們的CMDB資料庫裡面，拉出來調我們的流程系統，調我們的傳輸工具，把這些資源推到我們的生產環境。

推完之後，要啟動流程系統、啟動步驟、測試步驟、灰度步驟、上線步驟，一步一步串起來。這就是為什麼說自動化運維很重要的一個核心就取決於我們有什麼樣的一些料可以做這道菜。

接下來是流程系統，現在業界沒有一些特別適用的開源方案，但是我們還是在做流程系統，今年又在做一版新的，希望做得更強壯。

假設我們寫了100個指令碼，只是一個大的指令碼，把這100個指令碼串起來就是我們流程系統。

它可以通過一定的資料觸發執行，什麼時候這個流程跑什麼樣的工具都是有一些決策的，或者說當某個工具失敗了，究竟是重試還是跑分支流程，還是說終止告警，這就是我們的流程系統。

我們之前提供了一些函式頭，裡面的工具寫好自己的邏輯，能夠通過一些公共輸入輸出的函式方法，讓這個工具本身處理完的輸入輸出能夠被流程理解，能夠傳給下一個工具。

主要核心就是做了這樣一個事情，架構做成什麼樣子不重要，所以今天我畫的是原理，並不是架構。如果大家想看流程系統的架構，可以搜一下我以前分享過的運維自動化的PPT，裡面有那個架構。

最後是傳輸通道，怎麼樣讓流程串起來？

最終要操作生產環境的時候要怎麼樣做？在騰訊我們用一個C/S的架構來實現我們叫做命令通道的東西，可以傳檔案，可以執行命令。

大家寫一個C/S，自己配一個協議，傳一堆檔案，它能解析指令、執行，找到對應的檔案執行完，這個就是我們的傳輸通道最基礎的一些功能。

但是傳輸功能是不是僅僅這麼簡單就足夠了？

基於安全性考慮，我們還需要去關注我們的源IP許可權，防止被黑客攻擊變成肉機之後，隨意發起批量操作，有損大廠名譽。

其次是使用者身份的健全，QQ的運維不可能操作QQ音樂的裝置，當然如果兼崗是可以的。我們會對執行的命令做一些解析，防止高危操作，防止某個人失戀了要刪資料庫走人。

還有約束目標的IP，對我們生產環境管理的理念是息息相關的，少數的像系統運維，因為他負責整個10萬臺機器，一次1萬臺也要分10次處理，而不是說一個命令把10萬臺搞定，因為人總會犯錯的。

做完這些CMDB流程系統，還有傳輸通道，如果大家所在企業的規模或者你所管理的裝置量不大的話，效率已經提到很高了。

大家可以想一下，我要操作的物件都存在配置管理裡面，配置好一個流程做執行，就是先安裝包，再去啟動相關的包，再把測試程式呼叫一下，把灰度接入兩臺在域名上，然後去驗證一下沒有問題，然後再接著全量上線。我們點幾下按紐就解決了，不需要完全無人職守。

但是在騰訊這個體量還是不夠，所以我們做了無人職守，做了無人職守還要做到這七點：你的裝置怎麼管理？究竟怎麼樣決策？應該用哪個裝置？

還有我們的智慧決策，依賴什麼樣的資料決策，應該起什麼樣的流程？

假設我們有一個Web層有10臺機器同時掛了8臺，當只掛了一臺時我們可以不馬上發告警，因為有一個決策系統在。

我知道Web層的機器無狀態，我直接重啟它把它踢下線，但是又掛、又掛，掛了5臺時候決策系統就可以做一個決策，它的IP數量超過30%的不可用的時候，不能夠再不發通知了，這個時候就應該發通知給運維人員，讓人來干預這個事情，這是我們的智慧決策。

還有我們的自動測試、灰度放量。

灰度放量基於怎樣的策略來灰度放量是灰度管理系統考慮的。還有變更體檢，有沒有基礎指標，CPU，你新上線的裝置是不是跟現在裝置CPU曲線吻合，或者說有沒有一些業務監控能夠告訴我，這就是變更體檢要做的一些事情。

還有日誌通知，自動化系統跟監控系統聯動的時候，就像做一個變更，那邊有業務告警，這兩個資料一關聯起來，可能業務告警就不發了，那個取決於監控系統那邊告警策略建設。

3、實戰案例

做完了這七點，可以實現什麼狀態？上面是騰訊QQ會員的一個真實案例，大家如果有用騰訊的產品肯定都收過騰訊給你推的紅點。

有些人處女座一定要點那個紅點，馬上請求量就來了。這一點對於運維來說就是一個惡夢，如果沒有提前準備容量，業務請求量就會飆高。

但是在無人守職的運維能力下，你也什麼都不用做。你會收到一條簡訊提醒，無論是聊天工具的彈框，還是手機簡訊提醒你，現在正在有一個自動擴容在執行，它自己就跑完了整個流程。

因為我們把最核心的那三個部分，還有輔助它能實現最後一步七步做完，在自動化這一塊是可以說走在到了人生的巔峰。

最後想跟大家一起小結一下：今天分享的主題沒有把它鋪得特別大，大家回去可以看一下，我們有什麼樣管理物件可以做成標準化，要怎麼樣把它框起來，框起來之後針對這種標準的場景怎麼樣做到最高效的運維。

我們的標準化、配置化，再把流程系統，把我們對標準物件要做的一切連線起來，最終就可以實現我們的運維自動化。好了，今天的分享講完了，謝謝大家。