早期企業中的運維基本上由人工手動來維護，後來相繼出現了x86架構和虛擬機器，虛擬化技術逐漸成熟後容器技術又開始興起。到了現在運維正慢慢向更上層挺近，運維人員不僅要有基礎的運維能力，還需要對應用邏輯本身有非常深入的學習和瞭解，比如程式架構、模組功能、行程、埠這些都需要涉足，甚至資料庫和欄位含義也要知道。總的來看雲時代下對運維的要求會越來越高。

騰訊最初的運維團隊誕生的時候，要管理的伺服器並不多，大概僅有一二十臺，當時運維操作都是在Termainal上進行，因此自動化程度較低，容易出現人為失誤。後來隨著業務量和伺服器的增長，我們開始應用批處理指令碼，不過眾所周知指令碼的管理難度很高，操作也較為複雜，最關鍵的是併發數低，因此後面又轉移到了開源工具上。

當規模達到20萬以上的時候，開源工具也很難滿足需求了，必須要去做一些工具方面的建設。

目前行業中的自動化運維方案有兩種，一種是直接購買，另一種是自建。購買方面Bmc、惠普、IBM、CA是主要的軟體提供商，這4家幾乎壟斷了中國自動化IT運維繫統90%的市場，他們的產品有兩個特點，第一是“貴”，動輒就需要上千萬；第二是基於此的流程自動化不方便，容易出現斷點。

上圖列出的就是傳統軟體交付後容易遇到的各種問題，簡單來說就是被綁架了。對此的解決方案同樣有2個，一是重新選擇開發商，二是自主研發設計。這兩種方案其實代價都非常高，比如造成原有IT資源的浪費、技術儲備不足、建設週期長等。

目前最優的方案是PaaS，它的優勢在於能做到免運維、全託管和服務整合。

上圖左邊是傳統的業務架構管控，下方的黃色區域主要提供一些IaaS，基於此之上有兩套管控體系，一套是常見的管控平臺，另一套為容器管控平臺，最上層就是一些業務在跑。不過這種架構的問題在於一旦管控體系掛了，下層的IaaS就會失控。

右邊是藍鯨的PaaS，它下方集成了眾多的原子平臺同時還能無縫銜接傳統架構中已經建設好的管控體系和平臺，往上層是iPaas和aPaas，這些能力被整合上去之後就能讓運維或開發得以快速構建面嚮應用場景的SaaS。

PaaS根據定義來看可以分為2部分，一部分是aPaaS，擁有部署和執行託管能力；另一部分是iPaaS，負責服務的整合。

PaaS的構建流程總結起來有5個步驟，首先要部署支撐所有自動化系統的執行環境；第二步是整合原子平臺，實現企業內部不同平臺之間的整合和互動；第三步是構建企業服務匯流排，實現各個不同平臺團隊提供的系統或平臺的統一協議轉換。

所有能力整合起來之後，需要有一個排程引擎，將必要的原子能力連線起立，以服務的形式提供出來。

最後是將所有的工具或者說SaaS呈現出來，提供快速開發平臺，實現諸如快速構建自動化運維繫統的能力。

App Engine可以託管所有的SaaS工具，它對外釋出的社群版是基於虛擬機器的，每部署完成一個工具就會生成一個虛擬機器，不過這樣也導致資源無法隔離，從而引發一些不必要的問題，所以企業版中我們採用了容器的方案，以實現資源隔離。

運維經常使用的通用能力系統被稱為平臺，一般這些平臺在某個特定能力方面會更加深入，比如專門連線IaaS的管控平臺、用來執行指令碼和分發檔案的通用作業平臺。

除開基礎通用平臺外，一些周邊團隊可能也建設了很多系統，對於這些我們可以將它對接起來，構建更強大的PaaS能力。

企業服務匯流排是為了對接下方各種原子平臺，比如服務註冊、許可權控制異常處理、安全監控等。當然最重要的還是協議轉換，將下方不同語言不同協議的原子平臺的能力適配成統一協議。

集合起來的各原子平臺能力將透過排程引擎進行編排，比如釋出和擴容，除開會涉及到運維操作外，還有非常多的周邊系統需要去做。

有了排程引擎之後就能夠提供模板，讓運維在模板中透過引擎編排場景中的操作。

對於遊戲開區相信大家都不陌生，這背後涉及到了非常多的系統，包括和公司的流程相關聯。在沒有排程編排的情況下，一般一次開區需要耗費4到5個小時。

有了編排後就能實現一鍵自動開區，同時還能在這之前新增資料決策，透過大資料平臺採集相關資料，當檢測到資料達到某一標準後進行無人自動開區。

最後就是構建快速開發平臺。有過開發經驗的朋友應該都瞭解，傳統的開發樣式流程相對繁瑣，在應用開發之外，還要做環境構建、日誌追溯、監控告警、程式碼部署。

而在基於PaaS的開發樣式下開發者就只需要做開發之前的需求梳理和正式的核心程式碼開發。

應用開發主要分為前端和後端，釋出工具的前端開發讓運維人員去做顯然不合適，因此我們提供了一個前端的樣例庫，能夠輕鬆的拖拽生成頁面。後端則是基於python的堅果框架，就語言來說對運維人員比較友好，並且還封裝了大量的公共元件。

上圖是前面提到的前端方面的工具，叫做前端魔盒，可以看到這裡提供了非常多的視覺化佈局的元件。這樣就能讓運維專註於SaaS流程拼裝，大大降低了構建成本。

以上就是藍鯨自動化運維繫統的全貌，最下層是IaaS管控平臺；第二層集成了大量的原子平臺，包括自己構建的和對接第三方的；第三層為整合平臺，也就是前面提到的快速開發的部分；最上層是根據不同應用場景衍生的各種SaaS。

圖中是騰訊內部透過藍鯨構建的一些平臺和實踐，涵蓋運維、開發、自助工具等多個部分。

我們內部還有一個專門的藍鯨桌面平臺，其內有超過500多的SaaS，當需要用到某個工具的時候可以直接在這上面新增。

最初的SaaS大多用於針對自身的業務痛點，後來隨著不斷的擴充套件逐漸形成了一個系列，比如與王者榮耀相關的釋出、擴容等各種功能。

但是運維的能力畢竟有限，既然大家都在做釋出和擴容，那麼顯然也能做成通用的形式。

這些SaaS可以給各種崗位提供服務，比如產品的運營資料展示、開發方面的CI/CD，測試工具等。

故障自愈屬於基礎運維部分，針對運維的一些告警首先會對接該系統中。因為具體的業務問題只有相關負責人員才瞭解，因此我們也為運維人員提供了根據不同的業務流程編排套餐的能力。

上圖是CI/CD中的CD部分，傳統的非容器類釋出樣式都是透過它來做，從最開始提交釋出單到最後完成釋出結單都會在這上面透過模板編輯好。

另外需要註意的是我們內部所有正式對外業務的釋出不是運維人員在做，而是由專門的外包團隊負責。因為很多遊戲都是在凌晨釋出，我不希望因此耗費正式運維的精力。

上圖是使用者體驗類的工具，它會針對業務中使用者的每個環節進行資料分析，透過大資料、資料檢視展示資訊，並關聯自動化機械執行的流程形成閉環。

目前藍鯨已對外開發社群版，並會逐步將現有平臺打包到這個版本中，包括底層管控，配置平臺、作業平臺、整合平臺現已在社群版中。

同時我們還將內部的一些通用SaaS和指令碼放入到了應用市場中，以供使用者直接下載使用，類似於google商店的應用場景。

社群版2.0中內建了配置平臺和作業平臺，並且配備整合平臺以支援社群使用者的定製開，還提供API和開發樣例。

社群版3.0開始對外開放一些SaaS，比如監控、治癒，以及和合作夥伴聯合開發的平臺功能。社群版4.0的改進主要在CMDB和網路管理這塊。

轉載自：IT大咖說。

投稿：有投稿意向技術人請在公眾號對話方塊留言。

轉載：意向文章下方留言。

更多精彩請關註 “資料和雲” 公眾號 。