導讀：

客戶規模擴大，如何保證大數據軟件產品和服務質量始終如一？幾乎所有成長中的軟件廠商，尤其是需要通過私有化部署交付的廠商，都會面臨這個問題。正如《人月神話》中多次表明的，單純地增加人手、擴大團隊規模，并不能成功達成大型系統建設目標。

軟件的生產、交付和運維，如何從“手工作坊”走向“現代化工廠”？廠商又應當在什么時候改變對“高級工匠”的依賴，研究生產線如何改造？

本文作者牧然，奇點云資深技術專家，曾在多家大型互聯網公司負責DevOps、質量保障體系建設、效能和過程改進，主導完成奇點云的工程生產線改造。

2023年，奇點云產品研發團隊改造了面向交付的工程生產線。

雖然投入了大量的時間精力，我們的最終結論是“磨刀不誤砍柴工”——成功提升了產品的發布版本質量和穩定性，提高了客戶環境部署、版本升級的效率，完善了客戶項目運維的響應流程，強化了主動發現風險的能力。

一、為什么要改造？

私有化部署的大數據平臺軟件，帶來M*N的挑戰

大數據平臺軟件體量大，通常是私有化部署的方式交付給客戶。奇點云的核心產品數據云平臺DataSimba也不例外。

有別于SaaS產品專注維護一套生產環境的一個發布版本，私有化部署的大型平臺軟件產品在交付和運維上面臨更復雜的挑戰：

對不同客戶的獨立環境（M），維護不同的產品發布版本（N），從數學上說，就會有M*N種維護場景。

當然，在客戶規模尚未出現井噴時，上述挑戰的影響還在可預見、可應對的范疇之內。

我們開始探索從“手工作坊”走向“現代化工廠”的路徑，根本上源于需求爆發：

- 2019是大家熟知的數據中臺元年，那時在全行業范圍內，建設數據中臺的企業都比較有限。

- 2021年前后，數據價值陸續得到驗證，數字化成為確定性選擇。DataSimba作為企業的數據基礎設施，新客戶數量激增，老客戶復購需求持續上漲。團隊面臨的交付、運維挑戰，相較往年也成倍上難度。

- 2022年，我們在收斂主售版本的基礎上，推出了長期維護版（即LTS版），一定程度上讓維護的范圍更集中。但團隊仍然需要投入大量精力，來應對“M*N”的交付和運維問題——除了日常維護，版本更新、漏洞修復等都需要準確無誤地更新到每個獨立的客戶環境中。

- 2023年，客戶對數據的使用不斷深入，數據系統成為核心的生產系統。除了軟件的功能，開始關注其Reliability（可靠性）、Availability（可用性）、Serviceability（可服務性），要求可靠、連續、穩定地產出數據業務結果。這就需要服務商提供“產品+服務+連續可靠的運行機制”做保障。

“RAS”是企業級軟件的金標準。這一年，我們從軟件、服務、管理等各個層面向“企業級”升級。毋庸置疑，企業級軟件在企業級客戶的交付和運維，也要達到企業級標準。而形成一條更優質高效的生產線，是規模化服務好客戶的前提。

二、改造面向交付的工程生產線

SAFe框架下，四項主要改造

回歸正題，企業級的私有化軟件產品交付，應滿足3個基本要求：

1. 產品質量：軟件通過嚴格測試，包括功能測試、性能測試、安全測試等等，覆蓋所有的功能和邊界情況，確保軟件的穩定性、可靠性。
2. 交付時間：要在嚴格的時間內完成交付。（也就是說，過去友商常見的花1個月甚至更久時間部署已成“過去時”。）
3. 運維服務：要滿足SLA要求，服務水平和滿意度達標。

上述三個要求映射到工程生產線的“開發—交付—運維”，我們需要完成的是：

1. 開發環節：將眾多分散的需求開發整合為整體發布，并對整體進行全面的自動化回歸測試以控制質量；
2. 交付環節：建立標準化交付流程，并實現自動化部署升級。
3. 運維環節：實現運維響應流程閉環，能主動發現問題。

在介紹具體改造實踐前，奇點云的產品研發有一個大前提：SAFe。

2021年至今，我們嚴格遵循SAFe（Scaled?Agile?Framework，大型敏捷軟件工程方法論）的迭代原則，保持產品研發和版本發布的穩定節奏，目前總計發布了32個R版。

Built in Quality（內建質量）是SAFe框架中的一個重要概念，要求團隊在工作的每個階段都要關注和進行質量實踐，而不是把質量留到最后的測試階段。

正如質量管理的先驅戴明博士（William Edwards Deming）所說，“檢驗不能提高質量，也不能保證質量。檢驗為時已晚，產品已有好壞之分。”“它（即質量）必須內置在其中。”在SAFe方法論中，有5個關鍵維度來衡量內建質量：流程（Flow）質量，架構與設計質量，代碼質量，系統質量，發布質量。

- 流程質量，我們通過持續優化開發流程，進行DevOps實踐，串聯從需求開發到產品交付的每個環節，并提高流程節點上的自動化率。自動化是我們始終關注并堅持的要求。

- 架構與設計質量，我們采用“三評審”：需求評審，架構與設計評審，測試用例評審。

- 代碼質量，運行嚴格的代碼審查機制，結合自動化測試工具與CI流程，堅持代碼的準入標準。

- 系統質量，我們通過全面的功能測試、性能測試、安全測試。同樣，自動化率仍然是金標準。

- 發布質量，結合近3年在客戶環境進行的數千次部署/升級經驗，我們設計和完善了部署/升級的SOP，確保新版本順利更新到客戶環境。

SAFe方法論統領下，我們控制內建質量，并在以下維度做了改造：

1、分支管理

代碼分支管理老生常談，但有效。在這次改造中，有兩個重點：

其一，研發過程中，當穩定分支（master）有合并，就觸發完整CI流程，執行所有MR（Merge

Request，分支合并請求）卡點，通過全面自動化測試后才能合并成功。

其二，維護階段，某一個客戶現場有特殊問題需要修復時，bugfix分支向release發起MR，生成的包給客戶修復問題。MR積累到一定數量后再統一合入穩定分支（master），避免未經全面測試的特殊修復給全局版本引入風險。

各分支說明

2、需求從開發到發布（CI）

我們建立了研發流水線，并設計了自動化測試，開發環節效率得到顯著提升：目標分支發布到目標環境的效率提高；目標分支合并后產生的包都經過了12000個自動化測試用例，研發、測試、運維基于此工作，不會發生基礎問題。

如圖所示：

1）研發在feature分支完成需求開發后，向目標分支（如master分支）發起MR，自動觸發CI流程，將包與鏡像推往對象存儲，可一鍵構建到開發環境。（測試及生產環境需要通過發布平臺執行。）

2）測試過程中feature分支代碼變更，會再次自動觸發CI流程，生成包和鏡像，按需一鍵發布到目標環境。

3）在觸發穩定分支（master）合并后，會再次觸發CI流程，生成正式包，用于發版。

4）bugfix分支向release發起MR，生成的包用于客戶環境問題修復。

3、MR卡點

如前文所述，在開發環節我們增設了MR卡點，來控制產品質量，預防分支合并錯誤等問題產生。

· 分支名卡點，防止拉錯分支或將錯誤分支合入的情況。

· 編譯卡點，針對因代碼沖突或其他原因，導致代碼合并后的打包失敗情況。這是開發環節的高頻問題。

· 單元測試卡點，用于提高測試質量。

· 漏洞掃描卡點，用于識別新增或變更代碼是否引入了新漏洞。

上述要求是開發環境的強制要求。

測試環境、預發環境除此之外，還額外要求：

· MR審核，由至少1位架構師進行人工審核；

· 通過全量接口和場景自動化測試用例卡點，目前我們要求通過全部（12000個）自動化測試用例，無失敗。

4、交付部署（CD）

交付環節，我們同樣通過自動化的方式提效。

· 自動化部署工具：支持“一鍵”部署；可以集中管理配置、自動渲染；集成日志系統，支持日志集中查詢；支持監控報警，分級報警，分級處理。我們之所以把日志和監控工具都集成到了部署工具中，是因為部署DataSimba并不只是簡單的安裝軟件，也需要保障其運行穩定。

· 自動化驗證工具：我們從12000條自動化測試用例中選取了3000條，用于客戶環境部署后的驗證，以確保部署后的產品可用性。測試過程耗時僅30分鐘。

三、軟件工程生產線的最后一步

沒有標準化運維，談什么企業級？

做到這里，工程生產線基本上改造完成了。

相比之前，團隊工作上的體感已經大不相同：再也沒有出現分支發布到目標環境失敗或功能不可用的問題；再也不會出現臨時緊急修復一個問題，而影響到了全部版本；也不再出現客戶環境部署完成后還有功能不可用的問題。

很多廠商會把部署完成視為交付的最后一步，鑰匙交給客戶萬事大吉。但像前文所說的，數字化進程越深入，客戶越要求可靠、連續、穩定地產出數據業務結果，這離不開持續、可靠的運維。

運維是一個“人力”比較重的過程，所以同樣會面臨需求爆發和質量管控的問題：一位運維工程師通常會負責多家企業客戶的運維，同一個客戶也會經歷不同運維工程師的運維。

對此，解法也是類似的——“運維標準化”，即同一個產品在不同客戶環境，有統一的運維方案。從監控告警到日志標準化，從應急操作手冊到巡檢工具，都通過統一的運維SOP和工具完成，來保障運維響應的規范、質量、效率和全面性。

具體而言，我們在運維階段設置了主被動干預：

· 監控告警：設置分層監控（集群監控、服務監控、業務監控），配合多渠道告警（電話、短信、IM、郵件等），確保系統運維工程師和數據運維工程師快速響應；

· 自動化巡檢：定期自動化巡檢生成報告，由運維專家分析報告并給出優化建議；

· On-call小組：我們更新了On-call的機制，工單分級響應，并設置了問題處理超時預警機制，確保服務水平和滿意度。

此外，對運維有深度需要的客戶，我們還上架了配套的高級運維服務：數據開發陪跑包，協助客戶團隊建立數據開發的CI/CD流程；VIP專屬運維服務包，由我們原廠的運維專家提供一對一服務，包括系統運維規劃、專屬運維實施等等。