武漢是我國重要的科研教育基地，普通高校和本科院校數僅次于北京。10月29日，清晨的武漢下著淅瀝瀝的小雨，為已入冬的城市平添了幾分寒意，但是在光谷萬科中心卻有那么一群人冒雨因華為HDG而聚到了一起，他們就是樂于求知的開發者。

這已是華為HDG的第七站，也是演講與分享時間最長的一站。講師演講的精彩，開發者們提問更是踴躍，交流與分享高潮不斷。他們究竟聊了些什么呢?

演講中談到DevOps，華為軟件開發云高級架構師曾正陽表示：“DevOps給開發者帶來研發模式的革新，開發人員和運維人員協同合作，確保軟件高效交付的同時可以促進產品更快的面向市場，更快的得到反饋，提升軟件迭代周期。”

以下是他的現場演講實錄：

大家下午好。自我介紹一下，我之前在京東做了很多年的云計算，后來來到華為做同樣的事情，DevOps要把比較成熟的工具跟方法論以及整個流程搬到整個云上面去，所以我們做的事情都一樣，所以今天給大家分享一下。

下午的議題分為這幾個階段：第一點講一些概念，可能是DevOps、CD、CI，可能大家對這個概念看的比較多了，但實際上它官方的或者大家理解正確的是什么意思，有點疑問。第二點這邊做一些澄清，業界談到IBA或者亞馬遜他們怎么做的。第三點比較重要的一些點。第四點華為內部怎么做開發、DevOps，為什么要做DevOps。第五點在外部也有一個DevOps的供應鏈，已經在華為供應鏈上面承載了。大概這幾塊，第一大家看到風格，滿屏的風格是典型的華為風格，這是大頭制。之前一般寫拼音不這么寫，就寫一句話，來到華為之后受到這個影響，所以屏貼滿了，也沒改。

先講一下概念。什么是DevOps，因為網上資料太多了，我們截取兩個最重要的，一個是維基，一個是Gartner。這兩個是比較權威的，他們怎么講。維基里面講是個過程方法和系統總成，所以它是一個總稱，是一個聯合的東西，它能夠促進運維跟開發之間的一些溝通協調。Gartner怎么講，它其實有一樣，它基于里面的一個敏捷宣言，基于敏捷，從敏捷出發的，從開發的敏捷走到運維敏捷，基本上這樣一個概念，所以兩者我覺得核心是一樣的。看看他們三個專家怎么看，第一個是DevOps名詞發明者，他提出DevOps這個詞。他覺得DevOps是打破開發和運維之間的一個孤島，我們一般做開發，開發就開發，運維就運維，兩個是一個部門強，所以兩邊打架扯皮還是比較嚴重的。DevOps提出來一個實踐，他打破了兩個部門之間的一個障礙，起到一個互相協作。

第二個人說DevOps能夠提升入組頻率，重點是要聚焦在我們更快地把某個功能、某個產品上到生產環境，然后讓用戶能夠快速地反饋，從而提高這個交互的效率。

第三個人講的是如果沒有開發和運維之間的集合配合，持續交互變得非常難。什么意思?這個人是《持續交互》的作者，他的理解有點偏頗了。怎么講?DevOps是CD的前景，因為他是CD書的作者，所以他提出來DevOps是CD的一部分。但是我覺得在日常概念里面，CD跟DevOps涉及到什么樣的關系，一會兒會講到。

第三部分講到行業的的觀點。還有人提取了三個：亞馬遜、微軟、IBM，提取的差不多，大家看一下就知道了。后面有講到他們三個公司是用什么樣的工具鏈、什么樣的流程來去承接他們的理論，所以概括起來什么是DevOps，它就是一種文化，流程和工具的補充。我們講的這個文化怎么去改變?每個公司都不一樣，所以沒有標準這個文化要怎么做，流程每個公司不一樣，跟業務相關的。這個工具能夠幫助DevOps，能夠推動這個DevOps的開發。工具鏈整合是可以到處分享，但是文化跟流程是屬于內部的一部分，可能要改進一下。這是一個統稱。它從敏捷的開發走向敏捷的運維和敏捷的業務，這個都會講到。

為什么是這三個呢?首先是從敏捷的開發再到敏捷的運維跟敏捷的業務，它們三個是什么關系?大概先講概念，有點不是那么形象，我們看看，講一下歷史。DevOps的起源，基本上從2009年開始，很多專家提出促進的一些活動，比如一天要部署10次，以前都是一個星期、兩個星期或者一個月、兩個月，甚至產品大的半年布一次。它要求一天布10次，這個怎么做到呢?肯定要從DevOps兩方面要考慮的。下面還有精益之類的，所以DevOps是一個從敏捷開發，它起源是敏捷，敏捷開發越來越快，交互結構越來越快，運維怎么辦?要促使運維，每年開發快了之后，運維太慢了，所以會從開發促進運維，迫使運維加快腳步，讓運維做的更好，所以做敏捷的運維。

敏捷的業務怎么講?敏捷的業務是你開發快起來，運維也被你逼得快起來，之后能把一些特性、功能更快地上到生產環節，供用戶來用，供用戶來提供一些反饋的意見，所以它的業務就能夠很快地回到業務建議，包括一些Buy、產品的形態的一些問題都會很快地反饋到研發那邊，促進更快地業務開發，所以上一節也講到從敏捷的開發到敏捷的運維、敏捷的業務，具體要怎么做呢?開發跟運維之間是怎么去合作，簡單地說開發跟運維一定要協作，他們到底怎么協作呢?比如說DevOps，大家都缺工人，我直接把所有的工作扔給開發，開發自己做運維，做的也不對。運維丟給他以后不管，這個圖就講到開發跟運維怎么去協作。第一研發要把產品交付給運維，要傳遞一個產物，交付件或者是軟件包，交給運維，更好地促進運維氣氛，包括部署、監控、反饋、系統的一些迭代。同時運維也要反饋回來。以前我們基本上是開發者開發一款軟件包，就扔給運維，全部不管了，有問題運維打電話，你這邊出問題了，趕快解決，所以這兩邊幾乎不干涉。這邊運維必須要反饋給研發，因為研發在線上的一些問題，用戶反饋連接問題，比如說PBS太低了，還說頁面太亂了，還是其它的問題，運維要及時反饋給研發，這兩個是互相反饋的。這是一方面。

另外一方面，他們既能互相傳遞，就是開發者把整個業務要到運維，到運維之后一開始就會參與到業務的開發當中，整個業務的架構和初期的架構會怎么去搭合理。運維從一開始就要參與到研發過程當中，從研發的角度來說運維有些規范，肯定要提前去遵守，這是運維傳遞給研發的，你要根據我的一些要求來做，這樣應用不會那么容易掛了，容易規范。在前期提供腳本、檢查腳本，這個在目錄的什么結構，定一下規范，這是運維傳給開發的一些技能，所以兩邊互相參與的。這樣的話DEV和OPS兩者目標是一致的，以前開發跟運維目標不一樣，開發要盡快，我要快，運維是我要慢，我要維穩(保持穩定)。DEV之后有一個文化，這個文化怎么驅動呢?我們要把他們兩個弄在一個團隊里面，他們的目標是一致的，這樣的話目標一致，做事情比較好辦了。

它們之間前后有什么區別?以前做的開發基本上都是計劃比較多，計劃比較長，像半年、一年，這都是很常見的。會議也多，每天一堆會議，會議要去做什么?要去猜測用戶的行為，猜測用戶需要什么，所以都是猜測，以假設為依據，專注于計劃，缺乏一些合作，組織也不靈活，運維是運維，可能開發、運維、測試和其它部門，分布在不同的部門，所以組織不太靈活，最關鍵是流程，流程特別復雜。要從一個開發到上線開展要通過不同部門的審批，開一次會領導審批。

用了DevOps之后，流程簡化了，文化的整改，能做到這些。DevOps之后把文化和流程統一之后，會議肯定少了，交付也快，關注用戶的交付價值，同時團隊也比較專注，比較靈活，不像以前那么死了，基本上這是不同。

我們一般講到CD、CI、DevOps，他們到底是不是一樣，是不是互相包含一些問題。這邊講到2個CD，CI到開發、運維、測試、部署到驗證這幾部，這是CI的范圍。CD就是持續交付，持續交付跟持續部署的區別在最后一步，你是不是自動化到生產環節，所以交付到驗證之后可能會手動地，經過一系列流程，后面就不管了，怎么交付到生產上去就不管了，只是初步出了這個軟件包滿足要求就截止了，這是Devlivery的一個范圍。持續部署就要全程自動化，這是持續部署的含義。DevOps跟它有什么關系呢?DevOps實際上是一個環，但是它們三者，DevOps跟2個CD是一個活動，一步一步地，DevOps是個活動，一個流程的環，它從研發到部署之后，它通過操作監控，要把這些意見、用戶日志反饋到研發，研發再從中間提取一些需求，來進行新一輪的迭代，所以它不是一個單向的，這邊相當于是一個單向的。所以它們之間其實沒有任何的包含關系，它們之間的概念不一樣，包括CD、CI是一個活動，DevOps是一個文化流程，統一的一個簡稱。第一頁講到(14：50)的作者，他認為DevOps是CD、CI運轉，這樣顯然是不合理的。

講到DevOps的收益，講前面兩個，第一個收益占前兩者一個是提升軟件的部署質量，一個是更迭軟件的發布。為什么提升部署質量呢?很多人認為運維布得越少，可能錯誤也少，布得越多難道錯誤越少嗎?這個怎么去算出來呢?剛才講到敏捷的開發會促進敏捷的運維，以前因為布一次基本不會出現問題了，運維也不會出現什么問題。一天布10次之后，運維整個系統和工具是不是要做一些調整和改進呢?從這個層面來說，運維的能力是越來越強，對敏捷的開發促進越來越強，這樣普及量就會越來越高。

下面采用DevOps的原因，就是更快交付跟部署，減少停機。為什么減少停機呢?我們一般的做法一個月、兩個月升級一次，升級一次意味著一兩個月它的功能顆粒度很大。沒法做到不停地升級某一個大的產品，它可能是一個大的產品，可能是一級一級升級，我一般是半夜升級，他會影響，但是影響是最少的。平均的話，如果有跨時區的、國外用戶怎么辦，肯定會受影響。

總結一下，開發跟運維之間一些合作，更快地交付更可靠的軟件，簡單來說就是又快又好，怎么樣做到又快又好?甚至DevOps很重要20%是技術，技術是文化。這個文化剛才講了，文化每個公司各異，但是技術是目前無形的，特別一些工具都會有DevOps，但是它比較零散。一般都會把這些開源的或者已有的工具拼裝起來，整個流程串起來，實現一個完整的工具鏈。這是講到DevOps的共贏和收益。

前面講的DevOps的概念，還有它的好處，后面講到華為為什么會引進DevOps，這是有原因的。第一，業務形態發生變化，我們現在新出現的互聯網的一些浪潮和云計算、終端像手機的消費者產品，這個業務發生變化了，商業模式也發生變化了，以前是運營商那邊開發一個產品，運營商自己來管。現在商業模式變化，運營商其實不想管那些，他要求我們跟華為一起管業務。如果運營商自己來管，他發現問題，再反饋給華為，華為再市場上研發到后面開發，他們有一個聯合運維。聯合運維是什么概念?華為跟運營商一起來運維這個系統，如果出現問題就很快地去發現問題，做一些落實。商業模式也發生變化，另外我們研發的模式也發生變化，包括一些IPD，現在是敏捷，包括協作很多，這些因素決定了我們要有DevOps來算周期，快速有業務價值，把用戶體驗快速地帶回來。

這里講到華為為什么會用DevOps。這是業界的典型的解決方案，剛才也講了，這個是講了，華為還沒有講。剛才講到三個公司的解決方案，IBM有一個Bluemix，可能大家比較熟，它是把工具鏈服務化，做一個共有云。Bluemix前兩年比較火，最近沒關注到，在國內可能并不怎么樣，在國外特別火。微軟是新起來的，他們自己就圍繞著Visual Studio、Windows那一套，圍繞著Windows系列來做一個自己的生態系統。亞馬遜怎么做呢?亞馬遜沒有特別強調DevOps這個詞，但是會把內部的服務會產品化提供出來，提供在云上讓大家用。它最初剛開始提供的一個服務加S3，S3是一個整組。

微軟的做法基本上跟亞馬遜差不多，把他們這些服務全部聚焦過來，我們重新做了一套，后面會講一下華為的工具鏈怎么做的。咨詢公司不看了，沒有差異。

這邊總結關鍵的實踐，馬上過一遍，第一個倒過來講，第一個是環境，這個很重要，因為要完整的DevOps，為什么小公司做不起來呢?小公司就是覺得自己是不夠的。最重要是基礎設施即代碼，什么意思呢?我們底層一定要虛擬化，能夠很快地做一些升級、數據庫，很快地做一些擴容、減容，這些都是云化要支持的。另外它DevOps的前提的出發點，前面一個前提我們要把這個服務化。因為我們剛才講到一個產品要一年、半年再發布，很多機遇都失去了。為什么華為手機更新這么快，兩三個月一個手機出來了，必須要快，不快市場就失去了。我們要把這個產品拆成各個服務，然后再把各個服務成各個微服務，每個微服務單獨進行一些DevOps小批量的發布、升級，盡量把它B型化。所以現象6個第一個是小批量的發布越來越多。

大任務分解成可以迅速完成的小任務，微服務化的架構模式進行敏捷交付，細粒度持續向生產環節發布。亞馬遜怎么做，亞馬遜提供了一個面對供應鏈可以自己能夠實現工具鏈，每一個服務都是單獨的流水線，流水線從構建、測試、發布都是單獨的。服務跟服務之間沒有任何的耦合，這是服務間的一些關系，另外拆開之后它不能耦合，如果一耦合的話還是做不到并行。如果耦合，每次發布還是要把各個服務做成整體的包往外發，這樣不大好。這是服務之間的。

服務內部一樣的道理，因為你要把這些需求分成一個迭代，一個小迭代，滾動地去做一些開發，這是小批量的，把任務盡量細化，盡量能夠做一些頻率的開發。這個部署自動化很重要。部署自動化以一致的方式自動化將應用部署到各個環境，什么意思呢?一次打包，隨處部署。我們經常碰到什么情況呢?你測試完、開發完、生產完以后，可能要打包，它們之間的配置都不一樣，所以要重新打包，這樣就違背了這個概念，我們要一次打包，能夠在各個環境里面，α、β、γ各個環境里面部署，一次打包，多次部署，而且還不能做一些手動修改配置，你可能做一個配中心或者一些其它手段，用黃金變量去解決問題。為什么會這么多環境呢?包括功能測試、集成(25：30)這些環境，就是最快地測試先做完，比如說你到α環境，功能測試好，測出來有問題，立馬就能夠做一些回穩，這樣能夠避免到生產之后發現問題。每一個環境都有它的意義，等會講到三個環境特別是什么意義。這是自動化部署，我們會講到α、β、γ，還有(26：00)這上面幾個概念應該是華為內部的一些說法。

灰度發布。灰度發布，大家應該都比較清楚。一個新版本上了之后，100臺機器全部上100臺機器，如果有問題，全歇臺了。昨天我上1%，1%上去之后第一分析流量會少一點，比如100臺先升1臺，整個啟動流量是有限的，所以會觀察產生的數據、日志是否能符合你的預期，技術判斷來不斷擴展你的范圍。如果你看到1%，可以指揮1%，不用備份整個系統，所以DevOps基本上基于用戶來發生的，根據功能、兼容性、并發和性能選定發布批次的范圍，來做一些平滑的發布。

這個分為兩種，一種是灰度部署，一個灰度發布。灰度部署就是在部署的時候不是一下分布的，而是一臺一臺，或者先10臺，后20臺、50臺這樣部署。部署之后你要對外面開放有一些策略，發布一些策略。所以說這個灰度發布的測驗引擎也是比較重要的，所以我們作為DevOps的灰度發布沒那么簡單，你要做一個灰度發布引擎，做一個自動化的部署系統。

監控也必不可少，有三個等級，第一個是那些比較基本的，但是要做到分級監控，應用監控，所以這個是應用級別監控，應用的(28：00)監控。另外你要做一些核心功能的結構，比如說支付的。支付里面占的比重比較大，對支付的功能做一個重點監控，這是監控的范圍。

(圖)這是講到運維。監控講完之后肯定是個數據反饋，你要把線上的問題反饋到研發區，怎么做呢?你要把生產環境用戶行為，服務它本身的一些業務日志全部采集到，采集到以后，后臺應該有一個大數據平臺來做一些分析，做一些匯聚，分析出這些原因，比如用戶哪個頁面點得最多，用戶在論壇里面反饋的這些問題和關鍵字，比如說頁面太慢、太丑了或者怎么樣。做一些大數據的分析，產生一些報表之類的，或者去挖掘用戶潛在的一些預期，可以通過大數據平臺來分析的，這個是要反饋給研發的，所以這塊運維必須要做。監控要反饋，運維不只是部署，部署完了后面還有反饋，所以這是講到比較重要的一些實踐。

下面講到華為的解決方案，特別是內部的，內部有一個DevOps工具鏈完整的。它分為兩大塊，被理解為是一個研發區的流水線以及生產區的流水線。研發區的流水線提到α、β、γ三大塊。生產區到外面去了，因為華為內外的網絡是隔離的，所以要分內部和外部。中間解決從研發到生產，中間是流程，剛才講到DevOps作為三塊：文化、工具、流程。(圖)這個圖一個是工具，一個是流程，比如要數據庫、專業鏈、監控，把這些勾起來，勾起來就會產生一個代碼的框架模板。每個產品線都不一樣，先生這個產品線的框架模板，比如說這個產品是基于MIC來改造的，可能里面一些都改，你有自己的框架，要針對自己的框架之后自動提到里面去，這邊有一個代碼倉庫。你會通過IDE下來代碼，進行一些自己的開發。同時這個服務的設計，剛才講到服務的框架，服務的框架照搬亞馬遜的那一套。

第二步就是一般來說我們上一個產品會涉及很多部門和合作人，今天找一個人審批，萬一他請假了或者不在，或者沒空，明天再找一個人不在，做了一個自動化。第一步我們會把自動化指標全部采集到，做一個參考，以前怎么做的，以前華為通過在各個系統里面去倒出質量的報告，然后做一個Word文檔，做一個附件貼在那個系統里面。我們現在改了，做了自動化采集，從各個系統里面去采集出來，他們就不用去貼了，領導看了，你不知道貼出來是真的、假的。但是通過自動化采集之后，就不更改了，而且比較客觀的。有一次的審核，一次審核把所有相關人叫在一起，我們開一次會就夠了。這樣每一個指標的采集自動化有一次會議就沒了，沒了之后就會說明這個版本符合效果。往下的話就是一個變更管理，因為上到生產環境，生產環境跟運維頁面式開發的，這邊是運維，運維要什么時候操作呢?所以面臨一個管理，你符合要求，不一定表示你現在就要上線，可能白天10點、11點壓力比較大，可能會到下午的時候操作，所以有一個運維管理。運維管理通過之后運維才能進行操作。谷歌目前比較流行什么?谷歌SIE，它基本干這活，基本上研發跟運維銜接的一些工作，都是它來包的。這樣研發流水線已經完了，通過流程的自動化到生產環境。

生產環境的流水線通過一個消息機制來判斷，第一變更管理通過，第二你的包到位了，包會到版本倉庫里面去，按照這兩個到位就會自動觸發生產環節流水線。生產環節流水線就比研發復雜一點，剛剛那個圖1%、30%、100%會不會去發布?不像前面可能是自動的到每一步，如果測試之后就會自動的。生產環境可能手動的，1%之后你會看一下可能手動的流程，你去頁面看一看，點一點也好，如果你覺得沒問題，是自動的，這是可選的，一直到生產環節，生產環節用的比較多，1%、10%、30%、50%、100%。完了之后它有一個(37：15)所以生產環境一直在監控服務的SOA，包括它的KBS、TP99、成功率和監控。監控完之后會自動提單。比如我在生產環境自動化測試發現一個問題，它會自動提交到一個工單系統，工單系統SIE看到之后，它覺得這是個問題，就會把這個問題反饋到需求跟管理第一個環節，所以就把整個緩沖起來，這也是SIE的數據分析，剛才也講到一些數據分析來作為新一輪迭代需求的一個輸入。只能這樣講，沒有產品的截圖，大家如果要了解比較細的話，內部一些細節，包括大數據怎么做的、部署怎么做的，部署做什么，使用什么開源工具，這些點跟(38：25)站業界或者跟其它公司有區別的地方就是(38：32)跟亞馬遜，亞馬遜的Bluemix不是統一的。華為內部產品線比較多，所以我們服務商界有一個擴展功能就是用戶產品線可以自行定義它的框架，提供統一的框架，上他們可以做一個插件。

部署系統也一樣，整個華為公司不可能只用一個部署系統，所以部署系統對接行業不同的服務系統，包括虛擬機、容器、特別的，都會在這個平臺支撐。所以底層會華為的實際情況密切相關的。當然底層還比較重要，底層是提供云化的。基本把整個線弄完以后，華為要適配各種各樣的產品線，同時還要從頁面上要保證用戶進來，他覺得是一個產品，也就是部署系統，你聽到這個DevOps整個系統，我選任何一個部署系統它的頁面都是一樣的，它的配置都是一樣的，所以能夠做一些抽象化。這也是這個平臺的優勢。

講到內部的一些東西。內部我大概統計了一下，一共有16個獨立的服務。每個服務有十幾個微服務，加起來可能有兩三百個微服務，來組成這樣一個大的系統。這是內部的，所以拿不出來，我也沒辦法。華為為什么有區別呢?華為內部的業務更復雜，產品可能更多，對外稍微聚焦一點，它聚焦在開發上，包括它的實現方式不用考慮兼容系統，比較純粹。基本8個方面，通過項目管理、IDE管理，IED管理就是項目管理、配置管理、代碼檢查、編譯、構建、測試、部署、發布。8大作用目前已經正式對外公測，所以大家可以上到軟件開發上面做一些體驗。

(圖)上面講到一些部門，剛才已經涉及到了。這也是一樣，從這條鏈開發環境、測試環境、類生產環境、生產環境都可以在華為企業云上面來承載，同時不光有這條鏈，這條鏈讓你開發之后，這個平臺還有企業云作用，包括你的存儲、RDS，如果需要容易容器的話，上面也有。所以它形成了一個開發者，基本啥都不缺了，這是一個狀態。

DevCLoud到底怎么用?我們有一個Wed客戶端和移動端、IDE，我們一般都用本地的，但是本地的只能做一些配置，比較方便。如果換臺機器，換到別的機器，到另外的環境怎么樣，所以我們這邊提供的Cloud IDE，同時你有自己的IDE把這個插件放到自己的IDE里面去，能夠方便地跟這些系統進行交互。IDE插件跟他們對接，我們這樣提供了一個API，有這個渠道，這個就是體驗。現在我們開發的公測階段，大家可以體驗一下，還有一些獎勵。

現在項目管理和配置管理，配置管理就是DITER(音)。它體驗有些限制，比如說項目管理。項目管理目前支持免費的5個人，還有DITER(音)免費的話是600兆，后面還有一些測試、編譯，還有其它的要求，可能免費的話有些限制，但基本上夠用，大家可以試用一下。

(結束)