雲時代的騰訊運維團隊轉型：ECUG 10周年大會演講

編者按：運維職能越來越多被雲平台取代，運維如何轉型 DevOps，以便繼續為業務提供快速、低成本的支撐工具、運營系統？來自騰訊藍鯨的產品總監黨受輝在 ECUG 十周年大會上分享了騰訊運維團隊的實際案例，本文由 ECUG 授權高可用架構發表。

講師：黨受輝（騰訊藍鯨產品中心總監）

一、雲時代的背後

身邊的運維們

在騰訊，藍鯨支撐著騰訊內所有自研、代理的遊戲運維，目前大概有 300 多個（遊戲）。騰訊一半的收入都來自於遊戲，這個體系支撐了半個遊戲行業，也支撐了半個騰訊。這裡面有個最大的問題，即各遊戲業務的架構是不一致的。

互聯網公司（除了騰訊）所有事業群、事業部門業務都是自己開發，只要有自己的開發，就有自己的開發框架，沿著開發框架做一個規範，沿著規範再做一套運維。但是在騰訊不可能，騰訊遊戲的業務大部分都是代理的，全球上百家廠商開發好代碼後給到騰訊，騰訊遊戲的運維人員無法左右這款遊戲的架構、語言、操作系統，只能做差異化的運維，沒有標準化的運維。

傳統運維的工作

發布、變更、故障處理。

傳統運維的危機

圖 1

這三項工作（圖 1 ）在雲時代會有危機，雲平台出現後，大多數公司其實不需要那麼多運維了，傳統運維的崗位，比如 IDC 運維不需要自建那麼大的機房，有一部分可以租用。即便是私有雲，目前也出現定製雲，雲廠商按照網路架構定製好基礎設施，再交付給客戶或者幫客戶代維。各個公司中 IDC 運維、 DBA 等崗位都會萎縮，公司類似的崗位會減少。所以，傳統運維工作中有些就沒有了。

運維的對象

在雲時代，運維的對象有三個：第一個是 VM 。早期是物理機，後來出現了 VM ，一個物理機會虛出十幾個，以前手工做得很爽，變成一百台物理機就很難做完。第二個是容器的出現，build-ship-run 的發布形式完全突破了傳統的運維發布模式，運維還要同時兼顧以前的物理機、VM的操作管理，這對運維的技能又提出更大的挑戰。第三個是應用，業務競爭比較激烈，運維以前的身份是：這個業務可以出問題，只要不是運維造成的，這個責任就是產品、策劃、開發的。以前只需要負責這個業務的發布、變更、故障處理等基礎運維工作，現在需要因為運維的存在而讓業務指標往上走，必須把精力和注意力從設備上轉移到應用上。

傳統運維繫統

以前做一個發布系統、監控系統等，步驟是從底層往上做，最後做界面。後來發現，這個運維繫統橫向打通會出現問題。對於傳統企業來說並不存在這個問題，他們由 IBM 、CA 等廠商提供平台，基本上不管運維。但對於互聯網公司來說就會有問題，機器上可能有好幾個 Agent ，例如做監控的團隊做一個監控的 Agent ，做大數據的會做一個大數據採集的 Agent，做發布的做一個發布的 Agent 等等。

運維服務的轉型

轉型的主要有三個層次：運營保障、運營工具、運維決策。以前運維在發布、變更、故障處理做完之後就沒有責任了，在騰訊內部不可以這樣。因為前面提到的諸多原因，騰訊必須要做輸出和服務。例如，在做到運維保障的同時，需要做運維工具。DevOps 本質上是開發和運維的結合，要麼開發懂運維，開發把運維的工具做出來，這個平台最終要落成一個平台系統讓別人用，才能持續地沿用這個理論，否則只停留在概念理論。

在騰訊的理念中，運維如果能夠給開發做工具，能夠快速把開發和測試的崗位串聯在一起，每天實現一萬次發布，那就是 DevOps 。但是太窄了，要給產品、策劃、運營、老闆所有崗位做工具，這是騰訊的思路。在運營工具方面，運維需要轉型，能夠給公司各個崗位構建運維工具。同時，運維需要做一些輔助決策，通過大數據技術幫助產品如何拉升業務指標等。

二、運維的轉型

自動化

從手工操作到腳本自動化、Web 自動化，把一部分自動化不單獨在 CRT 上點，還要分擔到頁面上，這部分由外包做，把正聘運維崗位從操作中撤掉。

圖 2

調度自動化，很多工作需要跨系統操作，如果公司中有很多發布系統、變更系統等系統，運維做發布時，可能需要在不同的系統之間來回切換，這很浪費時間，如果要讓一個發布無人值守，就必須要打穿各個系統。運維的操作流程要麼是鏈狀的，要麼是樹狀的（圖 2 ）。

自動化的兩級調度

圖 3

原來是 tar、文件分發、修改配置文件、啟進程，後來發現不對，這個操作鏈很長，運維只覆蓋了很短的部分，怎麼樣把它串起來？通過調度自動化，運維就是要把自己的崗位提升，不能只操作這種配置服務或者方案服務。

藍鯨的前三個平台

配置平台

作業平台

作業平台，運維的操作有一個問題，一旦操作對象變多了，沒有工具便來不及操作。所以需要有一套東西能夠同時操作 20 萬以上的設備，而且效率必須比操作原來的 10 台還要快，因此騰訊做了這個管控系統（圖 4 ）。

圖 4

這個系統的好處是運維可以把腳本定製到裡面，由它代運維執行，運維可以忽略操作數量。騰訊在行業里辦的運維挑戰賽，每個周期都會弄幾萬台雲伺服器給幾個隊伍，每個隊一開始想 1 萬台，後來改成 5 千台、3 千台。第一次比賽，例如盛大、攜程、去哪兒等都參加過，騰訊用這個平台做現場驗證，例如跑 1 萬台伺服器，2、3 秒必須跑完。

這兩個東西都需要對 IaaS 有操作，為了使架構合理，單獨開發一套管控平台來對接。網路模式有的只用自己的內網。第二種是公有雲，買了五家公有雲，不可能所有公有雲的伺服器都開公網 IP，管控的時候可能開一個，只有一兩台機器有公網 IP ，通過一個 Agent 進行管理。如果是全球管控，例如管理全球 11 個國家的業務，需要專線和操作路徑能夠指定。有三種不同的連接模式，包括開發不同的管道、傳文件用一套管道、發命令用一套管道、採集大數據用一套大管道。對 1 萬機器做操作的話，必須 5 秒內全部完成，這些是硬指標。

圖 5

解決了運維的操作部分，比如傳文件、髮指令，這一塊能夠到 Web 上執行，下一步就是要把不同的 Web 連起來，不同的應用系統打通。這個時候要用到 20 年前的一種技術 SOA（圖 5 ），SOA 把各種各樣孤立的原子系統，核心服務開 API 出來再對接，在匯流排層做服務的發現、註冊、路由、協議轉換、監控等等，再往上開發運維繫統。這個時候再開發一個發布系統，所有的原子部分下面都有了，只需要做原子重組。這時能夠把運維成本降到 50% 。

上層系統 SaaS 化

圖 6

讓運維不用經過全職培訓就能夠開發運營系統，第一種是把運維能力往上提，第二種是把開發運維繫統的門檻往下降，兩個同時做就可以完成。降到 50% 以後怎麼繼續降？運維人員開發一個運維繫統的時候用的是 PaaS 技術，PaaS 能夠全託管運維環境，要實現各種 API，在開發內部系統的時候，代碼不會到處遷移，所以構建一套私有化即可。以前開發一個應用工具可能是先有需求，買一台機器，布署環境，各種包裝好，寫代碼，代碼管理，監控，日誌，不斷地改 Bug 。在雲時代下，用戶只要進入開發者中心編寫工具本身的很少一部分核心邏輯代碼（圖 6 ），代碼上傳到 PaaS，PaaS 自動幫用戶構建、分配環境、運行，運營環境全託管。

圖 7

運營系統已通過 SOA 拆解（圖 7 ），沒有必要為了單個運營系統而再做服務化拆解成多個模塊，那是平台需要做的事情。在上面構建的運營系統，足夠小到用一個項目就可以裝下。一個容器一個系統，容器之間不需要交互，可以做得更輕一些。

圖 8

實際上，只剩下編寫核心邏輯這點工作量，核心成本可以降低。這個時候如果有了 PaaS，上面的運營系統就可以稱之為 SaaS 了，怎麼樣把 SaaS 的成本再降到 10% 以下？運維有一個問題，大多數運維沒有經過前端培訓，後台也不夠強。這時需要再繼續拆解（圖 8 ），前端最早把各種頁面元素（導航、按鈕）全弄一起，分類放在那裡，運維要用的時候直接用就可以了。後來發現不行，運維調一個按鈕可能會花費一個上午，便改為調七八十種套餐，運維開發人員使用習慣後又不想和別人頁面類似，又進一步提出前端是否能夠做得更好，所以又繼續開發出了我們的 Magicbox，讓運維能夠直接拖拽生成他想要的頁面。騰訊內部已經把運營系統的 SaaS 開發成本降低到 10% 以下，一個普通的本科畢業生經過三周的培訓，如果還開發不了運營系統就會被開除，近三年只有一個人沒有達到標準。

騰訊內部的運維三百多，把其中一百個培養成 DevOps ，能做運營系統運維即可。構建價值、構建成本是沒有價值的，使用才有價值，其他崗位的人不會在乎這個系統怎麼來的，只會關注這個系統是否好用。從 2013 年開始到現在培養了 200 多個運維，100 多人都可以開發。在騰訊內部的藍鯨，現在有 500 多個運營系統，它的用戶群覆蓋了內部的秘書、開發、老闆、測試、運營等等崗位。

如果內部的藍鯨掛了，幾乎等同於辦公區停電，因為大家各種各樣的工具都在上面。上面可以按照小時為單位開發一個運維工具或者系統，能夠解決企業工具文化的問題。現在有很多工作室的開發也在上面做，在開發團隊中運營系統開發是最沒有價值的，他們一般會找團隊里剛畢業的學生去做。開發的責任是把產品的設計開發出來，原樣開發出來，所以開發不願意做，他們非常希望有運維這樣的崗位幫他們做好。2013 年，一份產品在上線時會做兩份方案，一份給開發，一份給運維，這樣運維上升到第二層面幫助企業落地工具文化。

落地企業工具文化

體現工具文化的不是幾個大型運營系統，而是無處不在的小工具。工具有維護成本，哪怕是一個秘書，每個月申請物資，要所有的員工填寫，申請 U 盤需要發郵件，兩天時間就沒有了。這個時候提出一個需求，幫助做出一個 SaaS 小工具，所有的事情都在上面填，自動整理成 Excel 可以導出來，2 分鐘就做完了。

工具只有在自己用的時候前途最大，所以把工具的門檻降低，讓所有人都能做，騰訊內部有很多業務開發，因為避免做運營系統耽誤時間，也在藍鯨上做。目前藍鯨上開發的運營系統有 560 多個。

運維參與運營

DevOps 在出現的早期是為了有一種機制能夠把開發、運維、測試串一起。互聯網中一個版本順利發布是企業最低的需求，這個東西為什麼那麼火？按照我們的理解，有人認為開發者要有運維意識，在開發版本的同時順手就把運維工具做出來，運維只需要點擊使用即可。如果一個公司真走到這個份上來，由開發來做運維，當這個項目完成之後，運維開始離職。

現在有很多創業公司或者國外著名的一些互聯網公司的人出來講 DevOps ，都是因為他們的公司由開發做運維工具，運維沒有事做，這種做法把運維弄走了，而且對公司來講很恐怖，一旦運維崗位沒有提起來，後面沒有一個崗位能夠支撐公司的精細化運營。什麼叫精益化運營？需要面向用戶，用戶在哪些環境體驗不好、如何丟失的，這些東西需要什麼崗位做呢？技術崗、懂運維環境、掌控運維環境的人，因為需要拿運維數據環境（伺服器數據、網路數據、用戶每一個階段體驗的日誌數據）、這個人需要有充足的時間、懂得如何使用業務（要知道映射到哪個模塊上、是哪個模塊的問題、不需要知道具體懂代碼怎麼寫，但必須要知道用戶的使用流程卡在哪兒等等），這樣才能做精細化運營。

那麼，除了運維之後並沒有適合的崗位能做這個工作。開發只顧自己的模塊，因為開發的工作沒完成，產品兩句話，開發兩個禮拜。開發最重要的工作永遠是把版本做出來，不是做旁枝末節。開發比運維貴，產品對運營環境完全不知道，數據哪兒來的都不知道。所以，一旦大公司的運維萎縮了是很恐怖的情況。運維不能明顯地拉升指標，但是它可以讓你的業務一瞬間消失掉。

騰訊眼裡的 DevOps

圖 9

騰訊是由運維開始，讓運維團隊做 DevOps 項目的同時，把運維能力稍微提一下，讓運維可以覆蓋 DevOps 所有平台。例如要做一個發布系統（圖 9 ），做一個集成系統，持續集成、持續交付、持續部署這些系統由運維來做，讓運維來支持開發。開發只需要寫一份邏輯，怎麼部署其實開發不在乎，都讓運維完成。在我們眼裡，DevOps 是讓運維轉型成為一個技術團隊，給開發做工具、給測試做工具、給所有需要的人做工具。

當開發做完了持續集成工具之後，因為他的工具已經自動化了，如果開發跑去給測試做工具、給秘書做工具，他就不是業務開發了，他就屬於一個公司裡面支撐開發了。按照我們的理解，做平台這部分應該和運維合在一起，叫做技術運維團隊。

運維能做毛的運營？

圖 10

遊戲中有互聯網所有的先進架構（圖 10 ），同一個遊戲給兩個公司開發，可能玩法一模一樣，使用的語言、平台、框架完全不同，這取決於這個公司的開發人員擅長什麼技術，取決於這個公司的技術創始人用什麼技術。公司的技術創始人會用自己最擅長的技術向下推，如果使用一個他完全不懂的技術，這個位置以後不好坐。

當業務上線之後需要有人分析，從流量開始一直到用戶引入、用戶整個過程體驗，有哪些問題？用戶是怎麼怕的？不單是這個渠道的轉化率到達 10% 就結束了，一百萬用戶最後發現付費的只有 10% ，渠道的轉化率是 10% ，不清楚剩下的 90% 去哪兒了。但是在騰訊的運維需要把整個鏈條梳理完，最早是引流，官網上別人不知道從哪兒點擊的廣告鏈到官網下載遊戲、安裝、註冊、創建角色、進入副本、玩遊戲。每一個點都要梳理出有哪些細節，用戶是怎麼丟的。

運維為什麼有時間做這些工作？因為運維的發布、變更、故障處理在上一層已經全部自動化，架構不變就不需要改了。一旦業務變了，以前發布工具不方便使用了，腳本需要改、配置需要改、SaaS 需要改，這個時候運維就再出來，把它改好再交付。所以運維只做方案，但是不做操作服務，因為運維太貴了。

例如下載服務裡面有一個加速，最早買流量的時候發現有很多用戶點了下載器，在下客戶端的過程中流失了，因為客戶端過大，5G、10G、20G，家裡的網速沒有那麼快，怎麼辦？在載入器上報兩個數據，一個是是否下載完成，一個是如果沒有下載，用戶的下載速度是多少。沒有下載完成之後，運維給用戶安全速度分組，這部分的玩家速度超過 800K ，理論上一定能夠下載，客戶端很大，如果一個月沒有玩的話需要更新半個小時，用戶就不玩了。用戶家裡的速度足夠快，推個包送他一些道具，用戶會接著下載。如果家裡網速太慢，下載不完，以前的笨辦法是給用戶寄一個光碟，現在簡單，直接調電信的 API 把用戶的網速改了。

圖 11

分析給哪些玩家發禮包、什麼時候發這個禮包，最後結論是：下載速度大的時候，當下載進度為 5% 、已經下載 10 分鐘的玩家，在進度 8%、15%、30% 發送禮包，用戶關掉下載界面的概率最低。找 100 萬、200 萬用戶 A/B test ，結果如圖 11 所示。這個項目做完之後，玩家下載的成功率提升了 20% ，玩家下載的時長降了 60% 。提速、拆包、減少下載的東西、帶寬速度快，下載的時間縮短很多。這個時候，整體的轉化率從 10% 提升到 20% ，最後轉化出來的 10% 等同於廣告費用 5 億。即運維可以量化自己的項目，到底給公司賺了多少錢。在安裝、登錄服務等等鏈條中，只要運維具備大數據使用能力，就可以做這些事情。

賦予運維大數據的使用能力

以前業務量小的時候不用大數據，寫一個腳本就行，但在騰訊的體量下這樣絕對不行，騰訊每天動不動上百 T ，需要思考大數據怎麼實時地採集、彙集、計算、展示。騰訊由數據平台採集，大數據平台做用戶營銷、用戶畫像，傳統大數據丟 1% 、2% 不影響結果，反正是做趨勢分析。但是運維不一樣，運維大數據平台首先必須要實時，因為要做決策，到底擴不擴容需要決定，如果數據丟 1% ，決策就會出現錯誤。實時、海量、污損，數據量是不能丟失的，每天跑 100T ，也不能丟一條。運維大數據平台的構建成本更高，從 2013 年起藍鯨數據平台，到現在已經三年多了，基本上解決了海量、實時和虧損，這三個指標單獨拿出來做一個數據平台很簡單，一個月足夠，但是把三個條件放在一起就不一樣了。

運維寫不了 Java 的運算邏輯，把運維轉為 DevOps ，也要考慮運維的接受能力。如果只有 10% 的運維能夠接受，那這個策略是失敗的。讓運維學 Python ，Python 既能做運維，也能做 Web 開發，而且 Web 的編程就一個框架。運維有些用過 Yaml ，內部有些運維不會寫 Yaml ，就開發一套 SQL 引擎，做出圖形化拖拽。這樣運維就具備了大數據的能力了。

三、藍鯨模式

藍鯨體系的工作模式

圖 12

集 SOA 、大數據、雲計算等一體的技術運營體系，不單可以做運維，它是一整套體系（圖 12 ）。分不同的平台，每一個平台都可以獨立使用，當然也可以插在一起使用，插在一起使用效果最好。下面都是原子，中間是集成平台，上面是 SaaS ，這個成本還不到原來的 10% 。

藍鯨團隊在內部不斷地開發原子，運維就找還有哪些點沒有自動化，把操作的流程梳理，每一個節點是一個點，用線連起來。當發現有這個原子缺失沒有東西可以調的時候，藍鯨就要看是否為公共需求，如果是公共需求就開發出這個東西給他們調用，他們只需要在上面配置需要采什麼、多少力度、植入計算機任務、得到結果實施。運維不斷地開發上面的 SaaS ，貼近不同崗位的需求構建 SaaS 。

現在《變形金剛 4 》上映之後出現了大力神，組合金剛，每一個機器人可以獨立作戰，但是在一起更牛，藍鯨就是這個思路。原子平台，運維不斷地開發 SaaS 。

四、開放

為運維行業的繁榮貢獻 ：諮詢方案、成熟產品、開源代碼

騰訊希望做一點貢獻，2015 年出去分享經驗，是運維業的領航者。最早企業 IT 、上市公司的總裁出去講「做企業級的藍鯨」，早期是給大家提供諮詢方案，告訴大家如何做。騰訊投資的公司不滿足，要求乾脆把它用出來，後來就把騰訊內部的產品功能大量裁減，弄成獨立搭建的版本給他們使用。運營系統上的圖一定是真實的，很多公司不大接受公有的 PaaS 做財務系統。怎麼辦呢？後來開發了獨立版本。騰訊主要的任務是支撐大半個騰訊、支撐半個遊戲主業，後面繼續改，把幾個部分開放出來，不斷升級。

最早的時候是騰訊雲，後來是給騰訊投資的公司提供方案，再後來是藍鯨校園。培養學生，從大一開始扶植一些大學內的社團讓他們接觸和學習藍鯨，從中直接招人，直接繞過招聘季的競爭，提前把學生鎖定，再進行社區版開放。

開放了公有雲版有 1 萬多用戶使用，但是留存只有 2000 ，後來調研說這個東西做得很好，他們就自己抄了，因為互聯網公司不敢用公有雲上的東西。開發免費版，盡量做成免維護，獨立搭建版本運維自己搭會碰到很多問題，整個藍鯨運營組整天應付這些問題，藍鯨的思路是把點和面連接起來。從去年底開放，相信 2017 年能把這個數字做到 1 萬家，騰訊以前只搞 2C ，現在也試試 2B 。

把騰訊的技術交給合作夥伴

頂級互聯網公司的技術 + 專註於運維服務的廠商 + 能力交付 = 多贏 。把騰訊的技術交付給服務商，讓服務商去賺錢，這樣成就我們的名聲。以前傳統的交付都是要把軟體賣給甲方，收後面的費用，甲乙方會產生矛盾。現在要求服務商把一定的能力交給他們，這樣就可以解決問題，以這種模式給傳統行業輸出東西。

例如中間件巡檢、VM 的生成、裝機，他們給傳統的客戶調研，在上面開發 SaaS 。這樣能夠扶持一批企業擠進軟體開發行列，以前軟體開發都是 CRM 、ERP ，以前代維都是代維通用的東西，一個企業很難想像把核心業務運維外包給別人，除非是運營商才可以，大多數企業並不能接受。服務商的優勢在於有客戶，有一對一做服務的耐心，我們有技術，合作點切得比較好。

藍鯨的理念是低成本的 SaaS 定製，很多軟硬企業最大的矛盾在於為了成本低，盡量做通用的東西賣，但是通用的東西用戶體驗一定差；定製的東西體驗好但是貴。藍鯨解決了低成本定製和完全免維護，PaaS 就不存在運維的成本。

更多深度技術分享，可關注本月七牛組織的架構師實踐日－大數據與機器學習的最佳實踐，點擊閱讀原文進行報名。