在我們開始下篇之前，我們先來回顧一下《保險産品SaaS化實踐之路(上)》中的一些重點内容。
我們提到了ZA Tech的 SaaS化演進的三個階段：項目、産品、SaaS，闡述了産品化是走向SaaS化的前置條件。接着，我們論述了産品化架構設計的三闆斧：Configuration，Composition，以及Extension/Plugin，這三闆斧成為了ZA Tech走向産品化公司，進而逐漸演進為SaaS化公司的重要技術架構和設計理念。
如果說産品化架構設計三闆斧是我們實作成為産品化公司，并逐漸向SaaS化公司演進的三塊基石，那麼我們的多租戶架構和解決方案，則是支撐我們成為SaaS化公司的又一塊不可或缺的技術基石。
今天，我們下篇繼續接着上篇來進一步論述，除了産品化三闆斧和多租戶，我們還需要哪些重要的技術能力來支撐一個企業級To B的SaaS模式？我們今天要提到的2個關鍵詞是：靈活，DevOps。
1►
靈活和DevOps的重要性
為什麼說靈活和DevOps對于産品化公司和SaaS公司如此重要？我們來設想一下現實的場景，有100個客戶，每個客戶都需要按他們的節奏上線生産、釋出新版本等，每一個客戶也或多或少會有定制化的需求，其中有50%的客戶有30%的需求很着急要上線，還有10%的新客戶急着替換掉他們老舊的已經不堪重負的保險核心系統，同時每個客戶可以接受的上線時間又受到不同國家、不同良辰吉日、不同法律合規稽核等的影響，不太可能完全按照我們定的節奏來安排。
如果産品的研發是傳統的瀑布式，2~3個月出一個新的産品版本，那麼對于其中某些客戶來說，在最壞情況下，需要約6個月才能等到其需求的上線。為什麼要6個月呢？因為客戶可能在目前版本開始研發之初提出了需求，那麼這個需求通常最早隻能安排在下一個版本，否則目前已規劃好的版本就會不停地插入計劃外的需求，導緻無限延期，而下一個版本要6個月後才能傳遞。由此可見，越小的可傳遞疊代越能适應靈動的傳遞和多客戶協同，靈活是我們唯一的選擇。
與此同時，因為一套代碼、一朵SaaS Cloud支援了如此多的客戶，那麼品質、可靠性、可用性也成為了不可犧牲的核心價值，時間和品質都不能妥協，于是DevOps中的品質左移、自動化等理念，成為了支撐我們産品化傳遞流程的重中之重。
2►
ZA Tech的靈活之路
靈活也是一個老生常談的話題，很多公司奉為聖經，也有很多公司實踐下來覺得純屬理論無法實踐，根本原因是沒有把靈活的理念跟組織架構、業務特點相結合，而隻是生硬地套用流程，隻是形似而非神似。靈活的思想并非教條，需要因地制宜。顯然我們多客戶、多元度、多優先級的協同，高品質、絲滑更新的要求，需要找到适合我們的工程方法論來指導我們前行，“更小疊代周期盡早傳遞更重要客戶價值”的靈活理念能很好地應對客戶和需求衆多且疊代周期無法統一等問題。
我們對産品研發傳遞端到端的流程進行了深入觀察思考後，形成了具有ZA Tech特色的大規模靈活實踐方法論。我們發現經典的Scrum模型雖然很适合2C業務，尤其适合能拆分到規模較小的、耦合程度非常低的技術研發團隊，進而做到高度自治、想上就上（這裡指新版本上線）。對我們To B型的企業級客戶而言，我們每次傳遞需要更加嚴謹、跨度時間更長的使用者安全心理，我們需要更加“正規”的産品版本疊代，需要傳遞給客戶正式的release，測試和壓測報告、安全掃描及滲透測試文檔等，需要更多的跨團隊協同、更多的全産品視角。是以經典的Scrum模型對我們有一定的限制。
圖1: 經典的Scrum模型
同時，一個高效的技術團隊，必須實作高度對齊、低度耦合的團隊搭建目标。
圖2: 高度對齊、低度耦合的團隊建設目标
綜上所述，我們最終選擇了Nexus這種可擴充的靈活架構作為我們的靈活模型（如下圖）。Nexus非常适合協同3～9個Scrum團隊進行靈活開發。確定每個疊代結束時，整個系統作為一個內建好的整體傳遞。
圖3: Nexus模型
圖4: 我們基于Nexus的組織架構
由于我們客戶更新的版本有時候時間跨度會比較大，我們也會有一些大型的需求，無法break down到單一疊代的User Story，是以，我們采用了如下圖所示改進後的需求管理模型。
圖5: 我們的需求管理模型
這樣，我們産品基線（給所有客戶公用的非定制化部分的産品核心）按照上面說到的靈活模型和方法論進行實踐，形成了穩定的心跳頻率：
圖6: 基線靈活疊代的1個Sprint
但是，我們的客戶總會有一些定制化需求，需要以plugin的方式由專項項目傳遞團隊支援，還有一些客戶并不是Public SaaS模式的，而是采用了集團式的Private SaaS模式，他們都會有自己的上線管理周期、同時他們也不願意跟随我們每2周一次的發版做頻繁更新，如何支撐好如此多的客戶需求和不同的上線生命周期呢？
我們引入了一個重要的概念把它稱之為項目PI，項目PI是項目疊代版本的意思，一個項目的PI通常會跨越多個産品基線的Sprints（疊代），進而傳遞一個更大型的、完整的産品更新版本：
圖7: 項目PI
圖8: 1個4-Sprint的項目PI的例子
圖9: 1個2-Sprint的項目PI的例子
通過良好設計和管理的項目PI，讓我們産品基線的演進和所有客戶的需求推進互相解耦，産品基線按照節奏和優先級支援各個客戶的項目，而項目需求則成為了基線産品化演進很好的輸入，互相之間形成了良好的律動：
圖10: 多項目和産品基線之間的律動
那麼，如何能保證一個良好的PI計劃得以執行呢？我們對于大客戶，都有專職服務的傳遞團隊，他們需要做到和客戶保持持續溝通，保持透明的計劃，同時保持我們的産品基線和傳遞過程實作持續的改進：
圖11: 良好的項目PI執行
這樣，有了産品基線的Sprints以及各個大項目的PIs，我們就有了一個全局的多元度看闆，進而保證了合理安排各個客戶需求的優先級的同時，維持穩定的産品演進的心跳頻率：
圖12: 項目PI看闆
以上就是ZA Tech基于Nexus的To B的靈活模型。從理論基礎到充分實踐，至今為止效果良好，很好的支撐了我們To B企業化SaaS的模式。
這裡大家可能注意到了一個非常重要的點，那就是，我們每2周一次的産品基線Sprint，必須能夠非常平滑地、高品質地上線。因為每一次基線的上線，都可能有1個或者N個客戶跟随着釋出了生産。如果每次釋出都靠SRE人肉、每次疊代都有很多bugs，那以上模式無論對業務同學還是技術同學來說，都是惡夢，都是地獄模式。
如何保證在如此頻繁的釋出下，仍能夠高品質且異常平滑的上線生産？我們的答案是基于DevOps的自動化+品質左移，這也呼應着我們團隊文化的《技術宣言》：
圖13: 呼應我們團隊文化的技術宣言
3►
1:N協作的DevOps實踐
DevOps是一種精神、是一種文化，DevOps是小步快跑、靈活傳遞高優先級客戶價值，DevOps是把一切自動化，是持續疊代、持續改進、品質為先、品質左移：
*注釋：1:N協作代表着1個産品基線團隊和N個客戶傳遞團隊間的協作。
圖14: DevOps
那麼，我們是如何做DevOps的呢？首先從我們的分支政策說起，我們設計了一套更适合To B産品研發的Git分支政策。
圖15: 我們的分支政策
同時，我們引入了基于Gitlab CI的Source Code CICD，進而做到MR自動化驗證代碼（Sonar，Fortify等）、自動化跑UT、觸發Code Review、自動化部署DEV環境：
圖16: 我們的CI看闆
圖17: 我們的測試覆寫率看闆
除了SourceCode，我們基于Liquibase對于DB變更實行增量化、幂等化管理，并設計了我們的DB CICD，對DB增量變更做自動化驗證并自動化部署DEV DB環境：
圖18: 我們的Database CI方案
除了自動化驗證和研發自身UT的驗證外，我們引入QE Auto Integration機制，作為測開團隊自動化Functional Testing和End 2 End Testing的持續內建環境，進而做到所有核心場景，每天100%自動化回歸和內建測試：
圖19: 我們測開團隊的自動化測試持續內建
至此，我們分享完了我們ZA Tech整個産品化、SaaS化過程中所有技術相關的核心内容。由于水準所限，錯誤之處在所難免，歡迎留言指正。
作者:蔣紀勻/高文濤
來源-微信公衆号:衆安國際技術團隊
出處:https://mp.weixin.qq.com/s/GEFwahvnvCDZuVUFbNIVFA