《專家觀察 | 景韻：“云在DevOps中的典型運維場景與實踐”》要點：
本文介紹了專家觀察 | 景韻：“云在DevOps中的典型運維場景與實踐”，希望對您有用。如果有疑問，可以聯(lián)系我們。

由工業(yè)和信息化部指導,中國信息通信研究院主辦,業(yè)界知名組織云計算開源產(chǎn)業(yè)聯(lián)盟(OSCAR)承辦的2017全球云計算開源大會于4月19日-20日在北京國家會議中心順利召開.本文為本屆大會嘉賓分享的大會演講速記內(nèi)容,敬請瀏覽.

嘉賓介紹：景韻

公司職務(wù)：樂視致新SCM工程師

大會演講速記

我叫景韻,來自于樂視,現(xiàn)在在樂視致新負責智能硬件這塊軟件配置的一些業(yè)務(wù).

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

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

首先想問一下,在座的聽說過DevOps的有嗎?看大家都比較靦腆.現(xiàn)在國內(nèi)的很多大型企業(yè)、小型企業(yè)都在做DevOps.我之前在內(nèi)部講這個.

我們了解DevOps的人都會聽說過DevOps年度報告,這是2016年最新的數(shù)據(jù),我們在樂視內(nèi)部講DevOps時候一定會給大家提這個.

現(xiàn)在很明顯,大家可以從圖上的數(shù)據(jù)看到,一個叫高績效,中等績效,一個是低績效,很明顯大家能看到差距是非常大的,包括這種部署頻率.

部署頻率和交付時間縮短很明顯,比如我之前在用友,可能一年會部署一次,但是現(xiàn)在不一樣,在線服務(wù)的一線會部署很多次,需求交付到我們手上之后,別人可以很快去交付,包括市場的變化,還有用戶的需求的變化都會影響到我們最終交付.

后面是變更失敗率和故障修復時間,這塊有一個非常明顯的感受,我們在處理一些故障的時候,分分鐘都有金錢上的內(nèi)容,比如我們做互聯(lián)網(wǎng)P2P的,他宕機一分鐘就會有多大的損失.

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

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

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

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

大家可以看到這是維基百科上官方的概念,非常抽象,涉及的角色非常多.關(guān)鍵詞是溝通、協(xié)作與整合,我們在提DevOps的時候,很多時候我們會去提DevOps像一種文化,就是因為更多強調(diào)大家相互之間的溝通和協(xié)作,目的很清晰,就是為了更快速的交付產(chǎn)品、軟件和服務(wù).

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

我們之前提到軟件危機之后,大家在總結(jié)一個軟件工程的疑慮,大家希望通過工程的方法解決我們的軟件危機.

日本豐田企業(yè)有一個GPS豐田的制造系統(tǒng),這里面DevOps也會去借鑒GPS當中的經(jīng)驗,從GPS這塊發(fā)出了精益這塊的內(nèi)容,精益衍生出精益創(chuàng)業(yè).

我們提到TPS,因為它是在生產(chǎn)制作行業(yè),我們把GPS當中自動化、看板這些應(yīng)用到軟件和互聯(lián)網(wǎng)行業(yè),我們說它相當于DevOps一個具體的應(yīng)用.持續(xù)集成,一旦遇到問題一定要停下來,修復它.

精益具體的事項,包括這后面精益創(chuàng)業(yè)里提到要度量、學習的過程,這個就會把它的工程化,相當于我們要去使用它當中的一些實踐.

DevOps要解決的是打造一條服務(wù)的供應(yīng)鏈,通過這條供應(yīng)鏈幫助我們團隊交付真正業(yè)務(wù)的價值.敏捷,解決了我們研發(fā)測試這個環(huán)節(jié),還有前面產(chǎn)品這塊的內(nèi)容,包括需求怎么去寫,怎么去拆分的內(nèi)容.敏捷應(yīng)用到端到端,它不僅僅是到這個包打出來就ok了,一定要部署到線上.還有ITIL和ITSM.

這個是高效運維社區(qū)現(xiàn)在正在做的DevOpsMaster的認證培訓,也是從歐洲的一個相當于非常強的一家機構(gòu)引進來的培訓課程.

當時我去參加這個培訓之后,對整個DevOps的知識體系有更全面的理解.我之前一直直接整個DevOps只是在這個環(huán)節(jié),但是現(xiàn)在不一樣了,為什么要延伸到這,要有敏捷,一直要延伸到前面,就是說整個DevOps一定要為業(yè)務(wù)負責,不僅僅是在工程領(lǐng)域.

這里可以看到整個交付的生命周期的過程,整個過程映射到不同的環(huán)節(jié),這塊一定是訓練有素的敏捷,包括現(xiàn)在有很多同事專門在做校驗,包括之前在用友也有專門校驗的團隊.持續(xù)交付就是我之前在用友重點攻破的內(nèi)容,由于會使用全開源的技術(shù),去打造一條持續(xù)交付的鏈條出來,為了讓我們的問題更快的去暴露,更快的去把一個質(zhì)量跟高的包打出來.

在之前沒有做這塊,很多時候由我們手工去做的.很多時候在做現(xiàn)場的時候,完全是由我們的開發(fā)人員自己把這個包打出來,大家可以想象這個質(zhì)量會有嚴重的問題.

下面是整個的知識基礎(chǔ),精益還有TPS這塊,包括自動化的內(nèi)容.

用心的同學可能會看到上面缺了一塊,開發(fā)之后直接是部署,為什么沒有測試,當時我們在學習的時候,明確強調(diào)了,我們的測試是一種能力,要嵌到每一個環(huán)節(jié),要把測試融入到整個開發(fā)過程當中去,不僅僅是到最終部署然后測試這么一個過程.

我們現(xiàn)在的流程是,因為我們做智能硬件,大家可能說這個過程是比較復雜的,我們的一次編譯可能都需要一個半小時的時間,而且在過程當中可能會產(chǎn)生大概200G左右的文件,打出來包也在10G以上.對我們來說失敗的成本是非常高的,所以我們要用內(nèi)建質(zhì)量的方式.

在編譯的環(huán)節(jié),我們要把很多的質(zhì)量檢查的東西做進去,包括我們后來做一些掃描,還有編譯過程當中做的findowner的機制.在做需求的時候,可能測試也要幫助產(chǎn)品經(jīng)理去分析一些問題.

DevOps能力模型,研發(fā)運營一體化.核心的要有能力共享,要有內(nèi)建質(zhì)量,自動化,還有反饋.這里面要提一下責任共淡.

開發(fā)和測試,質(zhì)量非常重要,一定要把它做起來,而不是說僅僅是CM的工作、測試的工作或者開發(fā)的工作而已,大家共同承擔.可視化.

整個你在做的過程中,一定要把你整個的過程還有你的質(zhì)量都要可視化出來,過程比如說使用看板,看板接入到運維的環(huán)節(jié),可以把很多東西和整個的交付鏈條清晰的看出來.包括質(zhì)量,度量代碼質(zhì)量,還有通過專門的報告去度量代碼的功能和質(zhì)量.敏捷研發(fā)大家很熟悉,持續(xù)交付,技術(shù)運營,比如做監(jiān)控預警,去做日志的管理,去做自動化部署.

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

過兩天會去深圳GOPS大會,通過絞殺者的模式,為什么叫絞殺者,熱帶植物有一種絞殺的現(xiàn)象,種子落在樹上,它可以逐漸長出寄生根,把原來的樹咬死,形成新的樹木.核心的意思是從大家的工作當中入手,從持續(xù)交付去做,更多的往我們的運維側(cè)做一些工作,能把一些包括我們的質(zhì)量和編譯的信息,更多的延伸,讓我們開發(fā)更多的了解.

后面講一下從DevOps角度怎么看云計算.從我的角度認為,云能帶來的對DevOps的兩個維度.

一個是快速構(gòu)建應(yīng)用,因為DevOps核心的是要幫助我們的業(yè)務(wù)實現(xiàn),尤其是中小企業(yè)或者剛剛初建的企業(yè),可以開素構(gòu)建一個應(yīng)用,build完之后去做度量,知道客戶到底買不買賬,然后我們再反過來做學習的過程.

快速構(gòu)建應(yīng)用,之前在用友做的時候,大家剛開始用阿里云的時候習慣的使用他的ECS,直接使用他虛擬機,包括數(shù)據(jù)庫都搭載在虛擬機上.其實我不贊同這種方式,需要更多使用云服務(wù),包括也有很多研發(fā)云這樣的內(nèi)容,可以很快定制出來一個移動端的App,包括像騰訊里做云服務(wù)的測試.還有持續(xù)交付這塊也有很多的云服務(wù).

運維這塊也有很多云服務(wù),大家都知道做DevOps這塊有個叫老王的人,非常厲害,他們自己開發(fā)的DevOps的產(chǎn)品,也有云上的服務(wù),很容易幫助我們做快速的構(gòu)建應(yīng)用,包括運維的過程都會有.

規(guī)模化,有個例子,滴滴在做了一段時間之后,尤其是在打價格戰(zhàn)的時候,當時預估只有10%的用戶增長,后來500%,整整50倍的增長.現(xiàn)有的這種技術(shù)能力已經(jīng)沒有辦法做支撐,聯(lián)系到阿里云做了一個7天7夜快速的重構(gòu),把整個滴滴的架構(gòu)搬到了云上,實現(xiàn)了非常快的規(guī)模化.

包括新浪微博做Docker和阿里云集成的時候,也是基于這樣的考慮,因為現(xiàn)有的機器已經(jīng)沒有辦法再做,甚至我們的機房已經(jīng)沒有任何的位置,這時候需要去使用云的一些能力去做到快速的規(guī)模化.

這是我自己結(jié)合我們的經(jīng)驗總結(jié)出來的DevOps與云典型實踐,并不成體系,我基于傳統(tǒng)的IaaS、CaaS、PaaS、SaaS的模式.

第一個,在IaaS層或者CaaS,我們有一個非常基礎(chǔ)的實踐,基礎(chǔ)設(shè)施即代碼.在美國有一個競爭對手,《紙牌屋》就是他們出的,他們云計算用得是爐火純青的一家公司,DevOps也是用得爐火純青,交付速度非常快.他們就是使用阿里云,在每一次應(yīng)用部署的時候,他不是在他的CaaS當中重新再去部署一個應(yīng)用,而是完整的替換,這里面節(jié)使用到了基礎(chǔ)設(shè)施即代碼這塊,他使用了亞馬遜的AMI這樣的技術(shù),通過文件去定義鏡像是什么樣的.

包括之前看過基于AWS其他的一些實踐.包括我們現(xiàn)在研發(fā),安卓編譯的效率對機器的性能要求非常高,我們在提供這種虛擬化的研發(fā)環(huán)境,在虛擬化的研發(fā)環(huán)境當中,我們通過OpenStack的基礎(chǔ)鏡像,加上ansible,把整個開發(fā)環(huán)境定義出來.整個安卓系統(tǒng)要基于芯片,類似于高通芯片有很多型號,這樣我們完全把它版本化,可以很容易研發(fā)出來任何版本的開發(fā)環(huán)境
.

同時,剛剛提到不可變基礎(chǔ)設(shè)施,他不會在一個虛擬機里部署應(yīng)用,是把虛擬機直接砍掉,然后直接部署一個新的.

PaaS這塊,后面有一個云原生應(yīng)用,包括12-Factor.SaaS剛提到了,這里可以快速幫我們實現(xiàn)業(yè)務(wù)的交付,包括研發(fā)云、測試運、運維云還有持續(xù)交付云.這里要提到后端即服務(wù),為了快速幫助研發(fā),幫助產(chǎn)品去定義出來一個他們自己的產(chǎn)品,包括即時通訊這樣的服務(wù),還有其他的一些消息服務(wù)之類的.后面是Serverless.

講一下云原生應(yīng)用,一定要把自己的應(yīng)用往云上做設(shè)計,你不是要成為像BAT這樣的規(guī)模,那你把你的應(yīng)用長在云上,沒有問題.

這是一個AWS的架構(gòu),有智能路由、負載均衡、應(yīng)用服務(wù)其,后面還有具體的緩存,還有存儲、CDN、監(jiān)控預警、消息服務(wù)、NoSQL、郵件,所有的都是基于AWS的服務(wù)來做,不是說自己去搭一個.

別人的技術(shù)一定比你牛,別人把這個東西做得很可靠,而且很多人支撐這樣,所以你只要快速把業(yè)務(wù)實現(xiàn)出來.這是樂視自己的,做了一個LeEngine,這邊還沒有用,用了一些其他的服務(wù).

比如CDN,我們有全球研發(fā)中心,剛剛提到,一個包就10G,每天有很多軟件包,需要同步到美國、印度,這時候用他的CDN分發(fā),包括讀數(shù)據(jù)庫這塊,我們不再自己去運維數(shù)據(jù)庫,我們自己把MySQL做一個高可用的集群,難度是有的,運維成本非常高,所以我們采用云服務(wù).

這個是云原生基金會,他們整理出來整個的云原生的全景圖.在每個領(lǐng)域我們基礎(chǔ)設(shè)施,還有編排、應(yīng)用等都會有這樣的一些工具平臺在里面.

剛剛提到12因子,我本身是做持續(xù)交付,這個東西被認為是非常重要的一塊,我們要按照12因子設(shè)計出來的應(yīng)用架構(gòu)就符合云原生架構(gòu)的應(yīng)用模式.基準代碼,一定大家有一個共同的代碼庫.

在開發(fā)環(huán)境、生產(chǎn)環(huán)境、測試環(huán)境、預發(fā)布環(huán)境,我們配置做部署舊好,因為我們的代碼加上配置,就形成真正在線上應(yīng)用的版本.這里面提到構(gòu)建、發(fā)布、運行,一定要嚴格走這樣的過程,而不是說大家直接倒出來一個東西就完了,包括后端服務(wù),一定要使用更多的SaaS服務(wù)來做這件事情.

相信很多做技術(shù)的同事都會有這種感覺,什么東西都要自己來一把,尤其是很多大公司更是這樣,一定要自己做,沒有那個必要,大家去使用更多的后端服務(wù)就好了.

推薦幾本書,《精益企業(yè)》,非常好的一本書,之前老王同學極力推薦,里面包括了持續(xù)交付的內(nèi)容,包括企業(yè)應(yīng)該搜查探索的還是發(fā)展的過程.《鳳凰項目》,之前高效運維還有沙盤定制版,這里面把整個IT交付的過程描述得非常清晰.還有《DevOps Handbook》,這是DevOps之父寫的.這個叫《遷移到云原生應(yīng)用》,這里面12因子也做了描述.

文章來自微信公眾號：云計算開源產(chǎn)業(yè)聯(lián)盟

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4152.html