課程概要
2009年，一場演講在O’Reilly Velocity大會上一炮而紅，演講中有一句話深得人心：“由於開發和運維需要在Flickr（一個圖片儲存和影片託管網站）上合作，這導致開發者每天至少得進行十次部署。”演講結束後，“DevOps之父”Patrick Debois受該演講啟發，在比利時發起一場名為DevOps之日的運動，號召開發和運維們，應該破除對立、走向合作。

DevOps是一個合成詞，由開發（Developments）和運維（Operations）兩個單片語成，其主要目的是拆斷不同部門之間隔離的牆。簡而言之，DevOps可以讓公司的流程更快、更有效，並且更可靠。那麼，持續交付和DevOps到底有什麼關係？為什麼要放到一起說？

4月1日，京東雲與AI雲產品研發部架構師井亮亮，講授了《六週玩轉雲原生》第三講：雲原生下的DevOps與持續交付，讓我們來回顧一下精華內容吧！

關於雲原生的解釋有很多種，這張PPT裡列了常見的兩種說法，大體意思是雲原生是持續交付+DevOps+微服務+容器化。

六週玩轉雲原生

雲原生下的DevOps與持續交付

— 京東智聯雲井亮亮—

概念與簡介

關於雲原生的解釋有很多種，這張PPT裡列了常見的兩種說法，大體意思是雲原生是持續交付+DevOps+微服務+容器化。

也就是說，雲原生是一個概念集合，既包含微服務、容器，也包含更多的管理方法，比如持續交付、DevOps和重組等。

那麼如何定義雲原生？下面這張圖是CNCF官網對於雲原生的定義，也是相對來說比較靠譜的定義。而想了解雲原生，就得先了解K8S，因為它是雲原生的基石。

- K8S

K8S是CNCF的第一個專案，雲原生整個生態都是依靠K8S構建出來的。雲原生的代表技術包括容器、微服務、服務網格、不可變基礎設施和宣告式API等。

- DevOps

每當大家提起DevOps，總把它比作盲人摸象，很多公司的叫法也不一樣。有的企業會把內部上線平臺說成這是自己構建的DevOps。

但我們先看維基百科的定義：即透過自動化“軟體交付”和“構建變更”的流程，來使得構建、測試、釋出軟體能夠更加快捷、頻繁和可靠。

-持續整合、持續交付和持續部署

持續交付可以讓軟體交付變得更快更頻繁，即隨時都可以釋出，它的目標是讓軟體的構建、測試與釋出變得更快、更頻繁。要確保效率，就只能交付得更快，但交付更快的前提是確保質量。說起持續交付，很多人還聽過持續整合、持續部署。如下圖所示，這三者之間存在著一定差別。

在傳統軟體開發中，開發者在專案結束後都需要做整合，這一過程少則幾星期、多則幾個月。軟體開發在中早期時，需要頻繁地進行整合，頻繁整合的好處就是，避免到最後環節才發現問題。

很多人可能會說，我們團隊早就整合了，那麼你們多久構建一次？是不是每次釋出時才走構建流程？如果是這樣就要考慮一下持續整合。因為持續整合是持續交付的第一步。

而持續交付就是把前面所有東西整合在一塊去交付給客戶。當然不同公司對於這個階段的叫法也有所不同，有些叫“測試-生產”，有些叫“測試-準生產”或者“上線”等等。

持續部署的意思是，所有環節都是自動化的，開發者提交完程式碼之後，可以自動化部署到生產環境裡。持續部署跟持續交付唯一的區別就是，開發者能否把產品自動化地釋出到生產環境裡。

近年來，技術名詞更新非常快。關於此，在基礎設施方面體現得最為明顯，幾年前釋出一個應用去部署時一般有如下幾種選擇：最好最根本的辦法就是建機房，但所有的硬體、網路、水電等問題都得考慮進去；其次是搞伺服器、裝作業系統，最後再部署或者虛擬化一下。

再後來，我們會做類似VMware的虛擬機器，即在上面虛擬化一下部署方式，直接寫一些指令碼執行一下就能跑起來。再往後，大家都開始搞類似OpenStack一類的私有云技術。

無論方法如何變化，也無論你用什麼基礎設施，最後都會演變成混合雲或者多雲的方式，你的交付不僅要支援這些模式、更要支援容器包。當前這個過程也變得越來越自動化，且越來越能滿足業務訴求。比如，我們會用彈性伸縮技術，來滿足業務需求和成本訴求。

持續交付-流水線？

持續交付需要一系列的過程，在這一系列的環境中，不論是測試、預發、生產，越往後就越接近客戶的環境。儘管每個階段關注的問題都不一樣，但你會發現，每一個過程和環境都需要做釋出做驗證。

而透過流水線的方式，就能很好地把這一系列過程自動化起來，開發者構建的效率和釋出的質量也會藉此提高。

- 軟體交付的挑戰和問題

上圖是2016年一個DevOps的調查報告截圖。大家都知道，軟體交付的過程本身，意味著線上變更，變更就意味著有風險。交付最大的挑戰是上線過程中遇到失敗，失敗的話肯定會引發線上故障。

2016年的調查報告顯示，81%的團隊能將失敗比例控制在15%以內，但是能把失敗比例控制在5%的團隊只有35%。這意味著釋出100次就有50次故障。所以，變更對於軟體交付的質量相當重要。

既然質量這麼重要，那該如何選擇交付工具？下面這張圖，供大家參考。

- 流水線

世界上的第一條流水線，由福特汽車提出並上線。在當時，流水線極大地提高了汽車生產效率。而開發者在提交完程式碼後，把軟體交付到客戶手裡，同樣也會經歷一系列的過程。那麼這個過程怎麼去建模和執行？

這時就得結合流水線的目標來推進，流水線的目標是快速整合、快速交付，可以說流水線其實就是個管道，它並沒有一個標準的流程，我們完全可以根據業務去定製。

比如說，當你要構建一個流水線，你可能需要程式碼掃描、程式碼測試、測試部署再預發等等一系列過程。但是你怎麼確保自己做的流水線可以很好地執行？

這個問題並不難，做到以下三點就可以：

第一，一定要做自動化構建。很多開發者覺得已經做了自動化了、已經持續整合了。但是如果你在構建上不夠自動化、也不夠及時，那就談不上測試或者整合。

第二，一定要做自動化測試。構建完之後產生的產物肯定要測試，無論是功能測試、效能測試、還是壓力測試。這個測試過程是為了達到預期質量，但也要根據情況去做自動化，因為只有自動化才能提高效率。

第三，持續整合。流水線只有重複、快速、頻繁地執行，才能發現問題、解決問題。

在整個軟體行業，起碼做到以上三點，才能達到持續交付的目標。世界上的第一條流水線，由福特汽車提出並上線。在當時，流水線極大地提高了汽車生產效率。而開發者在提交完程式碼後，把軟體交付到客戶手裡，同樣也會經歷一系列的過程。那麼這個過程怎麼去建模和執行？

- 最基本的部署流水線

上圖雖然是最基本的流水線，但是大家可以看到，它涵蓋整個環節，包括原始碼環節、提交環節構建、測試和程式碼分析等等，到了後面就是驗收、UAT測試生產環境、製品釋出到生產環境。

- 一些流水線實踐

上圖是一些流水線的實踐，具體可以分為三方面：

- 二進位制包只構建一次

二進位制包只構建一次的意思是，開發者在每次寫完程式碼後再構建一次，從而生成一個二進位制包，然後再去進行後面的流程。這樣不僅可以避免浪費時間、還能提升效率。

但即便是這樣，仍然出現兩次構建的結果不同的情況，這是因為雖然你的程式碼和ID沒變，但是你的包可能會產生變化。

- 要採用同一部署方式在不同環境裡

在釋出部署時，所有部署的方式和環境，例如測試、預發和生產都採用同一種方式部署，而不是部署到測試環境時用Jenkins做持續整合，生產環境要釋出時卻透過另外一套工具去部署。部署工具不一樣就有可能導致最終交付的產物不一樣。

線上上生產環境時，不管用物理機、雲主機還是虛擬化物理機，都要確保它的高可用效能。這時就需要堆一堆資源，來保障線上使用者的可用性。

- 流水線管道要靈活

流水線存在的意義，是為了提升效率和確保質量，但是開發者的業務可能有Java的、可能有Go的。因此你的流水線，要滿足各種各樣的訴求。

比如說，有些團隊一套測試環境就夠了，另外一個專案可能覺得該專案要提供給別的團隊做聯調，這時就要確保測試環境的穩定性，比如構建兩套測試環境，A環境可以團隊自己拿來做工程驗證，B環境則可以提供給第三方去聯調。

最後需要做的，是驗證整個流水線的落地，不能說你把整個流水線構建起來了，然後就按照這種方式去走。真正落地時，要考慮到每次程式碼提交完成後，是否完成了自動化觸發測試的流程。

京東智聯雲在持續交付的實踐

每個企業做持續交付的經驗，都是一步一步趟出來的。

京東最早的固定上線日是週二和週四，為了確保穩定性，研發人員不能去操作線上環境，那麼就得運維上線去操作。這時產品經理們就會在運維後面排隊，但是排隊的效率比較低，並且那時還沒有上線工具，自動化能力也特別差，線上故障的修復也無法得到保障。直到後來，才開始想辦法填平。

- 兩條交付的流程

在京東早期的兩條交付流程中，第一條交付流程從開發、編譯構建、程式碼分析、抽包到整個上線都有涵蓋到。

在工具上，私服用的是商業版Artifactory、構建用的是Jenkins、程式碼掃描用的是SonarQube、物件儲存用的是內部一個私有云，釋出用的是rsync。

在第二條交付流程中，最大的變化是我們把rsync替換成ANSIBLE了，這的確極大提升了效率，並且解決了排隊問題。

所以在釋出過程中，我們原來是抽包模式，後來全部改成全量包的方式。另外一塊是提測，原來我們只做功能測試，後來安全測試也做，原來只是對接靜態程式碼掃描，後來也做安全漏洞的篩查。這兩條流水線有一個共性問題，即每條流水線都會有一條測試包、一條生產包。

目前京東智聯雲的實踐，基本分為三套環境，一套測試、一套預發、一套生產，測試、預發、生產與網路之間又是相互隔離的。

如上圖所示，京東智聯雲的流水線會從原始碼、構建、程式碼檢查、測試依次進行，預發環節和生產環節基本都有涵蓋到，假如核心功能自動化這塊失敗了，開發者得確保部署到測試環境後能夠做到自動化驗證測試環境的功能，最起碼確保測試環境的核心功能沒有問題。

從設計角度來說，整個流水線本身就是一個管道，管道里面每一個原子的功能都是獨立的，像安全程式碼檢測肯定是安全團隊更專業，京東智聯雲在這一塊就是安全團隊去做的，他們提供安全機制，確保原子能力建設，我們透過流水線把它接過來。

- 持續交付最核心的就是規範

可以說，持續交付就是一個編排，大家都知道Jenkins特別流行，那為什麼京東智聯雲的持續交付不能直接用Jenkins呢？因為持續交付最核心的一塊就是規範。部署平臺好比在大草原上放羊，一定得有牧羊犬管理羊群。

- 京東智聯雲如何做規範

京東智聯雲所有線上的操作都以同一套上線平臺控制系統去做，這樣的好處首先是減少風險，另外是統一控制系統能夠做到秒級回滾。

其次，部署平臺要用統一的帳號去做釋出，出問題後好操作。而統一規範的例項部署路徑、日誌路徑，都是按照一定目錄去做，目錄如果出問題，很快能夠透過日誌平臺或者京東智聯雲內部平臺“門神”去快速找到問題。

此外，京東智聯雲內部有整套DevOps平臺，該DevOps平臺涵蓋各個方向，目標就是解決軟體全生命週期的問題，包括開發、測試、運維，讓開發者透過工具更好地工作。整個工具層面包含專案協作部分、開發工具和測試部分。

在配置管理方面，京東智聯雲的配置管理不僅涵蓋應用層面的一些服務管理，比如人員角色的許可權等。當把這些東西作為基礎資料的核心，那後面的業務邏輯，包括監控、釋出、日誌等所有的服務基礎資料都已經有了。

京東智聯雲是按照App的維度，向上是整個組織結構，向下會把整個模組和機器的資訊管理起來，這時就不需要考慮釋出機器的情況，只需要考慮釋出哪個App，以什麼流量切換的方式去釋出它。持續交付真正的核心是靠流水線把整個環節去打通，京東智聯雲的監控是一個比較全鏈路的監控，不僅僅包括技術層面的監控、底層基礎設施、容器、物理機，還支援混合雲。

現在的企業一般不可能只用一種雲或者只用自己構建的私有云，公有云也可能不會只用一家的，可能有A家的、有B家的，這種模式的話，不管是交付還是監控，都要做到支援基礎設施混合雲的模式。這樣的話，就得在上層做到統一排程，所有監控部署的Agent也要做統一管控。此外，如下圖所示，在這方面京東智聯雲也會對外輸出自己的經驗。