平安银行：云原生转型背景下的质效探索与思考

采访嘉宾 | 金艳 平安银行金融科技部 质量技术及工程效能负责人

数字化浪潮下，金融科技领域正经历着前所未有的变革与挑战。作为以金融科技为发展特色的金融企业，平安银行通过引入云原生体系，持续升级技术和工程能力，为业务提供更加坚实和灵活的技术支撑。

在日前举办的 FCon 大会期间，来自平安银行总行金融科技部的质量技术及工程效能负责人金艳接受 InfoQ 采访，分享了平安银行在持续测试这一领域的实践和经验。

金艳表示，“云原生”是平安银行数字化战略的重要抓手，通过对云原生技术的运用，银行能够更好地为业务战略提供支持，实现“更敏捷创新、更稳定运行、更高效复用、更专业领先”的价值提升。全面升级工程能力，提升全行研发质效，已是平安银行科技升级的题中应有之义。

其进一步指出，“持续测试”作为软件工程中先进和有效的实践，已在平安银行得到较为系统和广泛的应用，其很好地衔接起云原生软件研发流程中 CI 与 CD 间的质量鸿沟，完成软件研发生命周期的质量闭环，为金融业务价值的持续交付附上了高质量的属性。这不仅符合国家高质量发展的战略方向，同时在经济下行压力下具有降本增效的重要意义。

除了持续测试的实践外，平安银行的研发平台也广泛关注对其他新技术、新实践的探索和运用：如最近广受业界关注的 AGI 技术，以及平台工程的实践等。此外，除了朝全面云原生的目标演进，平安银行也非常关注 AI 技术的运用，比如也正探索将大模型融入到研发工具和平台之中，以实现全方位的智能化。

以下是对话全文（经 InfoQ 进行不改变原意的编辑整理）：

InfoQ：首先想请您简要介绍一下相关的工作和职责。

金艳：我在平安银行金融科技部，主要负责组织级研发流程规范、流程持续改进（EPG）、质量保障（QA）还有云计算相关平台建设与维护。如涵盖研发效能相关的数字化管理平台、开发运维一体化平台 Starlink 等等。

关于研发效能的理解和探索

InfoQ：您在 FCon 的演讲中提到平安银行在 DevOps 体系中持续测试能力建设的重要性。想请您再进一步谈谈，为什么平安银行对于持续测试的本质和原则如此关注？是从什么时候开始尤其关注这点的？

金艳：首先因为我们是一家银行，在金融行业，一分钱的错误都将对国计民生产生重大的影响，监管部门对我们的软件提出的要求远高于一般企业。软件的质量和安全性是金融企业立足的根本，在平安银行的工程师文化中我们就强调“质量是底线”。

另一方面，随着互联网企业的高速发展，倒逼银行业务需要更快地响应和支持。引入云原生技术体系，使我们的软件交付能力大幅提升。采用微服务、容器，以及 DevOps 的方法体系，让我们能够更灵活、快速地交付功能。然而，传统的质量保障体系难以跟上持续交付的节奏，测试成为了交付的瓶颈。

在社会降本增效的大趋势和金融行业对软件质量的高要求下，如何让软件交付做到“既好又快”，这是我们以及众多同业在转型、升级中共同面临的重要课题。“持续测试”就是我们在此背景下积极引入和持续探索的有效方法。

InfoQ：能否回顾一下平安银行在研发效能投入方面的历程，这个历程中有哪些关键的阶段或里程碑？

金艳：我们的云原生建设始于 2018 年，从微服务、DevOps 到容器 这样一路走过来。2019 年，我们开始引入 DevOps 的实践和方法，推动 Starlink（平安银行统一的开发运维一体化平台） 的建设。到了 2020 年，我们逐步替换了原有的一些研发工具和平台，将工具底座纳入整个 DevOps 平台，支持全行的研发工作。这个时期，暂称为“云原生 1.0 时期”

2022 年，平安银行提出了数字化升级的“新三年”的规划，我们迎来了全面云原生的新阶段。从 2022 年开始，我们将逐步完成对全行应用的云原生改造，实现技术底座和工程能力的全面升级。

在云原生 1.0 时期，我们主要聚焦于持续集成持续部署（CICD）能力的建设。随着云原生 2.0 的启动，我们融入了更多工具，包括持续测试（CT）能力的建设，以及全流程的整合与完善。

关于平台升级后的实际业务情况，我们在研发交付效率和质量两方面同时推进。随着敏捷的实施，开发交付速度加快，而我们也希望测试能够跟上开发的步伐，以“既快又好”地实现业务的价值。

在这个阶段，我们采取了一些持续测试的策略，进行工具体系的建设以及工程实践的运用和推广。比如我们开始倡导测试在软件开发的早期（需求、设计、开发阶段）就介入，通过各类评审、单元测试等实践，让质量问题得以在软件开发的早期就被发现和修复，即大家所了解的“测试左移”。

同时我们也开始关注软件在预发布环境和生产环境中的质量表现，通过建设全链路压测能力、混沌工程能力、流量模拟和仿真数据的使用，形成质量保证的闭环，让测试获得充分的反馈和学习，这是“测试右移”的实践；另外我们也纵向提升各个环节（包括传统测试环节）的自动化、智能化、精准化、服务化能力，引入自动化测试、精准测试、无码化 / 智能化案例生成能力，让测试的每个环节都获得效率及质量的全面提升。

InfoQ：在持续测试策略这块，有更具体的实践可以分享吗？

金艳：关于左移的实践，以持续集成中的单元测试自动化为例，过去，开发人员提交代码给测试团队，等待测试结果可能需要一周时间，遇到变更则更耗时。所以后面出现了单元测试的实践，通过让开发人员编写单元测试的代码，让代码在集成过程中就完成对功能的检验。但有一个问题，单元测试过程需要开发花费时间和精力去设计和维护单元测试代码，这往往成为推行单元测试的阻力。

在我们的持续测试体系中，我们引入并有效整合了单元测试案例自动生成的能力，开发人员在编写完程序并进行编译之后，系统会自动生成相关的单元测试案例。这些自动生成的单元测试案例会被提交给测试团队。这大大降低了开发人员实施单元测试的阻力，并形成了开发与测试更高效的协作形式。不仅可以提高版本质量，反馈周期也从一周的时间缩短到一两天，使单元测试和 TDD 实践更易于推广。

在测试右移的实践中，混沌工程是我们开展得比较早和相对成熟的实践。在传统情况下，只有在生产环境中发生节点故障或者发布后某个服务器不可用时，运维团队才能意识到问题，并采取应急措施。

通过混沌工程，我们可以在预发布环境中（金融企业无法在生产环境中做）引入一些受控的“捣蛋鬼”，模拟系统可能遇到各种故障和异常情况。研发团队可以观察系统在这些情况下的表现，并将这些观察结果作为一些测试准出的参考。这样一来，我们可以在系统上线之前就提前识别和规避一些潜在的问题，这种预防性的方法有助于提高系统的稳定性和可靠性。特别是对于分布式系统，这种方法极具价值。

此外，我们还可以利用混沌工程结合流量录制技术，将生产环境的数据导入灰度环境中。通过混沌工程的能力，进行一些对系统健壮性的验证，包括系统的韧性、抗压力等方面的测试，从而补充测试案例。

InfoQ：在追求研发效能的过程中，平安银行是如何平衡研发效能和满足业务需求之间的关系的？有哪些经验或实践可以分享？

金艳：首先，我们提升研发效能就是为了满足业务需求，是为客户提供更好服务、更及时响应的重要手段，“磨刀不误砍柴功”嘛。

但确实如你所说，在进行技术升级和工程实践推广时，我们面临着一些挑战。进入云原生 2.0 后，我们的业务研发团队时常面临着满足业务需求和升级技术与工程能力的权衡，因为研发人员的精力和研发资源是有限且珍贵的。

在这个过程中，最大的矛盾在于资源是有限的，业务部门并不关心研发基础能力，他们可能难以理解研发项目提升对他们的好处是什么。业务需要的是研发点对点地完成相应的业务需求，不喜欢研发投入资源去做这些“多余”的事情。

所以这个问题涉及到业务对“全面云原生”升级背后价值的理解，以及在研发资源分配上的一些共识。在我们的实践中，我们与业务达成了共识，形成了两个原则：即业务优先和价值优先。在资源冲突时，我们以业务为优先，同时保障有 15% 的 IT 资源用于技术体系改造等基础能力的升级建设。

价值导向也是判断哪些任务优先进行的关键，这里不得不提到 BizDevOps 的实践。BizDevOps 的实践主张将业务拉到同一战线，让业务参与到整个研发过程中来。 在实践里，我们通过透明化研发流程，为业务展示每一个需求的完成过程，同时建立统一的价值评价体系，将业务需求价值和 IT 升级改造的价值拉到同一个评判体系下进行排序，用同一套标准将需求分为不同层级（P0~P3）进而确定优先级，更有效地交付价值。”价值最大化”是平安在文化层面的共识。

研发效能团队的挑战与成长

InfoQ：相信历史技术债是每个研发效能团队都会面临的挑战，能否结合实际案例说说平安银行是如何处理研发历史债的？

金艳：对于“存量”的问题。我们从两个方向上来进行处理：一是治标，处理“症状”，我们行内有专门的工程治理团队，会结合行内的实际情况，制定整体的工程治理方案，推进整体的治理实施，业务团队通过对关键功能代码的修复或有意识的“重构”，整体上解决紧急程度较高的债务，这相当于“还债”；

二是治本，这里我们通过升级技术能力和组织能力，让团队获得研发质效的提升，进而获得高效处理技术债的能力，比如我们分享的“持续测试”体系能力，比如我们整理的云原生建设，这相当于提升我们的收入水平，过去的债务压力随着我们水平的提升，变得没有那么大了。

近两年我们一直在推动一个名为 “工程训练营” 的项目。在这个项目中，我们集结了全行各业务团队中研发质效领域的“种子选手”，通过对他们进行工程效能领域方法、实践的培训和指导。通过最后认证考试的选手将被视作全行工程质效领域的专家。

“工程训练营”的专家成员肩负着两个使命：一是配合全行总体的“工程治理”，配合工程治理组织在年初时进行工程架构的梳理，制定组织级的目标计划，确认各自团队需要进行的工程治理和架构改造项目，作为“代言人”推进相应治理和改造；二是作为工程方法和实践的“指导者”，规范团队行为，传递最佳实践。

InfoQ：除了处理当前的历史债务，平安银行的研发效能团队是否采取了一些预防措施，以避免未来积累更多的技术债务？

金艳：“工程训练营”面向的是“存量”技术债，另一项措施则针对“增量”。在这方面，我们会实施技术栈的统一，即进入我们银行的系统和框架的东西，即使是由外部第三方厂商引入的系统，我们都要求其达到我们的标准，进行规范化要求，确保新增系统基本上没有治理方面的问题。

InfoQ：除了研发债务，平安银行的研发效能团队在整个发展过程中可能面临了其他一系列挑战。您能否进一步谈谈这些挑战？

金艳：近年来，科技不断进步，对于团队来说，意味着我们需要更快地进行迭代，迭代速度要超过业务侧的开发和测试同学，需要不断学习，然后将学到的能力运用到实践中。因此，我们的团队面临的挑战除了工程效能的要求不断提高，我们对人才效能的要求也变得更高。目前团队成员都具备较强的抗压力和学习能力。

另外我们需要保持对行业的关注，可能需要参与行业大会、定期交流、与同行交流。近年来，我们加强了这方面的沟通频率，希望通过行业间的交流，反向审视我们团队在哪些方面做得还不够到位。因此，像 FCon 这类大会的分享不仅让我们充当了老师，也是学员，我们也在关注其他行业中是否有更好的实践。

未来发展与持续优化

InfoQ：面向未来，平安银行在研发效能方面有哪些短期或中长期的发展规划 / 持续优化的计划？能否分享一些关键的方向或目标？

金艳：一方面我们会将 AI 技术融入到研发工具和平台中，比如运用相对成熟的大模型，实现对整个研发体系的智能化升级，将 AI 纳入工具和平台，使它们更加智能。

另外我们将持续测试作为重要的发展方向。这与国家和行业对高质量发展的要求相契合，尤其在当前经济下行和降本增效的大环境下，云原生是一个有力的落脚点，既能支持持续测试，又能实现高质量发展。通过容器技术等手段，实现敏捷创新、组件高效复用，并提高系统的可用性、安全性和稳定性。

平安银行明年的重点是实现全面云原生，目标是让大部分系统实现云原生。这意味着不仅是技术的更新，还包括对工程工具和人才培养体系的全面升级。

报告推荐

《2023 银行数字化转型报告》正式发布，本报告重点探索作为金融服务核心的银行机构，在面临用户消费模式变化、银行业务结构调整、新兴金融机构竞争加剧等因素的影响下，如何推进五大重点场景的数字化转型，并总结输出大中小型银行的两条数字化转型路径，期望为不同类型和规模的银行业企业提供研究内容支撑。关注「InfoQ 数字化经纬」公众号，回复「银行报告」免费获取。