云原生技术体系在寿险行业的规划和落地实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 云原生技术体系在寿险行业的落地实践太平洋寿险 / 周建华

3. 为什么要建设云原生技术体系

4. 面临的主要问题：系统建设方面 应用系统数量较多，主要通过三种方式建设：一是自研，二是成品采购，三是定制化开发 很多老旧系统主要靠定制化开发和成品采购，当前绝大部分系统已经转变为自研，但存量系统基数仍较大 系统间的技术架构差距很大，全面保证代码质量和可维护性难度较大自研系统定制化开发系统 1、完全由自身科技团队设计并主导开发 1、只负责需求，系统的架构设计及具体 1、通过供应商进行标准软件采购的系统开发交由第三方公司实现 2、提供专人进行系统维护 2、主要的代码编写往往还是外包团队参 2、系统间有部分集成 3、与其他系统集成度不高与较多 3、业务需求驱动成品采购系统

5. 面临的主要问题：研发标准方面系统架构不统一研发流程不统一 1、架构设计语言不一致 1、研发流程在各个团队的实际落 2、架构设计标准不一致地差异较大 3、对非功能需求的架构设计差异 2、自动化程度不高性很大交付质量不统一平台化功能建设少 1、交付质量偏差较大 1、虽然采用分层架构，但平台化 2、系统监控不完善的能力下沉不够 3、不同团队之间的差异大 2、核心能力沉淀不足 3、公共技术组件支持能力不足

6. 面临的主要问题：项目研发方面 开发人力属于是外包密集型，具体编码工作以外包为主，管理和沟通的复杂性很高 系统开发由业务方”散点式“需求驱动，缺乏体系化的架构规划 业务对于需求上线时间要求很高，导致开发团队没有足够的时间来进行系统优化和质量保障项目团队架构师项目团队项目经理架构师职场A 开发项目团队项目经理项目经理职场A 职场A 外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包外包职场B 职场C 职场B 职场C 职场B 职场C

7. 目标定义

8. 研发模式的选择博弈：灵活性 VS 标准化灵活的研发模式优点：开发团队自由度高便于快速外部技术引入缺点：不同团队的交付结果偏差大对团队的技术能力要求很高团队沟通成本高标准化研发工艺 VS 优点：结果偏差小，可复制。降低错误率和风险。容易产生共识，协同作业更加顺畅。缺点：需要严格管控，需要投入一定管理成本需要一定的培训成本有时候可能牺牲创新速度

9. 寿险技术体系建设总体目标：形成标准化的生产工艺体系 形成一套标准化的架构设计语言、一个标准化的服务开发平台以及一套标准化交付流水线一套架构设计语言一个开发平台：让应用专注业务代码一套交付流水线：自动化软件交付 1、形成统一的架构设计方法论和设计语言，提升架构 1、应用系统代码聚焦于业务逻辑开发 1、以自动化为最终目标，逐步减少流程中人工设计和管理的规范化和标准化水平。 2、将服务治理、高可用能力、可运维性、可观测能处理的环节，形成端到端的自动化交付工艺 2、降低架构治理的难度，形成标准化的企业架构视力等通用基础能力下沉至PaaS平台 2、针对业务特性，形成稳敏双态的流水线，适图。 3、通过标准化应用开发脚手架的建设，快速开发上应于两种不同交付需求层业务应用应用应用应用应用应用开发脚手架 PaaS 分布式数据库服务治理框架 OB 容器平台分布式中间件 IaaS TDSQL

10. 总体目标：形成太保寿险标准化应用生产工艺体系架构蓝图演进方向架构蓝图建设为架构蓝图的规划和建设提供体系化的支撑，为重点业务和创新业务提供加速突破所需的可配置、可复用、可组合的核心业务能力应用服务基于云原生技术体系架构，结合太保寿险实际情况，建设符合太保寿险实际情况的稳敏兼顾的云原生研发体系来支撑“两个一”所要求的战略目标。形成太保寿险的云原生能力成熟度模型做为体系建设的依据，评估和指导规划和实施，确保整个建设过程的全面性、有效性和先进性。寿险新一代稳敏兼顾的云原生技术体系技术架构演进方向一个开发平台一套交付流水线通过剥离和沉淀通用基础技术能力构建现代化开发平台，大力提升业务应用的响应速度和交付质量构建自动化的端到端的现代化交付流水线，逐步替代人工处理环节，满足太保各类型业务的交付需求部署发布服务注册服务容错服务治理应用运维架构设计开发构建测试管理应用云原生一套架构设计语言企业架构框架和组织能力提升方向形成寿险统一的企业架构元模型和方法论，规范企业架构相关活动，提高企业架构规划、演进和治理的效率和效果人员能力建设构建满足生产体系能力要求的胜任力模型，体系化评估和提升参与人员和团队的能力，保障应用系统生产体系的持续完善和演进资源管理运维保障研发测试应用服务云原生体系能力模型技术架构云原生安全云原生* 应用安全基础架构安全基础设施安全研发运营安全运维安全

11. 云原生体系的成熟度模型以云原生能力成熟度模型（技术架构、应用）作为输入，结合金融行业的特殊性及寿险技术体系总体目标，对模型进行调整，制定适合寿险的云原生成熟度评估模型。云原生成熟度评估模型-技术架构云原生寿险云原生成熟度评估模型云原生成熟度评估模型-应用云原生

12. 太保寿险云原生评估模型定义(1/2)  根据“一个开发平台”、“一条流水线”的总体规划，对技术架构模型进行调整。能力域资源管理域维保障域研发测试域应用服务域建设领域开发平台关键维度流水线关键维度计算环境 √ × 网络环境 × × 存储环境 × × 融合调度 √ × 基础运维 √ × 可观测 √ × 高可用 √ × 应用研发 × √ 应用测试 × √ 应用中间件 √ × 应用治理 √ × 应用编排部署 × ×

13. 太保寿险云原生评估模型定义(2/2)  根据“一个开发平台”、“一条流水线”的总体规划，对业务应用模型进行调整。能力域基础设施域应用研发域服务治理域建设领域开发平台关键维度流水线关键维度基础设施资源 √ × 基础设施运维 √ × 架构设计 √ × 开发构建 × √ 测试管理 × √ 部署发布 × √ 注册发现 √ × 流量管理 √ × 服务容错 √ × 服务降级 √ × 故障注入 × × 链路追踪 √ × 应用监控 √ × 日志管理 √ × 配置管理 × √

14. 寿险云原生成熟度评估模型  云原生技术架构评估模型共包括6个能力域、11个建设领域、40个过程项。  结合“一个开发平台、一套交付流水线”的目标，开发平台涉及7个建设领域、23个建设领域。交付流水线涉及4个建设领域、17个过程项。其中“部署分发”过程项两者均有涉及资源管理域运维保障域研发测试域应用服务域应用开发域服务治理域计算资源融合调度基础运维可观测性高可用研发支撑测试支撑应用中间件架构设计服务治理配置管理资源及运行时管理调度机制自动化程度日志应用高可用版本管理测试分层策略共享化架构设计注册发现配置管理代码质量管部署与发布模式理服务化流量管理开发能力服务容错托管程度监控告警弹性能力监测指标容灾备份链路追踪组件服务化部署分发部署流水线数据变更管理环境管理度量指标服务降级变更管理度量驱动改进链路跟踪构建实践应用监控持续集成日志管理研发需求管理一个开发平台相关交付流水线相关两个都相关

15. 现状及差距分析

16. （1）一个开发平台

17. “一个开发平台”总体目标 03 02 01 弹性可伸缩系统可观测 04 服务可治理 1、资源100%容器化 1、建立统一的监控管理体系 2、容器及服务节点按需扩容，提高 2、丰富监控维度和监控指标 a. 完善应用限流策略体系沉淀至云原生平台，如服务限资源使用率 3、监控数据分角色管理 b. 完善应用降级策略流等 c. 完善应用扩缩容策略 2、沉淀非业务能力组件：通用能 3、资源扩容自动化，减少人工操作，提升突发流量场景的响应能力 1、完善微服务治理体系能力可共享 1、沉淀标准化方案：将服务治理力沉淀至云原生平台，如弹性能力、可观测能力、灰度能力。

18. “一个开发平台”差距分析总结计算资源服务治理融合调度应用中间件基础运维高可用 * 详细评估表见后可观测性

19. 弹性可伸缩：打造敏稳一体的数字底座应用弹性&服务治理服务注册发现熔断降级流量限流应用弹性 PaaS服务组件微服务网关消息队列分布式数据库分布式缓存任务调度容器平台镜像仓库存储管理容器管理 Auto Scaling IaaS层（多云环境）容器编排云原生可观测体系

20. 系统可观测：建立全方位的监控体系打造云原生监控体系，提升运维效率指标链路日志覆盖全链路的对象观测系统层网络层中间件应用层 CPU 内存 API网关 Nginx 数据库消息队列系统日志业务埋点磁盘 I/O F5 微服务网关缓存。。。 APM 。。。

21. 服务可治理：标准化服务治理策略 Sidecar模式 SDK模式应用应用应用业务逻辑业务逻辑业务逻辑服务发现服务发现服务发现负载均衡负载均衡负载均衡熔断熔断熔断限流限流限流 SDK 应用业务逻辑 Sidecar 服务发现负载均衡熔断限流

22. 能力可共享：沉淀云原生公共能力寿险业务应用营销展业系统核心业务系统 APIGW KMS 对象存储日志中心资源管理接口信创/X86 TDMQ 数据库监控告警 K8S容器编排云原生底座计算 SLB DevOps TSF RabbitMQ Kafka . . . PaaS服务 TMF * 已具备 * 未具备 Redis 认证鉴权 ... 业务核心关键能力1 业务核心关键能力2 容器网络。。。。 IaaS接口存储平台化能力网络 IaaS基础资源统一底座、统一账户、统一运维、统一监控、按需扩展

23. （2）一条交付流水线

24. “一套交付流水线”总体目标 03 02 01 自动化一体化 04 数据化智能化协同公司各开发团队，建立统一聚焦研发过程，打通全流程工具建立完善的研发管理度量体系，实现通过数据智能技术在DevOps体系中持续交付流程与规范，自动化研链，形成一体化企业级Devops 研发过程“端到端”监控，实现需的运用，利用自动化代替重复性的工发过程，减少人工参环节，打破平台，提升IT持续研发、集成、求、功能点、代码、质量、成品、环作，进一步提升软件工程师的工作效部门壁垒，提升需求交付能力交付、部署能力境的全过程追溯能力。率和体验

25. ”一条流水线“差距分析总结部署与发布测试管理配置管理度量与反馈环境管理 CI/CD

26. 建设目标一：提升研发流程自动化 1 2 3 4 提升研发自动化程度，减少人工参与环节，提升标准化程度；提升研发工具间的集成，提升需求交付能力简化研发审批流程，减少研发过程中的审批环节；明确各角色职责，减少不必要的沟通成本。明确研发标准，并将标准下沉至研发平台，减少团队间的沟通成本，降低平台的使用门槛，提升团队间的协同效率优化系统发布模式，实现自动化发布，并支持灰度发布

27. 建设目标二：工具链整合，平台一体化云平台测试平台多平台协同平台 PaaS CI CD 一站式平台

28. 建设目标三：建立完善的研发效能度量体系 1、从端到端的交付效率、交付质量、交付交付效率平均需求交付周期需求吞吐量完成计划率平均开发交付周期平均测试交付周期交付质量变更频率变更前置时间变更失败率缺陷修复时长。。。。交付能力代码提交频率测试自动化率持续集成时间自动化部署率部署时长。。。。能力三个维度定义度量指标体系。 2、指标体系包括需求、开发、持续集成、测试、发布等关键环节 3、兼顾过程和结果的度量。

29. 建设路径

30. 分层分级拆解，逐步构建太保寿险云原生体系建设领域云原生成熟度模型对于云原生能力的二次拆解，和云原生能力相比粒度适中，可操作性更强 10个建设主题缩小对应建设领域的重要建设方向，一个改进主题可以提升多个建设领域 8个建设项基于建设主题的分解的可执行的云原生能力提升活动，每个举措可以落地为具体的、可执行的项目 30+个

31. 规划8个建设主题，全面构建太保寿险云原生体系资源调度应用研发可观测高可用通过提升资源池化提升应用弹性能力，降低平台TCO 提升研发效能管理能力，覆盖完整的软件研发流程建设云原生可观测体系，提升平台稳定性构建高可用机制，提升平台和业务应用跨区可用性价值 ✓提升业务支撑能力，缩短应对突发流量的响应时间 ✓降低资源成本和运维成本 ✓统一底座，降低迁移成本应用迁移量 100% 资源利用率 60% 价值价值价值 ✓建立指标体系，快速识别研发瓶颈 ✓建立制品追踪体系，提升诊断效率 ✓流程清晰，控制变更范围，降低发布风险扩容时间部署时间自动化部署率持续集成周期 30s 30min 95% 2天 ✓快速了解平台异常情况并处置，提升平台的稳定性 ✓集中的日志和调用链平台，联动更多资源，提升问题处理效率接入应用量 100% 指标数量 60+ 修复时间 <1h ✓ 构建高可用机制，具备快速故障恢复能力 ✓应对机房级别的异常情况，提升业务连续性应用恢复时间 < 30s

32. 规划8个建设主题，全面构建太保寿险云原生体系（续）应用测试架构设计服务治理应用发布引入自动化机制提升测试效率，把软件质量控制内建于研发流程提升应用架构治理能力，建立可复用架构资产全面提升服务治理能力，增加业务应用的韧性建立灰度发布体系，降低发布变更的风险价值价值 ✓自动化替代手工，提升测试效率 ✓测试左移，提前识别质量风险 ✓提前修复安全、性能等非功能性问题单元测试覆盖率 60% 关键性能测试 100% 质量门禁指标接入 100% ✓架构设计风险前置，降低技术负债 ✓沉淀标准化的、可复用的应用技术方案 ✓保障架构的可演进性，避免僵化设计标准化方案数 30+ 价值价值自动化健康度检查 2次/周 ✓提升系统自愈能力，常见错误自动恢复 ✓降低应用故障频率和持续时间，增强用户体验 ✓ 降低发布变更对于业务的影响 ✓增强发布变更信息，缩短业务迭代周期服务治理覆盖率流量切换时间自动发布成功率灰度覆盖率 >=90% <=5m 90% 30%

33. 围绕建设目标项，细化建设举措用建设项指标应用发布服务治理架构设计应用测试高可用可观测应用研发资源调度建设主题

34. 建设项与指标映射建设项建设指标持续集成；部署与发布模式；部署流水线部署时间；自动化部署率；持续集成周期部署流水线建设项建设指标弹性能力资源利用率；扩容时间监测指标，日志指标数量；问题排查时间部署时间；自动化部署率；持续集成周期测试分层策略；代码质量管理单元测试覆盖率；质量门禁指标接入日志；链路追踪指标数量；修复时间服务化；开发能力标准化方案制定部署流水线部署时间；自动化部署率；持续集成周期测试分层策略质量门禁指标接入资源及运行时管理；融合调度；托管程度；应用迁移量服务容错治理服务数量；标准化方案数量资源及运行时管理；托管程度资源利用率计算资源域应用迁移量开发能力应用迁移量日志，监测指标指标数量开发能力标准化方案制定；自动化健康度检查开发能力标准化方案数计算资源域资源利用率；扩容时间测试分层策略单元测试覆盖率共享化；开发能力应用标准化；标准化方案制定流量管理服务治理数量；计算资源域；应用高可用应用恢复时间资源及运行时管理；融合调度；托管程度；资源利用率；测试分层策略质量门禁指标接入共享化；服务化；开发能力；标准化方案数可观测性接入应用量；指标数量；问题排查时间流量管理灰度覆盖率数据变更管理质量门禁指标接入度量指标；度量驱动设计指标数量开发能力；测试分层策略质量门禁指标接入；标准方案数

35. 定义优先级评价模型：对项目内容优先级排序高第三优先级业务价值第二优先级低第一优先级低高复杂度

36. 技术体系建设性阶段性目标定性目标阶段通过提升资源池化提升应用弹性能力，降低平台TCO 建设云原生可观测体系，提升平台稳定性指标项目 24年底资源利用率 60% 分母：当前系统资源使用情况，完成迁移之后系统的常态资源使用情况扩容时间 30秒分母：当前流程+操作的时间分子：自动化扩容的时间应用接入量 100% 以PaaS平台上的应用系统为基准指标数量 60 监控功能聚合后的指标数量修复时间 1小时从告警发生至问题定位、问题处理完成的时间平均修复时间数据丢失 0 PaaS平台应用节点故障后，备用节点/多活节点接受流量后，数据丢失量应用恢复时间 30秒 PaaS平台应用节点节点故障后，备用节点/多活节点就绪时间服务治理覆盖率 90% PaaS平台服务治理方案推广范围流量切换时间 5分钟 PaaS平台应用节点故障后，切换时间部署时间 30分钟分母：当前流程时间+操作时间分子：自动化处理时间自动化部署率 95% 分母：接入PaaS平台的系统个数分子：自动化发布的系统个数持续集成周期 2天分母：当前周期时长（22年平均值）分子：采用devops全流程后系统集成周期平均值单元测试覆盖率 60% 二季度、三季度进行单元测试覆盖试点关键性能测试 100% devops与性能测试平台集成打通分母：性能测试指标分子：接入的性能测试指标质量门禁指标接入 100% 分母：质量门禁接入综合分子：已经接入数量标准化方案数 30 自动化健康度检查 2次/周自动发布成功率 90% 灰度覆盖率 30% 构建同城协调机制，提升平台和业务应用跨区可用性全面提升服务治理能力，增加业务应用的韧性提升研发效能管理能力，覆盖完整的软件研发流程引入自动化机制提升测试效率，把软件质量控制内建于研发流程提升应用架构治理能力，建立架构健康度守护机制建立灰度发布体系，降低发布变更的风险阶段一阶段二阶段三阶段四指标说明根据项目需要和系统等级进行灰度改造和推广

37. 一些思考和总结

38. 一些思考：不应过分关注量化指标，真正的价值往往无形化真正用户需要的是无法精准表达的无形化目标，需要不断精进定性目标定量目标用户公司管理层 1、需求调研，现状分析 1、流程简化一些 2、针对不同角色需要解决的问题是什么 2、自动化 3、对于团队技能的变化有哪些 3、用户体验好一些 1、降低研发复杂度 1、提升公司科技能力 2、提升研发效率 2、形成行业壁垒 3、加强公司自主创新

39. 一些思考：方案设计和方案落地，哪个更重要？方案落地好坏方案设计好坏方案设计是手段，不是目的架构方案设计不到位，落地会带来技术债务架构方案设计需要的不仅仅是专业水平，现状的问题及各相关方的沟通是非常关键方案落地是真正的目的 VS 架构方案可行，但是没有按照预期落地，所有努力都白费方案要能落地，各个关联方，尤其是需求团队达成一致很重要

40. 一些思考：个人决策和集体决策哪个更适合？个人决策集体决策方案设计周期相对较短各方沟通比较耗时投入精力相对较少时间成本较高方案专业度取决于个人专业度取决于集体决策效率方案适用度容易脱离其它关联方预期方案落地性落地性可能相对较差小范围内相对较优落地性较强

41. 一些思考：淮南为橘淮北为枳没有“银弹“，需要结合公司实际情况，制定适合自身发展需要的技术方案目标定义现状分析差距分析建设规划

42. 一些思考：行业交流利于科技价值的进一步释放行业交流利于做大蛋糕行业峰会合作伙伴交流咨询公司交流公司间的交流

43. 总结：云原生体系建设目标形态云原生技术体系愿景：打造标准化的研发体系一个开发平台一套交付流水线弹性可伸缩自动化系统可观测一体化服务可治理数据化能力可共享智能化

44.