50+大厂技术专家现场分享,GMTC北京站9折购票倒计时,戳此查看最新日程 了解详情
写点什么

保险产品 SaaS 化实践之路(下)

蒋纪匀/高文涛 众安国际技术团队

  • 2022 年 6 月 30 日
  • 本文字数:3068 字

    阅读完需:约 10 分钟

保险产品SaaS化实践之路(下)

在我们开始下篇之前,我们先来回顾一下《保险产品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 化过程中所有技术相关的核心内容。由于水平所限,错误之处在所难免,欢迎留言指正。

2022 年 6 月 30 日 18:072212

评论 1 条评论

发布
用户头像
plugin framework 啥时候开源
2022 年 07 月 08 日 15:39
回复
没有更多了
发现更多内容

字节面试数据结构与算法:B+树的删除和插入,不够详细你打我

小Q

Java MySQL 学习 面试 算法

Python进阶——如何正确使用魔法方法?(下)

Kaito

Python

新图灵测试背后,智能交互点燃了哪些产业可能性?

脑极体

iOS AOP 方案的对比与思考

GrowingIO技术专栏

ios aop

一次浪费时间的面试

escray

程序员 面试 面经

区块链赋能医疗行业,区块链医疗应用场景开发

13530558032

高速二维码报警定位系统开发,智能报警系统

13530558032

一位Java程序员在上家公司CRUD了3年,金九银十想要跳槽面试却屡屡碰壁,感觉很迷茫!网友:这是你安逸太久技术能力跟不上了!

Java架构之路

Java 程序员 架构 面试 编程语言

《华为数据之道》读书笔记:序言

方志

数据中台 数字化转型 数据治理

区块链加持,鉴定溯源双保险,科技赋能茅台老酒成零售数字化标杆

CECBC

区块链 大数据 防伪溯源

怎么做好一场分享或者培训

fq

MySQL选错索引导致的线上慢查询事故

Zhendong

Java MySQL

数字货币将使货币政策实施更精准有效

CECBC

数字货币

架构师训练营第 1 期 第 9 周作业

李循律

极客大学架构师训练营

数字货币步伐加快,苏州将于双十二推出数字人民币红包测试

CECBC

数字人民币

字节跳动内部授课课件:附图讲解MySQL底层索引结构算法实现

小Q

Java MySQL 学习 编程 面试

“新鲜出炉”阿里面试终极指南V3.0,符合一线大厂面试点需求

小Q

Java 学习 编程 架构 面试

《码出高效:Java开发手册》,每一位想要成为优秀开发工程师的程序员必须要看的一本小册!

Java架构之路

Java 程序员 架构 面试 编程语言

迁移到 Atlassian Data Center 并没有您想象的那么可怕

Atlassian

负载均衡 高可用 Atlassian Jira

架构设计:高并发读取,高并发写入,并发设计规划落地方案思考

互联网应用架构

高并发读,高并发写

JVM Metaspace内存溢出排查与总结

Java老k

Java OOM 内存溢出 metaspace

Java踩坑记系列之线程池

Java老k

Java 线程池

第九周 性能优化(三)总结

钟杰

极客大学架构师训练营

上周我面了个三年 Javaer,这几个问题都没答出来

yes

面试 RPC HTTP

乘上这艘“智能体”之舟,即刻前往智慧未来

脑极体

一个隐藏在方法集和方法调用中且易被忽略的小细节

Gopher指北

后端 Go 语言

五年Java开发经验,裸辞准备半月面试阿里,阿里巴巴却“不讲武德”,居然面了我7轮,历经千辛万苦终于斩获P7及Offer

Java架构之路

Java 程序员 架构 面试 编程语言

奉劝各位Java工程师都要学习这份阿里内部绝密《百亿级并发系统设计》实战教程,大厂面试官可“不讲武德”!

Java架构之路

Java 程序员 架构 面试 编程语言

甲方日常 55

句子

工作 随笔杂谈 日常

贼好用,冰河开源了这款精准定时任务和延时队列框架!!

冰河

redis 中间件 消息队列 延时队列 Zset

第十周作业

Geek_4c1353

极客大学架构师训练营

保险产品SaaS化实践之路(下)_云原生_InfoQ精选文章