摘要：摘要在北京云棲大會上，阿里巴巴高級技術專家陳鑫花名神秀，給大家帶來了億背后的企業級高效持續交付，引起強烈共鳴。

摘要： 在2017北京云棲大會上，阿里巴巴高級技術專家陳鑫（花名神秀），給大家帶來了《1682億背后的企業級高效持續交付》，引起強烈共鳴。神秀從技術負責人關心的研發流程混亂、質量無法保障、環境管理低效、資源浪費等方面，結合阿里巴巴的DevOps實踐，深度解析了企業級持續交付如何做，企業如何高效協作，控制成本的精彩分享。

導讀：在2017北京云棲大會上，阿里巴巴高級技術專家陳鑫（花名神秀），給大家帶來了《1682億背后的企業級高效持續交付》。神秀從技術負責人關心的研發流程混亂、質量無法保障、環境管理低效、資源浪費等方面，結合阿里巴巴的DevOps實踐，深度解析了企業級持續交付如何做，企業如何高效協作，控制成本的精彩分享。

一、技術管理者的煩惱

開發工程師的日常

我們看下開發工程師每天都是如何工作的。老三樣總是逃不掉，寫代碼、測試、發布到線上。具體來看首先要拉分支，每個團隊一般都有自己的研發規范，團隊成員都需要遵守才能保障基本研發秩序。其次，我們會先在本地進行一些測試，編寫一些測試用例，測試通過后需要進行合并請求，最終經過一個流程，逐級發布代碼到生產環境。

這老三樣說起來簡單，但正是我們研發效率需要提升的重要環節，因為它們每天都在不停地被重復。甚至在不斷的反復踩坑。比如有重復的工作，有質量問題，有環境問題，還有協作問題。在持續交付原則中有一項，就是如果這件事讓你痛苦，那就盡早且盡可能頻繁地去做。當然我們不能容忍各種坑，各種效率低下，那么就要想辦法去解決這些讓我們頭疼的問題。

技術管理者的煩惱

開發者日常的苦惱，必然也是技術管理者的煩惱。總結一下，一般會是這么幾個方面：

研發流程混亂。團隊有大量新人的時候，如何能確保每次代碼提交都不會出錯？跨團隊協作的時候，如何讓所有人對于流程理解都是一致的？如何能不用一個scm團隊來解決這個問題？其實我們的實踐中scm團隊也解決不了，如果沒有完善的工具支持，很難確保萬無一失。
質量無法保障。測試用例覆蓋，規約掃描，安全檢查是否都能實打實的保障，如何去促進代碼質量逐步提高，而不是形成破窗效應后越來越差。
環境管理低效和資源浪費。這個一直是運維工程師的痛，尤其是測試環境。微服務化后，這個問題更加嚴重，服務之間互相依賴。管理復雜度和工作量成倍提升。還好我們有了容器化的救命稻草，但是仍然無法解決應用穩定性問題。穩定性不好直接導致開發工作互相block，最終拖慢我們整個團隊效率。
繁雜的開源工具。用一堆工具攢出來的流程能否一站式解決所有問題，并且有比較好的體驗？這要畫一個問號。

看到這些問題，我想大家不由自主的會想到云計算，容器化，DevOps等等新的名詞，那我們首先看看目前這幾個在業界的形勢如何。

持續交付與云計算

這是我從2016中國軟件開發者白皮書中摘錄的一些信息。首先看到的是企業上云成為趨勢，因為上云可以大大減少我們的it成本，不管是公共云還是私有云。目前來看私有云還是首選，最近3年從7%增長到27%，混合云是目前比較流行的玩法。

DevOps成為業界熱詞。DevOps給大家帶來的直接的想法是將兩種角色合二為一，效率肯定有提高，因此可以看到86%的企業不同程度上使用了DevOps相關工具，大部分是Docker和Jenkins。不難理解，這兩個工具是目前最容易上手的。

最后是企業對開發工具和流程的認可，絕大部分企業都有嚴格的研發流程對開發工作進行規范，7成人群在其中受益，并且21%開發者希望公司能加大在這方面投資。這個數字挺有意思，可能表明還有3成的員工還在痛苦掙扎，等待救援。

持續交付與DevOps

看了以上我們管理者的痛點，回到正題，持續交付和DevOps，如何能使用這兩個理念來解決我們軟件生產中的問題？先看看兩者要解決的核心問題。

首先是持續交付，核心是需求小批量流轉，配合自動化流水線，實現軟件短周期的頻繁交付。
DevOps的核心是什么？幾個關鍵詞：一種方法和文化，自動化、度量和分享，基礎設施即代碼。

在這里名詞解釋并不是我的重點，先撇去概念看本質，其實兩者都是在說效率與成本這兩個詞。如何做到效率最高，如何做到成本最低，就是我們研發平臺要解決的核心問題。

下面我會重點圍繞這兩個主題，來介紹阿里巴巴如何做到高效協作和成本控制。

二、高效協作&成本控制

研發模式全自動化

說起自動化我們就想到了流水線，但是僅僅是流水線還是不夠的，它僅僅解決的是發布過程自動化問題，并無法完全解決開發者的日常協作問題。比如什么時候拉分支，什么時候合并代碼，需要達到什么樣的標準，發布分支怎么處理，如何和流水線自動的結合起來。這些才是開發日常工作中最繁瑣，最容易出錯的事情。

如何將研發模式固化下來，并形成全集團的幾套規范，落地平臺？如何讓開發之間的協作都一鍵化，自動化？這是云效首先要解決的問題。

在我們的實踐中，將分支模式、自由模式、gitflow模式抽象到產品層面，穿插在流水線前中后，實現研發模式全自動化。真正的做到了研發過程全上平臺，所有數據可追蹤，并且徹底杜絕了漏發、錯合、管理混亂的情況。甚至開發只需要會checkout和push，其他的都交給平臺處理。

總結一下就是規范操作、高效協作、避免錯誤。分支模式和自由模式已經在云效開放，其他模式和高級配置功能正在陸續開放中。

統一技術棧和運維棧

研發過程統一了，那么接下來要面對的就是技術棧和運維棧。我想絕大部分企業都不太喜歡自己的技術棧過于龐雜，這會給員工帶來很大的學習成本，比如阿里巴巴主要是Java，我們可以投入很大精力去做框架，去做JVM優化，建設中間件，包括很多測試方案都會基于這個技術棧來做。運維棧更不用說，標準化才能帶來成本的節省和效率的提升。

阿里是從以下五個方面來保障技術棧和運維棧統一的。
首先我們有基于不同研發模式和流水線的視圖，根據不同的技術棧，在流水線視圖上也略有不同。打個比方：C類應用的發布比Java類的就略顯復雜，他們在依賴軟件包的更新和參數維護上略有差異，我們通過不同的流程組件來解決。
其次是代碼推薦，其中包括各種語言技術棧，最新的玩法和框架，讓我們平臺成為了新技術推廣的窗口。
運維模板會包含軟件包的模板，Dockerfile，環境規劃等等。我們會提供標準化推薦，各個BU技術負責人也可以在平臺上針對自己的部門進行定制和維護。所有這些都會在應用創建時確定，普通開發基本不需要介入和了解。
最后兩層可以歸納到基礎設施層面，統一的應用運維平臺，負責機器資源和相關軟件資源的分配。系統軟件幫我們解決虛擬化和運行環境問題。
這五個層次共同協作才能完整實現技術棧和運維棧的統一，而云效在阿里巴巴正是我們看到的paas和iaas層的對普通研發人員統一出口，并且負責將這些服務粘合起來。比如最新的發布技術、中間件隔離技術、灰度切流技術、測試技術等等。

全云化測試平臺

前面從研發、技術、運維角度講了如何幫助開發高效協作。下面會講兩個成本控制的例子。

首先是全云化測試平臺，阿里巴巴雖然技術棧大體統一，但是仍然避免不了各個BU在測試方面的創新，各種工具，各種平臺必然會導致一些重復建設和資源浪費。最近幾年我們開始建設全云化測試平臺，首先他要做的是將各種測試工具通過統一的標準接入進平臺，再通過統一的調度引擎為測試工作提供資源保障。當資源由我們來控制的時候，就可以創新出很多資源節省的策略，比如動態伸縮，資源池復用，離在線混布等等。目前我們每日的任務是已經達到了10w+。

可以從這個圖中看出用戶的各種測試工具統一運行在我們的Test engine上，資源來自集團ECS和Docker池，并且在云效我們支持了企業自研自動化測試工具的接入，方便用戶將自己的測試方案在企業內部推廣和落地。

測試環境隔離

下面我們看下測試環境，大家可別小看了線下測試所帶來的資源成本。在阿里目前線下測試物理機規模已經達到數萬臺。隨著微服務化的推進，應用數量和依賴復雜度都被迅速放大，如何管理好測試環境和資源已經變得非常棘手。

這里介紹下阿里的一個比較好的實踐經驗：測試環境隔離。先看下這個圖，我們把日常工作環境分為三部分，第一個是開發機，調用請求的發起方，可能就是我的一個筆記本。第二是隔離環境，里面部署著我們需要聯調的應用A1、B1、C1。這三個應用正在實現我們一個要上線的需求。當然我的調用鏈路會很長，有更多的依賴方，自然我們需要一個基礎環境，這個環境里部署著我們所有的應用。

類似這種隔離設計，既保障了業務聯調又節省了大量機器資源，當然最關鍵是我們如何實現服務之間的調用隔離。在阿里內部http統一接入、全鏈路追蹤和統一中間件技術，幫助我們實現了無業務侵入性的服務隔離，不需要額外的運維工作，只需要在系統上劃出相應的服務范圍，對于調入請求會自動進行染色操作，不管這個請求調用到哪里，不管是同步還是異步，最終都可以保證A、B、C服務在兩個環境中的互斥關系。

未來類似的環境規劃和服務隔離能力也會在云效開放。總結一下就是環境復用、一鍵申請、快上快下、無代碼侵入。

企業級持續交付

我們看下一個持續交付平臺如何才能做到真正的企業級。

第一個階段應用創建，元數據維護，代碼推薦，技術棧模板，流水線。第二是測試驗收，靜態掃描、代碼規約、安全測試等等。測試完成我們需要部署，就涉及到環境的標準化，企業統一的環境規劃，運維模板和云化的動態伸縮能力可以為我們大大節省成本。最終要發布前還需要管理審核、驗收卡點、發布窗口等等管控策略。最后上線過程一定需要分批滾動、過程監控和快速回滾能力。

如此五大內容基本可以滿足我們開發人員日常的研發活動，不斷地在這幾個過程中流轉，實現最終持續交付目標。

三、阿里DevOps落地

應用為中心的DevOps理念

接下來我們回到DevOps這個熱詞上，和大家分享下阿里巴巴如何實現DevOps落地，從開發工程師角度怎么看待DevOps這個運動。

第一點我要提的是以應用為中心的DevOps理念。應用信息其實可以歸納為cmdb中的一種數據，它對于研發人員天然是親切的，它可以直接對應一個服務，一個代碼庫。從代碼為起點，又可以串聯流水線、環境、測試和資源，最外圍工具鏈監控、db、運維、中間件等等。

用應用串聯整個工具鏈，可以讓開發順理成章的理解和打通DevOps整體過程。不會存在開發說代碼，說服務，運維說機器，說機房這種雞同鴨講的情況出現。

當工具通過應用打通后，開發就可以順理成章的在平臺上定義它的應用，同時也是在定義運維。比如我可以規劃環境，創建資源，設置發布策略等等。

完成定義后，誰定義就要誰負責，因此在阿里，開發需要為應用全生命周期負責，也就是我們看到的這整個大圈。通過類似理念和運維自動化工具化的推進，dev潛移默化的接手了ops的工作，會發現原來這些東西并沒有那么復雜。

應用生命周期自助管理

下面我們看一個實際的例子，這是我們一個應用上線過程，信息初始化，代碼推薦，配置設置，資源申請，step by step完成。

不論是測試環境還是生產環境，不管是技術棧還是運維棧，全部由開發工程師來定義。在全過程中只需要一次審核操作，分鐘級即可完成應用注冊和發布。

說到全生命周期管理，我們在應用上線后，還會配合度量系統，評估應用健康狀況和資源使用情況，對長尾應用進行及時清理和資源調整。

容器化助力DevOps落地

再來看容器化。阿里巴巴從2016年雙11前開始大規模推廣容器化技術，到今年雙11已經完成了幾乎所有活躍應用的容器化，這是一個非常驚人的技術革命。為什么我們要這么大力氣去推動改變，容器化對DevOps又有何幫助？

大家可以看這個圖，左側是在容器化前，我們要做的事情和所需要的角色。軟件包管理、基線變更、運維腳本的修改、資源申請、擴縮容等等，哪個工作離不開運維工程師。這些事情門檻高，手工程度大，變更方式復雜，最終導致兩個角色協作效率低下。

右側是我們容器化后的情況，原先軟件包管理、基線變更、運維腳本統統交給了dockerfile來解決。在代碼庫里管理，并通過流水線實現變更，大大簡化了變更復雜度。另一部分比如日志清理，巡檢類的運維腳本我們通過全網命令通道插件化的承載在ops工具上，負責同學轉型為工具開發來維護插件的可靠性。

其他資源類的事情統一由容器調度解決，其中包括統一調度開發，規模化運維相關算法開發等等，通過人工智能，通用性的解決資源利用率問題，比如2017年雙11落地的離在線混布技術。

通過容器化，我們實現了環境標準化，運維服務的下沉，智能化的解決了效率和成本問題。因此可以說通過容器化改造，DevOps理念真正在阿里落地。

松管控和強卡點

最后還有一個比較關鍵的點，當開發開始定義運維，接手運維的時候，我們管理者會不會有些擔憂，比如會不會開發任意操作導致線上故障，隨意發布導致穩定性問題等等。

在阿里我們建設平臺的核心理念是松管控和強卡點。先看松在哪里？松在我們有多種流水線可以供開發選擇，應用owner可以完整定義這個應用的各種規則，比如如何發布，如何測試，資源、環境配置如何。我們有通用構建和自定義構建給用戶最大自由度，最后我們是輕發布，重恢復。在每一個應用維度，開發可以隨時使用流水線來交付代碼，而并不需要特別的限制，僅僅需要思考的是如果出問題，我們應該如何快速恢復。

在足夠的自由度下我們還有一些卡點可供選擇，比如代碼審核和質量紅線，規約檢查，發布窗口，和前后端聯動。這些卡點是為了保障集團所有開發工程師步調統一，交付合格的產品。

持續交付核心是快速交付價值，給與開發最大自由度，負責開發和運維全部過程。在監控、故障防控工具，功能開關的配合下，可以在保障用戶體驗和快速交付價值之間找到平衡點。

四、云效實踐

上手云效最佳路徑

最后我們看看如何通過云效提高研發效能。首先可以通過首頁的快速開始完成創建產品空間，創建代碼庫，選擇我們的研發模式，創建應用，也就是剛我們所說的非常重要的基礎元數據。然后配置構建、機器、部署規則，并通過流水線完成交付。

云效會提供一些模板和測試機器，幫助我們快速上手。

使用持續交付流水線

大家現在看到的是我們系統一個流水線的視圖，根據不同的研發模式，視圖會略有不同。云效根據現代企業軟件研發特點，自主研發了全新的流水線。不同的團隊，比如研發、測試、運維都可以在不同的stage上工作，并且互不干擾。而且有多種觸發機制可供選擇，阿里優秀的組件還在陸續開放中。

無侵入的構建加速

再來看下構建，云效完全自研的全云化構建調度系統，擁有經過阿里云安全團隊認可的安全加固機制。并且根據不同技術棧提供了自適應的構建緩存策略，避免依賴的重復下載，大大節約構建時間，提高開發過程效率。開發在使用云效只需要選擇他的技術棧和構建命令，其他都可以交給平臺自動化完成。

全網部署能力

再看下部署能力，不管是公共云，還是專有云，還是其他云主機，云效都可以接入并執行部署。他是基于阿里內部的agent的技術，安全高效，此技術已經在阿里巴巴全網部署并且經過多年改進。

如下圖所示，不管是采購云效公共云還是專有云，我們的主機都無需暴露公網就可直接接入，可選擇通過internet或者專線對不同的云進行互聯，對開發人員屏蔽底層機器資源細節，提高自動化程度和工作效率。

Docker、EDAS、ECS任意切換

云效目前支持Docker、Edas、Ecs三種部署方式，對每個應用的每個環境都可多帶帶定義它的部署方式，并且實現任意切換，方便快捷。比如我們生產環境使用edas保障穩定，測試環境使用ecs混合部署節省資源都是可以實現的，非常方便。

在我們做運維棧轉型升級的時候，可以通過修改部署配置進行平滑升級，如果有問題，我們還可以實現一鍵回滾。云效保存著歷史所有軟件發布升級的基線數據隨時可查，隨時可rollback，這些都是阿里巴巴內部多年積累的實踐經驗。

作者介紹

陳鑫（花名神秀），阿里巴巴高級技術專家，負責阿里集團持續交付平臺和研發工具建設，致力于企業研發效率、產品質量、DevOps方向研究和探索。在阿里6年帶領過大數據測試團隊、測試工具研發團隊、持續交付平臺團隊。對研發協同、測試、交付、運維領域都有很深的見解。