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

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

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

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

敏捷和 DevOps 的重要性

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

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

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

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: 呼应我们团队文化的技术宣言

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