流程、组织、技术三位一体，数字化如何以低成本撬动高价值？

瑞士再保险（简称“瑞再”）成立于 1863 年，总部位于瑞士苏黎世，是全球领先的再保险、保险及其他保险型风险转移方案的提供商，致力于提升全球的风险防范能力，也是全球第二大的国际再保险公司。

作为金融行业数字化转型的先行者，瑞再在 2015 年首次将应用部署在 Azure 上。瑞再中国自 2019 年起开始基于公有云进行数字化转型，在短短几年内，已将业务应用全部迁移至云端。

在今年 8 月举办的 FCon 全球金融科技大会上，瑞再高级解决方案架构师刘晨带来了题为“瑞士再保险的低成本高杠杆 DevSecOps 之路”的专题演讲，探讨了瑞再如何在数字化转型过程中，实现理论与实践的同步推进，以低成本撬动高价值。  

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

本次分享主要分为四个部分。首先，将详细解析如何建立一个以低成本撬动高价值的杠杆体系。然后，结合瑞再的具体理论和实践，从流程、组织和技术三个维度，与大家分享我们如何利用这三个关键因素，帮助企业实现价值的高效转化。

低成本撬动⾼价值

在金融数字化领域，探讨成本与价值的关系时，我们首先需要明确企业最关心的成本和价值是什么。简而言之，成本是投入，而价值是产出。在衡量成本时，我们会遇到多种不同的维度。有些成本可以直接用金钱来衡量，例如人力成本和机器成本。人力成本包括内勤成本、外勤成本和人力管理成本。机器成本则涵盖了自建机房的成本、云服务成本、购买 SaaS 服务的成本以及软件许可的成本。这些都是可以用金钱直接衡量的成本。

有一些成本是无法直接用金钱衡量的，比如机会成本和沉没成本。以机会成本为例，当你选择使用 AI 大模型技术来赋能一两个头部应用，打造企业的爆款产品时，实际上是在深耕某一特定领域。但在资源有限的情况下，你不得不放弃拓宽业务范围，让多个系统同时发展的机会，这就是你所付出的机会成本。沉没成本又是什么呢？

以一个长期自建 IDC 的企业为例，当它突然决定转向云服务时，它所面临的成本包括过去十几年自建机房的成本、人才团队培养的成本、企业文化为适应旧技术架构所做的调整成本，以及在此基础上的 IT 系统整体运营成本。所有这些成本都很难用金钱来直接衡量。这些成本虽然不直接体现在财务报表上，但它们对企业的长期发展和战略决策有着深远的影响。

反观价值这一侧，我们同样面临着多种衡量维度，有些可以量化，有些则难以量化。在我看来，价值的核心问题归结为两个：一是创造价值的数量，二是创造价值的能力。 当这两个要素结合在一起时，我们得到的是价值效能，这也是企业真正追求的目标。

要构建一个低成本、高杠杆的价值体系，我认为有三个关键要素至关重要。首先是流程。流程就像航舵，不良的流程可能成为企业数字化转型的障碍，而良好的流程则能引导我们以高效统一的方式前进，建立起统一的标准和最佳实践，从而使杠杆效应规模化。

其次是组织。组织是杠杆的核心。康威定律指出，系统设计的本质反映了企业的组织结构形态，系统中模块间的接口也映射了组织内团队间信息流动和互动的模式。在杠杆体系中，组织是连接成本和价值的基础和桥梁，是整个体系运作的核心。

最后是技术。技术是杠杆的支点。没有支点的杠杆无法运作，同样，没有技术赋能的数字化转型也是不可持续的。技术更新迭代迅速，创新层出不穷，如何在企业体系中为技术找到最合适的落脚点，即在杠杆的哪个位置放置支点以最大化效应，这是对企业管理者和架构师的重大考验。

流程、组织和技术构成了高效能杠杆的三位一体。接下来，我将结合瑞再的实践，分享我们是如何综合利用这三个因素，让我们的杠杆体系有效运转起来的。

流程是船舵

在构建高效能杠杆体系的过程中，流程是至关重要的航舵。我们从理论体系出发，探讨为什么流程扮演着如此关键的角色。在瑞再的软件研发过程中，成本和价值思维 是贯穿始终的核心理念。这一理念指导我们在软件流程的每个节点上，不断地从成本和价值的角度进行考量。

1. 需求阶段，我们首先明确问题定义是否清晰，用户场景是否真实反映了用户的需求。我们还要评估问题规模，避免无谓的放大，因为支持 10 并发的系统与支持 10 万并发的系统在成本上有着天壤之别。

2. 方案阶段，我们追问这个方案是否是解决问题的最有效方法，是否能够在现有的组织结构和人才配置下安全落地，是否有更简单的方案可行。

3. 架构阶段，我们继续深入，用 FinOps 的理念来审视架构设计。我们需要做出关键决策，比如系统是采用云服务还是自建，以及如何降低架构的复杂度。

4. 实施阶段，我们面临的主要问题是在产品质量、技术债务和自动化之间做出取舍。每一次选择都是在不同成本和价值之间进行权衡。

5. 维护和下线阶段，这两个阶段最容易产生高成本、低价值甚至负价值的情况。例如，对于一个边缘系统，我们是否需要进行频繁的灾备演练？正确的答案是否定的。如果做出了错误的选择，那么就是用高成本实现了负价值。然而，如果我们能在这些阶段采用自动化运维代替手动运维，大幅降低运维成本，或者通过持续监控用户使用习惯和系统容量，合理缩容或下线使用量少的系统，那么我们实际上是在创造价值。因为这样做释放了资源，而这些资源可以被重新分配到其他更有价值的项目上。

在讨论了理论和技术之后，让我们来看一些具体的实践案例。这里要介绍的是瑞再的 WoW，这可能是大家第一次听说这个术语。WoW 全称是“ways of working”，可以翻译为“瑞再工作模式”。这是瑞再将敏捷开发和 DevSecOps 的方法论、准则和最佳实践整合而成的一套流程框架。

这套框架能帮我们解决什么问题呢？WoW 框架类似于洋葱结构，它采用层层递进的方式，从粗到细，从抽象到具体，最终将每一项实践量化，变成可执行的任务。在下面的图中，我们展示了这个框架的最外层，也就是洋葱的最外层形态。从下到上，这个框架可以分为三个部分：

1. 基础层：这一层定义了企业文化、团队文化和产品管理的最佳实践。其主要目的是在思想、做事方式和价值观上，在团队之间形成对齐，确保每个成员都能理解并遵循相同的原则和标准。

2. 核心层：以基础层为基础，核心层的核心是 DevOps 的 8 个持续实践，这些实践涵盖了从持续集成到持续监控的整个软件开发生命周期，确保开发、测试、部署和运维等各个环节都能高效协同。

3. 度量层：最顶层的度量层主要负责量化和衡量。有一句名言：“如果你的系统是无法量化的，那么它就无法衡量。”同样的道理，我们在核心层和基础层细化出的很多指标，都会被度量层收集，形成对系统的总体评估和跟踪，确保我们能够持续改进和优化。

核心层

以瑞再工作模式（WoW）的核心层为例，我们有 8 个持续实践：持续计划、持续集成、持续发布、持续质量、持续安全、持续运维、持续合作以及持续优化。这些实践构成了核心层的第二层结构，与最外层的 WoW 直接相关。然而，这些方法论虽然正确，但它们仍然是高层次的要求，不可拆解，难以直接执行。为了解决这个问题，我们在实践中如何落地、评估和量化这些要求呢？每个持续实践后面都有自己的星型结构，意味着每个持续实践又被细分为许多子任务。

以持续安全为例，我们进一步深入讨论，可以看到围绕持续安全这一维度，又细分出许多子任务，比如密钥管理、安全威胁模型的集成、容器安全扫描、生产环境的权限配置等。我们使用不同颜色的边框来标注这些子任务，绿色代表做得好的地方，红色代表需要优化的地方，黄色代表正在进行中的工作。没有标注颜色的则表示这些要求不适用于我们的系统。

即便到了这个层面，我们仍然面临如何落地的问题。例如，容器安全如何落地？这仍然很抽象。因此，我们对每个具体任务定义了目标和实践需求。以容器安全为例，其目标是确保容器没有高危漏洞，许可证没有风险，并符合通用的最佳实践。除了目标，我们还会展开具体实践需求，这些需求相对具体，有明确的标准和依据，可能来自业界或我们自己的定义。对于每项任务，就像一个小功能一样，它有自己的目标和具体的实现要求，以及这些要求背后的理论依据。

有了需求和目标，我们还需要实现方法。例如，我们提供了 Aqua 这样的容器安全扫描组件，要求集团内部使用这个组件来扫描容器内的问题。扫描完成后，这个工具会自动生成两个可量化的指标：安全扫描的覆盖率和 DSO 得分。这两个指标会被我们的度量层收集，成为整个系统体检报告的一部分。

总结一下，在瑞再的 WoW 框架中，我们逐层递进，由粗到细，由抽象到具体，将抽象的要求最终落地为可实施的项目，从而使系统持续优化。

度量层

度量层在我们的框架中扮演着至关重要的角色，它由三个部分组成，可以为我们提供一个全面的系统评估和跟踪工具。

我们会为每个度量指标建立一个独立的仪表盘。这里展示的是三个具有代表性的指标：测试覆盖度、变更的自动化程度。例如，某个应用的测试覆盖度较低，变更的自动化程度为 0，这些仪表盘忠实地反映了系统在这些指标上的表现，让我们能够迅速识别出系统的健康状态。

我们使用蛛网图来对相应的指标进行打分。蛛网图帮助我们清晰地看到系统在哪些方面表现良好，哪些方面需要改进。以下图为例，我们可以看到虽然变更的自动化程度和测试覆盖度较差，但安全扫描覆盖度以及 DevSecOps 标准的执行覆盖度表现较好。

有了蛛网图，我们就能明确知道需要优化的领域。那么，我们如何跟进这些优化呢？这就引出了度量层的第三部分：时间线。我们会记录每个指标在历史过程中的变化，观察它们是变好还是变坏，这是一个持续跟踪的趋势图。

将这三部分结合起来，就形成了我们完整的度量层 Dashboard。在这个度量层中，我们可以清晰地评估和跟踪每个应用的当前状态、历史状态，以及随着时间推移优化后的状态。这样的度量层不仅帮助我们识别问题，还提供了一个持续改进的路径，确保我们的系统能够持续优化和提升。

组织是杠杆

高效能杠杆的第二个关键因素是组织。从经济学的角度来看，一个优秀的组织应该是一个高 ROI 的团队，即高投入回报率的团队。要成为一个高 ROI 的团队，我们需要做到以下四点：

1. 做正确的事。在开始任何工作之前，我们应该自问，如果这件事不做，会有什么后果？如果发现不做这件事也没有什么后果，那么我们应该果断放弃。此外，我们还要思考，团队 A 做这件事是否最合适？如果用更专业的团队 B 来做，会不会更快、更好、成本更低？因此，“做正确的事”背后包含两层含义：一是不做不必要的事；二是因地制宜，用最合适的团队去做正确的事。

2. 用正确的方法做事。我们应该多质疑那些传统的做法，尤其是那些重复性任务的做法，因为这些做法往往存在问题。习惯成自然，而自然的东西很少被质疑和反思，很多冗长低效的流程就是这样产生的。

3. 实现真正的敏捷。敏捷的核心不在于形式，而在于精神。不是说使用 Jiar 管理任务、每天开站会、每两周一次冲刺就是敏捷。作为敏捷教练，应该关心的是如何 引领团队发现和解决问题，而不是机械地走流程。真正的敏捷应该关注的问题包括：这个冲刺的结果是否达到了项目计划的预期进度？如果没有，原因是什么？是因为沟通不足、会议太多、代码重构花费了太多时间，还是因为某些新手开发人员的能力不足，成为了项目开发的短板？这些问题才是真正敏捷应该考虑的。

4. 把杠杆效应最大化，我们应该减少团队之间的摩擦，消除那些冗长低效的流程，去掉合作中的障碍，使我们的杠杆变得更长更平，这样才能使我们的杠杆效应最大化。

瑞再 DevSecOps 团队实践

我在这里分享一个瑞再 DevSecOps 团队的实践案例。瑞再的 DevSecOps 团队成立于 2019 年，最初是一支位于欧洲拉脱维亚的团队，他们基于国内某云服务商搭建的配置来服务中国客户。但这种配置带来了许多问题。首先，成本问题显著，欧洲的人力成本是我们的 3 到 4 倍。其次，语言和时差问题导致业务响应非常慢，甚至出现了需要采购翻译软件将中文翻译成英文以提供服务的有趣情况，整个过程非常低效和不顺畅。

在 2023 年，我们决定打造一支中国本地化的 DevSecOps 团队。经过一年的努力，我们已经将欧洲的十几个项目全部转移到中国，成本降低了三分之一，业务响应时间提高了 10 倍以上。这是一次非常成功的 DevSecOps 团队本地化过程，体现了我们用低成本获取高价值的理念。

如果我们深入探讨 DevSecOps 的层面，它的文化、思想和最佳实践能为我们的应用开发带来什么呢？我将其总结为四个方面：链接、过滤、放大 和 缩小。

• 链接。DevSecOps 链接了应用开发团队和运维团队，降低了两者之间的沟通成本。在系统层面，DevSecOps 团队链接了应用系统和云平台，使得应用系统无需关心部署方式，开发完成后可以近乎透明地部署到云平台上，这是一个非常大的进步。

• 过滤。在金融企业中，安全合规要求繁多且不断变化，这种持续的波动对应用开发产生很大影响。DevSecOps 层的出现能够将这种影响完全限制在这一层，让应用团队能够专注于业务开发。

• 放大。我们构建的 CI/CD 自动化流水线和许多工具，将点的价值扩展到线和面，使整个应用的开发效率和产品上线速度提升了数倍甚至一个量级。

• 缩小。自动化永远做不到 100%，那么那些不得不由人去做的事情，如何将其成本降到最低呢？我们的思路是自服务，采用类似银行柜台机的方式，让我们的业务用户能够通过自助形式以最简单的方式提交手动任务。

数字化转型中的技术取舍之道

另外，我想从架构师的角度分享我们在数字化转型中的技术选择和权衡。首先，架构设计就像是驾驶，左脚油门、右脚刹车。一方面，我们不能一味追求新技术和复杂的架构，而忽视企业的实际情况、落地的可行性和成本，这种盲目加速的行为就像是在激烈驾驶。另一方面，如果因循守旧，不愿意走出舒适区，害怕拥抱创新和变化，那么这种架构设计就像是在畏缩不前，缓慢爬行。一个合格的架构师应该知道，在合适的路段果断加速，在不确定的路段则应该谨慎驾驶，稳步前进。

其次，架构设计是一个不断做出选择、妥协和简化的过程。这里有一个选择题：如果降低架构的复杂度可以满足未来三个月的需求，而增加复杂度可以满足未来十年的需求，你会如何选择？对我来说，我会选择前者。这是因为在快速变化的技术环境中，过于超前的设计往往意味着资源的浪费和对当前需求的忽视。

第三，自我否定是架构师的必备修养。自我否定是一种有效的自省方式。我们可能会在一年后回顾一年前的架构设计时，觉得它非常可笑，但这种可笑并不需要等待一年才能发现。通过持续的自我否定，甚至邀请他人来挑战自己的设计，可以及时发现并修正问题。这种持续的自我审视和开放的态度是架构师成长的重要途径。

瑞再灾备恢复最佳实践

在技术层面，我再分享下瑞再在灾备恢复方面的一些最佳实践。下图展示了亚马逊云定义的软件灾备恢复的四个模型，从左到右依次是备份恢复、冷备、温备和异地多活。我们可以看到，随着模型从左到右的演进，灾备恢复的时间可以从小时级缩短到分钟级，甚至实现实时恢复。然而，随着恢复时间的缩短，成本也呈现出三个量级的变化，即成本随着恢复时间的减少而显著增加，也就是说，灾备恢复的时间与成本成反比。

在实践中，选择合适的灾备恢复方案是一个复杂的过程，瑞再通过将灾备恢复方案的选择过程分解为五个关键维度来进行决策。

1. 软件系统的重要性等级： 我们将其划分为五个等级，等级越低，表示系统越重要。

2. 服务水平协议（SLA），我们特别关注两个指标：恢复时间目标（RTO）和恢复点目标（RPO）。RTO 指的是在灾难发生时，系统能够承受的最大宕机时间，而 RPO 是指系统能够容忍的数据丢失的时间窗口，这个时间窗口可能是一天、一小时还是一分钟。

3. 灾备恢复模型：包括备份恢复、多站点活跃、温备和信号灯等不同的模型。

4. 灾备基础设施的构建方式：我们需要决定是采用全自动、手动还是混合模式来构建我们的灾备基础设施。

5. 灾备演练的频率：这决定了我们是每年、每半年还是每个季度进行一次灾备演练。

假设我们有一个数据处理系统，它是核心系统的一个分支，因此在重要性等级上，我们将其定义为 Level 3，属于次重要级别。在服务水平协议（SLA）方面，我们评估后认为这个系统可以接受一天的数据丢失和半天的系统恢复时间。因此，它的恢复时间目标（RTO）是半天，恢复点目标（RPO）是一天。在选择灾备恢复（DR）模型时，我们需要在异地多活和备份恢复之间做出选择。这时，我们需要评估技术能力，判断是否能在一天内和半天内通过备份恢复的方式将系统恢复。如果可以，那么备份恢复将是我们的首选，因为它的成本最低。

经过评估，我们决定采用备份恢复作为 DR 模型。接下来，我们需要决定 DR 资源的构建方式。是完全自动化的基础设施即代码（IaC），还是纯手动构建，或者采用混合模式？我们发现，灾备恢复分为两个部分：备份和恢复。备份是一次性的，使用手动方式是最省成本的。但恢复操作是多次且频繁的，且比较复杂，因此我们应该使用代码自动化来实现。所以在第四个维度上，我们最终选择了一种混合模式。最后，根据系统的情况，我们决定每年进行一次非生产环境的演练，每两年进行一次生产环境的演练。

在这个过程中，如果你手里有一个计算器，你会发现，当你对每一个维度进行选择和决策时，就像是在计算器上不断加上一些数字。最后的总成本就是你在每个维度上选择的成本总和。

总结

企业始终在追求使用低成本来撬动高价值，以降低成本和提高效率作为持续发展的目标。我们讨论的流程、组织和技术这三位一体构建的高效能杠杆，是实现这一目标的关键。这种杠杆效应能够有效地帮助金融企业在数字化转型的旅程中，穿透迷雾，持续前行。

嘉宾介绍

刘晨，现任瑞士再保险高级解决方案架构师，负责集团本地化应用的落地，推动数字化转型的实践，探索 AIGC 驱动的业务模式创新。北邮国家重点实验室硕士，拥有 15 年软件开发和移动数据领域从业经验。曾任移动应用数据分析开创者 App Annie 研发总监，完成全球大后端团队的整合和技术架构的统一。