高效自主的容器化交付平臺=敏捷工程理念 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 個左右，最終抽取的核心指標主要是跟工程的正向促進相關的。
謝謝大家。
