[[141127]]

作者介紹

黨受輝（咖啡黨）

騰訊游戲 藍(lán)鯨產(chǎn)品中心總監(jiān)

目前負(fù)責(zé)騰訊游戲運維支撐體系（藍(lán)鯨）的建設(shè)和運營，致力于打造行業(yè)級的基礎(chǔ)運維無人值守解決方案，以及數(shù)據(jù)化增值運維解決方案，推動devops生態(tài)。

十余年來專注行業(yè)信息化及運維領(lǐng)域，做過多年運維團隊管理，期間為不同類型的游戲及千萬PCU級游戲平臺設(shè)計過自動化運營系統(tǒng)。

引子

最近，在運維圈里看到觸控科技的蕭總提出的一個概念“運維2.0”，學(xué)習(xí)之后，感觸頗多，和幾年前騰訊游戲的應(yīng)用運維團隊發(fā)起的“運維轉(zhuǎn)型”戰(zhàn)略項目神似，那個項目在數(shù)年間幾乎重塑了“應(yīng)用運維”在騰訊游戲的定義，而在過程中帶動并承載這次轉(zhuǎn)型的具體實現(xiàn)，叫藍(lán)鯨。

藍(lán)鯨是騰訊游戲應(yīng)用運維（ARE）技術(shù)生態(tài)體系的代號，由正在逐步產(chǎn)品化的六大運維平臺和眾多應(yīng)用運維（含devops）、運營規(guī)劃等人員構(gòu)成。

在應(yīng)用運維這一領(lǐng)域，藍(lán)鯨以“獨特”的方式承載著半個騰訊，也承載著國內(nèi)游戲行業(yè)半數(shù)份額。

出自應(yīng)用運維團隊的藍(lán)鯨體系，最初的設(shè)計理念，是希望能武裝運維，使其可以提供更高維度的服務(wù)。例如，為產(chǎn)品、策劃、運營等崗位提供：

• 自助化的運營工具；

• 數(shù)據(jù)化決策支持；

• 直接的用戶體驗改善等。

本文嘗試以半敘事的方式，概述藍(lán)鯨出現(xiàn)的背景，設(shè)計理念，和落地方式，希望業(yè)界廣大應(yīng)用運維同行們，在我們的發(fā)展歷程中能找到自己現(xiàn)階段的影子，共鳴共勉，共同努力，繁榮應(yīng)用運維生態(tài)。

1. 藍(lán)鯨的背景：運維轉(zhuǎn)型

十年前，我們的業(yè)務(wù)運維忙于這些工作：

服務(wù)器、網(wǎng)絡(luò)、OS、DB、發(fā)布、變更、監(jiān)控、故障處理、運營環(huán)境信息維護(hù)提取等等。

這些工作大多是被動的，或者說是“需求驅(qū)動型的“，運維大多數(shù)時候在被動的為產(chǎn)品、策劃、運營、開發(fā)等合作崗位的同學(xué)提供操作服務(wù)，而且很多是重復(fù)性的操作服務(wù)。

五年前，我們的一個運維小組發(fā)起了轉(zhuǎn)型嘗試，目標(biāo)是使我們的運維團隊從“操作服務(wù)輸出”，轉(zhuǎn)型為“解決方案服務(wù)輸出”。

三年前，也就是2012年，依據(jù)這個先行試點團隊的效果評估，整個騰訊游戲的十余個運維團隊（目前200+運維）走上了艱難的轉(zhuǎn)型之路，作為落地承載方案的藍(lán)鯨體系同時開始構(gòu)建。

當(dāng)年促使我們決心轉(zhuǎn)型的原因，可以歸結(jié)為以下三點。

原因1：業(yè)務(wù)紅?；?/h3>

行業(yè)競爭很激烈，精細(xì)化運營越來越重要。產(chǎn)品和運營人員忙于更貼近用戶體驗的業(yè)務(wù)設(shè)計和運營設(shè)計，開發(fā)團隊忙于更快更可靠的實現(xiàn)，運維團隊則希望為用戶提供更高的可用性，不論是刮風(fēng)下雨，還是發(fā)布變更，都能將業(yè)務(wù)可用性保持在無限接近7*24（此處省略幾萬字）。

在此之上，還需要能為產(chǎn)品策劃運營等其它崗位提供各類運營工具以提高“產(chǎn)品運營”的效率（一直以來，騰訊運維的職能在內(nèi)部被定義為“技術(shù)運營”，所有運維們所在的職級通道就叫做“技術(shù)運營通道”），甚至能為運營決策提供準(zhǔn)確的數(shù)據(jù)依據(jù)。

[[141128]]

原因2：“傳統(tǒng)運維”生存空間塌縮

幾年前我們預(yù)感到“傳統(tǒng)運維”的職能空間會被逐步壓縮：

比如一些新技術(shù)對運維的傳統(tǒng)工作會有一些沖擊（此處省略幾萬字），這一點到今天已經(jīng)不用再展開說了，近一年運維領(lǐng)域各類危機言論開始滿天飛了。

再比如開發(fā)團隊出于追求更高可用性等原因，在運維不給力的情況下會直接涉足精細(xì)化運營領(lǐng)域。

雖然我們認(rèn)為運維始終是不可或缺的，但也不得不承認(rèn)傳統(tǒng)運維的需求量會有一定的減少，崗位的萎縮對所有從業(yè)者都不是好消息，出于自救我們也要嘗試轉(zhuǎn)型。

#p#

原因3：我們太累了

那些年，騰訊游戲瘋狂的增長，如果不轉(zhuǎn)型，別提什么輔助決策這樣的高級玩意兒，就是發(fā)布變更、故障處理之類的運維基礎(chǔ)工作都會把我們拖死。

[[141129]]

因此，運維轉(zhuǎn)型的長遠(yuǎn)目標(biāo)可以歸結(jié)為：

1. 將基礎(chǔ)運維服務(wù)（發(fā)布變更、監(jiān)控處理、數(shù)值調(diào)整、數(shù)據(jù)提取等）盡可能做到運維無人值守，運維提供解決方案（工具）;

2. 同時負(fù)責(zé)隨時調(diào)整解決方案，但不提供重復(fù)性的操作服務(wù)，由使用者自助或者外包團隊操作；

3. 運維分出一部分精力，嘗試“用戶體驗優(yōu)化”和“運營決策輔助”等運維增值服務(wù)。

2. 藍(lán)鯨的設(shè)計思想

和很多公司的情況不同，在騰訊游戲設(shè)計運維技術(shù)體系，有4個天然的難處。

1. 在運維眼里，這里幾乎有著互聯(lián)網(wǎng)行業(yè)中所有的業(yè)務(wù)類型：有重客戶端游戲，網(wǎng)頁游戲，各類官網(wǎng)，移動終端游戲，大型游戲平臺（平鋪式架構(gòu)，拓?fù)潢P(guān)系復(fù)雜，模塊數(shù)量上百，服務(wù)器數(shù)量幾千）……

2. 這里幾乎有著互聯(lián)網(wǎng)行業(yè)中所有的流行技術(shù)，因為騰訊游戲300多款業(yè)務(wù)中，大多數(shù)是由世界各地開發(fā)商開發(fā)出來，由騰訊獨家代理的所謂“獨代游戲”。

   因此，這些游戲所使用的開發(fā)語言、開發(fā)框架、操作系統(tǒng)、數(shù)據(jù)庫等技術(shù)組合，是沒有直觀規(guī)律的。而且由于游戲從簽訂代理合同到上線運營之間的間隔時間越來越短，開發(fā)商很難為了運維體系而對架構(gòu)或技術(shù)做大規(guī)模的修改。

3. 300多款游戲相互之間是沒有關(guān)系的，發(fā)布變更、故障處理等運維操作場景和操作流程是沒有直觀規(guī)律的，即便是同一個游戲，也可能因為上了一個新版本，新增了幾種后臺server，或者改變了表結(jié)構(gòu)，而導(dǎo)致運維操作流程發(fā)生改變。

4. 這些游戲的服務(wù)器數(shù)量，也就是操作單元，有十余萬，而隨著容器技術(shù)的普及，操作單元的數(shù)量還會暴漲。

因此，藍(lán)鯨的設(shè)計，不能侵入業(yè)務(wù)架構(gòu)，不能依賴業(yè)務(wù)架構(gòu)，不能依賴業(yè)務(wù)所使用的技術(shù)，不能依賴有統(tǒng)一的運維操作流程。

#p#

甚至，也最好別指望開發(fā)商為你做什么改造，還得支持海量場景（最好能支持十萬級操作單元并發(fā)）。

最終，我們總結(jié)出來的共同點是：

運維通過linux命令，可以搞定所有“發(fā)布變更故障處理等”運維操作流程。

雖然只有這一點，但也足夠了，這至少說明，運維的基礎(chǔ)服務(wù)，不論是發(fā)布變更還是告警處理，都是可以分步驟的，步驟可能是串行的，也可能有分支結(jié)構(gòu)。

藍(lán)鯨的設(shè)計思路是：盡可能將單個步驟抽象為原子，再將原子自動化，而后通過任務(wù)引擎連接成“串”或者“樹狀分支結(jié)構(gòu)”實現(xiàn)全自動化。

這種參照SOA的設(shè)計，其最大優(yōu)點在于不依賴業(yè)務(wù)類型，不依賴架構(gòu)，不依賴場景，只要運維手工能做的，都可以做成無人值守。

運維需要做兩件事，將原子自動化和將原子集成為工具，這兩件事也正是藍(lán)鯨體系武裝運維的切入點。

1）將原子自動化：

運維通過命令可以做的步驟，在藍(lán)鯨作業(yè)平臺上封裝個腳本，就變成了可集成的自動化原子，而運維通過其他運營系統(tǒng)頁面操作的步驟，由藍(lán)鯨集成平臺中的ESB平臺與其對接好接口之后，也變成了可集成的自動化原子。

2）將原子集成為工具：

運維/運營工具的開發(fā)對傳統(tǒng)運維是有一定障礙的，藍(lán)鯨通過幾方面的工作來解決這個問題。

• 在“藍(lán)鯨集成平臺”（藍(lán)鯨體系目前有6個平臺）中構(gòu)建了一個PaaS模塊，業(yè)務(wù)運維（devops）無需關(guān)注找服務(wù)器、部署環(huán)境（各種包、mysql、nginx等）等步驟，只需要寫好工具本身的邏輯代碼上裝到PaaS容器就行了，同時還免除了工具的運維成本（高可用、故障修復(fù)等）?；赿ocker技術(shù)，工具的部署也是一鍵式的。

• 其次是開發(fā)了一套工具代碼框架，內(nèi)置了統(tǒng)一登錄、權(quán)限、tag等通用功能，更重要的是，不需要一個一個去對接各個系統(tǒng)的接口（原子），因為ESB模塊都封裝好了，只要寫個函數(shù)就可以調(diào)用這些原子。

• 再有就是解決運維的前端開發(fā)難題——前端樣例庫。提供了“從各種頁面元素到不同類型的運維工具的頁面組合套餐”，減少了運維消耗在前端開發(fā)上的時間。

• 最后，還為藍(lán)鯨開發(fā)者提供培訓(xùn)，一般來說，新進(jìn)畢業(yè)生在通過四周以內(nèi)的培訓(xùn)之后，就可以獨立在藍(lán)鯨集成平臺中構(gòu)建APP工具。

到此，藍(lán)鯨已經(jīng)基本解決了運維構(gòu)建工具高門檻的問題，而且可以隨時低成本的根據(jù)業(yè)務(wù)變化（例如新增了模塊，導(dǎo)致發(fā)布變更、告警處理流程都變了）調(diào)整工具。

運維在“轉(zhuǎn)型”的過程中，需要補充或者需要強化的技能，只有python（Django）和shell及初淺的web開發(fā)，這對大多數(shù)運維來說，都是可以接受的。

#p#

在這種設(shè)計模式下，藍(lán)鯨團隊的建設(shè)方向就很清晰了：

1. 繼續(xù)降低工具本身的開發(fā)成本，提高PaaS模塊的可靠性；

2. 擴展原子服務(wù)，找出運維海量操作流程中，重復(fù)度最高的一些原子，構(gòu)建成平臺，封裝接口提供給PaaS作為自動化原子，讓運維更輕松的調(diào)度更多節(jié)點，提升單個節(jié)點功能密度，升級拓展更多的流程，直到把流程升級到運維無人值守，升級到對產(chǎn)品、策劃等崗位的閉環(huán)服務(wù)為止。

經(jīng)過三年的發(fā)展，藍(lán)鯨體系構(gòu)建了六個平臺，其中后四個都是直接或間接提供原子服務(wù)供運維集成的功能性平臺：

1. 藍(lán)鯨集成平臺：包含PaaS、ESB、開發(fā)框架、web樣例等模塊，是運維制作工具APP的平臺。

2. 藍(lán)鯨移動平臺：藍(lán)鯨體系的移動端操作入口。

3. 藍(lán)鯨作業(yè)平臺：各種大小文件傳輸，含參腳本執(zhí)行類的動作，可以在藍(lán)鯨作業(yè)平臺封裝，通過接口操控。

4. 藍(lán)鯨配置平臺：從業(yè)務(wù)的各層分級結(jié)構(gòu)到子節(jié)點的各類屬性，都可以直觀的存儲于藍(lán)鯨配置平臺，通過接口存取。

5. 藍(lán)鯨管控平臺：一套基于海量標(biāo)準(zhǔn)設(shè)計的管控系統(tǒng)，為作業(yè)平臺提供文件管道和任務(wù)管道，為數(shù)據(jù)平臺提供數(shù)據(jù)管道等，整個藍(lán)鯨體系對OS及容器單元、大數(shù)據(jù)的所有管控，只依賴管控平臺的一個智能agent。

6. 藍(lán)鯨數(shù)據(jù)平臺：基于kafka、storm構(gòu)建的供應(yīng)用運維使用的實時計算平臺，為上層藍(lán)鯨集成平臺上的智能決策類工具族、數(shù)據(jù)視圖類工具族、輔助決策類工具族提供大數(shù)據(jù)處理及實時計算能力。

Storm之類的技術(shù)早已不新鮮，但供運維“使用”的比較少見。上述平臺大多是由運維“維護(hù)”的，為了適應(yīng)運維的技能樹，藍(lán)鯨數(shù)據(jù)平臺包括如下特性：

1. 提供了在線IDE，運維可以用相對熟悉的yaml語言描述運算邏輯，而不需要學(xué)習(xí)java；

2. 通過各種渠道對接了大量常用的運營環(huán)境數(shù)據(jù)（客戶端數(shù)據(jù)、服務(wù)端數(shù)據(jù)、網(wǎng)絡(luò)數(shù)據(jù)、自定義數(shù)據(jù)源、在線、登陸、發(fā)布變更、營銷活動、故障等運營事件）;

3. 提供了數(shù)據(jù)字典供運維針對個性化的業(yè)務(wù)選用實時數(shù)據(jù)組合來做“運維自動決策”或者“輔助運營決策”。

目前已有的這六個平臺的組合，給了應(yīng)用運維近乎無限的發(fā)揮空間。

我們內(nèi)部有三個運維中心，十幾個應(yīng)用運維組，他們各自支持著不同的業(yè)務(wù)，各自處于不同的發(fā)展階段和能力水平。

出自應(yīng)用運維團隊的藍(lán)鯨團隊，在與他們不斷的磨合中持續(xù)改進(jìn)著各個平臺，武裝應(yīng)用運維逐級提升服務(wù)能力。一般來說，分三個階段.

階段1：運維基礎(chǔ)工作自動化

大家“盡量”將重復(fù)性的，由“運營環(huán)境”觸發(fā)的工作，例如縮容、擴容、開區(qū)、合服、告警處理、故障處理等做成全自動化的無人值守，業(yè)務(wù)架構(gòu)或者業(yè)務(wù)需求有變化的時候才去調(diào)整解決方案，這算是解放了應(yīng)用運維自己，至少晚上可以好好睡覺。

因為這類運維基礎(chǔ)服務(wù)，應(yīng)用運維必須做好，至于付出的成本和代價，產(chǎn)品策劃和開發(fā)團隊其實并不在意。

或許只有運維經(jīng)理或運維總監(jiān)在意，不但在意團隊做這類工作的質(zhì)量成本和效率，還在意做的方式，至少在一個組織架構(gòu)下，必須是相對標(biāo)準(zhǔn)化的，絕不能是一個人搞一套，走一個員工就要對單個業(yè)務(wù)的單個場景工具做交接或者推倒重來。至少在藍(lán)鯨體系下，這類工具用的都是相同的原子組件，相同的集成方式。

階段2：輔助產(chǎn)品運營自動化

將“人”（產(chǎn)品、策劃、開發(fā)等）觸發(fā)的工作例如發(fā)布、變更、配置調(diào)整、日志或數(shù)據(jù)提取等工作封裝成藍(lán)鯨集成平臺上的自助APP工具，由產(chǎn)品自己操作或者轉(zhuǎn)給外包操作。

這樣既進(jìn)一步解放了應(yīng)用運維自己，也讓相關(guān)崗位的同事不用再看運維臉色，等運維排期，自己就能隨時做“產(chǎn)品運營”。

如果做到這一步，應(yīng)用運維就算是切入業(yè)務(wù)運營核心流程了，因為越是競爭激烈的重點產(chǎn)品，在“運營”過程中越需要頻繁的做重復(fù)性的不涉及業(yè)務(wù)架構(gòu)的功能或配置調(diào)整，例如改數(shù)值、改圖片、上傳加載新腳本等等，其實就是業(yè)務(wù)的“后臺管理端”。

不同業(yè)務(wù)的管理端，功能大多各不相同，在過去往往是業(yè)務(wù)開發(fā)兼做管理端，自己找服務(wù)器、搭環(huán)境、寫代碼、部署、最可怕的是產(chǎn)品用的不習(xí)慣，整天改改改……

這對業(yè)務(wù)開發(fā)來說簡直是噩夢，因為他們的本職工作（業(yè)務(wù)功能開發(fā)）不會因為一個管理端而減少，而且業(yè)務(wù)開發(fā)團隊的人手永遠(yuǎn)是不夠的，所以大多數(shù)業(yè)務(wù)開發(fā)團隊都會讓新手做這類“永遠(yuǎn)做不完”的工作。

現(xiàn)在運維能干這類工作，而且不用考慮工具自身的高可用和運維（PaaS是免運維的），用業(yè)務(wù)開發(fā)的話講，“現(xiàn)在的運維真是幫上大忙了”。

在我們內(nèi)部的某些產(chǎn)品團隊，每當(dāng)設(shè)計一個新產(chǎn)品，業(yè)務(wù)開發(fā)和應(yīng)用運維團隊會各自收到來自產(chǎn)品策劃人員發(fā)來的需求設(shè)計，運維的那一份是《運營工具交互設(shè)計文檔》。

而在我們內(nèi)部，個別團隊的業(yè)務(wù)開發(fā)在應(yīng)用運維忙不過來的時候偶爾會自己跑到“藍(lán)鯨集成平臺”開發(fā)“后臺管理端”，然后再和應(yīng)用運維商量后續(xù)修改維護(hù)誰來做，很有聯(lián)合team的感覺。

達(dá)到這個階段，應(yīng)用運維實際上已經(jīng)在支持“產(chǎn)品自動化運營”了。

#p#

階段3：數(shù)據(jù)化運維

接下來，當(dāng)藍(lán)鯨團隊將大數(shù)據(jù)實時匯集計算的能力作為原子服務(wù)并入藍(lán)鯨體系的時候，應(yīng)用運維的職能翻開了新的一頁，也就是第三個階段。

在傳統(tǒng)模式下，應(yīng)用運維如果想做運營環(huán)境大數(shù)據(jù)分析，需要自己寫腳本采集日志或OS指標(biāo)，傳輸，入庫，交叉查詢計算，再搞幾個頁面展示出來，雖說有開源的東西能做一部分，但一來承載有限，二來易用性不夠，最關(guān)鍵的，實時性、穩(wěn)定性、完整性等都有欠缺。

而讓業(yè)務(wù)開發(fā)團隊做這個，也真是為難了，比做“管理端”更為難：

因為相對于單個項目開發(fā)團隊來說，實現(xiàn)實時計算所投入的成本相對太高了。所以很多公司選擇在支撐團隊內(nèi)，為所有的業(yè)務(wù)部門專門組建“商業(yè)智能組”或者“數(shù)據(jù)挖掘組”之類的公共服務(wù)團隊。

但這類團隊大都在忙于做“經(jīng)營類數(shù)據(jù)分析”，而且人手永遠(yuǎn)“不夠用”，很少有舍得用他們給運維做運營環(huán)境數(shù)據(jù)分析的，應(yīng)用運維們可能更多的在底下做這些數(shù)據(jù)平臺的“運維”工作，而不是在使用大數(shù)據(jù)平臺。

藍(lán)鯨數(shù)據(jù)平臺是參照運維的技能樹量身設(shè)計的，運維做運營環(huán)境大數(shù)據(jù)分析，只需要做三件事：

1. 寫腳本描述采集內(nèi)容，給svr上部署的“藍(lán)鯨管控平臺agent”，管控平臺會進(jìn)行實時數(shù)據(jù)匯集，把各地海量svr上的數(shù)據(jù)匯集到kafka集群；

2. 用yaml描述所上報數(shù)據(jù)的計算邏輯，用于storm實時計算；

3. 在藍(lán)鯨集成平臺上用APP來展示實時數(shù)據(jù)視圖。

比如，通過各地的服務(wù)器日志實時分析用戶的登錄、注冊、消費、等各種指標(biāo)，找出區(qū)域性的用戶使用問題。

再比如，上了一個新功能，可以通過和研發(fā)約定的日志分析用戶的使用情況和各種用戶行為，或者為了某個營銷活動或者新版本，臨時的專項設(shè)置一些精細(xì)化監(jiān)控，或者為了定位某個問題。

應(yīng)用運維一般來說都是對口服務(wù)某個業(yè)務(wù)的，對自己的業(yè)務(wù)形態(tài)以及從用戶的角度如何使用都很熟悉，這就決定了：運維是可以理解產(chǎn)品運營策略的，也有能力推測出哪些數(shù)據(jù)經(jīng)過怎樣的處理，是有輔助運營價值的。

藍(lán)鯨數(shù)據(jù)平臺的出現(xiàn)，降低了運維使用大數(shù)據(jù)的門檻，直接推動了“運維增值服務(wù)”的拓展。

在我們應(yīng)用運維團隊內(nèi)部，催生了很多由應(yīng)用運維團隊主導(dǎo)的，基于大數(shù)據(jù)的運維服務(wù)化項目，比如探索中的“云梯項目”。也就是說在這個階段，“數(shù)據(jù)化運維”、“大數(shù)據(jù)運維”等說法，在藍(lán)鯨體系中不是說著玩的，而是很普通的日常工作。

從應(yīng)用運維“崗位價值”的角度來說（我們認(rèn)為一個崗位的價值可以從被其他崗位替代成本來衡量），當(dāng)藍(lán)鯨體系將應(yīng)用運維武裝到第三個階段，就算是逆天了。

如果說第一個階段的運維工作，開發(fā)等團隊可以通過IaaS的高彈性（現(xiàn)在還不大靠譜）及業(yè)務(wù)架構(gòu)的高可用（假設(shè)他們做得到）輕松替代的話，那在第二個階段就要付出一些成本了，畢竟是硬性增加了開發(fā)團隊的建設(shè)及維護(hù)工作量。

而在第三個階段，對業(yè)務(wù)開發(fā)來說就太為難了，也就是說應(yīng)用運維們借助藍(lán)鯨數(shù)據(jù)平臺可以大量進(jìn)行業(yè)務(wù)開發(fā)團隊從成本上難以承受的工作——運營環(huán)境大數(shù)據(jù)分析，來進(jìn)行產(chǎn)品運營的決策輔助。

所以，業(yè)界當(dāng)前在擔(dān)憂的運維危機，我們在幾年前也擔(dān)心過，而現(xiàn)在無所謂了。

“數(shù)據(jù)運維”在我們內(nèi)部還屬于優(yōu)化推進(jìn)階段，藍(lán)鯨數(shù)據(jù)平臺也在逐步成熟中，我們希望協(xié)助產(chǎn)品策劃人員，在紅海競爭中通過我們對精細(xì)化運營的一些努力，為業(yè)務(wù)提升一點點競爭力。

我們希望為產(chǎn)品策劃人員提供盡可能全面的輔助運營服務(wù)，或許當(dāng)他們某一天離開騰訊后，會感覺各種不適應(yīng)。

記得我們在杭州辦藍(lán)鯨沙龍那次，中間茶歇的時候，有個哥們跟我們說了一句話“我現(xiàn)在感覺騰訊游戲成功的背后有很多我們不知道的因素”。

雖然我們很清楚，在騰訊游戲發(fā)展的過程中我們所起到的必然不是決定性因素，可能只是其中很小很小的一部分，但他的這句話里所流露出來的那一點點意思，依然給了我們很大的鼓勵。在騰訊的很多部門，即便是邊角的支撐團隊，也在為其所支撐的產(chǎn)品線的市場競爭力和口碑而傾盡全力。

3. 藍(lán)鯨服務(wù)

藍(lán)鯨的服務(wù)可以分成兩類：PaaS和SaaS。

上邊提到的所有服務(wù)，都是PaaS：

• 比如藍(lán)鯨集成平臺，不管門檻多低，應(yīng)用運維都需要自己去開發(fā)工具APP；

• 比如藍(lán)鯨作業(yè)平臺，應(yīng)用運維需要自己上去寫腳本；

• 再比如藍(lán)鯨數(shù)據(jù)平臺，運維需要自己用腳本寫采集邏輯、用yaml寫計算邏輯，如果需要結(jié)果的實時展示，還得在藍(lán)鯨集成平臺做展示APP。

對應(yīng)用運維來說，PaaS服務(wù)是萬能的，幾乎沒有場景限制，只要是原子能覆蓋的流程，都能做得出來，非常靈活，還能最大化發(fā)揮應(yīng)用運維的技能，體現(xiàn)其價值：

• 比如可以針對某一種發(fā)布做個藍(lán)鯨APP，

• 可以針對某個告警的處理邏輯做個“故障自動恢復(fù)”工具APP，

• 針對某個場景，開發(fā)一個實時刷新的數(shù)據(jù)視圖APP…

藍(lán)鯨大力發(fā)展PaaS服務(wù)，也印證了我們的理念：即依靠運維，武裝運維，使其能提供更高維度的服務(wù)，而不是取代運維，同時迎合了 運營、開發(fā)、測試等崗位人員的需求。

用PaaS構(gòu)建的服務(wù)工具，適配場景幾乎無限制，高度的定制化使得體驗最好，但有“重復(fù)建設(shè)”以及對于基礎(chǔ)運維服務(wù)“難以統(tǒng)一化管理”的問題。

因此在很多高頻場景，藍(lán)鯨也聯(lián)合應(yīng)用運維團隊，提供了不少SaaS。

比如針對發(fā)布變更場景，結(jié)合藍(lán)鯨集成平臺上大量的發(fā)布變更類工具，藍(lán)鯨推出了“標(biāo)準(zhǔn)運維”APP，使得已經(jīng)慢慢變成大多數(shù)應(yīng)用運維負(fù)擔(dān)的大量的花樣繁多的“操作類APP”得以下架。

這樣使得我們逐步的在應(yīng)用層構(gòu)建起了標(biāo)準(zhǔn)化場景組件，再允許大家從其他的APP調(diào)用“標(biāo)準(zhǔn)運維”接口，也就是說，進(jìn)行更高層面的“場景調(diào)度”。

或者直接使用“標(biāo)準(zhǔn)運維”提供的APP Maker功能針對某一操作流程，拖拽生成類似于快捷方式的“輕應(yīng)用”，以實現(xiàn)輕量操作類APP的免開發(fā)拖拽生成。

這樣，也使得藍(lán)鯨生態(tài)在運維基礎(chǔ)服務(wù)層面對業(yè)務(wù)來說更加安全可靠，面對運維人員的流動，抗風(fēng)險能力更強。

#p#

再比如，在告警處理及故障恢復(fù)場景，為了避免運維制作大量針對不同業(yè)務(wù)的“故障自動恢復(fù)”類工具，藍(lán)鯨團隊提供了通用的“故障自愈”服務(wù)：

1. 將基礎(chǔ)告警及自定義告警的產(chǎn)生封裝成了通用服務(wù)；

2. 將告警處理中常用的一些節(jié)點封裝成組件再集成為套餐供運維通過圖形化界面選用。

當(dāng)然為了適配個性化的場景，也提供了PaaS編輯器，允許運維用python語言自定義復(fù)雜的故障分析樹。

4. 收尾

運維是一個被壓抑了太久的崗位。在行業(yè)的一些交流中，很多公司的運維說他們雖然掌控著運營環(huán)境，卻在逐漸地被排擠出業(yè)務(wù)的關(guān)鍵流程中，感到對未來很迷茫。

我只能說，沒有充分利用運維的價值，這是他們整個公司的損失，每個業(yè)務(wù)都是有專職運維的，運維了解運營環(huán)境，了解業(yè)務(wù)架構(gòu)，了解產(chǎn)品本身，有著豐富的想象力。

而藍(lán)鯨，就是要讓運維的想象力爆發(fā)出來，并施加到業(yè)務(wù)上。

藍(lán)鯨，是騰訊游戲的運維們從實戰(zhàn)中“總結(jié)、提煉、構(gòu)想、設(shè)計、建設(shè)”出來的體系，其設(shè)計初衷是武裝運維，使其能提供更高維度的服務(wù)，而不是取代運維，同時迎合了運營、開發(fā)、測試等崗位人員的需求。

在所謂的“運維危機”時代，我們更懂得，并成功驗證了運維對業(yè)務(wù)的價值。

藍(lán)鯨曾支撐騰訊游戲走過了不同層級的標(biāo)準(zhǔn)化、自動化時代，當(dāng)前正在和應(yīng)用運維一起探索服務(wù)化。而我們自己也在慢慢的將各平臺逐步產(chǎn)品化，以支持騰訊的投資公司以及自己部署在公有云上的業(yè)務(wù)和我們的合作伙伴。

希望在經(jīng)過更多的磨合及歷練之后，有一天我們可以和大家一起走的更遠(yuǎn)。

一個周末寫下這些，對于在高效運維群的分享做背景和概要介紹應(yīng)該足夠了，其他更詳細(xì)的內(nèi)容和案例，我們本周四（16號）群里見，當(dāng)然后續(xù)我們還會在各地組織藍(lán)鯨沙龍，和業(yè)界同行共同探討應(yīng)用運維（ARE）的發(fā)展方向。

【python，C，java，docker，node.js，storm，Elasticsearch，graphite，kafka，elk，pydata，mvvm，d3】之一
你懂的~
blueking.jobs@gmail.com

歡迎關(guān)注 游戲運營技術(shù)論壇，以獲得更多關(guān)于騰訊藍(lán)鯨的信息。

如何一起愉快地發(fā)展

高效運維系列微信群是國內(nèi)高端運維圈子、運維行業(yè)垂直社交的典范?，F(xiàn)有會員800余名，其中運維總監(jiān)及以上級別會員300多名。

“高效運維”公眾號值得您的關(guān)注，作為高效運維系列微信群的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇線上/線下活動精彩分享及部分群友原創(chuàng)。“高效運維”也是互聯(lián)網(wǎng)專欄《高效運維最佳實踐》及運維2.0官方公眾號。

提示：目前高效運維兩個微信群均已滿員，如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友，并申請加入我們聊天群（技術(shù)討論+部分水貼，已有來自1群和2群眾多喜歡熱鬧的朋友）。

重要提示：尊重知識，請必須全文轉(zhuǎn)載，并包括本行及如下二維碼。