本文來自騰訊社交多媒體業(yè)務(wù)負(fù)責(zé)人@梁陵水（大梁）在聽云的同名主旨演講。 工作變成手工。

今天和大家分享的話題是如何做手工運維。

之前大家可能聽我介紹過智云平臺是怎么工作的。 最近在想一件事，比如騰訊的體量（QQ月活8.3億，DAU 8.3億）和海量運維的壓力。 自動化運維平臺如果真的放在一些中小企業(yè)，用處不大。

那怎么辦呢？

還在琢磨怎么才能不讓大家白白分享這一次，所以特意把之前分享的手動運維上的內(nèi)容重新提煉總結(jié)了一下。 多年來，上述一些最重要的功能模塊一直由人工操作和維護。

所以明天我就不給大家介紹一個非常龐大的系統(tǒng)了。 我會專門講一下手工化中最核心的環(huán)節(jié)（CMDB分層、技術(shù)架構(gòu)、后續(xù)實現(xiàn)方式等），說不定那些核心環(huán)節(jié)你都做了，你的效率就會提升到一個很高的水平。

1. 人工運維的能與不能

明天的分享主要有三個部分。 前兩部分會著重告訴大家在做手工運維之前我們應(yīng)該有什么樣的概念。 不管是運維還是開發(fā)這兩個角色，雖然都需要遵守這樣的規(guī)范，但是我們的規(guī)范是什么？ 基于這樣的規(guī)范，我們?nèi)绾螌崿F(xiàn)我們的手動實現(xiàn)。

手動化不是萬能的，并不是所有場景都適用。 人工運維也是如此。 騰訊小的時候，我們還在思考如何高效的運維。

由于騰訊的社交產(chǎn)品是樹狀結(jié)構(gòu)，因此有很多小應(yīng)用。 只有QQ相冊、Q空間、QQ音樂這些核心的非常大，其他都是很零散的小應(yīng)用。 如果這樣的小應(yīng)用無序增長，如何規(guī)范？ 當(dāng)它發(fā)展起來的時候，我們的運維效率才能跟上。

今年6月，騰訊整個集團的化機數(shù)量剛剛突破50萬臺。 我們運維團隊的增長速度遠(yuǎn)不及服務(wù)器。

我們先來看看人工化要解決什么樣的問題？

里面有意思的話摘自我們團隊內(nèi)部：比如文檔過期了，我們做運維，老大要我們整天寫一些所謂的運維文檔。 這份文件寫出來的時候，似乎意味著它已經(jīng)過期了。

也有一些資深朋友辭職了，經(jīng)驗就沒了。 都是希望人工解決的。 還有邏輯前饋，微服務(wù)，硬編碼IP，或者必要的切換等等，這絕對是你在做人工運維的時候絕對不想觸碰的雷區(qū)，同時包括人為錯誤。 、失控結(jié)構(gòu)等。

我們?nèi)绾翁岢鰳?biāo)準(zhǔn)化規(guī)范？ 讓我們的研發(fā)團隊和運維團隊更高效的合作，防止誤會？

規(guī)范化不是為了眼花繚亂，也不能為了規(guī)范化而規(guī)范化。 20%的工作消耗了我們80%的精力。 只要集中精力把那20%的工作做好，基本就能達(dá)到好的狀態(tài)。 你可以釋放你的精力去做大數(shù)據(jù)和智能運維，而不是說所有的場景都要追求到極致。

在我們團隊里面，大家經(jīng)常會說一句話，我們做任何事情做到80分，半年就夠我們投入了。 而要完成另外的20分鐘，可能比80分鐘的時間要少很多，所以這個時候，也希望大家回家規(guī)劃自己的手工運維場景時，能夠注意這一點。 這是當(dāng)務(wù)之急。

我們已經(jīng)定義了我們的手動操作和維護。 做任何事情之前，首先要明確自己的目標(biāo)：在大規(guī)模運維場景中，基于監(jiān)控數(shù)據(jù)的智能決策，觸發(fā)高重復(fù)性任務(wù)，實現(xiàn)無人參與，人工操作的運維能力稱為人工操作和維護。

這里重要的是沒有人參與。 目前，我們的平臺可以在無人值守的情況下進行擴容和縮容。 明天，我將介紹如何實現(xiàn)它。

再回到業(yè)務(wù)場景，在騰訊的社交業(yè)務(wù)場景中，在海量、敏捷、復(fù)雜、高可用上有一些具體的描述，這也是國內(nèi)所有擁有如此龐大用戶群體的社交產(chǎn)品的共同體現(xiàn)。

2. DEV與OPS：求同存異

在如此巨大的業(yè)務(wù)壓力下，我們?nèi)绾闻c我們的開發(fā)人員和運維人員共同訂制一個我們可以實施的標(biāo)準(zhǔn)化運維解決方案？

2008年和2009年的時候，我們當(dāng)時就提到了D/O分離，但是我還是覺得D/O分離有點弄巧成拙。 如果你把程序開發(fā)出來交給我，你就不用做了。 我眼里含著淚水。 完成這件事。

結(jié)構(gòu)不良的程序無法有效地維護它。

在騰訊的社交產(chǎn)品線，我們現(xiàn)在有超過5000個功能模塊，對應(yīng)的微服務(wù)有上萬個。 在這些情況下，沒有辦法維護一些結(jié)構(gòu)不良的程序代碼。

那個時候2010年，概念的概念還沒有提出來，我們就已經(jīng)意識到了這個問題，所以我們當(dāng)時就已經(jīng)開發(fā)了智云平臺，真正對接這個概念的時候，恰逢用它。

只有合作，才能在激烈的互聯(lián)網(wǎng)紅海競爭中走得更快，才能勝出。 怎么做？

我們把開發(fā)和運維可能涉及到的地方分為四大塊：第一塊是架構(gòu)。

運維很關(guān)心架構(gòu)，否則沒辦法評估它的好壞是不是和架構(gòu)有直接關(guān)系。 Ops 希望開發(fā)違背我們的規(guī)范。

之前也和一些傳統(tǒng)行業(yè)的同事交流過。 他們寫了很多無法完成的規(guī)范開發(fā)。

因此，帶著這個問題，我們來看看騰訊是如何實踐的。

我們提倡的統(tǒng)一架構(gòu)和運維規(guī)范，對開發(fā)者的面子有什么影響？ 那么基于這樣一個統(tǒng)一的規(guī)范，我們?nèi)绾螛?gòu)建一個運維工具體系，使其成為手冊呢？

基本上所有的互聯(lián)網(wǎng)業(yè)務(wù)架構(gòu)都可以用上圖簡單概括，分為客戶端、用戶終端、PC、中間的運營商，以及以下三層結(jié)構(gòu)：接入層、邏輯層、數(shù)據(jù)層.

騰訊整個社交網(wǎng)絡(luò)大致是這樣劃分的。 同樣的結(jié)構(gòu)，我們開始提出管理理念：框架化、組件化、無狀態(tài)、分布式。

我們的框架是如何實現(xiàn)的？

在騰訊社交上，我們整個業(yè)務(wù)開發(fā)的技術(shù)棧基本上都是以C作為主要開發(fā)語言，而不是Java，所以沒有辦法基于Java無痛注入來做APM。 技術(shù)習(xí)慣設(shè)計更適合我們的框架。

所以在通信上，我們使用CS架構(gòu)的服務(wù)器，根據(jù)公共功能進行通信、收集和分包，將這些能力做成一個框架。 業(yè)務(wù)開發(fā)只需要專注于編寫其業(yè)務(wù)邏輯和實現(xiàn)我們的框架即可。

基本上在騰訊，我們有一個支持同步的開發(fā)框架，一個支持異步的開發(fā)框架，還有一些Web服務(wù)的應(yīng)用，都是一個通用的框架來支持。

再來說說組件化，這里也舉個例子。 假設(shè)我們現(xiàn)在要上一個網(wǎng)站，必須有一個Web，不同的開發(fā)團隊會有不同的選擇，有的說性能好，有的說NGINX好，有的說我用IIS，有的說這三個都是垃圾，我自己寫的是最好的。

不幸的是，如果這件事在2009年之前在騰訊確實是這樣，百花齊放，讓我們無法維護。 為了運維，我要選擇100個不同的網(wǎng)站100次。

為什么我們不能要求一致？ 我們站在組件化的高度和要求上，只能選擇一種應(yīng)用場景。 這一次，我們可以將這些組件化做到極致。

說完我們的一些框架和組件化的例子服務(wù)器運維技術(shù)，通過提出這樣的需求，我們的運維團隊讓我們的每一個業(yè)務(wù)開發(fā)，開發(fā)出來的框架基本上就是里面的樣子。 還有一些組件如TGW和L5沒有介紹。 可以在搜索引擎上找到之前的分享。

明天我非常希望能和大家充分討論這個概念。 當(dāng)我們的業(yè)務(wù)架構(gòu)層級長成這樣的時候，無論是手動運維還是監(jiān)控，都非常方便。

剛才一位老師提到了一件讓我覺得很有啟發(fā)的事。 我們應(yīng)該如何衡量應(yīng)用程序？ 指標(biāo)是什么樣子的？

今年是騰訊內(nèi)部的直播年。 騰訊自己也在做直播。 僅靠我們的社交直播應(yīng)用程序可能還不夠。 各個開發(fā)團隊都在做直播。 不同的直播如何衡量？

所以這個時候，運維團隊就起到了非常重要和決定性的作用。 我下來就是說，直播的質(zhì)量和系統(tǒng)應(yīng)該是這樣看的，這些指標(biāo)我都給大家定好了。

我覺得很多東西，不是說技術(shù)好壞，而是看誰更適合去做。 這個時候侯運維作為一個公共支撐團隊，權(quán)力更大或者應(yīng)該規(guī)范這樣的事情，讓我們?nèi)ズ饬客|(zhì)化的業(yè)務(wù)場景。

接下來的兩部分完成了我們的理念。 我們要怎么著陸？ 細(xì)節(jié)是怎樣的？ 下面有一張全局圖。

在我們的社會運維團隊中，我們主要的運維產(chǎn)品有四大部分：一個是智云，主要負(fù)責(zé)人工運維的方向，還有一個天網(wǎng)，還有我們的報表系統(tǒng)，是專門做用來做我們可以測量的。 最后是手機運維MSNG，里面包含了很多子系統(tǒng)。 明天主要講智云的一小部分。

3、人工運維技術(shù)細(xì)節(jié)

明天我們重點說說智云，這是智云的核心功能點。 標(biāo)準(zhǔn)化之后，需要做很多事情，這樣就可以輕松實現(xiàn)人工運維工作。

說到人工運維，大家都在講標(biāo)準(zhǔn)化、運維規(guī)范。 它們到底是什么？ 明天真想和大家一起打開這個黑匣子，看看騰訊運維的標(biāo)準(zhǔn)化程度如何？

我們把業(yè)務(wù)架構(gòu)分成不同的層次，雖然是剛才的圖的另一種表達(dá)方式。 五層，不同的層次，我們要做的標(biāo)準(zhǔn)化是針對不同的對象。

像我們的設(shè)備層有哪些標(biāo)準(zhǔn)？ 統(tǒng)一型號，計算型，內(nèi)存型，SSD，你用的是關(guān)系型數(shù)據(jù)庫，你要用什么型號，你要用大硬盤，你是做web的，標(biāo)準(zhǔn)顯存就夠了。

尤其是在當(dāng)今這個虛擬化的世界里，如果讓一個企業(yè)可以隨意選擇它的模式，對我們來說將是一個額外的工具。 騰訊這么大的體量，容不得我多掉一個運維對象。

所以我用紅色標(biāo)注了幾個字，就是減少運維對象。 和其他業(yè)務(wù)層一樣，你是一個IM類的應(yīng)用，架構(gòu)肯定是三地三活分布的。 QQ的調(diào)度方案必須和QQ空間一致。 所以我們所做的一切都是為了減少運維對象。

減少運維對象后如何實現(xiàn)？ 在開發(fā)之前，整個產(chǎn)品生命周期被分成幾個部分。 開發(fā)前、上線前、上線中、運營中，在不同的階段考慮不同的點。

開發(fā)前要知道業(yè)務(wù)形態(tài)是什么樣的，可能用到什么樣的組件，什么樣的框架。 這時候硬編碼IP的想法或者對本地存儲很敏感的情況基本就避免了。

雖然只是記下來了，但是在真正的運維工作中，我并沒有說我們每次上線產(chǎn)品都要，時間不夠用。

當(dāng)我們形成了這樣一種開發(fā)和運維合作的文化之后，開發(fā)團隊就會跟進，只是在不同的階段，我們提出不同的要求。 每一個需求也會對應(yīng)一個我們運維的工具體系來支持它，也就是說我們的標(biāo)準(zhǔn)化是可以落地的。

下面看一下我們互聯(lián)網(wǎng)業(yè)務(wù)架構(gòu)層的分層特點，針對不同層級的對象構(gòu)建對應(yīng)維護對象的系統(tǒng)。 該系統(tǒng)形成的數(shù)據(jù)將在我們的配置管理CMDB上進行結(jié)構(gòu)化和實施。 這個 CMDB 在整個人工運維過程中起到了非常核心的作用。

什么是CMDB層？

我們的開發(fā)和運維在思維模式上有著本質(zhì)上的不同。 我們在CMDB中提出了一個概念，就是模塊的概念。 為什么會有模塊的概念？ 也許開發(fā)者聽到了自己寫的一組代碼。 對他來說，這套代碼部署在一處，部署在三處。

但是對于騰訊來說，我們所有的核心服務(wù)都是三地三中心。 用戶方面，上海的用戶數(shù)量與北京不同，南方的用戶數(shù)量和容量也與北方不同。 數(shù)量不一樣，提前規(guī)劃的機房也不一樣。

這時候，我們提出了一個概念，就是模塊。 這個模塊必須按照運維的命名規(guī)則來定義，存儲我們的固定資產(chǎn)、硬件配置、軟件配置、運行設(shè)置、資源配置、流程配置、測試用例等信息。

存這種東西有什么用？

如果CMDB可以一下子看到我們整個QQ的某個功能，分布在北京、上海、深圳的容量分布圖，或者記錄下這個模塊的測試用例。 這樣我們在做手動化的時候，我可以在部署之后手動調(diào)整它的測試用例，手動測試完之后上線。 要實現(xiàn)這個目標(biāo)，無非就是為手工化做鋪墊。

1、智云的運維思路

后面還是會講思路和概念。 接下來兩部分介紹了標(biāo)準(zhǔn)化以及如何將標(biāo)準(zhǔn)化做成我們的配置，然后最后一步就是實現(xiàn)手動化。

手動化的過程在技術(shù)上似乎很簡單。 無非就是配置一堆結(jié)構(gòu)化的數(shù)據(jù)，用一些手工的手段或者寫批處理腳本，全部上傳到機器上恢復(fù)。

現(xiàn)在業(yè)界比較流行，口號是BUILD、SHIP、RUN（構(gòu)建、傳輸、上傳到生產(chǎn)環(huán)境執(zhí)行），但實際上真的有那么理想嗎？

上圖是我們在騰訊每次發(fā)布的時候做的。 其實我陷害的內(nèi)容并沒有幫助我們解決問題。 怎么申請業(yè)務(wù)權(quán)限，可能是騰訊很有特點的。

大家知道，騰訊的很多業(yè)務(wù)都是在QQ的關(guān)系鏈系統(tǒng)下發(fā)展起來的，并不是所有的業(yè)務(wù)都有拉QQ關(guān)系鏈的權(quán)限。 訪問QQ關(guān)系鏈必須經(jīng)過授權(quán)，這是鏡像部署無法解決的問題。 而我們智云平臺必須要解決這樣的事情。

據(jù)悉，測試中還有一些問題無法解決。 比如有人說我直接在測試環(huán)境下測試，做了個鏡像，就可以了。

但是我們QQ有一些大集群，上千臺機器。 每次發(fā)送都會重啟嗎？ 這也不現(xiàn)實。 測試結(jié)果如何？ 怎么解決灰度問題？ 到底如何上網(wǎng)？ 也沒有解決上網(wǎng)的問題。 對于我們網(wǎng)站類的應(yīng)用，還是需要加入外域解析，加入DNS。 怎么做

為了解決這個問題，我們內(nèi)部整理了一個最適合騰訊社交的流程，如右圖所示。

我們將整個手動部署過程可視化為六大步驟，但分解下來畢竟有23個步驟。 為了兼容業(yè)務(wù)特性的部署發(fā)布，我們帶上一些我們運維需要的部署發(fā)布，而且還要有測試環(huán)節(jié)，要有灰度環(huán)節(jié)，最后完成上線。

我們將我們的手工流程可視化為23個步驟，并將其放在我們的資源平臺上，資源平臺起到什么作用？ 或者它有什么特別之處？ 我們用七大要點來概括，如右圖所示。

首先，它必須能夠推廣。 所有運維經(jīng)驗都是存儲在CMBD上的一種配置項資源，需要提出很多標(biāo)準(zhǔn)。 這個標(biāo)準(zhǔn)是在我們管理不同對象的運維系統(tǒng)上實現(xiàn)的，最終是協(xié)同的。

這么多特性構(gòu)成了智云的整個技術(shù)框架，今天就不講了，因為我覺得不需要那么多復(fù)雜的東西。

2. 人工運維核心組件

想和大家深入交流一下核心CMDB和人工運維的流程體系，通過我們的傳輸通道，把我們的工具一一對接起來。

只要做到這一點，你的運維效率就會提高很多，不需要完全人工或者無人化。 為什么要無人值守？ 本來500臺機器，10個人，一個人50臺機器很輕松。

上圖是我們CMDB最重要的技術(shù)框架，歸根結(jié)底是關(guān)系型數(shù)據(jù)庫。

我們需要保存什么配置項來設(shè)計表的結(jié)構(gòu)，但是我們可以提供，這樣我們的工具系統(tǒng)就可以調(diào)度了。

想要部署一個包系統(tǒng)，首先要知道運行的對象是誰？ 這個對象的模塊名稱是什么？ 我剛剛提到了一個非常重要的點。 我們統(tǒng)一了開發(fā)和運維的語言。 我們需要為這個模塊的每個部署安裝什么包？ 發(fā)送什么配置？ 最近入駐我們的CMDB數(shù)據(jù)庫，拉低調(diào)整我們的流程系統(tǒng)，調(diào)整我們的傳輸工具，把這個資源推送到我們的生產(chǎn)環(huán)境。

推送之后，需要啟動流程體系，啟動步驟，測試步驟，灰度步驟，上線步驟，一步一步來。 這就是為什么人工運維的核心很重要，就看我們用什么樣的材料來做這道菜了。

下一步是工藝系統(tǒng)。 目前業(yè)界還沒有非常合適的開源方案，我們還在做流程體系。 去年，我們做了一個新版本，希望讓它更健壯。

假設(shè)我們寫了100個腳本，就一個大腳本，把這100個腳本串起來就是我們的流程體系。

它可以由某些數(shù)據(jù)觸發(fā)，有一些決定在什么時候在流程中運行哪些工具，或者當(dāng)一個工具失敗時，是否重試或者運行分支流程，或者停止報警，這就是我們的流程系統(tǒng).

我們之前提供了一些函數(shù)頭。 上面的工具可以自己寫邏輯，通過一些公共的輸入輸出函數(shù)，讓工具自己處理的輸入輸出可以被進程理解，傳遞給下一個工具。

主要核心就是做這么一個東西，結(jié)構(gòu)長什么樣都無所謂，所以明天畫的是原理，不是結(jié)構(gòu)。 如果想看流程體系的結(jié)構(gòu)，可以搜索我分享的手動運維PPT，就是那種結(jié)構(gòu)。

最后是傳輸通道，如何讓進程流起來？

終于要運營生產(chǎn)環(huán)境了怎么辦？ 在騰訊，我們用一個C/S的框架來實現(xiàn)我們所說的命令通道，可以傳輸文件，執(zhí)行命令。

你寫一個C/S，自己配置一個合約，傳一堆文件。 它可以解析指令，執(zhí)行它們，找到相應(yīng)的文件并執(zhí)行它們。 這些是我們傳輸通道的一些最基本的功能。

傳遞函數(shù)就這么簡單還不夠嗎？

基于安全考慮，我們也需要注意自己的源頭IP權(quán)益，避免被黑客黑入肉機后隨便發(fā)起批量操作，損害大廠商的聲譽。

二是用戶身份的完善。 QQ運維是不可能操作QQ音樂設(shè)備的。 其實兼職是可以的。 我們會對執(zhí)行的命令做一些分析，避免高危操作，避免有人失戀想刪庫走人。

還有就是限制目標(biāo)的IP，這跟我們生產(chǎn)環(huán)境管理的理念是息息相關(guān)的。 其中有幾個是系統(tǒng)運維之類的。 由于他負(fù)責(zé)整個10萬臺機器，一次1萬臺機器要處理10次，而不是一條命令。 獲得 100,000 個單位，因為人們總是會犯錯誤。

完成這個CMDB流程體系后，也就有了傳輸通道。 如果你的公司規(guī)模或者你管理的設(shè)備量不大，效率上面已經(jīng)說的非常高了。

大家可以想一下，我要操作的對象都在配置管理上，配置一個流程執(zhí)行，就是先安裝包，然后啟動相關(guān)包，然后調(diào)用測試程序，連接灰度到兩臺機器。 在域名上，去驗證沒有問題，然后全量上線。 我們點幾下按鈕就解決了，不需要完全無人值守。

但是騰訊的體量還是不夠，所以我們做了無人值守，要做這七點：你的設(shè)備怎么管理？ 如何做決定？ 我應(yīng)該使用哪種設(shè)備？

而我們的智能決策，應(yīng)該依靠什么樣的數(shù)據(jù)決策，應(yīng)該啟動什么樣的流程？

假設(shè)我們有一個web層有10臺機器，8臺機器同時掛了。 當(dāng)只有一臺機器掛了，我們不需要馬上報警，因為有決策系統(tǒng)。

我知道web層的機器是無狀態(tài)的。 我直接重啟踢下線，又掛了又掛。 當(dāng)5臺機器都掛了，決策系統(tǒng)才能做出決定。 它的IP號超過30%是不可用的，這時候就不能不發(fā)通知了。 這個時候就應(yīng)該給運維人員發(fā)通知，讓人介入這件事情。 這是我們的明智決定。

還有我們的人工測試和灰度量。

灰度管理系統(tǒng)根據(jù)什么策略來考慮灰度量。 還有變更復(fù)檢，有沒有基礎(chǔ)指標(biāo)，CPU，你新上線的設(shè)備是否符合當(dāng)前設(shè)備的CPU曲線，或者有沒有業(yè)務(wù)監(jiān)控，你可以告訴我，這些是一些東西在變更時需做復(fù)檢。

還有日志通知。 當(dāng)手動系統(tǒng)與監(jiān)控系統(tǒng)聯(lián)動時，就像是在做一個改變。 那里有商業(yè)警報。 一旦這兩個數(shù)據(jù)關(guān)聯(lián)起來，就可以不發(fā)出業(yè)務(wù)告警了。 哪一個取決于監(jiān)控系統(tǒng)的告警策略？ 建筑。

三、實際案例

完成這七點后，能達(dá)到什么境界呢？ 是騰訊QQ會員的真實案例。 如果你用的是騰訊的產(chǎn)品，那你肯定收到過騰訊發(fā)給你的紅點。

有的處女座一定要點那種紅點，量馬上就到。 這對運維來說是一場噩夢。 如果不提前規(guī)劃好容量，業(yè)務(wù)請求量就會飆升。

但是有了無人值守的運維能力，你什么都不用做。 你會收到郵件提醒，無論是聊天工具彈框還是手機郵件提醒你當(dāng)前正在執(zhí)行手動擴容，它自己完成了整個過程。

自從我們完成了三個核心部分，并協(xié)助他們完成了最后七個步驟，可以說我們在手工化方面已經(jīng)達(dá)到了人生的巔峰。

最后跟大家總結(jié)一下：明天分享的主題不會做的很大服務(wù)器運維技術(shù)，大家回家看看，我們有什么樣的管理對象可以標(biāo)準(zhǔn)化，怎么去框定，以及框架搭建好之后，如何在這些標(biāo)準(zhǔn)場景下實現(xiàn)最高效的運維。

我們的標(biāo)準(zhǔn)化和配置，然后把流程系統(tǒng)和我們需要做的一切都連接到標(biāo)準(zhǔn)的對象上，最終可以實現(xiàn)我們的手動運維。 好了，明天的分享到此結(jié)束，謝謝大家。

闡明

本文來自中國應(yīng)用性能管理行業(yè)盛會——2016中國應(yīng)用性能管理大會（簡稱2016），由聽云等聯(lián)合主辦，8月起在廣州新廣東皇冠假日酒店隆重召開18 日至 19 日。