【國外技術標準】Netflix、Oracle、ING、思科、JFrog都如何做DevOps的？

今天我分享的主題是《一站式軟體交付：世界五百強企業的 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，實現統一的資源申請。這樣的好處是每個團隊的交付流程一致，能夠在公司內部實現持續交付的標準，研發團隊也不用維護底層的各種工具鏈。

一、Netflix

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

二、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時，他們開始做一些自動化的刪除，前面也講過了一個規範，如果包在半年之內沒有被用到、沒有被下載，這個包就會被刪掉，都會用這個去做。

三、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的節點，因為他們要進行幾萬開發團隊的並行上傳、下載，是非常高的併發構建。

四、思科

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

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

全球 DevOps

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

後設資料

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

五、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機器即可使用，按照用量、儲存量計費，用量會比你實際儲存還要少一些。