一、藍鯨智雲及雲端計算運維平臺參考框架標準

雲端計算運維平臺參考框架標準是基於騰訊的藍鯨智雲的開源專案總結歸納的，這個標準是一個全面的雲端計算運維平臺系統的框架標準，規定了一個面向雲端計算運維環境的運維平臺功能模組和能力要求。

有開源專案了，為什麼還要做標準？

開源和標準其實都是一種標準化的模式，開源是程式碼的事實標準，提煉成文件形式的標準框架，是因為程式碼是給開發人員看的，但是對於我們的 CIO 或者客戶需求方，當他在建設或者選擇一個產品的時候，不看程式碼，只看標準，什麼樣的平臺才是好的雲端計算時代的運維平臺？

一起來看下標準。

1.1、雲時代——運維變遷

運維物件的變革

從 VM、容器到應用，隨著運維物件的改變，我們可以看到雲時代已經來臨，運維的環境非常複雜，不再是單一的環境，要管理多種複雜的環境。

所以，現在很多行業客戶在雲的環境下，它的原始運維繫統要發生變化。傳統環境下，企業在建設運維繫統的時候，大部分模組是自己拼湊的，採購一些工具，各個運維工具之間存在重疊或者不互通的問題。

那麼在雲的環境下如果還是這樣，成本就非常大了。包括政府行業、金融行業在內的傳統企業客戶，都希望有一套整體運維平臺的標準，能夠幫他們整體規劃運維平臺。

傳統  IT  運維 VS 雲運維

我們可以看到雲時代的運維是很複雜的，已經不像以前一樣，形式單一、範圍侷限，跟傳統的  IT  相比，雲時代的運維不管是從人員的成本，自動化的程度，還有工作模式都是不一樣的，以前傳統的運維是響應式的，救火式的，現在運維都應該是自發主動式的，動態感知、發現問題等等。

1.2、藍鯨智雲

藍鯨的挑戰

大家都知道騰訊的遊戲的需求量非常大，上線很快，尤其是移動網際網路的遊戲，而所有的騰訊遊戲的運維平臺都是基於騰訊的藍鯨專案，藍鯨因為沉澱多年的技術運營支撐體系,承擔著數百款業務線上的運營，包括線上海量運維、大規模併發，以及遊戲不斷的升級、變更等等。

相容各種複雜的系統架構，運維能力是比較強的，所以在這種運維環境下的藍鯨智雲運維平臺，先天的優勢就是可以應對規模大，技術棧複雜，流量大，變更頻發的需求。

所以這套平臺可以滿足這種環境的要求，而這種環境恰恰也是目前很多傳統行業在轉型過程中面臨的雲端計算環境的需要。

比如說銀行業或者金融行業，很多網際網路金融產品也要很快地上線，這種應用開發也需要微服務架構的，同時也會面臨高併發的情況。

網際網路以前面臨的很多應用需求，對平臺的要求，傳統行業現在都在面臨，甚至工業智慧智造也會面臨這樣的問題，包括工控系統能力的要求。

所以我們認為在這種環境下成長起來的藍鯨平臺，在面臨雲端計算環境的運維，具有一定的先進性的。

藍鯨智雲的發展歷程

藍鯨的發展道路就是越來越智慧化。在2009年，藍鯨只是一個具有簡單能力的遠端讀寫和配置集中的系統，到2011年的作業時代，就能夠實現操作作業化和頁面操作智慧化。

再到2013年的場景自動化，不僅能夠做到跨系統排程的自動化、工具平臺自動化、服務自動化，初步做到無人值守，到今天的智慧運維，做到智慧服務理論、智慧系統、運維智慧化及運營智慧化，真正做到無人值守。

智慧化主要表現在：

• 系統本身的智慧化，系統決定是否發起需求，比如資源不夠用了。
• 運維沉澱的很多資料，可以支撐運營，哪款業務比較好，哪款遊戲在什麼時間段受歡迎，以及支撐運營的規劃等等。

藍鯨生態圈

藍鯨是開源的，大家可以下載它的原始碼。

藍鯨使用者資料

可以看到藍鯨從合作伙伴到企業使用者都是非常多的。

所以為什麼選擇藍鯨平臺作為標準的基礎藍本。

• 根據我們對國內所有運維平臺的考察，認為騰訊基於遊戲商長出來的藍鯨智雲平臺，具有功能完備性、技術運營、自動化和智慧化的先進性，比較符合目前網際網路環境下的雲端計算的很多特點。
• 第二，它是開源的，從程式碼程度已經做到了程式碼的標準化，有自己的生態管理體系。這個標準既可以作為藍鯨自身的開發商管理標準，也可以作為業界的參考。在標準過程當中除了藍鯨以外，還有很多運維廠商，包括客戶都加入其中一起探討出來的。參考框架裡的很多要求，可能藍鯨目前沒有做到，但是是它們努力的方向。

1.3、雲端計算運維平臺參考框架標準

那麼一個面向雲端計算環境的運維平臺要具備哪些功能模組的完備性呢？

從底層到上層，整個平臺包含了運營保障，運營工具和運營決策三大塊。

• 運營保障是最基礎的基礎資源運維層，包括 IaaS 管控，要滿足私有云、公有云和混合雲多種雲端計算場景。
• 運營工具是中間層，包括原子平臺層和整合平臺。原子平臺是運維能力的核心模組，包括作業、配置、資料、容器和 AI。整合平臺是在原子平臺的基礎上，進一步的能力綜合框架，包括定製化桌面、開發、服務匯流排等等。
• 運營決策是最能體現智慧化的應用層，可以只是簡單的運維場景，也可以包括智慧擴縮容、輔助運營等。

這裡我們是非常先進的採用了運營的詞，是因為很多運維的有識之士認為運維的發展方向應該是技術運營，而不僅僅是簡單的工具能力，應該從技術方面能夠支撐業務運營。

具體功能點

而每一個模組所具備的細分功能，可以從這個圖上看出，這裡不一一列舉，大家可以下載標準詳細看每個功能點。

需要注意這是完整和開放的框架，每個模組都是一個單獨的工具。

1.3.1、運營保障

我們每一層再細看下流程。

運營保障層以解放運維為目標導向。

整個運維平臺的理念，就是從運維到技術運營。

運營保障跟傳統的運維平臺本質需求沒有太大改變，但是由於和很多新技術的結合，比如服務匯流排和微服務和容器結合，具備了更多的靈活性和可擴充套件性，解放了很多複雜的配置操作，更便於管理。

1.3.2、運營工具

運營工具層以 DevOps 理念推動工具文化落地。

運營工具在 DevOps 裡面每個環節會提到，它包括 PaaS 平臺的介面工具和自動部署工具等等。

1.3.3 、運營決策

運營決策層是資料驅動運營分析, 實現智慧決策。

大資料智慧化把各個平臺的資料收集起來，供運營的決策者做一些參考。

接下來我們再看每一層中的幾個關鍵模組。

1.3.4、IAAS 管控層

管控層可以管控不管是公有云、私有云還是混合雲等等異構化的資源池。包括網路、CPU、儲存、各種作業系統、各種小型機 X86等等的管控，而且是一個跨雲的，可以實現跨資料中心的管控。

1.3.5 、原子平臺層

原子平臺層面向的是伺服器和技術資源的管理能力，包括作業平臺、資料平臺、容器管理還有 AI 的管理。

原子平臺層是所有 IT 運維繫統的核心，這裡面增加的容器管理模組和智慧運維模組。容器管理模組，剛才所有的 CICD 也好，自動化運營也好，都離不開容器的模組。

智慧運維，就是 ETL、儲存、讀寫等資料初步的蒐集和處理，供運維場景層分析決策。

1.3.6、整合平臺層

整合平臺層給開發人員看的，比如企業裡的不同運營系統，可能一個產品線有自己的運營系統，是給不同的產品運營系統看的是整合平臺層。

可以用呼叫底下任何模組的功能，這種整合平臺層的展現包括像定製化的桌面、開發平臺、開發框架、服務匯流排的方式。這一層是每個產品線的運營可以看到的。通過這個部署每個產品線的業務，在頂層的平臺上。

整合平臺層有點類似於微服務架構。我們可以看到它有一個 APP Engine，在微服務裡面就是服務註冊的地址。它把運維的環境通過整合平臺層開發出來以後，我們不同產品線的人可以基於它來開發部署。

1.3.7 、運維場景層

從整合平臺到往下所有能力，它可以實現的體現提煉出來的抽象的平臺功能，包括基礎的運維、CI/CD、智慧決策、輔助運營等等。

1.3.8 、標準進展情況

我們的標準從今年的3月份開始的，到7月份就已經做完了。

在這裡我代表我們整個編寫組，也是非常感謝我們所有參與的人員，包括高效運維社群，騰訊等等，這個標準已經完成，並在 CCSA WG5 工作組立項，最後這裡有一個藍鯨地址供大家下載。

作者：

慄蔚
中國資訊通訊研究院雲端計算與大資料研究所云計算部門副主任 / 雲端計算開源產業聯盟祕書長

原文來自微信公眾號：高效運維