如何構建高效自主的容器雲交付平臺？

高效自主的容器化交付平臺=敏捷工程理念 x七牛雲交付平臺組件(雲存儲+大數據+容器雲)

隨着 DevOps 理念的普及，大部分公司已經嘗試敏捷項目管理並取得必定的成果，但實際代碼生產過程仍然是分角色的瀑布式交付，沒法實時開發、實時測試、實時部署，但隨着容器和大數據技術的到來，讓每一個企業都能擁有一套高效自主的容器化交付平臺。

11 月 23 日，七牛雲架構師實踐日第 32 期以「容器技術的實踐與分享」爲主題，在成都成功舉行。七牛雲工程效率部負責人李倩，在會上爲你們帶來了題爲《容器雲交付平臺—實現真的敏捷開發/測試/部署》的精彩分享。

做者簡介：

李倩，前後主導多家 IT 企業分層自動化測試框架的落地實踐，積累了大量自動化實戰經驗。2014 年入職七牛，從零開始構建七牛質量保證體系，推動與完善了研發體系持續交付和持續集成。前後負責存儲、數據處理、直播等產品的質量把控，構建了第一支使用 go 語言爲自動化框架基礎支撐的質量保證團隊。

如下是演講內容的實錄整理。

---

你們好，簡單介紹一下，我我的經歷作了九年的軟件開發和測試開發工做，其中包含四年技術管理經驗，2014 年入職七牛在負責工程效率部，目前帶領 40 人左右的團隊爲咱們的研發團隊提供質量保證，研發流程管理，持續交付平臺等工程和質量服務支撐。今天就容器交付方面實踐經驗給你們分享一下。

七牛雲的業務場景

七牛雲已經成立 7 年了，如今有 6 條產品線和豐富的行業解決方案，還有一些產品內部運營和私有化項目。體量是很是大，架構上咱們基本是微服務化，主要是採用 go，也有其餘語言棧，這就須要提供多樣性的編譯和運行環境。做爲一個創業公司，咱們的發佈要求很高，要很快的響應客戶的需求。

大公司和小公司對於 to B 的服務差別在於，小公司能快速應變，考慮需求合理性快速實現，以適應客戶的業務，而在大公司裏可能須要一個月甚至兩個月。咱們發佈週期一天會有十幾回的發佈，也會有按時按需的發佈需求。另外，咱們的協做難度也比較大，有 400 多個研發同時寫代碼，進行上線、運維。有一些還要進行後續的跟蹤和反饋，質量上難以控制。作雲計算本質上是在提供「水、電、煤」給各個業務，對可用性和健壯性，質量方面要求很是高，這兩年咱們面向行業提供完整解決方案，會涉及更多的複雜場景，其中會涉及多產品服務的組合測試，自動化測試用例數量也是很是多的，要高效的運行同時知足高業務覆蓋率是很是大的挑戰。

工程效率的挑戰

在這樣的業務場景下，按照角色總結了不一樣的挑戰。

第一，開發同窗面臨多樣化的編譯、運行環境，自測難度高，分支合併頻繁沒法可靠發佈。做爲工程師，咱們七牛要求每一個人要對本身的代碼負責，因此咱們須要給你們提供測試的便利性以及關注代碼發佈質量的可控性。讓開發同窗有能力從保證代碼的正確執行到去關注業務的正確性。

第二，質量方面，有限的測試資源，咱們不可能徹底模擬，咱們有測試的獨立機房，有限的測試環境下，怎樣充分利用資源，怎樣模擬更多的場景，這些都是要面對的質量問題。

在不少偏業務的公司裏，測試看起來是阻礙公司快速上線但又不得不作的事情。那如何提供更快的反饋能力讓 QA 同窗如何更早介入、更早驗證，作到實時測試，更快上線，這也是一個巨大挑戰。另外，如何作到對總體質量的把握，對整個代碼生產過程的質量管控都是要工程上關注的問題。

第三，運維方面，服務拆分後運維須要管理維護的服務數量級增長了數倍或者數十倍，運維架構複雜度提高，雖然服務能夠獨立部署，可是因爲內部依賴，獨立部署的微服務不可測、或者功能不能完整走通。咱們雖然是拆開了部署方面提高了速度，可是拆了之後怎樣保證在合的時候沒有問題。面對這樣的架構複雜，怎樣提高運維的效果？

解決的思路

下面介紹解決的思路。標準化，關於怎麼樣讓團隊更快項目迭代的內容我會省略，而後直接講敏捷開發，關於全流程的質量保障是怎麼作的。重點會講怎麼樣把研發過程搬上平臺，讓開發過程再也不是部門壁壘式的，而是真正你們在價值流動過程當中看到本身的交互過程，以及提供的延展服務。智能化這塊我也會省略，咱們作了一些嘗試，仍是比較有效果的，後面會有一些數字給你們看。

標準化

首先介紹代碼生產的過程。代碼管理咱們用的 github，作了比較完善的持續集成體系，工程師能夠屢次頻繁的提交快速得到每個代碼片斷的質量反饋，這裏的反饋會包括單元測試，覆蓋率合規，代碼檢查合規。另外 CI 過程耗時我建議 10 分鐘之內，若是達不到這樣的水平，要分析 UT 是否是寫的有問題，是什麼致使你的損耗，另外就是構建平臺自己效率有沒有瓶頸。這裏 PR Auto Check經過，通常狀況會有一到兩我的作 code review。這裏我很是建議你們重視 code review，這是工程師自我提高和追求極致很是好的方式和契機。code review 經過後，合併到 Develop 分支，會自動觸發平臺作持續交付。成熟度高的產品，若是這個測試經過，咱們配置好的 hook 流程會自動流轉到待發布的狀態，通常成熟度的產品會有 QA 作業務驗證和測試用例補充人工觸發 jira 的狀態變化，這裏描述的是一個功能的完整交付過程。這個過程協同幾乎是同步的，issue 粒度上開發交付什麼測試就能夠測什麼，後續平臺但願支持到 pr 能直接觸發持續交付，這會將自動化驗證能力進一步提早，進一步縮短代碼到 ship 間的距離。

這是預發佈到發佈的階段，以前的功能代碼都測過。Develop 合併至 master，它就能夠觸發持續交付面向發佈的驗證，對接發佈平臺按需進行發佈。

咱們協做經過什麼方式作起來呢？

是用角色的 Pipelines，面向角色和觸發條件，咱們會定義自測、集成、發佈的 Pipelines 創建交付機制。真正的敏捷是他再也不須要去按照準入條件是什麼，在週四仍是週五測，而是咱們能夠隨時測，每日均可以測試，能夠隨時去補測試用例做爲自動化驗證的一部分。

流程裏的涉及質量保障，咱們的思路是面向不一樣的觸發條件和交付目的創建質量卡口並創建自動化驗證體系收集質量數據作分析。

平臺化

平臺化是今天介紹的重點。這個平臺咱們作了一年多，中間也經歷了不少過程，從不成熟的容器化到容器化的狀態，到如今能夠規模容器化的狀態。

這是一站式研發交付平臺的能力的描述，支持混合模式測試環境管理。不少人在上微服務，但其實咱們的微服務不全都是一把上的，多是一個一個來上，基本思路先從無狀態的上，再上有狀態和基礎應用。這種方式下，如何保證質量穩定，如何保證順利容器化，咱們也想了不少的辦法。咱們考慮必須支持混合的模式，如今咱們是支持兩個完整的環境，哪些內容容器化，咱們就在容器化管理；哪些沒有容器化，咱們就以兼容模式來作管理，這樣保證環境是持續進行更新的，整個研發體系的支撐也是持續更新的。另外咱們提供產品和服務級別的編排，易於管理微服務關係和依賴，可以將微服務組裝成完整的產品，並構建面向角色的持續交付流水線。咱們主張開發測試運維一體化，因此會統一管理渲染關係和涉及到的模版。

交付工具鏈。咱們目前一部分產品已經切到持續交付平臺 2.0 版進行容器化交付，這跟產品階段，業務形態，複雜度都有關係，經過評估咱們會逐步遷移和支持。測試框架我推薦你們用下 ginkgo，在處理分佈式和併發測試的時候，執行效率很是高並且維護起來很輕量，框架自己是 go 寫的。其實你們不難看到咱們並無採用不少的工具，我認爲工具在於你能不能用好，而且低心智負擔的銜接起來，遊刃有餘的把流程真正梳理清楚歸入平臺。

延展服務。咱們會作不少服務嵌入到工做流裏，好比持續集成過程裏咱們服務化收集單元測試，代碼審查的質量數據。在持續交付階段則支持集成測試與覆蓋率服務。測試服務咱們已經延伸到了各類環境場景，好比說交互的私有云、雲存儲，也能夠定向跑驗證灰度部署成功與否。另外咱們也作了 Chaos 工程嘗試，會拿不少破壞性的程序，看服務是否健壯。接下來會把這些的服務能力逐步歸入新的持續交付體系。

微服務架構介紹

首先講一下工程理念。你們一直會有疑問，微服務架構究竟是什麼東西？微服務究竟是什麼世界觀？如下是我我的的見解，面對更多的場景和業務的時候，咱們要處理本身團隊規模的複雜度提高，系統高可用、高併發的要求，如何讓更多人更爲有效的開發更大致量業務的程序？你們發現微服務可讓更多的人蔘與到複雜體系的設計和交付上，咱們根據業務架構拆分更合適的微服務經過接口約定實現高效協做。

微服務化是化零爲整、化繁爲簡的過程，持續交付平臺是提供組裝和管控的能力。自動化的框架要穩定，而且自動化 Case 要能覆蓋交付能力，這樣能夠真正到必定程度自助的持續發佈、持續部署。

Spock 的總體架構不復雜，分 biz、service 和底層服務支撐。底層的 Service，咱們用七牛雲本身家的存儲、大數據、容器雲，也分別解決了不一樣的問題。好比說存儲，咱們會把交付的可用包和 log 放在雲存儲上作備份，用大數據產品提供實時日誌分析和監控的能力。容器則是最最核心的底層，咱們的容器團隊提供了很穩定可靠的容器集羣以及各類基礎組件 app。

上圖是平臺工做流結果查看。右邊有一個關聯問題，下面會有對應的代碼庫以及服務內容，是一個基本的信息和構建。構建之後部署，部署會有產品信息以及部署的環境，以及經歷什麼樣的測試，串聯的項目管理、代碼管理、環境管理與發佈相關的全部信息、交互的管理，都會在這裏去體現。

這是咱們的質效系統，會去分析持續交付過程當中的一些質量和效率指標，幫助咱們識別質量和效率短板。這裏的指標是其中一部分，這些指標是會根據每一個季度，半年度，從衆多量化指標中選擇比較關注的急切去改善的放在這裏，內部優秀團隊評比和獎勵也會參考質效數據，獎勵也是會涉及交付鏈條中各個角色而再也不是一個實體部門。

這裏也跟你們分享下個人見解，全部的指標都不該該是評價人的絕對值，由於人的素養是多維的，不可能被徹底的數字化評價，可是經過這些數據來反映必定的交付和團隊協做能力，好比說返工率是必定程度體現返工和質量狀況；單元測試和合規實際上是代碼基礎質量的評估；事故反應全組對服務高可用最終努力的成果。

咱們如今達到的水平是核心模塊是 60% 以上，核心模塊代碼合規 80 分以上，持續交付經過率 85% 以上，集測覆蓋率 E2E+API 達到 35% 以上，事故嚴重率逐 Q 降低1 0% 以上，構建效率 2-10 分鐘，缺陷解決率是 82.97%。有一部分 QA 已經從測試開發變成了開發工具或測試服務的狀態。

以上是咱們平臺實踐成果的圖，增加業務比例在降低，質量水平是穩步提高的。質量平臺大概是從 2016 年初開始作的，也有一些指標由於不合理被砍掉，最終從 20 多個指標到 10 個左右，最終抽取的核心指標主要是跟工程的正向促進相關的。

謝謝你們。

---