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

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

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

那怎么辦呢？

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

所以明天我就不給大家介紹一個非常龐大的系統了。 我會專門講一下手工化中最核心的環節（CMDB分層、技術架構、后續實現方式等），說不定那些核心環節你都做了，你的效率就會提升到一個很高的水平。

1. 人工運維的能與不能

明天的分享主要有三個部分。 前兩部分會著重告訴大家在做手工運維之前我們應該有什么樣的概念。 不管是運維還是開發這兩個角色，雖然都需要遵守這樣的規范，但是我們的規范是什么？ 基于這樣的規范，我們如何實現我們的手動實現。

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

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

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

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

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

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

我們如何提出標準化規范？ 讓我們的研發團隊和運維團隊更高效的合作，防止誤會？

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

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

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

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

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

2. DEV與OPS：求同存異

在如此巨大的業務壓力下，我們如何與我們的開發人員和運維人員共同訂制一個我們可以實施的標準化運維解決方案？

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

結構不良的程序無法有效地維護它。

在騰訊的社交產品線，我們現在有超過5000個功能模塊，對應的微服務有上萬個。 在這些情況下，沒有辦法維護一些結構不良的程序代碼。

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

只有合作，才能在激烈的互聯網紅海競爭中走得更快，才能勝出。 怎么做？

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

運維很關心架構，否則沒辦法評估它的好壞是不是和架構有直接關系。 Ops 希望開發違背我們的規范。

之前也和一些傳統行業的同事交流過。 他們寫了很多無法完成的規范開發。

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

我們提倡的統一架構和運維規范，對開發者的面子有什么影響？ 那么基于這樣一個統一的規范，我們如何構建一個運維工具體系，使其成為手冊呢？

基本上所有的互聯網業務架構都可以用上圖簡單概括，分為客戶端、用戶終端、PC、中間的運營商，以及以下三層結構：接入層、邏輯層、數據層.

騰訊整個社交網絡大致是這樣劃分的。 同樣的結構，我們開始提出管理理念：框架化、組件化、無狀態、分布式。

我們的框架是如何實現的？

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

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

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

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

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

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

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

明天我非常希望能和大家充分討論這個概念。 當我們的業務架構層級長成這樣的時候，無論是手動運維還是監控，都非常方便。

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

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

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

我覺得很多東西，不是說技術好壞，而是看誰更適合去做。 這個時候侯運維作為一個公共支撐團隊，權力更大或者應該規范這樣的事情，讓我們去衡量同質化的業務場景。

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

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

3、人工運維技術細節

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

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

我們把業務架構分成不同的層次，雖然是剛才的圖的另一種表達方式。 五層，不同的層次，我們要做的標準化是針對不同的對象。

像我們的設備層有哪些標準？ 統一型號，計算型，內存型，SSD，你用的是關系型數據庫，你要用什么型號，你要用大硬盤，你是做web的，標準顯存就夠了。

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

所以我用紅色標注了幾個字，就是減少運維對象。 和其他業務層一樣，你是一個IM類的應用，架構肯定是三地三活分布的。 QQ的調度方案必須和QQ空間一致。 所以我們所做的一切都是為了減少運維對象。

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

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

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

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

下面看一下我們互聯網業務架構層的分層特點，針對不同層級的對象構建對應維護對象的系統。 該系統形成的數據將在我們的配置管理CMDB上進行結構化和實施。 這個 CMDB 在整個人工運維過程中起到了非常核心的作用。

什么是CMDB層？

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

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

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

存這種東西有什么用？

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

1、智云的運維思路

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

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

現在業界比較流行，口號是BUILD、SHIP、RUN（構建、傳輸、上傳到生產環境執行），但實際上真的有那么理想嗎？

上圖是我們在騰訊每次發布的時候做的。 其實我陷害的內容并沒有幫助我們解決問題。 怎么申請業務權限，可能是騰訊很有特點的。

大家知道，騰訊的很多業務都是在QQ的關系鏈系統下發展起來的，并不是所有的業務都有拉QQ關系鏈的權限。 訪問QQ關系鏈必須經過授權，這是鏡像部署無法解決的問題。 而我們智云平臺必須要解決這樣的事情。

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

但是我們QQ有一些大集群，上千臺機器。 每次發送都會重啟嗎？ 這也不現實。 測試結果如何？ 怎么解決灰度問題？ 到底如何上網？ 也沒有解決上網的問題。 對于我們網站類的應用，還是需要加入外域解析，加入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次，而不是一條命令。 獲得 100,000 個單位，因為人們總是會犯錯誤。

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

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

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

而我們的智能決策，應該依靠什么樣的數據決策，應該啟動什么樣的流程？

假設我們有一個web層有10臺機器，8臺機器同時掛了。 當只有一臺機器掛了，我們不需要馬上報警，因為有決策系統。

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

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

灰度管理系統根據什么策略來考慮灰度量。 還有變更復檢，有沒有基礎指標，CPU，你新上線的設備是否符合當前設備的CPU曲線，或者有沒有業務監控，你可以告訴我，這些是一些東西在變更時需做復檢。

還有日志通知。 當手動系統與監控系統聯動時，就像是在做一個改變。 那里有商業警報。 一旦這兩個數據關聯起來，就可以不發出業務告警了。 哪一個取決于監控系統的告警策略？ 建筑。

三、實際案例

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

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

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

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

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

我們的標準化和配置，然后把流程系統和我們需要做的一切都連接到標準的對象上，最終可以實現我們的手動運維。 好了，明天的分享到此結束，謝謝大家。

闡明

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