本文根據馬致傑老師在〖Gdevops 2017全球敏捷運維峰會廣州站〗現場演講內容整理而成。

講師介紹

馬致傑，英文名：George Hurn-Maloney，JFrog中國區創始人/CEO，於2016年底創立了全球領先的DevOps平臺JFrog的中國分公司。George在國內的資料中心、伺服器架構、移動應用運營，以及DevOps領域擁有超過8年的經驗。

今天我分享的主題是《一站式軟體交付：世界五百強企業的DevOps轉型之道》，會講到國內外的一些大型企業是怎麼實現DevOps落地的，以及企業決策者通常會關注哪些DevOps帶來的收益，希望本次分享可以幫助大家說服領導快速落地DevOps，提升企業的競爭力。

軟體開發趨勢

眾所周知，敏捷開發帶來的是持續測試的能力，是把開發和測試的團隊合在一起，實現一些持續測試。 DevOps目前主要做的事情是實現持續部署、持續交付，現在可以用一些灰度釋出、金絲雀釋出去做小規模的釋出，但只是釋出應用到某一部分的叢集。

就像谷歌所做的，比如Google地圖現在想釋出某個新功能，會先在公司內部發布或者是做一個小規模的釋出，後面再做一些對外的釋出，這是DevOps帶來的一個好處。

此外，DevOps還需要一些工具去實現。在構建方面，我們看到網際網路公司裡80%都在用Jenkins，因為Jenkins做實時構建、實時編譯，平臺本身是非常開放的，也有很多的外掛可以支援單元測試、效能測試 。如果用付費版的軟體，國外有一些做容器編譯的比如 CircleCI 等。在測試環節，很多工具都是免費的，比如  Junit、Jmeter等。在部署方面，國內外主要是Ansible和Saltstack這兩個用得最多，我們也有一些比較酷的工具，後面會展開介紹。

DevOps的工具鏈特別多，也比較複雜，所以企業要想辦法去支援所有的工具鏈，因為我想要開發團隊能夠自由使用他們想用的工具，幫他們提高研發效率，而不是強制他去用某幾種工具，所以落地DevOps平臺是很重要的，因為需要用API的方式去對接各個工具鏈。

DevOps的發展現狀

我們看看DevOps的發展狀況，通過每年的DevOps現狀調查報告，我發現了一個比較有意思的現象：就是前三年，公司內部叫DevOps工程師的員工數量增長了兩倍，現在很多公司有專門的DevOps工程師，做創業的人都知道，之前你要找一個技術團隊肯定是先找開發，再找運維，第三個再找DevOps，但現在很多矽谷公司，他們是DevOps和開發一起找，因為DevOps 工程師可以用很多較超前的工具做快速的釋出。

DevOps的收益

關於DevOps的收益，我們都知道，一鍵釋出可以提高我們的軟體交付速度，也叫做快速釋出，但快速釋出依賴於很高的自動化測試能力，自動化測試可以提高軟體軟體交付質量。但自動化測試工具和用例多了之後，測試的時間開始變長，開發需要等待時間很長，如果最後一步失敗，這會浪費很多等待的時間，所有需要讓失敗的case在早期失敗（Fail Fast），將下游的測試用例補充到上游測試用例，可從而避免在最後一步失敗的問題。

DevOps全球開發者分佈

我們看一下全球在做DevOps的公司分佈。從上圖可以看出一個很大的問題，就是亞洲明明有很高的消費能力，有很多智慧手機的使用者，但全球的DevOps工程師數量亞洲只佔了10%，而歐洲和美國卻佔有全球最大的一部分，為什麼？這也是我此次分享的一個目的，我希望大家都可以多做一些交流，多對外分享各自內部的DevOps實踐。在歐洲，很多大的銀行、保險公司都會分享他們內部的一些實踐：怎麼用亞馬遜或公有云，用了哪些工具，如今中國國內也有越來越多的公司在分享，但也還比較侷限於國內地區，我們需要擴大影響力。

全球最超前做DevOps的公司

全球範圍內哪些公司做DevOps最超前？我們這邊有一些案例，谷歌雲每週20億次變更，都是用Kubernetes；我們認為Netflix是最超前做DevOps的公司，大家可能有看過《紙牌屋》，一個比較敏感的美劇，但Netflix不僅是拍美劇了，還佔有全國60%的頻寬，很多人坐沙發上看電影，在國外都是用Netflix。

還有甲骨文和思科，他們都做了一個一站式交付平臺，封裝了Jenkins、JFrog、Sonar 等測試工具去做統一的測試與部署，他們是屬於大規模的DevOps。國內的騰訊和阿里，騰訊至少有兩個團隊在做相關的事情，一個是在做集中式的DevOps平臺，另一個是負責藍鯨，藍鯨是一個非常強大的自動化運維工具平臺。阿里巴巴在杭州有一個團隊在打造阿里內部的平臺- AOne，阿里的很多業務已經遷移到他們的平臺上去做一站式的測試和部署。還有華為，我們知道至少有兩個團隊在做公司內部的DevOps交付平臺，這也是特別超前的，做得效果也很不錯。

這些公司是怎麼做DevOps的？

下面是今天分享的重點，主要跟大家分享一些上述這些公司是如何超前地做DevOps，他們用了哪些工具，怎麼評估團隊，怎麼說服領導，如何做一個自助式的DevOps平臺 。

第一，自助式DevOps

就是在每個階段要評估最好的工具，這裡以騰訊為例，騰訊在前面做構建時，大部分是用Git，然後用Jenkins去構建，用容器的環境去跑構建的任務，比如說一個Jenkins任務跑到一個容器裡面，構建完了，就可以很好地收集一些資源。而測試工具，值得一提的是SonarCube。SonarCube做單碼掃描，它也是被用得比較多，像滴滴、百度、阿里等這些大網際網路公司都在用。中間工件管理部分也是比較關鍵的，包括你的資料管理在每個階段從提交程式碼一直到構建、測試，釋出到什麼環境，都是存在一個地方，所有的資料和包都是存在JFrog Artifactory裡面，都要通過各自公司內部的標準區做流水線。最後部署和評估，很多公司在評估他們的DevOps資料，這個月和上個月底相比，釋出到底有沒有變得更加高效，我的測試突破率有沒有比之前快。上圖中提到的是我們評估用得最多的一些工具，當然每個階段還有更多別的工具。

第二，自定義流水線

不知道在座的有沒用到Jenkins 2.0Pipeline外掛，現在Jenkins創始人KK在每個大會上都會講他的Pipeline外掛概念，去年我參加了他在以色列的Jenkins大會，他在會上就釋出了Pipeline外掛。但不管是用Jenkins或者別的工具，都要把一些可重複使用的階段，比如測試、部署放在一個模組化的CI流水線裡面， 開發者就可以自己上線，自己釋出。現在一些大企業的團隊就是自己上線、自己釋出，他們採取微服務架構，不設定有變更日，隨時都可以獨立釋出自己的模組，不用要協同所有模組一起。大家可以嘗試 Jenkins Pipeline 這個外掛，是開源免費的。

在我們這個例子裡面，做Maven 構建，然後搭建一個映象，用映象做一些測試，部署到測試環境裡，那麼做完各種自動化測試之後，就可以部署到生產環境。一些金融公司是要有一個員工稽核的過程，也可以放在開發裡面，開發可以發郵件、發簡訊等。

記錄生命週期元資料

這個過程會產生很多資料，每一步關鍵的資料都需要存在統一的地方，叫元資料。Jenkins和JFrog目前世界五百強裡面大部分的企業都在用，JFrog有一個外掛在Jenkins裡面，安裝之後，在構建時就可以把你的測試通過率，還有SonarCube的地址、部署的結果，以及你當時部署了什麼機器，都跟構建包進行繫結，所以現在你公司內部所有的工件，不管是什麼語言（可以看到圖中左手邊各個語言的包），都要根據DevOps團隊的一個規範和標準去上線，如果這個包沒有所有的元資料，沒有所有的測試結果，而且沒有這個QA，這個包就不能上線。這就等於在公司內部設定了一個質量關卡， 從開發、構建、測試到部署所有階段的關鍵資訊都是要放在一個地方才能實現流程的決策自動化。

制定軟體交付質量關卡

質量關卡是一個比較老的概念，Jenkins和JFrog是怎麼參與到這個過程中的呢？答案是用自動化測試供，通過把測試結果和這個包繫結，如果想要把釋出的包從開發環境升級到測試環境，再到部署環境，必須得收集到特定的元資料才可以到下一個階段，這個叫質量關卡，很多大企業現在就是用的這個標準，即如果我的 Released包沒有具備所有的測試資訊，流水線不會讓它到部署到我的生產環境，這個主要是去保證軟體的質量，正如之前講的“快速失敗”，如果把一些自動化測試、繼承測試放在一個早一點的階段，就可以避免浪費很多的時間。

第三，智慧查詢

最後，你需要一個智慧的查詢能力，去找到公司內部的好幾萬個包，像思科、華為都有幾十億個包，不是最新的版本，而是經過測試且單元測試通過率為100%、漏洞掃描已經通過的包，可以自動地將它部署到生產環境。像思科、甲骨文他們會做一些自動的清理，比如說有一個包在半年之內沒有被下載，它會自動去做刪除，所以如果你們儲存的成本越來越高，也肯定要評估怎麼做一次自動化的清理。同樣是做一個環節再做下一個環節，所以可以用AQL這樣一個工具去做，很多大企業也是這麼實現的。

全球DevOps標準

現在國內外都有一個非常大的趨勢，就是說公司到了一定的規模，都要開始封裝自己的DevOps 平臺，不然很難讓一個小而傳統的團隊去上持續自動化交付，通常我們需要花錢找一個敏捷教練在公司裡面講PPT，讓他們快速用這個工具。網際網路公司的做法是自己封裝一個DevOps 平臺，對接底層工具平臺，比如Sonar、K8S、Jenkins，實現統一的資源申請，這樣的好處是每個團隊的交付流程一致，能夠在公司內部實現持續交付的標準，研發團隊也不用維護底層的各種工具鏈。

1.Netflix

第一個例子是Netflix。Netflix在開源社群是一個非常大的貢獻者，他們開發了很多開源工具去做部署、打包等各種功能。 其中有一個做混合雲環境部署的工具叫 Spinnaker，Spinnaker是Netflix在的一個開源的專案，能夠實現跨雲平臺的部署任務的編排。現在Netflix使用Spinnaker每天釋出4000次變更到亞馬遜的機器上。谷歌雲也在用Spinnaker去做部署。他們構建時也是用Jenkins，其中有一個過程叫bake，bake是把應用打包成一個映象，然後把這個映象用deploy去做部署。Netflix的DevOps實踐非常值得關注，他們也有很多專案和開源工具都值得一看。

2.Oracle

第二個例子是甲骨文，我們都知道甲骨文是做資料庫的，但它同時也是一個非常大型企業級軟體公司，他們現在是4萬開發者的規模，之前有很多傳統的應用，也有非常大的部署。甲骨文內部也有很豐富的容器雲實踐經驗，到去年年底，他們每天有150萬次Docker併發請求，這是比較酷的。

複雜交付流水線

這是甲骨文之前一個很大的痛點，他們的流水線非常複雜，有很多併發的任務，特別是他們的測試方案，要花很多的時間，比如說某一個任務需要兩個多小時去做，如果現在每個開發者都提交程式碼，都在位置上等兩三個小時，然後再把4萬開發者乘以兩個小時，這樣算下來一年要多少錢？所以肯定要開始優化這個過程，因此他們需要一個視覺化的工具，去知道哪個步驟是最好的時間，然後去看哪一步、哪一個任務怎麼優化，是不是要做一些效能測試的優化。

多語言DevOps

甲骨文自己內部做了一個持續交付平臺，是封裝的JFrog、Jenkins，這個團隊最開始是隻有中介軟體一個小團隊，他們也是遇到其它公司普遍遇到的問題——怎麼說服領導。他們是先有一個小團隊，進而做這種實施的評估，看這個團隊的效率有沒有什麼變化，比如說上線的速度有沒有變得快、測試通過率有沒有變化，然後在公司內部出了一個報告，顯示中介軟體團隊用了DevOps 平臺上之後效率的情況如何。

於是，他們在一年之內把這個資料庫的團隊和甲骨文其它的團隊遷移到了 DevOps 平臺上，因為他們都發現做同一持續交付平臺的好處是很明顯的，那麼從2015年開始，這個平臺通過API的方式可以去支援任何開發工具、開發語言，就是最開始講的一個很關鍵的事情，如果要做公司內部的平臺，未來肯定要擴容。就像我現在雖然只有 Java 開發，但將來我們收購了一個小公司，他們用的是別的語言，我必須能夠變得能夠支援別的語言。

視覺化流水線

這是平臺自定義作業編排的介面，你可以按需編排任務，通過訊息觸發每個階段容器化的構建、測試。

報表及統計

甲骨文最強大的事情就是跨團隊的報表評估，他們可以檢視每一個跑了多少次，裡面有多少次成功，多少次失敗。裡面所有複雜的任務，他們都可以進行時間的評估。也有視覺化的工具，不用派幾個人，週末加班，給領導做一個報告或Excel，現在有自動化的頁面可以給領導看，這是非常重要的事情，即使不太懂底層技術的人，也可以上線看團隊的一些效率方面的評估報告。

DevOps平臺內部擴容

甲骨文是 JFrog Artifactory 的早期使用者，在2013年-2015年間，他們某一個研發中心某一個倉庫的資料，一年半之內從17TB漲到了70多TB，這還只是其中一個研發中心（甲骨文有6個研發中心），當資料達到70多TB時，他們開始做一些自動化的刪除，前面也講過了一個規範，如果包在半年之內沒有被用到、沒有被下載，這個包就會被刪掉，都會用這個去做。

3.ING

第三個例子是ING。ING是全球金融巨頭，雖然中國的銀行在全球十大銀行裡面佔了6個，但ING在國外算是比較大規模的了，去年超過1000億收入的規模，也有全球的研發中心。現在他們要面對國內很多金融公司要面對的事情，就是怎麼從傳統的開發模式變成一個超前的DevOps模式。

ING持續整合

之前ING 公司 IT 部門有1000多個團隊，每個團隊都有自己的上線流程，每個團隊都在重複踩坑，開發重複的功能來支援上線。所以ING為公司所有IT部門搭建了統一持續交付流水線，讓公司所有團隊都受益，也叫作”CDaaS”，提供端到端的上線服務。

ING持續交付

部署工具支援Ansible、Puppet、XL Deploy、Nolio、Chef等多種部署工具，這些工具在分發包之前都從 JFrog Artifactory去獲取包的對應版本。

ING多語言開發

部署的話，他們也能部署到多個工具，比如Artifactory，因為不同的研發中心，不同的團隊，不同的工具都要去做部署。所以這個平臺得非常靈活，能夠支援很多團隊的工作。他們也是多元的，有Maven、Docker、NPM等，他們都要開始管理。

ING自定義流水線

他們的目的是最終實現600個團隊的支援，一個自定義的流水線，從拉原始碼開始，然後做一些測試，把包放到Artifactory，他們用一些付費的工具去做部署，測試也很多跑在Docker容器裡面。ING提供的統一交付平臺對接了很多工具，覆蓋了程式碼管理、構建管理、工件管理、部署管理、環境管理等上線所需的功能，為ING的內部 IT 團隊提供了可靠的交付流水線。

ING高可用容災

金融行業比較關注的是高可用的容災，這些包肯定要用容災的，那麼可以做高可用的包管理，也可以用多個節點去做分流。例如華為，在深圳有七個 Artifactory的節點，因為他們要進行幾萬開發團隊的並行上傳、下載，是非常高的併發構建。

4.思科

最後介紹下思科，思科的平臺叫Account Management，他們有一個5人團隊，做了一個平臺，可支援全公司3萬開發者，同時也是全球多地開發的。Account Management是封裝Jenkins、JFrog，從圖中可以發現基本上是一樣的工具。Account Management通過給團隊一個頁面，去申請一個Jenkins容器，申請JFrog的資源外包，都在Account Management裡。

從這裡我們可以看到，建立一個新的Service非常簡單，你不用關注底層的Jenkins配置，不用關注包管理系統，只需要在一個頁面上去申請。

全球DevOps

它們也有全球的包複製方案，他們在美國的矽谷有一個高可用的容災，英國和印度都要做實時複製，比如說他們的某一個包是在矽谷構建，但要複製到印度去做測試，這就需要有實時複製的能力，這裡都是用高可用容災去做實時複製。

元資料

之前那個例子就是把思科每個包繫結很多的資料，測試報告、測試型別、QA的狀態，所有的都要在一個地方去管理。

5.JFrog傑蛙

最後跟大家介紹下JFrog的平臺（官網：JFrogchina.com）。JFrog是作為一個全語言的管理系統，統一管理外網的依賴包和公司內部構建的包，並且提供企業級高可用，它可以跟Jenkins對接，能夠分析這次構建涉及到的外網的包是否存在漏洞，也能做元資料收集，跟測試工具整合，將測試資料跟包做繫結，並將應用部署到虛擬機器或者容器環境的資訊回寫到Artifactory，作為元資料與包進行繫結。

我們還有一個平臺，提供一站式的快速釋出服務。我們今天看很多公司都有一個頁面去做整套DevOps，但這些都不是開源的，也不能快速地落地。我們跟騰訊聯合開發了一個應用叫DevOpsOne（官網：devopsone.cn），對接到藍鯨做部署，下一步我們要做一個全開源的平臺，這個開源的平臺就是做甲骨文、思科做過的事情。具體做法是封裝這些開發工具鏈，提供一個統一的平臺去做流水線、部署、測試，報表及資料探勘，全面降低DevOps上手的複雜度。

這個架構也是用Jenkins、Maven、JUnit、Sonar、Docker容器等工具來做的平臺，這是一個免費開源的平臺，可以快速實現企業內部的一站式持續交付平臺。

未來還要做很多報表，在需求到上線的整個流程中，持續度量團隊上線的速度和平均的上線速度，我們都會根據標準進行分析和評估。所有工具都會在一個系統裡面去做，從需求、構建、原始碼、測試到部署都在一個地方去做流水線，包括管理、部署、報表，都是開源、免費的。

最後這是提供流水線的形式，底層就是用Jenkins Pipeline，使用者只需要在 DevOpsOne上定義自定義的持續交付流水線即可。

Q&A

Q1：關於DevOps的問題，您剛才提到國外的很多企業，比如甲骨文、思科他們都是用同樣一個DevOps平臺，大家的開發、部署、業務都是統一一個平臺。但我們公司不太一樣，我們之前傾向於統一的平臺，但這個統一的平臺出問題了，所有人都在等，後來我們就拆了，就是說每個團隊的運維，這些全部都是自己的團隊去負責，你可以選自己的工具，這個工具也是自己維護的，我不知道是統一平臺管理所有的東西，還是交給自己的團隊去負責整個DevOps的東西的做法，哪一種比較正確？

A1：先不說正確與否，從業界的趨勢來說，大家做開發，他們所有的團隊構建是底層基於一個很龐大的構建系統，包括測試、打包、釋出，每個團隊維護的成員就是一個很小的團隊，每個人上來以後做自己的構建、測試。你剛剛說的問題可能是平臺穩定性的問題，這裡面還是回到甲骨文這個案例，甲骨文是平臺公司內部有500個Jenkins的Slave節點，這500個節點都是跑在高可用容器環境裡面，讓其具備很強的高可用能力，它用這個容器去保證這個節點的高可用，如果宕掉了，它會實時再虛擬出來一個環境，讓它接著跑這個任務。這個是容器環境讓它具備這種高可用的效能。

它還有一個好處，我的資源就這麼多，當每個團隊都來申請，勢必出現資源緊缺、排隊的情況，所以容器的好處是我用完以後，測試完以後，我自然就釋放了。但我把這個構建產出物，上傳到我這裡，把每一步執行的測試元資料記在這個包上面，再走到下一步，通過這種方式去給每個團隊提供統一的流水線。

Q2：想問關於自動化測試這一方面的，剛才介紹了很多工具，我們公司目前現狀是上線之前會有測試組，人工來測，關於DevOps自動化這一套測試有什麼好的建議？

A1：從測試角度來看，其實如果有在外企、國企或者是國內民營企業待過的，可能會發現有一些明顯的不同。外企的研發團隊對這個測試的覆蓋率、自動化率相對來說會高一些，國內由於業務上線的壓力，我先上了，實現功能了，再來補這個測試用例，但最後發生一個什麼問題呢？上線交付週期越短，沒有那麼快的時候還好，如果交付頻率變快，那你的測試團隊會變成瓶頸。

之前我們和亞馬遜 Kindle團隊的測試負責人聊過，他們就用這個Kindle做完全自動化的UI測試，他們用一個工具叫做APPIUM，專門做這種模擬螢幕的點選，完全百分之百的案例覆蓋，他們杜絕一切人工的模擬螢幕的點選，雖然這個投入很大，但在一年半載之後會產生很大的收益。同時你的測試團隊會從一個點選的角色，人工測試的角色變成一個開發團隊。亞馬遜全公司都是自動化測試，沒有員工手動測試的概念，雅虎也是，這兩個公司測試做得非常好。

Q3：你們有沒有計劃跟雲廠商合作，會不會考慮這種資源會更節省的方案？因為其實我們如果一個很大新的專案，需要很多 Artifactory例項，想了解一下你們這邊的情況。

A3：本身JFrog 也有一個公有云版本，目前支援在亞馬遜和谷歌雲、微軟雲上部署。如果是部署到亞馬遜，也有一個工具。如果你已經是亞馬遜的使用者了，可以在亞馬遜上建一個帳號，你不用維護任何的 Artifactory機器即可使用，按照用量、儲存量計費，用量會比你實際儲存還要少一些。

原文來自微信公眾號：DBAplus社群