保险产品SaaS化实践之路（下）

【2022年 第2篇】

在我们开始下篇之前，我们先来回顾一下《保险产品SaaS化实践之路(上)》中的一些重点内容。

我们提到了ZA Tech的 SaaS化演进的三个阶段：项目、产品、SaaS，阐述了产品化是走向SaaS化的前置条件。接着，我们论述了产品化架构设计的三板斧：Configuration，Composition，以及Extension/Plugin，这三板斧成为了ZA Tech走向产品化公司，从而逐步演进为SaaS化公司的重要技术架构和设计理念。

如果说产品化架构设计三板斧是我们实现成为产品化公司，并逐步向SaaS化公司演进的三块基石，那么我们的多租户框架和解决方案，则是支撑我们成为SaaS化公司的又一块不可或缺的技术基石。

今天，我们下篇继续接着上篇来进一步论述，除了产品化三板斧和多租户，我们还需要哪些重要的技术能力来支撑一个企业级To B的SaaS模式？我们今天要提到的2个关键词是：敏捷，DevOps。

为什么说敏捷和DevOps对于产品化公司和SaaS公司如此重要？我们来设想一下现实的场景，有100个客户，每个客户都需要按他们的节奏上线生产、发布新版本等，每一个客户也或多或少会有定制化的需求，其中有50%的客户有30%的需求很着急要上线，还有10%的新客户急着替换掉他们老旧的已经不堪重负的保险核心系统，同时每个客户可以接受的上线时间又受到不同国家、不同良辰吉日、不同法律合规审核等的影响，不太可能完全按照我们定的节奏来安排。

如果产品的研发是传统的瀑布式，2~3个月出一个新的产品版本，那么对于其中某些客户来说，在最坏情况下，需要约6个月才能等到其需求的上线。为什么要6个月呢？因为客户可能在当前版本开始研发之初提出了需求，那么这个需求通常最早只能安排在下一个版本，否则当前已规划好的版本就会不停地插入计划外的需求，导致无限延期，而下一个版本要6个月后才能交付。由此可见，越小的可交付迭代越能适应灵动的交付和多客户协同，敏捷是我们唯一的选择。

与此同时，因为一套代码、一朵SaaS Cloud支持了如此多的客户，那么质量、可靠性、可用性也成为了不可牺牲的核心价值，时间和质量都不能妥协，于是DevOps中的质量左移、自动化等理念，成为了支撑我们产品化交付流程的重中之重。

敏捷也是一个老生常谈的话题，很多公司奉为圣经，也有很多公司实践下来觉得纯属理论无法实践，根本原因是没有把敏捷的理念跟组织架构、业务特点相结合，而只是生硬地套用流程，只是形似而非神似。敏捷的思想并非教条，需要因地制宜。显然我们多客户、多维度、多优先级的协同，高质量、丝滑升级的要求，需要找到适合我们的工程方法论来指导我们前行，“更小迭代周期尽早交付更重要客户价值”的敏捷理念能很好地应对客户和需求众多且迭代周期无法统一等问题。

我们对产品研发交付端到端的流程进行了深入观察思考后，形成了具有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: 呼应我们团队文化的技术宣言

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看板

除了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化过程中所有技术相关的核心内容。由于水平所限，错误之处在所难免，欢迎留言指正。

谢谢阅读！不求打赏，但求关注、点赞！