由工業和資訊化部指導，中國資訊通訊研究院主辦，業界知名組織雲端計算開源產業聯盟（OSCAR）承辦的2017全球雲端計算開源大會於4月19日-20日在北京國家會議中心順利召開。本文為本屆大會嘉賓分享的大會演講速記內容，敬請瀏覽。

嘉賓介紹：景韻

公司職務：樂視致新SCM工程師

大會演講速記

我叫景韻，來自於樂視，現在在樂視致新負責智慧硬體這塊軟體配置的一些業務。

之前我在用友也是在做DevOps的推進工作，之前用友和阿里雲有一個深度的合作，在這個過程當中有積累一些DevOps和雲之間的經驗或者教訓，今天跟大家來一塊分享一下。

今天想講兩個，一個是DevOps，另外一個是雲原生應用，今天早上我看在主會場也有人提到這一塊。我把DevOps一些核心的東西提前跟大家劇透一下，讓大家更容易吸收。

首先想問一下，在座的聽說過DevOps的有嗎？看大家都比較靦腆。現在國內的很多大型企業、小型企業都在做DevOps。我之前在內部講這個。

我們瞭解DevOps的人都會聽說過DevOps年度報告，這是2016年最新的資料，我們在樂視內部講DevOps時候一定會給大家提這個。

現在很明顯，大家可以從圖上的資料看到，一個叫高績效，中等績效，一個是低績效，很明顯大家能看到差距是非常大的，包括這種部署頻率。

部署頻率和交付時間縮短很明顯，比如我之前在用友，可能一年會部署一次，但是現在不一樣，線上服務的一線會部署很多次，需求交付到我們手上之後，別人可以很快去交付，包括市場的變化，還有使用者的需求的變化都會影響到我們最終交付。

後面是變更失敗率和故障修復時間，這塊有一個非常明顯的感受，我們在處理一些故障的時候，分分鐘都有金錢上的內容，比如我們做網際網路P2P的，他宕機一分鐘就會有多大的損失。

為了幫助大家更容易理解DevOps，我認為DevOps起源於敏捷，但是它高於敏捷，我們可以從三方面。

從最開始瀑布模式，瀑布模式可以看到開發、測試和運維，這塊是最終一個價值交付的時間點，在整個過程當中價值是沒有交付的。後來變成敏捷這種模式，敏捷之後開發測試相親相愛在一塊，但是價值的交付依然是在最後的時間點。沒有價值真正交付到線上的，這是我們所說的DevOps需要改變的內容。

我們在DevOps下，開發、測試和運維是在一起的，我們要共同為業務去負責，這塊大家可以看到每一個迭代我們都一定要做上線，甚至一個迭代當中我們要去做多次的上線，就是為了把我們的價值更快的交付出去。

通過剛剛那個例子可以瞭解到整個DevOps從敏捷起源，最開始也是我們的IT運維工程師希望通過敏捷的工程方法去解決運維的問題，所以提出了敏捷運維的概念，逐漸演化，最終形成DevOps。

大家可以看到這是維基百科上官方的概念，非常抽象，涉及的角色非常多。關鍵詞是溝通、協作與整合，我們在提DevOps的時候，很多時候我們會去提DevOps像一種文化，就是因為更多強調大家相互之間的溝通和協作，目的很清晰，就是為了更快速的交付產品、軟體和服務。

下面我們具體理解一下，我們說DevOps的時候，剛剛大家也看到，它什麼東西都有，都在做，這就是說DevOps是一個集大成者，一定要去理解在整個的軟體工程。

我們之前提到軟體危機之後，大家在總結一個軟體工程的疑慮，大家希望通過工程的方法解決我們的軟體危機。

日本豐田企業有一個GPS豐田的製造系統，這裡面DevOps也會去借鑑GPS當中的經驗，從GPS這塊發出了精益這塊的內容，精益衍生出精益創業。

我們提到TPS，因為它是在生產製作行業，我們把GPS當中自動化、看板這些應用到軟體和網際網路行業，我們說它相當於DevOps一個具體的應用。持續整合，一旦遇到問題一定要停下來，修復它。

精益具體的事項，包括這後面精益創業裡提到要度量、學習的過程，這個就會把它的工程化，相當於我們要去使用它當中的一些實踐。

DevOps要解決的是打造一條服務的供應鏈，通過這條供應鏈幫助我們團隊交付真正業務的價值。敏捷，解決了我們研發測試這個環節，還有前面產品這塊的內容，包括需求怎麼去寫，怎麼去拆分的內容。敏捷應用到端到端，它不僅僅是到這個包打出來就ok了，一定要部署到線上。還有ITIL和ITSM。

這個是高效運維社群現在正在做的DevOpsMaster的認證培訓，也是從歐洲的一個相當於非常強的一家機構引進來的培訓課程。

當時我去參加這個培訓之後，對整個DevOps的知識體系有更全面的理解。我之前一直直接整個DevOps只是在這個環節，但是現在不一樣了，為什麼要延伸到這，要有敏捷，一直要延伸到前面，就是說整個DevOps一定要為業務負責，不僅僅是在工程領域。

這裡可以看到整個交付的生命週期的過程，整個過程對映到不同的環節，這塊一定是訓練有素的敏捷，包括現在有很多同事專門在做校驗，包括之前在用友也有專門校驗的團隊。持續交付就是我之前在用友重點攻破的內容，由於會使用全開源的技術，去打造一條持續交付的鏈條出來，為了讓我們的問題更快的去暴露，更快的去把一個質量跟高的包打出來。

在之前沒有做這塊，很多時候由我們手工去做的。很多時候在做現場的時候，完全是由我們的開發人員自己把這個包打出來，大家可以想象這個質量會有嚴重的問題。

下面是整個的知識基礎，精益還有TPS這塊，包括自動化的內容。

用心的同學可能會看到上面缺了一塊，開發之後直接是部署，為什麼沒有測試，當時我們在學習的時候，明確強調了，我們的測試是一種能力，要嵌到每一個環節，要把測試融入到整個開發過程當中去，不僅僅是到最終部署然後測試這麼一個過程。

我們現在的流程是，因為我們做智慧硬體，大家可能說這個過程是比較複雜的，我們的一次編譯可能都需要一個半小時的時間，而且在過程當中可能會產生大概200G左右的檔案，打出來包也在10G以上。對我們來說失敗的成本是非常高的，所以我們要用內建質量的方式。

在編譯的環節，我們要把很多的質量檢查的東西做進去，包括我們後來做一些掃描，還有編譯過程當中做的findowner的機制。在做需求的時候，可能測試也要幫助產品經理去分析一些問題。

DevOps能力模型，研發運營一體化。核心的要有能力共享，要有內建質量，自動化，還有反饋。這裡面要提一下責任共淡。

開發和測試，質量非常重要，一定要把它做起來，而不是說僅僅是CM的工作、測試的工作或者開發的工作而已，大家共同承擔。視覺化。

整個你在做的過程中，一定要把你整個的過程還有你的質量都要可視化出來，過程比如說使用看板，看板接入到運維的環節，可以把很多東西和整個的交付鏈條清晰的看出來。包括質量，度量程式碼質量，還有通過專門的報告去度量程式碼的功能和質量。敏捷研發大家很熟悉，持續交付，技術運營，比如做監控預警，去做日誌的管理，去做自動化部署。

前面把DevOps的一些基礎的東西給大家做了一個簡單的介紹，DevOps本身是一個比較大的概念，涉及到的東西也非常多，讓大家有一個整體的瞭解，知道它有什麼內容。這塊還是想跟大家提，DevOps雖然非常大，但是大家可以從自己手上的工作開始做起。

過兩天會去深圳GOPS大會，通過絞殺者的模式，為什麼叫絞殺者，熱帶植物有一種絞殺的現象，種子落在樹上，它可以逐漸長出寄生根，把原來的樹咬死，形成新的樹木。核心的意思是從大家的工作當中入手，從持續交付去做，更多的往我們的運維側做一些工作，能把一些包括我們的質量和編譯的資訊，更多的延伸，讓我們開發更多的瞭解。

後面講一下從DevOps角度怎麼看雲端計算。從我的角度認為，雲能帶來的對DevOps的兩個維度。

一個是快速構建應用，因為DevOps核心的是要幫助我們的業務實現，尤其是中小企業或者剛剛初建的企業，可以開素構建一個應用，build完之後去做度量，知道客戶到底買不買賬，然後我們再反過來做學習的過程。

快速構建應用，之前在用友做的時候，大家剛開始用阿里雲的時候習慣的使用他的ECS，直接使用他虛擬機器，包括資料庫都搭載在虛擬機器上。其實我不贊同這種方式，需要更多使用雲服務，包括也有很多研發雲這樣的內容，可以很快定製出來一個移動端的App，包括像騰訊裡做雲服務的測試。還有持續交付這塊也有很多的雲服務。

運維這塊也有很多雲服務，大家都知道做DevOps這塊有個叫老王的人，非常厲害，他們自己開發的DevOps的產品，也有云上的服務，很容易幫助我們做快速的構建應用，包括運維的過程都會有。

規模化，有個例子，滴滴在做了一段時間之後，尤其是在打價格戰的時候，當時預估只有10%的使用者增長，後來500%，整整50倍的增長。現有的這種技術能力已經沒有辦法做支撐，聯絡到阿里雲做了一個7天7夜快速的重構，把整個滴滴的架構搬到了雲上，實現了非常快的規模化。

包括新浪微博做Docker和阿里雲集成的時候，也是基於這樣的考慮，因為現有的機器已經沒有辦法再做，甚至我們的機房已經沒有任何的位置，這時候需要去使用雲的一些能力去做到快速的規模化。

這是我自己結合我們的經驗總結出來的DevOps與雲典型實踐，並不成體系，我基於傳統的IaaS、CaaS、PaaS、SaaS的模式。

第一個，在IaaS層或者CaaS，我們有一個非常基礎的實踐，基礎設施即程式碼。在美國有一個競爭對手，《紙牌屋》就是他們出的，他們雲端計算用得是爐火純青的一家公司，DevOps也是用得爐火純青，交付速度非常快。他們就是使用阿里雲，在每一次應用部署的時候，他不是在他的CaaS當中重新再去部署一個應用，而是完整的替換，這裡面節使用到了基礎設施即程式碼這塊，他使用了亞馬遜的AMI這樣的技術，通過檔案去定義映象是什麼樣的。

包括之前看過基於AWS其他的一些實踐。包括我們現在研發，安卓編譯的效率對機器的效能要求非常高，我們在提供這種虛擬化的研發環境，在虛擬化的研發環境當中，我們通過OpenStack的基礎映象，加上ansible，把整個開發環境定義出來。整個安卓系統要基於晶片，類似於高通晶片有很多型號，這樣我們完全把它版本化，可以很容易研發出來任何版本的開發環境
。

同時，剛剛提到不可變基礎設施，他不會在一個虛擬機器裡部署應用，是把虛擬機器直接砍掉，然後直接部署一個新的。

PaaS這塊，後面有一個雲原生應用，包括12-Factor。SaaS剛提到了，這裡可以快速幫我們實現業務的交付，包括研發雲、測試運、運維雲還有持續交付雲。這裡要提到後端即服務，為了快速幫助研發，幫助產品去定義出來一個他們自己的產品，包括即時通訊這樣的服務，還有其他的一些訊息服務之類的。後面是Serverless。

講一下雲原生應用，一定要把自己的應用往雲上做設計，你不是要成為像BAT這樣的規模，那你把你的應用長在雲上，沒有問題。

這是一個AWS的架構，有智慧路由、負載均衡、應用服務其，後面還有具體的快取，還有儲存、CDN、監控預警、訊息服務、NoSQL、郵件，所有的都是基於AWS的服務來做，不是說自己去搭一個。

別人的技術一定比你牛，別人把這個東西做得很可靠，而且很多人支撐這樣，所以你只要快速把業務實現出來。這是樂視自己的，做了一個LeEngine，這邊還沒有用，用了一些其他的服務。

比如CDN，我們有全球研發中心，剛剛提到，一個包就10G，每天有很多軟體包，需要同步到美國、印度，這時候用他的CDN分發，包括讀資料庫這塊，我們不再自己去運維資料庫，我們自己把MySQL做一個高可用的叢集，難度是有的，運維成本非常高，所以我們採用雲服務。

這個是雲原生基金會，他們整理出來整個的雲原生的全景圖。在每個領域我們基礎設施，還有編排、應用等都會有這樣的一些工具平臺在裡面。

剛剛提到12因子，我本身是做持續交付，這個東西被認為是非常重要的一塊，我們要按照12因子設計出來的應用架構就符合雲原生架構的應用模式。基準程式碼，一定大家有一個共同的程式碼庫。

在開發環境、生產環境、測試環境、預釋出環境，我們配置做部署舊好，因為我們的程式碼加上配置，就形成真正在線上應用的版本。這裡面提到構建、釋出、執行，一定要嚴格走這樣的過程，而不是說大家直接倒出來一個東西就完了，包括後端服務，一定要使用更多的SaaS服務來做這件事情。

相信很多做技術的同事都會有這種感覺，什麼東西都要自己來一把，尤其是很多大公司更是這樣，一定要自己做，沒有那個必要，大家去使用更多的後端服務就好了。

推薦幾本書，《精益企業》，非常好的一本書，之前老王同學極力推薦，裡面包括了持續交付的內容，包括企業應該搜查探索的還是發展的過程。《鳳凰專案》，之前高效運維還有沙盤定製版，這裡面把整個IT交付的過程描述得非常清晰。還有《DevOps Handbook》，這是DevOps之父寫的。這個叫《遷移到雲原生應用》，這裡面12因子也做了描述。

文章來自微信公眾號：雲端計算開源產業聯盟