1、海峽兩岸信息產業和技術標準論壇海峽兩岸信息產業和技術標準論壇技技術報告匯編術報告匯編開發開發運維運維一體化兩岸共通標準研究報告一體化兩岸共通標準研究報告DevOps Cross-strait Common Standard ResearchReport中國電子工業標準化技術協會中國電子技術標準化研究院華聚產業共同標準推動基金會臺灣云端物聯網產業協會共同公布目目 錄錄前言前言.1第一章第一章 DevOps 簡介簡介.21.1 創新思維與革新創新思維與革新.21.2 未來發展前景未來發展前景.5第二章第二章 DevOps 發展情況發展情況.62.1 萌芽與緣起萌芽與緣起.62.2 淬煉與演進淬煉與

2、演進.72.3 適用類型漸增適用類型漸增.92.4 組織文化與管理能力組織文化與管理能力.11第三章第三章 DevOps 應用場景應用場景.123.1 研華研華WISE-PaaS/EnSaaS 物聯網云平臺物聯網云平臺 DevOps 實踐實踐.123.1.1 案例簡介.123.1.2 需求分析.133.1.3 解決方案.153.1.4 總結.233.2 Gogolook全球千全球千萬用戶等級萬用戶等級 App 的的 DevOps 架構架構.243.2.1 案例簡介.243.2.2 需求分析.253.2.3 解決方案.263.2.4 總結.323.3 騰訊騰訊社交網絡業務持續運維方案與實踐社交網

3、絡業務持續運維方案與實踐.343.3.1 案例簡介.343.3.2 需求分析.363.3.3 解決方案.373.3.4 總結.473.4 華為華為華為云軟件開發服務華為云軟件開發服務 DevCloud.483.4.1 案例簡介.483.4.2 需求分析.483.4.3 解決方案.503.4.4 總結.56第四章第四章 海峽兩岸海峽兩岸 DevOps 關鍵技術關鍵技術.594.1 Docker 及應用編排技術及應用編排技術.594.2 微服務應用微服務應用.604.3 安全工具安全工具.614.4 自動化測試自動化測試.624.5 流程管理流程管理.624.6 領域型解決方案領域型解決方案.63

4、第五章第五章 市場潛在市場潛在 DevOps 標準化需求標準化需求.645.1 DevOps 標準化需求分析標準化需求分析. 645.2 DevOps 標準化建議標準化建議.655.2.1 基礎標準.655.2.2 產品/解決方案標準.665.2.3 安全標準.665.2.4 服務標準.675.2.5 流程/過程管理.675.3 總結總結.68附錄附錄 1：名：名詞術語對照表詞術語對照表. 69附錄附錄 2：DevOps 共通共通標準研究報告參編單位及人員名單標準研究報告參編單位及人員名單.71附錄附錄 3：中電標協和電子標準院簡介：中電標協和電子標準院簡介. 72附錄附錄 4：華聚基金會和臺

5、灣云協簡介：華聚基金會和臺灣云協簡介. 741前言前言云計算作為信息技術領域的一種重大創新應用模式，是戰略性新興產業的重要組成部分，為推動兩岸云計算標準融合與共通，促進兩岸云計算產業合作與發展的理念，自2013 年 10 月“第十屆海峽兩岸信息產業和技術標準論壇”開設云計算分論壇以來，在兩岸云計算專家共同努力下，雙方在合作機制、標準、產業、開源組織等方面進行了廣泛溝通，成功牽引和帶動兩岸云計算產業及標準務實合作。在 2017 年第十四屆活動中，許多與會學者專家和產業代表一致認為，云服務發展至今已扭轉整個世界、產業、消費習慣甚至生活形態，而背后支撐這些服務的軟件的重要性已不可同日而語，不僅默默支

6、持業務，更成為拓展業務的關鍵要素，也被賦予成重塑企業軟件開發流程和組織文化的神圣使命，而 DevOps 的出現，改變了企業開發與交付軟件的方式，打破了開發和運營團隊的文化隔閡與壁壘，被視為當今企業轉型的有力工具，包括 Amazon、Facebook、Netflix 等國際企業均因采用 DevOps 流程大幅提升市場競爭力。為推動推動兩岸在 DevOps 方面的相互了解與合作機會，海峽兩岸云計算分論壇組成海峽兩岸云計算工作組，組織雙方企業和專家，在今年首次針對這個議題共同編著了開發運維一體化（DevOps）兩岸共通標準研究報告，邀集了兩岸知名且具代表性的企業案例分享，從理論、實務與標準等方面加以

7、探討，希望提供兩岸產業界參考，希望通過此工作，對接海峽兩岸產業合作需求，推動兩岸合作實質落地。2第一章第一章 DevOps 簡介簡介軟件工程發展史上，工程師們為了解決各時代不同軟件開發環境和效率、質量與速度問題，不斷推出相關軟件開發標準和規范，譬如早期 ISO9001 進化到 CMMI，或從瀑布式開發演變到今日的敏捷（Agile），其目的皆與軟件開發程序與時俱進，滿足當代產業脈動需求。近年，互聯網和云端服務大規模普及，徹底顛覆了由來以往的競爭格局，客戶需求變化多端，商業模式日新月異，以移動 APP 為核心市場成為兵家必爭之地，在此產業發展背景之下，企業軟件開發速度和質量受到空前重視，而特別能滿

8、足此類產業需求的 DevOps 方法便應運而生。市場對于 DevOps 的發展和應用雖不陌生，但各方定義目前卻仍未江山一定，原因是現階段尚未出現正式的 DevOps 國際標準（ISO 與 IEEE 皆草案制定中）。本研究報告綜合目前全球 IT 企業如 Amazon、 HP、 IBM、 微軟等以及Garner 等知名研究機構對 DevOps的定義加以融合為：“DevOps 象征 IT 文化的轉變，著眼于采用敏捷、精實的系統化作法，達成快速的 IT 服務交付，其本質是一種分工，強調在人群與文化層面，試圖促進開發和運營團隊的合作，亦即通過開發、測試、運維等角色職責的分工，來實現工程效率最大化，進而滿

9、足業務需求?！?.1 創新思維與革新創新思維與革新傳統企業分工模式無法反應新業務工作需求是 DevOps 崛起的原因之一，DevOps 提出了許多創新概念和實施方法，消除了這些因為重復性工作和資源不均導致的效率低落問題，DevOps 分工和傳統模式的區別如圖 1-1 所示。3圖 1-1 DevOps 分工和傳統模式的區別圖片來源: http:/ 運維與 QA 質量保障，設為各自獨自的部門，開發部門的驅動力是頻繁交付新功能，因此開發和部署無需考慮 IT 支持或 QA 跨部門支持，而運維部門則關注在 IT 服務的可靠性和運作效率，各部門目標彼此沖突、時而相擘，久而久之，開發和運維部門產生一道鴻溝，

10、拖累整個企業交付業務的速度，可能沖突場景如下：開發人員往往沒有考慮程序對運維造成的可能影響，在交付程序之前，自然也不會邀請運維人員參與架構決策或程序評審；開發人員修改配置或環境后，并未及時告知運維人員，導致新的程序無法執行；運維人員對應用程序缺乏了解，不易正確選擇執行環境和發布流程；運維人員希望盡量避免修改功能，降低異動可能引發的宕機風險；決策階層不了解團隊工作狀況，業務部門亦無法掌握需求被處理的進度；開發團隊工具不同，不同團隊溝通不易。上述場景并不罕見，因為在多數企業里，應用程序發布是一項涉及多團隊、風險高、壓力大的任務，各團隊立場很容易針鋒相對。但 DevOps 提供協同工作的流程和方法，

11、4搭配自動化工具，來打破不同部門之間的壁壘，打通以前曾是瓶頸的每個環節，大幅減少甚至消除這些障礙，主要差異在于：先以價值產出為目標導向，再向下展開流程和方法；以應用程序為中心來理解基礎設施；定義簡潔明了的流程；更小、更頻繁的變更；讓開發人員有更多權限能控制生產環境；盡可能自動化；促成開發與運維協作。有些專家認為 DevOps 是敏捷（Agile）和精實（Lean）開發概念的延伸，主要在打破過往封閉回路，從需求分析、系統設計、程序開發、安裝測試、系統運維的每一個獨立的階段，要求開發人員、運維人員等盡可能以自動化方式執行任務，例如由工具進行自動化測試、自動化部署，減少手動及傳遞或等待的時間，避免人

12、為錯誤，改善軟件交付質量，另外，也將自動化相關資料提供給所有參與的人，根據量化的資料加以滾動式改進。DevOps 以頻繁更新降低系統風險如圖 1-2 所示。圖 1-2 DevOps 以頻繁更新降低系統風險圖片來源:維基百科https:/upload.wikimedia.org/wikipedia/commons/1/1c/Agile-vs-iterative-flow.jpg5從一些導入案例來看，實施 DevOps 確實能對企業生產起巨大作用，以開發部署速度為例，傳統開發周期常用大規模、不頻繁的發布，所以常常以“季”或“年”為單位發布，改用 DevOps 或迭代式開發后，大幅縮短成為以“天”或

13、“周”為單位周期，1 年發布 18 個版本，甚至 1 天發布 18 次都不令人意外。DevOps 持續頻繁的發布，每次發布變化自然相對變少，每次部署也就不會對生產系統造成巨大影響，因此應用程序會以平滑的速率逐漸增生，也讓企業不用擔心系統崩潰和服務失效的風險。1.2 未來發展前景未來發展前景目前許多企業已經開始關注 DevOps， 不論是從交付和部署流水線的自動化起步投入小規模試點，或從底層基礎架構的容器化開始探索這塊領域，都看中它在扭轉傳統軟件開發時過于片段與無法快速回饋需求改變的缺陷，不過，從整體來看全球除了大型聯網業者之外，其他還是處于比較前期的嘗試階段，缺乏大規模、系統性的導入?？偨Y而言

14、，在傳統軟件開發和基礎設施程序管理的組織，其內部開發、運維和測試經?；ゲ幌嗤?，但通過導入 DevOps 科技化方法、自動化工具等，就可以更快、更有效率的開發和改進，讓組織能對客戶提供更快、更好的服務。因此，即使有些專家認為雖然它不是一個具體的技術，但仍對它的未來發展寄予厚望，并認為將進一步結合新工具和新技術后迅速在市場普及。6第二章第二章 DevOps 發展情況發展情況DevOps 興起并非一朝一夕，事實上，在歷經近 10 年的進化改進后，DevOps 的含意已不再只是單純字面意思的開發運維一體化，而具有組織文化變革的意涵，成為貫穿產品與軟件研發生命周期，包括縱向打通需求、設計、開發、編譯、構

15、建、測試、部署、運維，橫向打通架構、開發、測試、質量監管、運維、運營等概念。2.1 萌芽與緣起萌芽與緣起一般認為 DevOps 之所以興起，在于進入云計算時代，企業核心商業行為與網絡密不可分，大量的應用服務將載體遷移到云端，使過去網絡底層架構、中介軟件和環境設定工作承載變得不再沉重，取而代之的挑戰是如何滿足快速市場變化與需求，推出對應的獲利服務，對這些如同企業命脈的應用服務，勢必要加速開發、不斷更新、持續交付，速度等同商機，所以網絡大腕級企業和領域專家的軟件工程師們，都相繼提出各自的解決方案。時間回溯 2008 年，全球信息科技產業出現一些重大訊息，比如金融海嘯引發經濟危機、微軟擬以 446

16、億美元收購雅虎遭拒、Google 推出手機專用的 Android 平臺、全球最大的垃圾郵件發送商 McColo 遭斷懲處、以及奧巴馬運用網絡科技當選美國總統，使人們了解到互聯網對當代局勢影響的重要性。場景轉到加拿大多倫多敏捷會議 （Agile Conference） 、 Patrick DeBois 和 Andrew Shafer兩位專家對傳統軟件開發流程深感受挫，故深入討論敏捷架構的發展性，業界人士咸認這場會議讓 DevOps 概念萌芽。次年，兩位 Flickr 工程師 John Allspaw 和 Paul Hammond在美國加州 Oreilly Velocity 大會發表“1 天部署

17、10 次”引發熱烈回響，而此一演說啟動了 Patick DeBios 在同年 10 月于比利時根特市創辦全世界第一場 DevOpsDays 活動， 當時此消息在 twitter 上快速傳播時，許多人將 DevOpsDays 縮寫簡化成“DevOps”，DevOps7一詞就此正式誕生。自此之后，DevOps 經常變成各大 IT 論壇和演講焦點議題，迅速在世界各地蔓延，至今全球各地 DevOpsDays 已舉辦超過 60 場，若再加上其他與各種形式相關討論或分享更為可觀，意味有愈來愈多的人對這個詞所包含的理念與實踐，有非常深刻的共鳴。經過數年的產業倡議，DevOps 發展日趨成熟，在 2010 年

18、美國山景城 DevOpsDays活動中，Damon Edwards 提出以“CAMS”來詮釋 DevOps，即文化（Culture）、自動化（Automation）、度量（Measurement/Metrics）和分享（Sharing），之后，又有 Jez Humble把原本用于豐田生產方式的精益 （Lean） 管理原則加以轉變并融合其中， 變成 “CALMS” ，其精神更能抓住 DevOps 的深意，即除了技術之外，還有管理與組織文化的議題，也就是人的問題，概述如下：文化：指組織文化應勇于變革，促進協同工作與溝通；自動化：指盡可能降低價值鏈中可能存在的人為干擾環節；精益：指及時制造（開發），

19、消除一切浪費，利用快速推出逐步改善的方式強化產品的彈性；度量：指通過測量和監控取得數據，并通過數據改善循環周期；分享：指開放與他人分享成功或失敗經驗，以不斷學習。2.2 淬煉與演進淬煉與演進DevOps 工具對其快速普及扮演了很重要的推手，不論是商業軟件或開源軟件，企業能夠選擇使用的工具，早期只有單純構建、部署、運維階段的個別方案，到今天細化成可以分別支撐構建、持續整合、持續交付、配置管理、日志紀錄、監控、協同運作、測試等不同流程的工具包，整合出幾乎等同全方位解決方案，使用這些工具的成功案例，又被當成新進企業的工作指引，協助企業挑選和搭配符合自己公司自動化程序無縫接軌8的落地方案。早期 Dev

20、Ops 工具如 Saltstack，曾經嘗試把部分 DevOps 概念具象出一些基本的功能和接口，但真正投入實際運作過程中，會消耗大量資源，而且需要自行加工，例如自己再撰寫一些程序，才能達到期望的自動化功能，而且有時需要安裝在客戶端，增加了部署的難度，這些都讓早期 DevOps 發展沒有那么順利，直到最近，許多工具在工具廠商和開源組織的集體創作之下，有了比較突破性的發展，也讓 DevOps 的接受度快速打開，以下列討論度較高的兩種技術工具為例：容器（Container）過去在軟件開發流程中，對于執行軟件的操作系統和網絡環境相當依賴，而容器出現后，它運用虛擬化“應用程序及其相對應的環境”技術，從

21、根本上解決了軟件對環境依賴的問題，在整個應用程序生命周期工作流程中，提供隔離、可移植性、彈性、延展性和控制能力，以及為開發與作業提供隔離。尤其 Docker 出現后，這種具有輕量化優勢的容器技術，帶來高可用性和易用性，讓DevOps 的普及向前躍進。根據 VMfive 的調查，2013 年以前，只能使用 Chef 或 Puppet等架構厚重、使用不便的容器技術，所以企業導入不易，直到 Docker、Kubernetes 等輕量化容器出現后，再加上工具廠商適時推出各種可云端托管的容器管理服務，讓 2017 年全球采用容器技術的企業大爆發， 一舉超過 70%， 也吸引愈來愈多企業愿意采納 DevO

22、ps。微服務（Microservices）傳統應用程序開發架構多半是單體式應用程序或三層架構，而不管哪一種，都越來越難應付大規模部署、服務不中斷，龐大的架構與無窮無盡的程序代碼成為開發上的沉重負擔。微服務架構出現后，它以單一責任的小功能區塊為基礎，彼此通過 API 通信來構建出大型的應用程序，這種方式由于職責單一、程序代碼少，不僅提高開發速度，亦9可達到獨立部署、調校與測試的目的，讓大型服務能通過快速水平擴充易于應付突發性流量暴沖的問題，這也是 DevOps 發展的重要助力之一。DevOps 相關工具如圖 2-1 所示。圖 2-1 DevOps 相關工具數據源: Continuous deli

23、very tool landscape James Bowmanhttp:/www.jamesbowman.me/post/continuous-delivery-tool-landscape/愈來愈多支撐 DevOps 工具問世， 讓企業對 DevOps 的觀念和技術愈來愈容易采用和熟悉，協助企業成功重整原本在軟件開發遭遇的破碎流程和工具雜散問題，甚至把開發/運維等傳統企業戰略位階較低的工作，提升到與企業策略同級，與戰術目標緊密結合。2.3 適用類型漸增適用類型漸增適用對象方面， 過去有些專家認為 DevOps 比較適合大型網絡服務業者， 譬如Amazon、Google、Netflix、阿里

24、巴巴這種巨型商業公司，論點在于此類企業擁有大量優秀的工程師，也有充沛的資源可以解決導入 DevOps 時遭遇的各種困難，所以可以專注改善內部流程和優化。但根據由 Puppet、DORA 與云霽科技合作發表的2017 年 DevOps 現狀調查報告發現，DevOps 適用于所有類型的組織，說明其更快、更好地進行研發與部署軟件，實現組織價值。而另一份 Interop ITX 于 2017 年對 Devops 狀況調查結果則顯示，企業對于實施 DevOps 后得到的效果，第一名是部署的應用表現和質量，有 70%以上認為10確實有提升或顯著提升，而其他除錯和維護應用時間也有縮短，增加軟件/服務的部署頻

25、率亦有提升，部門之間的協同合作等都有超過 50%的人表示肯定。在 Gartner 一份針對 2017 年之后應用程序開發（Application Development）的研究報告數據指出，今后從事應用程序開發的企業中，將有 35%從原本使用的 Scrum 改變用敏捷/精益為基礎的軟件開發方法； 而至 2020 年， 預估將有 50%的企業會采用 DevOps 方案，并以開源工具進行持續檢測，讓 IT 組織能在穩定、近似于實際生產環境的情境中執行定期測試；另外將有 50%的企業采用先進的分析技術，提升應用程序的質量和交付速度。Lean-Agile IT 最低限度的構建組成如圖 2-2 所示。圖

26、 2-2 Lean-Agile IT 最低限度的構建組成數據源:Gartner/科技發展觀測平臺整理https:/outlook.stpi.narl.org.tw/index/focusnews/detail/307事實上，DevOps 接納度之所以快速提升，原因之一為實證效益，有愈來愈多工具使用和導入之后，對于公司的效率或其他目標有顯著的提升，因此累積愈來愈多好評和口碑，就會吸引愈來愈多企業投入。DevOps 未來除了在既有技術基礎優化或創新之外，將轉向創新分析技術，即結合大數據或 AI 人工智能等技術，從企業龐大的巨量資料中探勘挖掘，產出有價值的情報，超越現今單純提供戰情數據回報功能而已，

27、協助企業增加競爭力，這也象征 DevOps 未來11的應用范圍有機會再進一步擴大。2.4 組織文化與管理能力組織文化與管理能力經過多年發展，DevOps 概念、技術、工具、架構和方法已逐漸成熟，例如導入方法上可從時間、質量兩大目標著手改進，只要先抓住這兩個最高位階的戰術目標后，再細化后續展開的各項任務，就容易合理化相對應的各項工作，而從許多市場研究報告和產業分享案例中也能發現，企業在導入 DevOps 過程中，若先著眼于最終目標再細化各流程步驟時是比較容易成功的，幾乎不會有技術阻礙，反而對于管理能力的要求成為最艱難的部分，亦即技術層次最容易實踐，流程其次，人的問題才是最難的最后一里。完整的 D

28、evOps 是一個龐大的體系，和企業的組織架構、技術、流程、文化息息相關，并且涉及組織改造，而只要改造就有受到影響和波及的對象，因此任何革新都無法忽略組織的反彈和人性的抗拒。部分專家認為 DevOps 在某種程度上只是一組相互鏈結的技術實踐，所以企業采納有不同適應，雖然遵循相同的規則，但最終會拼貼出屬于自己企業文化和流程的藍圖。雖然拼圖不盡相同，但在產業實務發展上，仍有許多組織偏好和習慣能有一個管理框架去實現這些不論是組織文化或流程方面的變革，因此本研究報告在第三章邀請海峽兩岸在 DevOps 實踐有成功經驗的企業，提供導入歷程或方法，希望這些案例能讓有意采納DevOps 的企業更有信心或縮短

29、學習曲線。另外，本研究報告也嘗試從案例與調研資料中嘗試提煉出一些發展特點及可行的標準方向，來提供更多的思維角度，讓 DevOps 實踐能夠更為容易。12第三章第三章 DevOps 應用場景應用場景3.1研華研華WISE-PaaS/EnSaaS 物聯網云平臺物聯網云平臺 DevOps 實踐實踐3.1.1案例簡介案例簡介（一）案例背景在物聯網的帶動下，制造業正迎來新一輪變革浪潮，云計算、大數據、人工智能等新技術正在加速與工業領域的全方位融合?？v觀全球市場，工業 4.0 趨勢所向，各國的企業都在制造領域中尋找新的經濟成長契機。自 2015 年大陸公布中國制造 2025計劃以來，大陸的工業轉型正迎來大

30、突破、大升級。中國制造 2025的核心關鍵是為了打造智能化、網絡化生產系統的“智能工廠”。物聯網、大數據、人工智能和實體經濟深融合，在工業的應用下已迎來蓬勃發展時期。作為最早工業計算機行業的廠商之一，研華意識到物聯網的發展趨勢將給世界帶來巨大的變化，致力于充當推手的角色來推動物聯網產業的發展。研華為構建工業物聯網的完整價值鏈，自 2017 年起與資策會協同開發 IoT PaaS 物聯網云平臺，并導入 DevOps的開發流程，以加速從端到云（Edge, PaaS, SaaS）的串接與運維服務。雙方將通過研華在 Edge 端既有的硬件系統優勢、共同開發 WISE-PaaS 2.0 數據分析平臺，以

31、及開放各垂直領域第三方單位 SaaS 服務于該平臺上進行開發， 以構建完整工業設備聯網的運維云計算服務平臺。（二）案例特點WISE-PaaS 工業物聯網云平臺，以下簡稱為“WISE-PaaS 云平臺”或“云平臺”，是一個整合的物聯網服務平臺，旨在從邊緣到云端提供可操作的洞察力。讓使用者能夠輕松安全地連接、管理和吸收大規模的物聯網數據，實時處理和分析/可視化數據。憑借全套開發工具，WISE-PaaS 簡化了物聯網解決方案部署，使資源可集中在關注的專業領13域。WISE-PaaS 2.0 平臺架構視圖如圖 3-1 所示。圖 3-1 WISE-PaaS 2.0 平臺架構視圖3.1.2需求分析需求分析

32、軟件交付需要經過構建、測試、部署等復雜過程，如果主要依賴人工去完成這個流程需要花費很多時間，延誤產品的上線發布。為了實現軟件的快速交付，越來越多的企業開始遵循 DevOps 軟件交付理念和方法，DevOps 集文化、實踐和工具于一身，以開發團隊和運維團隊的密切合作為核心，通過工作實踐將交付過程打造成一條包含開發、構建、測試、發布、部署、運維等步驟的標準化流程，并用各種工具將其自動化，最終實現產品的快速、高質量交付，并提供 7*24 小時不間斷服務，如圖 3-2 所示，上圖為研華 WISE-PaaS 架構流程與工具，下圖為打造的交付作業標準化流程。14圖 3-2 DevOps 打造交付標準化流程

33、153.1.3解決方案解決方案（一）總體技術架構WISE-PaaS 平臺解決方案如圖 3-3 所示。解決方案的最上層提供 CodePipeline 服務，它是正在開發的一款具有持續集成/持續交付能力，并能兼容 Jenkins 的 SaaS 化產品。通過使用 CodePipeline，可以使客戶方便的在云端實現從源碼到應用的持續整合和交付，方便客戶快速的對產品進行功能迭代和推進。整個解決方案的核心是 Jenkins，Jenkins 提供了軟件開發的持續整合服務，它通過Master/Agent 架構來實現分布式構建，將不同的任務下發到多臺機器（Jenkins Node）執行，提高處理性能。解決方案

34、的最下層通過 Kubernetes 來管理 Jenkins 的節點， 當有構建任務時會自動創建一個 Docker Container 來完成構建任務，當任務結束后 Container 會自動銷毀，資源動態使用動態銷毀，避免資源浪費，無需擔心源碼或構建物外泄。圖 3-3 WISE-PaaS 平臺解決方案（二）具體技術方案16WISE-PaaS 平臺技術方案可從兩方面闡述，包括持續交付流程以及 Jenkins Pipeline，如圖 3-4 所示。圖 3-4 WISE-PaaS 持續交付流程1) WISE-PaaS SRP（Solution Ready Package）持續交付流程 開發人員提交源

35、碼到源碼倉庫； 倉庫打 tag 后通過 Git Webhook 觸發 Jenkins 上面自動編譯的 Pipeline； 編譯后將產物存儲到 storage，例如 blob； 觸發 Jenkins 上面自動部署的 Pipeline 從 storage 拉取編譯產物部署到準生產區； QA 在準生產區進行自動化及人工測試，包括功能測試、性能測試、壓力測試和穩定性測試。 測試通過后觸發 Jenkins 上面自動部署的 Pipeline 將編譯產物部署到生產區。2) Jenkins PipelinePipeline 是 Jenkins 的一系列插件的組合，通過這些插件可以將持續交付管道化流程在一個 J

36、enkinsfile 中實現，將復雜的交付流程轉化為 code，即“Pipeline as Code”，并且可以將 Jenkinsfile 放入項目的源碼管理中，像管理其它源碼一樣來管理 pipeline 的 code。jenkins 中 pipeline 腳本是基于 groovy 編寫的，可實現靈活、可擴展的持續發布（CD）工17作流。WISE-PaaS 平臺 App 的自動構建和自動部署都是通過編寫 Pipeline 腳本來實現的。在 Jenkins 上面創構建建和部署 Job，并將構建和部署的步驟在 Pipeline 腳本中實現，然后配置各種運行參數，便可實現構建和部署的自動化。Job

37、被觸發后，Jenkins Server 會將Pipeline 腳本發送到腳本中指定的 Node 上去執行，最終完成構建和部署任務，如圖 3-5所示。圖 3-5 WISE-PaaS 平臺實現自動構建和自動部署3) Kubernetes+Jenkins傳統的 Jenkins Master/Agent 方式可以說明使用者實現分布式構建，提高處理性能，但是在使用時還是會存在很多缺點，例如： 當 Master 節點發生故障時，便無法再進行任何構建任務； 為了完成不同語言的編譯打包等任務，會創建很多 Jenkins Node，但是這些 Node的環境又很難復制，導致管理和維護都很困難；18 資源分配不均衡

38、，有些 Node 使用率比較高，會出現 job 排隊的情況，但有些使用率比較低的 Node 卻很多時候又處于空閑，導致資源的浪費。為了解決以上種種問題，需要尋找一種更可靠更高效的方式來完成 CI/CD 流程，使用 Kubernetes 搭建 Jenkins 集群的架構便解決了這些問題，如圖 3-6 所示。圖 3-6 以 Kubernetes 搭建 Jenkins 集群完成高效 CI/CD 流程在這種架構中，Jenkins Master 和 Jenkins Agent 以 Docker Container 形式運行在Kubernetes 集群的 Node 上，創建一個持久化的 Volume 用來

39、存儲 Jenkins 服務的數據，當Master 出現故障時，可以保證數據不會丟失。創建 JenkinsAgent 使用的 Docker Image 保存在 Docker 存儲服務中（例如 Docker Hub），便于管理和復用。Jenkins Agent 會根據需要拉取 Docker Image 動態創建和銷毀，不會一直占用資源。具體實現過程：Jenkins 提供了 Kubernetes 的插件，安裝插件并配置好 Kubernetes 連接信息后，就可以在 Pipeline 腳本中調用 Kubernetes 的接口自動啟動一個 Pod 和多個Docker Container，其中一個 Con

40、tainer 作為 Jenkins Agent 注冊到 Master 上面，構建任務19可以指定在其他 Container 上面完成，當所有操作都完成后，Jenkins Agent 會被注銷，并且釋放掉所有 Docker Container 的資源。4)藍綠部署傳統模式下，如果要更新應用，基本上無可避免有停機時間。在 WISE-PaaS 上，通過藍綠部署實現不間斷服務的更新。藍綠部署是軟件部署模式的一個術語，藍色是現在正在運行的當前版本，綠色是更新的版本，先部署綠色版本，然后對綠色版本執行煙霧測試。通過測試后，才將應用流量逐步切換到綠色版本，然后監控綠色版本，一旦異常，立刻回滾到藍色版本。整個

41、過程高效迅速，可保證零宕機升級，服務不間斷，如圖 3-7所示。圖 3-7 通過藍綠部署實現不間斷服務更新WISE-PaaS App 能夠實現藍綠部署，主要是因為平臺支持 App 通過 Scale 實例個數來分擔流量，比如藍的版本有 6 個實例，目前用戶訪問的所有流量都集中在藍的版本上。20需要升級時，先部署只有一個實例的綠的版本，測試通過后，再將其 Scale 到 4 個實例，并將用戶使用的 Route Map 到綠的版本上， 并且將藍的版本 Scale 為 2 個實例， 這個時候，綠的版本正式被用戶所用，并且分擔了 67%的流量，然后再繼續將綠的版本 Scale 到 6個實例，并且將藍的版本

42、 Stop，最終所有流量成功導入到綠的版本，升級過程中不會出現宕機的狀況。5)煙霧測試與 A/B 測試QA 為每個 APP 都編寫了自動化的 SmokeTest 腳本，每次部署之后都會自動運行SmokeTest 腳本，保證 APP 部署以及基本功能的正確性，如圖 3-8 所示。圖 3-8 煙霧測試與 A/B 測試確保功能正確性WISE-PaaS 平臺的 APP 還支持 A/B 測試。在不斷引進持續交付的流程后，產品更新越來越快，不同的方案設計有可能會帶來不同的用戶使用效果，A/B 測試提供了一個有價值的方式來評估新特性對客戶行為的影響。具體來說，就是為同一個目標制定 2 個方21案（例如 2

43、個頁面），讓一部分使用者使用 A 方案，另一部分用戶使用 B 方案，對 2 種方案進行用戶轉化率、點擊量等指標的統計，以判斷 2 種方案的優劣并進行決策。WISE-PaaSApp支持A/B Test， 主要是因為平臺支持同一個Route Map到不同的App，這樣就可以讓用戶通過同一個 url 訪問到不同版本的 APP。 實際測試時， 同時部署 2 個版本的 App，保持相同的實例個數，并且 Map 相同的 url，就可以將用戶流量分別導向 2個 App， 然后通過統計用戶對不同版本的 App 的使用情況， 最終確定選擇哪個方案更好。6)CodePipeline 服務CodePipeline

44、是在 Kubernetes +Jenkins 的基礎上開發的一個 SaaS 化的產品，提供可視化的操作頁面，協助用戶簡單快捷地實現持續整合與持續交付的流程，服務結構設計如圖 3-9 所示，而 CodePipeline 服務提供的可視化操作頁面如圖 3-10 所示。圖 3-9 CodePipeline 服務結構設計22圖 3-10 CodePipeline 服務提供的可視化操作頁面（三）解決方案特點使用 Kubernetes +Jenkins 作為基礎架構，提高了服務可用性，并且實現資源按需使用，避免浪費；上層又封裝了 CodePipeline 服務，讓使用者打開服務即可使用，不需要自己搭建編譯

45、和部署等復雜的環境，也無需用戶運維：服務高可用：當 Jenkins Master 出現故障時，Kubernetes 會自動創建一個新的Jenkins Master 容器，并且將持久化的 Volume 分配給新創建的容器，保證數據不丟失，從而達到集群服務高可用性。資源按需使用、動態生成、動態銷毀：Jenkins Agent 只有在 Job 運行時才會被創建， Job 運行結束后會自動銷毀以提高資源使用率， 而且還可以防止源碼或者構建物外泄。服務打開即用，無需額外的配置：打開 CodePipeline 服務鏈接，即可在上面通過23配置完成 CI/CD 的過程，不需要自己搭建編譯和部署等復雜的環境。

46、用戶無需關心整個交付系統的運維，由平臺統一管理。3.1.4總結總結（一）經濟/社會效益目前研華內部人員已經開始使用CodePipeline服務來完成部分SRP的持續交付過程，加速了軟件產品的交付流程，降低部署過程出問題的風險，提高了客戶滿意度和產品的市場競爭力。自動化軟件發布流程提高開發人員的工作效率更快發現并解決缺陷更快交付更新（二）用戶評價回饋目前CodePipeline還有很多需要完善的地方， 使用者在使用過程中也發現了一些bug，目前正在修正中。另外，系統本身也有很多功能需要完善，比如需要設計更完善的使用者操作權限，整合 WISE-PaaS 云平臺的 SSO 系統，在使用方面也希望能增

47、加一些更簡單的可視化配置，讓用戶不用寫源碼就能快速完成編譯和部署的工作。（三）小結在快速發展的云時代，軟件產品層出不窮，為了搶奪先機，第一時間將產品上市，快速發布和保證質量成為產品取勝至關重要的因素，而 DevOps 就是順應潮流的一種軟件交付理念和方法，遵循 DevOps 的交付理念，可以幫助開發人員第一時間發現軟件中的缺陷，保證產品快速和高質量上線，并提供不間斷的服務，提高客戶的滿意度和產品的市場競爭力。所以 DevOps 已經成為軟件驅動型企業在云計算時代取得成功的關鍵。243.2Gogolook全球千全球千萬用戶等級萬用戶等級 App 的的 DevOps 架構架構3.2.1案例簡介案例

48、簡介（一）案例背景Gogolook（走著瞧股份有限公司）成立于 2012 年春天，成員來自臺灣、香港、韓國、巴西等地的軟件創新人才，希望通過快速且不間斷地服務創新以及使用者為中心的設計理念，建立全球行動裝置上最值得信賴的人際溝通網絡。Whoscall 是目前最具代表性的產品，擁有全球超過十億筆電話數據庫信息，提供Android 及 IOS 行動裝置用戶最實時的來電辨識服務。Whoscall 于 2012 年獲當時 Google執行長 Eric Schmidt 公開表揚，并獲數字時代、華人行動應用大賞、Google 年度創新獎等獎項肯定，曾被全球知名科技媒體 TechCrunch、TechinA

49、sia 專題報導，也與臺灣警政機構、韓國金融監督局（FSS）等單位簽訂合作備忘錄。Whoscall 全球用戶超過六千五百萬，主力市場為臺灣、巴西、香港、日本、韓國等地，可警示惡意推銷來電，數據庫中也提供豐富的商家營業信息，并已成功的協助數千萬的商家通過來電辨識功能取得行動用戶的信賴。目前亦致力于運用數據庫系統發展人工智能，利用長期用戶接收詐騙電話的數據分析仿真詐騙集團的行為，進而預防犯罪。隨著用戶規模擴大，服務內容增加，對于基礎設施穩定性、研發敏捷性、產品安全性的考驗亦不斷上升。為了適應下一階段的服務挑戰，公司開始進行一連串的 DevOps大改造。（二）案例特點Whoscall 服務的 Dev

50、Ops 改造案例是依據 DevOps 指導原則逐步進行，流程與工具改造并重，此經驗對其他軟件公司應該很容易借鑒實施。以鳳凰項目（The PhoenixProject）“三步工作法”觀點闡述案例特點如下：25流動原則：以自動化工具為輔，全面貫通提交源碼、測試、組態配置、部署等流程。在安全網的基礎上，放心提交源碼進行實驗，加速研發與應變腳步?；仞佋瓌t：通過許多層次，透明化監測部署的任何服務的實際運作狀態，以得到實時且精密的回饋，進而產生對于服務質量及商業目標的洞見。持續學習與實驗原則：系統化改善端到端服務流程，對于服務流程及規格，有宏觀及微觀的掌握。對研發的工程質量，能夠起規范化的積極作用，也有助