前言

　　隨著越來(lái)越多的企業(yè)將云計(jì)算產(chǎn)品應(yīng)用到基礎(chǔ)設(shè)施及其核心業(yè)務(wù)中，如何提高和保證軟件交付質(zhì)量、減少軟件開發(fā)迭代周期、加速軟件發(fā)布頻率成為所有云廠商面臨的關(guān)鍵問(wèn)題。

　　根據(jù)IDC 2018年的預(yù)測(cè)，中國(guó)云計(jì)算市場(chǎng)在未來(lái)5年將持續(xù)高速發(fā)展的態(tài)勢(shì)，主要表現(xiàn)為：中國(guó)傳統(tǒng)的非云計(jì)算IT基礎(chǔ)架構(gòu)占整體IT基礎(chǔ)架構(gòu)的投入比例將從2018年的50.3%下降到2022年的40.7%；中國(guó)私有云平臺(tái)建設(shè)的市場(chǎng)規(guī)模將以年均24.8%的復(fù)合增長(zhǎng)率快速增長(zhǎng)；中國(guó)云計(jì)算IT基礎(chǔ)架構(gòu)支出占全球市場(chǎng)比將從2018年的12%上升到2022年的25%，屆時(shí)中國(guó)私有云IT基礎(chǔ)架構(gòu)支出將超過(guò)美國(guó)，成為全球第一大市場(chǎng)。在這一輪新的迭代更新中，更多的企業(yè)和行業(yè)開始部署或者建立更大規(guī)模的私有云；而新應(yīng)用（數(shù)據(jù)分析，AI，IoT，移動(dòng)）和新場(chǎng)景（邊緣計(jì)算，智慧/平安城市，行業(yè)云）也對(duì)云平臺(tái)提出了更高的需求。

　　ZStack憑借創(chuàng)新的產(chǎn)品化理念，在業(yè)內(nèi)率先提出云計(jì)算的4S標(biāo)準(zhǔn) – 簡(jiǎn)單Simple，健壯Strong，彈性Scalable，智能Smart。同時(shí)，ZStack企業(yè)版從第一版發(fā)布到最新的3.5.0版本，一直以每六周一次的周期迭代更新軟件版本，快速提升和擴(kuò)展產(chǎn)品功能，積極應(yīng)對(duì)云計(jì)算市場(chǎng)對(duì)私有云產(chǎn)品不斷增長(zhǎng)的需求。而保證其私有云產(chǎn)品化的關(guān)鍵要素有以下三點(diǎn)：

   1、 流程 – 快速敏捷

   2、 運(yùn)維 – 智能高效

   3、測(cè)試 – 嚴(yán)謹(jǐn)全面

　　注：ZStack堅(jiān)持快速、簡(jiǎn)潔、高效的開發(fā)、運(yùn)維、測(cè)試流程，確保新需求六周便可實(shí)現(xiàn)

 1. 流程-快速敏捷

　　ZStack開發(fā)流程依然定義了傳統(tǒng)開發(fā)模式中的幾個(gè)關(guān)鍵階段 - FF、CF、RC和GA。同時(shí)針對(duì)不同階段的任務(wù)和目標(biāo)，進(jìn)行有的放矢地優(yōu)化。在Feature Freeze階段，主要以需求分析為主，要求產(chǎn)品經(jīng)理將客戶的需求分片化、分級(jí)化，需求描述本地化，更有效地將需求安排到不同發(fā)布版本周期中。開發(fā)和測(cè)試工程師則需要將Code Freeze和Release Candidate的任務(wù)提前到Feature Freeze階段中，減少互相之間任務(wù)的依賴，提高各個(gè)階段的并發(fā)度。而測(cè)試不僅需要滲透到開發(fā)的每個(gè)環(huán)節(jié)中，同時(shí)也要通過(guò)模型測(cè)試、路徑測(cè)試、穩(wěn)定性測(cè)試等方法，提高代碼的覆蓋度和測(cè)試效率。每個(gè)發(fā)布周期通過(guò)反復(fù)地從需求->開發(fā)->測(cè)試的快速迭代，保證了產(chǎn)品的新需求和問(wèn)題始終能夠被快速滿足和解決。

　　注：ZStack產(chǎn)品開發(fā)流程高度并發(fā)，保證版本之間快速迭代

 2. 運(yùn)維-智能高效

　　作為私有云產(chǎn)品開發(fā)的基礎(chǔ)保證，一套快速、穩(wěn)定、高并發(fā)、可伸縮的運(yùn)維系統(tǒng)是必要的。而傳統(tǒng)運(yùn)維提供的簡(jiǎn)單CI和CD功能是顯然無(wú)法滿足這樣快速迭代的需求。ZStack產(chǎn)品化過(guò)程中，搭建了一套以ZStack Kubernetes為基礎(chǔ)、面向公司各個(gè)部門的整體性服務(wù)框架。這套框架中所包括的服務(wù)內(nèi)容涵蓋從開發(fā)&測(cè)試人員使用的測(cè)試環(huán)境、到整個(gè)項(xiàng)目的管理工具。框架的底層以ZStack作為IaaS提供給上層可靠的、可擴(kuò)展的物理資源，同時(shí)結(jié)合Kubernetes，將容器運(yùn)行于云主機(jī)中，既保證了隔離性、又充分利用了ZStack和Kubernetes對(duì)云主機(jī)和Docker調(diào)度的優(yōu)勢(shì)，起到了對(duì)上層服務(wù)高可用、高并發(fā)及可伸縮的雙重保障。

　　注：ZStack作為IaaS層向上層服務(wù)提供可靠的物理資源，而更重要的是，內(nèi)部的ZStack環(huán)境也會(huì)隨著發(fā)布版本更新，真正做到了自己的產(chǎn)品自己先用起來(lái)。

　　注：實(shí)際生產(chǎn)環(huán)境中，一次自動(dòng)化測(cè)試至少在Jenkins上并發(fā)創(chuàng)建500 個(gè)請(qǐng)求，每個(gè)請(qǐng)求包含10~50個(gè)測(cè)試用例，ZStack Kubernetes保證了這些請(qǐng)求幾秒內(nèi)可以被處理

 3. 測(cè)試-嚴(yán)謹(jǐn)全面

　　打造一個(gè)產(chǎn)品化的私有云軟件需要全面且嚴(yán)謹(jǐn)?shù)臏y(cè)試，這不僅僅是單元測(cè)試和集成測(cè)試能保證的。ZStack從以下四個(gè)方面入手強(qiáng)化測(cè)試：

　　3.1  測(cè)試高效化：整個(gè)產(chǎn)品流程中開發(fā)和測(cè)試要同步進(jìn)行，這包括了對(duì)不同的開發(fā)分支需要有不同深度的測(cè)試代碼保證其質(zhì)量——例如，對(duì)于Release分支，必須有持續(xù)性的Nightly測(cè)試把控每天進(jìn)入的代碼質(zhì)量；對(duì)于Feature分支，需要能快速檢測(cè)出patch對(duì)代碼核心功能影響的BAT測(cè)試。同時(shí)測(cè)試系統(tǒng)和CI系統(tǒng)要高度集成并且做到同步觸發(fā)。

　　高效化的另一個(gè)重點(diǎn)就是要做到所有測(cè)試都能運(yùn)行在云端，提高測(cè)試的并發(fā)度和資源利用率。ZStack內(nèi)部的測(cè)試都是跑在云端的，而云端環(huán)境也是基于ZStack自身搭建的，利用其對(duì)底層硬件資源的抽象和管理，模擬出測(cè)試中需要的不同的硬件配置場(chǎng)景，包括網(wǎng)絡(luò)、存儲(chǔ)、虛擬化平臺(tái)、甚至不同的ZStack高級(jí)功能配置，如企業(yè)管理、災(zāi)備服務(wù)等。同時(shí)，為了滿足大規(guī)模資源需求的測(cè)試場(chǎng)景，例如1萬(wàn)臺(tái)或10萬(wàn)臺(tái)云主機(jī)的測(cè)試場(chǎng)景，ZStack測(cè)試中還實(shí)現(xiàn)了simulator機(jī)制，即不真實(shí)分配硬件資源，而使用mock后端API的方式提供了對(duì)后端資源的調(diào)配，真正做到了有針對(duì)性的測(cè)試。

　　注：ZStack云端測(cè)試的環(huán)境構(gòu)建是通過(guò)XML配置文件實(shí)現(xiàn)的，測(cè)試工程師可以非常簡(jiǎn)單地用幾分鐘配置出一臺(tái)自動(dòng)化環(huán)境。

　　3.2 測(cè)試標(biāo)準(zhǔn)化：ZStack所涵蓋的測(cè)試內(nèi)容不僅包括功能性測(cè)試，還包括一套完整測(cè)試體系所需要的各種測(cè)試，如開發(fā)工程師需要做的集成/單元測(cè)試，測(cè)試工程師需要做的系統(tǒng)測(cè)試中的壓力、性能、可靠性測(cè)試、以及針對(duì)不同版本定制的發(fā)布測(cè)試。例如ZStack的可靠性測(cè)試就包括了兩類測(cè)試 – MTBF和DPMO測(cè)試，MTBF會(huì)對(duì)ZStack平臺(tái)進(jìn)行15,000小時(shí)長(zhǎng)時(shí)間的真實(shí)用戶操作模擬；DPMO測(cè)試則會(huì)對(duì)ZStack平臺(tái)進(jìn)行高達(dá)10,000次的斷/上電、重啟等測(cè)試。

　　標(biāo)準(zhǔn)化的另一方面體現(xiàn)在對(duì)關(guān)鍵節(jié)點(diǎn)的標(biāo)準(zhǔn)把控上，對(duì)FF、CF、RC和GA各個(gè)階段都會(huì)有相應(yīng)的代碼準(zhǔn)入和驗(yàn)收標(biāo)準(zhǔn)，例如CF階段后功能開發(fā)代碼禁止進(jìn)入發(fā)布分支而只能進(jìn)入下一個(gè)發(fā)布版本的周期；又例如各個(gè)階段驗(yàn)收時(shí)要求的bug數(shù)量限制，CF階段要求小于5個(gè)P0，GA階段要求沒(méi)有P0的bug。

　　3.3 測(cè)試覆蓋智能化：軟件測(cè)試沒(méi)法達(dá)到100%的覆蓋率，所以我們要做的是在資源有限的情況下，以盡量少的代價(jià)做到盡可能高的覆蓋率。要提高覆蓋率，需從兩方面入手，一方面是對(duì)代碼進(jìn)行覆蓋率檢查，我們?cè)谌粘I的包中插入了代碼不同模塊的覆蓋率，不管是手動(dòng)還是自動(dòng)測(cè)試，或是日常bug的驗(yàn)證，都會(huì)為覆蓋率提供數(shù)據(jù)。

　　另一方面我們?cè)黾恿四Ｐ蜏y(cè)試，它可以產(chǎn)生由隨機(jī)API組合構(gòu)成的場(chǎng)景，會(huì)持續(xù)運(yùn)行直到遇到預(yù)定義的退出條件或者找到一個(gè)缺陷。這種模型測(cè)試很好地彌補(bǔ)了人為定義用例的不足，提高了測(cè)試場(chǎng)景和路徑的覆蓋率。由這種測(cè)試模型，也衍生出了三種不同場(chǎng)景的覆蓋率提高測(cè)試：

　　3.3.1 覆蓋率測(cè)試：

　　除常規(guī)有序的測(cè)試步驟外，運(yùn)用模型測(cè)試，收集無(wú)序測(cè)試步驟下的測(cè)試覆蓋率。

　　3.3.2 MTBF測(cè)試:

　　從有序和無(wú)序兩種測(cè)試維度，對(duì)系統(tǒng)穩(wěn)定性及可靠性進(jìn)行測(cè)試。

　　3.3.3 路徑測(cè)試

　　通常一個(gè)系統(tǒng)測(cè)試用例最多5~6個(gè)操作步驟，而最終客戶的問(wèn)題場(chǎng)景是極其復(fù)雜的，通常需要10~20個(gè)以上的步驟才能重現(xiàn)，運(yùn)用模型測(cè)試的方法，可以有效減少構(gòu)建測(cè)試用例的代碼量。

　　注：一個(gè)典型路徑測(cè)試，只需要將測(cè)試對(duì)象和操作步驟寫到測(cè)試用例中即可完成

　　3.4 報(bào)告立體化：主要從兩方面實(shí)現(xiàn)，一是測(cè)試報(bào)告的結(jié)果自動(dòng)化、可讀化，是通過(guò)對(duì)測(cè)試用例中插入DITA描述實(shí)現(xiàn)的。另一方面是結(jié)果的可追溯和可回放，這是通過(guò)記錄測(cè)試過(guò)程中API的調(diào)用順序和參數(shù)實(shí)現(xiàn)的。

　　注：一個(gè)測(cè)試結(jié)果的操作記錄及回放方法，能夠有效幫助開發(fā)測(cè)試工程師重現(xiàn)bug

 總結(jié)

　　作為產(chǎn)品化的云計(jì)算公司，ZStack一直致力于打造自研的ZStack私有云、ZStack混合云、ZStackMini超融合一體機(jī)、ZStack CMP多云管理平臺(tái)、ZStack企業(yè)級(jí)分布式存儲(chǔ)等產(chǎn)品和方案。本文從開發(fā)流程、基礎(chǔ)運(yùn)維以及測(cè)試能效等角度，介紹了 ZStack 團(tuán)隊(duì)如何高效打造一個(gè)產(chǎn)品化的私有云。