來自：https://dbaplus.cn/news-134-1744-1.html
（點擊底部“鏈接”獲取馬致傑演講完整PPT）
講師介紹
馬致傑，英文名：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標準
undefined
現在國內外都有一個非常大的趨勢，就是說公司到了一定的規模，都要開始封裝自己的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機器即可使用，按照用量、存儲量計費，用量會比你實際存儲還要少一些。