引子
最近，在運維圈裏看到觸控科技的蕭總提出的一個概念“運維2.0”，學習之後，感觸頗多，和幾年前騰訊遊戲的應用運維團隊發起的“運維轉型”戰略項目神似，那個項目在數年間幾乎重塑了“應用運維”在騰訊遊戲的定義，而在過程中帶動並承載這次轉型的具體實現，叫藍鯨。
藍鯨是騰訊遊戲應用運維（ARE）技術生態體系的代號，由正在逐步產品化的六大運維平臺和衆多應用運維（含devops）、運營規劃等人員構成。
在應用運維這一領域，藍鯨以“獨特”的方式承載着半個騰訊，也承載着國內遊戲行業半數份額。
出自應用運維團隊的藍鯨體系，最初的設計理念，是希望能武裝運維，使其可以提供更高維度的服務。例如，爲產品、策劃、運營等崗位提供：
1.自助化的運營工具；
2.數據化決策支持；
3.直接的用戶體驗改善等。
我們受邀於7月16號晚上在高效運維 1號羣做一次專題分享（屆時將有多個羣轉播，超過1500人在線收看、互動），本文是爲保障羣內分享效果而提前撰寫的背景和概要介紹。
本文嘗試以半敘事的方式，概述藍鯨出現的背景，設計理念，和落地方式，希望業界廣大應用運維同行們，在我們的發展歷程中能找到自己現階段的影子，共鳴共勉，共同努力，繁榮應用運維生態。
1. 藍鯨的背景：運維轉型
十年前，我們的業務運維忙於這些工作：
服務器、網絡、OS、DB、發佈、變更、監控、故障處理、運營環境信息維護提取等等。
這些工作大多是被動的，或者說是“需求驅動型的“，運維大多數時候在被動的爲產品、策劃、運營、開發等合作崗位的同學提供操作服務，而且很多是重複性的操作服務。
五年前，我們的一個運維小組發起了轉型嘗試，目標是使我們的運維團隊從“操作服務輸出”，轉型爲“解決方案服務輸出”。
三年前，也就是2012年，依據這個先行試點團隊的效果評估，整個騰訊遊戲的十餘個運維團隊（目前200+運維）走上了艱難的轉型之路，作爲落地承載方案的藍鯨體系同時開始構建。
當年促使我們決心轉型的原因，可以歸結爲以下三點。
原因1：業務紅海化
行業競爭很激烈，精細化運營越來越重要。產品和運營人員忙於更貼近用戶體驗的業務設計和運營設計，開發團隊忙於更快更可靠的實現，運維團隊則希望爲用戶提供更高的可用性，不論是颳風下雨，還是發佈變更，都能將業務可用性保持在無限接近7*24（此處省略幾萬字）。
在此之上，還需要能爲產品策劃運營等其它崗位提供各類運營工具以提高“產品運營”的效率（一直以來，騰訊運維的職能在內部被定義爲“技術運營”，所有運維們所在的職級通道就叫做“技術運營通道”），甚至能爲運營決策提供準確的數據依據。
原因2：“傳統運維”生存空間塌縮
幾年前我們預感到“傳統運維”的職能空間會被逐步壓縮：
比如一些新技術對運維的傳統工作會有一些衝擊（此處省略幾萬字），這一點到今天已經不用再展開說了，近一年運維領域各類危機言論開始滿天飛了。
再比如開發團隊出於追求更高可用性等原因，在運維不給力的情況下會直接涉足精細化運營領域。
雖然我們認爲運維始終是不可或缺的，但也不得不承認傳統運維的需求量會有一定的減少，崗位的萎縮對所有從業者都不是好消息，出於自救我們也要嘗試轉型。
原因3：我們太累了
那些年，騰訊遊戲瘋狂的增長，如果不轉型，別提什麼輔助決策這樣的高級玩意兒，就是發佈變更、故障處理之類的運維基礎工作都會把我們拖死。
因此，運維轉型的長遠目標可以歸結爲：
將基礎運維服務（發佈變更、監控處理、數值調整、數據提取等）儘可能做到運維無人值守，運維提供解決方案（工具）;
同時負責隨時調整解決方案，但不提供重複性的操作服務，由使用者自助或者外包團隊操作；
運維分出一部分精力，嘗試“用戶體驗優化”和“運營決策輔助”等運維增值服務。
2. 藍鯨的設計思想
和很多公司的情況不同，在騰訊遊戲設計運維技術體系，有4個天然的難處。
1.在運維眼裏，這裏幾乎有着互聯網行業中所有的業務類型：有重客戶端遊戲，網頁遊戲，各類官網，移動終端遊戲，大型遊戲平臺（平鋪式架構，拓撲關係複雜，模塊數量上百，服務器數量幾千）……
2.這裏幾乎有着互聯網行業中所有的流行技術，因爲騰訊遊戲300多款業務中，大多數是由世界各地開發商開發出來，由騰訊獨家代理的所謂“獨代遊戲”。
因此，這些遊戲所使用的開發語言、開發框架、操作系統、數據庫等技術組合，是沒有直觀規律的。而且由於遊戲從簽訂代理合同到上線運營之間的間隔時間越來越短，開發商很難爲了運維體系而對架構或技術做大規模的修改。
3.300多款遊戲相互之間是沒有關係的，發佈變更、故障處理等運維操作場景和操作流程是沒有直觀規律的，即便是同一個遊戲，也可能因爲上了一個新版本，新增了幾種後臺server，或者改變了表結構，而導致運維操作流程發生改變。
4.這些遊戲的服務器數量，也就是操作單元，有十餘萬，而隨着容器技術的普及，操作單元的數量還會暴漲。
因此，藍鯨的設計，不能侵入業務架構，不能依賴業務架構，不能依賴業務所使用的技術，不能依賴有統一的運維操作流程
甚至，也最好別指望開發商爲你做什麼改造，還得支持海量場景（最好能支持十萬級操作單元併發）。
最終，我們總結出來的共同點是：
運維通過linux命令，可以搞定所有“發佈變更故障處理等”運維操作流程。
雖然只有這一點，但也足夠了，這至少說明，運維的基礎服務，不論是發佈變更還是告警處理，都是可以分步驟的，步驟可能是串行的，也可能有分支結構。
藍鯨的設計思路是：儘可能將單個步驟抽象爲原子，再將原子自動化，而後通過任務引擎連接成“串”或者“樹狀分支結構”實現全自動化。
這種參照SOA的設計，其最大優點在於不依賴業務類型，不依賴架構，不依賴場景，只要運維手工能做的，都可以做成無人值守。
運維需要做兩件事，將原子自動化和將原子集成爲工具，這兩件事也正是藍鯨體系武裝運維的切入點。
1）將原子自動化：
運維通過命令可以做的步驟，在藍鯨作業平臺上封裝個腳本，就變成了可集成的自動化原子，而運維通過其他運營系統頁面操作的步驟，由藍鯨集成平臺中的ESB平臺與其對接好接口之後，也變成了可集成的自動化原子。
2）將原子集成爲工具：
運維/運營工具的開發對傳統運維是有一定障礙的，藍鯨通過幾方面的工作來解決這個問題。
在“藍鯨集成平臺”（藍鯨體系目前有6個平臺）中構建了一個PaaS模塊，業務運維（devops）無需關注找服務器、部署環境（各種包、mysql、nginx等）等步驟，只需要寫好工具本身的邏輯代碼上裝到PaaS容器就行了，同時還免除了工具的運維成本（高可用、故障修復等）。基於docker技術，工具的部署也是一鍵式的。
其次是開發了一套工具代碼框架，內置了統一登錄、權限、tag等通用功能，更重要的是，不需要一個一個去對接各個系統的接口（原子），因爲ESB模塊都封裝好了，只要寫個函數就可以調用這些原子。
再有就是解決運維的前端開發難題——前端樣例庫。提供了“從各種頁面元素到不同類型的運維工具的頁面組合套餐”，減少了運維消耗在前端開發上的時間。
最後，還爲藍鯨開發者提供培訓，一般來說，新進畢業生在通過四周以內的培訓之後，就可以獨立在藍鯨集成平臺中構建APP工具。
到此，藍鯨已經基本解決了運維構建工具高門檻的問題，而且可以隨時低成本的根據業務變化（例如新增了模塊，導致發佈變更、告警處理流程都變了）調整工具。
運維在“轉型”的過程中，需要補充或者需要強化的技能，只有python（Django）和shell及初淺的web開發，這對大多數運維來說，都是可以接受的。
在這種設計模式下，藍鯨團隊的建設方向就很清晰了：
1.繼續降低工具本身的開發成本，提高PaaS模塊的可靠性；
2.擴展原子服務，找出運維海量操作流程中，重複度最高的一些原子，構建成平臺，封裝接口提供給PaaS作爲自動化原子，讓運維更輕鬆的調度更多節點，提升單個節點功能密度，升級拓展更多的流程，直到把流程升級到運維無人值守，升級到對產品、策劃等崗位的閉環服務爲止。
經過三年的發展，藍鯨體系構建了六個平臺，其中後四個都是直接或間接提供原子服務供運維集成的功能性平臺：
藍鯨集成平臺：包含PaaS、ESB、開發框架、web樣例等模塊，是運維製作工具APP的平臺。
藍鯨移動平臺：藍鯨體系的移動端操作入口。
藍鯨作業平臺：各種大小文件傳輸，含參腳本執行類的動作，可以在藍鯨作業平臺封裝，通過接口操控。
藍鯨配置平臺：從業務的各層分級結構到子節點的各類屬性，都可以直觀的存儲於藍鯨配置平臺，通過接口存取。
藍鯨管控平臺：一套基於海量標準設計的管控系統，爲作業平臺提供文件管道和任務管道，爲數據平臺提供數據管道等，整個藍鯨體系對OS及容器單元、大數據的所有管控，只依賴管控平臺的一個智能agent。
藍鯨數據平臺：基於kafka、storm構建的供應用運維使用的實時計算平臺，爲上層藍鯨集成平臺上的智能決策類工具族、數據視圖類工具族、輔助決策類工具族提供大數據處理及實時計算能力。
Storm之類的技術早已不新鮮，但供運維“使用”的比較少見。上述平臺大多是由運維“維護”的，爲了適應運維的技能樹，藍鯨數據平臺包括如下特性：
1.提供了在線IDE，運維可以用相對熟悉的yaml語言描述運算邏輯，而不需要學習java；
2.通過各種渠道對接了大量常用的運營環境數據（客戶端數據、服務端數據、網絡數據、自定義數據源、在線、登陸、發佈變更、營銷活動、故障等運營事件）;
3.提供了數據字典供運維針對個性化的業務選用實時數據組合來做“運維自動決策”或者“輔助運營決策”。
目前已有的這六個平臺的組合，給了應用運維近乎無限的發揮空間。
我們內部有三個運維中心，十幾個應用運維組，他們各自支持着不同的業務，各自處於不同的發展階段和能力水平。
出自應用運維團隊的藍鯨團隊，在與他們不斷的磨合中持續改進着各個平臺，武裝應用運維逐級提升服務能力。一般來說，分三個階段.
階段1：運維基礎工作自動化
大家“儘量”將重複性的，由“運營環境”觸發的工作，例如縮容、擴容、開區、合服、告警處理、故障處理等做成全自動化的無人值守，業務架構或者業務需求有變化的時候纔去調整解決方案，這算是解放了應用運維自己，至少晚上可以好好睡覺。
因爲這類運維基礎服務，應用運維必須做好，至於付出的成本和代價，產品策劃和開發團隊其實並不在意。
或許只有運維經理或運維總監在意，不但在意團隊做這類工作的質量成本和效率，還在意做的方式，至少在一個組織架構下，必須是相對標準化的，絕不能是一個人搞一套，走一個員工就要對單個業務的單個場景工具做交接或者推倒重來。至少在藍鯨體系下，這類工具用的都是相同的原子組件，相同的集成方式。
階段2：輔助產品運營自動化
將“人”（產品、策劃、開發等）觸發的工作例如發佈、變更、配置調整、日誌或數據提取等工作封裝成藍鯨集成平臺上的自助APP工具，由產品自己操作或者轉給外包操作。
這樣既進一步解放了應用運維自己，也讓相關崗位的同事不用再看運維臉色，等運維排期，自己就能隨時做“產品運營”。
如果做到這一步，應用運維就算是切入業務運營核心流程了，因爲越是競爭激烈的重點產品，在“運營”過程中越需要頻繁的做重複性的不涉及業務架構的功能或配置調整，例如改數值、改圖片、上傳加載新腳本等等，其實就是業務的“後臺管理端”。
不同業務的管理端，功能大多各不相同，在過去往往是業務開發兼做管理端，自己找服務器、搭環境、寫代碼、部署、最可怕的是產品用的不習慣，整天改改改……
這對業務開發來說簡直是噩夢，因爲他們的本職工作（業務功能開發）不會因爲一個管理端而減少，而且業務開發團隊的人手永遠是不夠的，所以大多數業務開發團隊都會讓新手做這類“永遠做不完”的工作。
現在運維能幹這類工作，而且不用考慮工具自身的高可用和運維（PaaS是免運維的），用業務開發的話講，“現在的運維真是幫上大忙了”。
在我們內部的某些產品團隊，每當設計一個新產品，業務開發和應用運維團隊會各自收到來自產品策劃人員發來的需求設計，運維的那一份是《運營工具交互設計文檔》。
而在我們內部，個別團隊的業務開發在應用運維忙不過來的時候偶爾會自己跑到“藍鯨集成平臺”開發“後臺管理端”，然後再和應用運維商量後續修改維護誰來做，很有聯合team的感覺。
達到這個階段，應用運維實際上已經在支持“產品自動化運營”了。
階段3：數據化運維
接下來，當藍鯨團隊將大數據實時彙集計算的能力作爲原子服務併入藍鯨體系的時候，應用運維的職能翻開了新的一頁，也就是第三個階段。
在傳統模式下，應用運維如果想做運營環境大數據分析，需要自己寫腳本採集日誌或OS指標，傳輸，入庫，交叉查詢計算，再搞幾個頁面展示出來，雖說有開源的東西能做一部分，但一來承載有限，二來易用性不夠，最關鍵的，實時性、穩定性、完整性等都有欠缺。
而讓業務開發團隊做這個，也真是爲難了，比做“管理端”更爲難：
因爲相對於單個項目開發團隊來說，實現實時計算所投入的成本相對太高了。所以很多公司選擇在支撐團隊內，爲所有的業務部門專門組建“商業智能組”或者“數據挖掘組”之類的公共服務團隊。
但這類團隊大都在忙於做“經營類數據分析”，而且人手永遠“不夠用”，很少有捨得用他們給運維做運營環境數據分析的，應用運維們可能更多的在底下做這些數據平臺的“運維”工作，而不是在使用大數據平臺。
藍鯨數據平臺是參照運維的技能樹量身設計的，運維做運營環境大數據分析，只需要做三件事：
1.寫腳本描述採集內容，給svr上部署的“藍鯨管控平臺agent”，管控平臺會進行實時數據彙集，把各地海量svr上的數據彙集到kafka集羣；
2.用yaml描述所上報數據的計算邏輯，用於storm實時計算；
3.在藍鯨集成平臺上用APP來展示實時數據視圖。
比如，通過各地的服務器日誌實時分析用戶的登錄、註冊、消費、等各種指標，找出區域性的用戶使用問題。
再比如，上了一個新功能，可以通過和研發約定的日誌分析用戶的使用情況和各種用戶行爲，或者爲了某個營銷活動或者新版本，臨時的專項設置一些精細化監控，或者爲了定位某個問題。
應用運維一般來說都是對口服務某個業務的，對自己的業務形態以及從用戶的角度如何使用都很熟悉，這就決定了：運維是可以理解產品運營策略的，也有能力推測出哪些數據經過怎樣的處理，是有輔助運營價值的。
藍鯨數據平臺的出現，降低了運維使用大數據的門檻，直接推動了“運維增值服務”的拓展。
在我們應用運維團隊內部，催生了很多由應用運維團隊主導的，基於大數據的運維服務化項目，比如探索中的“雲梯項目”。也就是說在這個階段，“數據化運維”、“大數據運維”等說法，在藍鯨體系中不是說着玩的，而是很普通的日常工作。
從應用運維“崗位價值”的角度來說（我們認爲一個崗位的價值可以從被其他崗位替代成本來衡量），當藍鯨體系將應用運維武裝到第三個階段，就算是逆天了。
如果說第一個階段的運維工作，開發等團隊可以通過IaaS的高彈性（現在還不大靠譜）及業務架構的高可用（假設他們做得到）輕鬆替代的話，那在第二個階段就要付出一些成本了，畢竟是硬性增加了開發團隊的建設及維護工作量。
而在第三個階段，對業務開發來說就太爲難了，也就是說應用運維們藉助藍鯨數據平臺可以大量進行業務開發團隊從成本上難以承受的工作——運營環境大數據分析，來進行產品運營的決策輔助。
所以，業界當前在擔憂的運維危機，我們在幾年前也擔心過，而現在無所謂了。
“數據運維”在我們內部還屬於優化推進階段，藍鯨數據平臺也在逐步成熟中，我們希望協助產品策劃人員，在紅海競爭中通過我們對精細化運營的一些努力，爲業務提升一點點競爭力。
我們希望爲產品策劃人員提供儘可能全面的輔助運營服務，或許當他們某一天離開騰訊後，會感覺各種不適應。
記得我們在杭州辦藍鯨沙龍那次，中間茶歇的時候，有個哥們跟我們說了一句話“我現在感覺騰訊遊戲成功的背後有很多我們不知道的因素”。
雖然我們很清楚，在騰訊遊戲發展的過程中我們所起到的必然不是決定性因素，可能只是其中很小很小的一部分，但他的這句話裏所流露出來的那一點點意思，依然給了我們很大的鼓勵。在騰訊的很多部門，即便是邊角的支撐團隊，也在爲其所支撐的產品線的市場競爭力和口碑而傾盡全力。
3. 藍鯨服務
藍鯨的服務可以分成兩類：PaaS和SaaS。
上邊提到的所有服務，都是PaaS：
比如藍鯨集成平臺，不管門檻多低，應用運維都需要自己去開發工具APP；
比如藍鯨作業平臺，應用運維需要自己上去寫腳本；
再比如藍鯨數據平臺，運維需要自己用腳本寫採集邏輯、用yaml寫計算邏輯，如果需要結果的實時展示，還得在藍鯨集成平臺做展示APP。
對應用運維來說，PaaS服務是萬能的，幾乎沒有場景限制，只要是原子能覆蓋的流程，都能做得出來，非常靈活，還能最大化發揮應用運維的技能，體現其價值：
1.比如可以針對某一種發佈做個藍鯨APP，
2.可以針對某個告警的處理邏輯做個“故障自動恢復”工具APP，
3.針對某個場景，開發一個實時刷新的數據視圖APP…
藍鯨大力發展PaaS服務，也印證了我們的理念：即依靠運維，武裝運維，使其能提供更高維度的服務，而不是取代運維，同時迎合了 運營、開發、測試等崗位人員的需求。
用PaaS構建的服務工具，適配場景幾乎無限制，高度的定製化使得體驗最好，但有“重複建設”以及對於基礎運維服務“難以統一化管理”的問題。
因此在很多高頻場景，藍鯨也聯合應用運維團隊，提供了不少SaaS。
比如針對發佈變更場景，結合藍鯨集成平臺上大量的發佈變更類工具，藍鯨推出了“標準運維”APP，使得已經慢慢變成大多數應用運維負擔的大量的花樣繁多的“操作類APP”得以下架。
這樣使得我們逐步的在應用層構建起了標準化場景組件，再允許大家從其他的APP調用“標準運維”接口，也就是說，進行更高層面的“場景調度”。
或者直接使用“標準運維”提供的APP Maker功能針對某一操作流程，拖拽生成類似於快捷方式的“輕應用”，以實現輕量操作類APP的免開發拖拽生成。
這樣，也使得藍鯨生態在運維基礎服務層面對業務來說更加安全可靠，面對運維人員的流動，抗風險能力更強。
再比如，在告警處理及故障恢復場景，爲了避免運維製作大量針對不同業務的“故障自動恢復”類工具，藍鯨團隊提供了通用的“故障自愈”服務：
1.將基礎告警及自定義告警的產生封裝成了通用服務；
2.將告警處理中常用的一些節點封裝成組件再集成爲套餐供運維通過圖形化界面選用。
3.當然爲了適配個性化的場景，也提供了PaaS編輯器，允許運維用python語言自定義複雜的故障分析樹。
4. 收尾
運維是一個被壓抑了太久的崗位。在行業的一些交流中，很多公司的運維說他們雖然掌控着運營環境，卻在逐漸地被排擠出業務的關鍵流程中，感到對未來很迷茫。
我只能說，沒有充分利用運維的價值，這是他們整個公司的損失，每個業務都是有專職運維的，運維瞭解運營環境，瞭解業務架構，瞭解產品本身，有着豐富的想象力。
而藍鯨，就是要讓運維的想象力爆發出來，並施加到業務上。
藍鯨，是騰訊遊戲的運維們從實戰中“總結、提煉、構想、設計、建設”出來的體系，其設計初衷是武裝運維，使其能提供更高維度的服務，而不是取代運維，同時迎合了運營、開發、測試等崗位人員的需求。
在所謂的“運維危機”時代，我們更懂得，併成功驗證了運維對業務的價值。
藍鯨曾支撐騰訊遊戲走過了不同層級的標準化、自動化時代，當前正在和應用運維一起探索服務化。而我們自己也在慢慢的將各平臺逐步產品化，以支持騰訊的投資公司以及自己部署在公有云上的業務和我們的合作伙伴。
希望在經過更多的磨合及歷練之後，有一天我們可以和大家一起走的更遠。
一個週末寫下這些，對於在高效運維羣的分享做背景和概要介紹應該足夠了，其他更詳細的內容和案例，我們本週四（16號）羣裏見，當然後續我們還會在各地組織藍鯨沙龍，和業界同行共同探討應用運維（ARE）的發展方向。