平安科技毛倩影：从 DevOps 到 BizDevOps，金融数字化下的研发效能提升

在日前的 InfoQ《超级连麦·数智大脑》直播节目中，我们与平安科技研发管理部副总工程师毛倩影围绕 DevOps 和 BizDevOps 进行了一场深度对话。毛倩影不仅分享了她多年的实践经验，还深入探讨了金融机构在数字化转型中面临的复杂挑战，包括与业务部门的紧密合作、满足安全和合规要求，以及如何在企业文化和组织架构中找到最佳实践。以下是对话的几个重要要点：

1. 认知差异与业务对接：IT 部门在追求技术卓越和自我提升时，常常与业务方存在认知差异。

2. DevOps 在金融与互联网的差异: 在金融机构落地 DevOps 时，由于存在稳定的长期团队和管理流程，整个实施过程需要更加细致和全面。与互联网公司相比，金融机构更需要考虑到现有流程和部门间协作的整合。

3. BizDevOps 的崛起： 随着业务复杂度和需求的增长，BizDevOps 逐渐成为行业内认可的趋势。这不仅要求 IT 部门继续“练好内功”，还需要与业务方更紧密地合作，以适应不断变化的大环境。

4. 文化与组织的重要性： 落地 DevOps 不仅需要技术上的准备，还需要组织和文化上的支持。特别是在金融环境中，如何建立有效的组织模式和文化是成功的关键。

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

毛倩影： 在我看来，随着近年整个大环境的变化，企业特别是金融机构，对数字化转型的期望越来越高。作为 IT 从业者，我们可以明显感觉到这种变化。合作伙伴不仅期待数字化能带来商业模式的突破，还逐渐提出了降本增效和精细化管理等更高的要求。我们也观察到，在企业拥抱数字化转型的过程中，新技术的应用节奏和速度明显加快。以 ChatGPT 为例，自从去年底和今年初起，它在公司内部的讨论群中就迅速火爆起来，上千名开发人员在短短三天内热烈讨论如何将其应用到不同的业务场景中。

实际上，对比以往，新技术的落地速度明显加快。现在，IT 人员不仅需要完成技术开发，还要与业务部门并肩作战，深入了解一线业务需求，以提供全面的 IT 解决方案。以我们内部一个专门做低代码平台的团队为例，他们在落地项目时不仅需要解决技术和工具的成熟度问题，还需要深入一线业务，发现并解决业务痛点。这也反映在团队结构上，产品经理这样的角色越来越多，与业务部门深度合作，共同规划 IT 系统的发展。

当然，作为金融机构，我们也不能忽视监管、合规和安全等方面的要求。相较以往，现在不仅需要确保软件无 bug、按时上线，还需要考虑更多其他因素。

毛倩影： 在早期，金融机构主要侧重于将线下作业迁移到线上，并在这个过程中逐步完善和成熟其 IT 系统。这些年来，大多数金融机构已经走完了这条路，拥有了相当成熟和完备的系统。目前，我们更多地是依托这些成熟的技术进行业务方面的创新。创新往往是一个从无到有的过程，需求通常很模糊，通常来自于高层的战略考量。这需要一个漫长的过程来逐步分解和明确。尽管如此，市场对产品上线的期望并没有降低，这也促使我们和合作伙伴需要快速适应并做出响应。

在这个变化的大背景下，我们观察到合作伙伴也经历了诸多变化，需要更多的 IT 支持。不再是以往的接力赛式的工作方式，而是需要将需求和交付紧密结合，共同推动业务发展。

另外，因为现阶段很多事情还在探索阶段 ，面对许多不确定性，更需要前瞻性地与业务部门合作，共同分析和解决问题。这也是金融机构在数字化转型过程中，面对内外部变化，需要做出的多方面应对和调整。

毛倩影： 首先，创新与合规之间的平衡是非常关键的。由于金融机构是强监管的单位，在业务和技术模式创新时，合规性是必须要考虑的。这与非金融机构存在明显的差异，因此需要找到一种更稳妥的解决方案来应对这一挑战。

其次，在面对与业务对快速交付和迭代的期望下，金融系统的安全与稳定性也面对着一定的困难与挑战。业务方面的预期越来越大，同时也面临着高速业务增长的压力。但金融系统的质量和稳定性标准不能因业务的快速需求而降低。因此，研发团队需要找到一种方法，在保证系统质量和安全的前提下，去响应业务的快速发展需求。

第三，我们面临着技术升级与成本控制的双重压力。尤其在近两年里，随着技术如微服务、云原生等不断演进，系统需要持续升级以更好地支持业务发展。但这些升级都需要资金投入。如何证明这些投资能给业务发展带来更高的价值和回报，是 CTO 和 CIO 需要持续解决的问题。

最后，管理复杂度的提升也是一个不可忽视的问题。随着数字化转型的深入，IT 团队规模越来越大，不仅团队管理复杂度提高，技术管理的复杂度也在指数级地增长。这涉及到项目外包和人力外包的问题，以及如何在复杂的管理模式下平衡效率、风险和安全。

毛倩影： 整个技术研发体系是从比较统一和标准化，逐渐走向多元和不确定性。早期，我们主要采用大瀑布模式和依赖 CMMI 框架，各个部门的要求基本一致。但随着业务的快速发展和新技术（如 AI 和大数据）的引入，我们的研发体系也在逐步演进。从 2011 年开始，我们导入了敏捷开发，到 2016 年左右开始引入 DevOps，近年来，我们也更加注重与业务侧的合作，特别是在“业研一体”的项目中。

在一些项目管理中可能存在项目目标管理及业务需求价值不够清晰明确，业务需求进度跟踪及交付管理透明度不够等情况，导致项目交付效率及质量存在极大的挑战。业务和 IT 都普遍认为，按照原来的管理方式继续前行是不可行的。于是，我们开始尝试一些新的实践，如与业务方一起开展工作坊，进行目标对齐等，并在项目初期就开始实施这些措施。与此同时，我们的项目组的核心骨干从项目规划的最初阶段就开始参与，而不是等到业务方花了三四个月时间明确了所有事项之后，再用剩下的三个月来完成项目交付。这样，整个项目的运作方式也发生了显著的变化。

毛倩影： 一方面，金融有着更高要求的合规和安全要求，导致在研发和业务发展方面有着与其他行业不同的侧重点。另一方面，在 DevOps 或“业研”方面的项目实施中，金融行业和互联网行业也有不小的差异。在金融行业中，产品经理，他们在需求定义过程中会有一个特别重要的步骤，那就是需要将需求提交给合规和安全部门进行严格的评审。这一环节通常会受到非常严格的控制。

毛倩影： 从 2015 开始，我们逐步搭建并优化了 Devops 体系。在与行业同仁的交流中，我明显感觉到大家对 Devops 的理解越来越深入。这种深入理解促使了协作模式和思考方式的变化。这种变化背后有两个主要的推动力。

第一个是社区的推动和行业大会的作用。每年在各种社区和大会上，大家都会分享很多优秀的实践和案例，这些案例能解决大家实际面临的问题。这也使得相关理念逐步深入人心。第二个推动力来自成熟度的评估标准，如信通院的评估体系。很多机构每年都会进行三级、四级的成熟度评估，这不仅提高了大家的标准，也让大家清楚地看到了自己与理想状态之间的差距，从而明确了改善方向。

参与推动 Devops 理念落地的企业越来越多，但回到本质，其实大部分企业是出于解决自身的需求和痛点而引入这一套理念。通过对项目的具体落地实践以及切身痛点解决前后对比，带来的实际价值感知；更有力的推动各行业对与 Devops 体系的认可度提升。因此，实际需求和业务痛点更能驱动我们引入了更好的工具和协作模式，提高了整体效率。

毛倩影： 当我们开始落地 DevOps 体系时，要面对的不仅仅是一套新的工序，而是一个全面的体系结构。因为金融机构通常有稳定的长期团队和一套现有的管理流程，这些都需要在引入 DevOps 时进行整合。

在整个组织层面上，实现 DevOps 不是一个简单的“平地盖高楼”的过程。而是需要在很大程度上继承和兼容现有的各个流程和部门间的协作，甚至需要考虑到成本利润分配。这意味着，在引入新体系时，必须综合考虑当前的研发流程管理、安全管理等多方面的要求。

另一方面，业务的复杂度和历史系统也是一大挑战。比如，在引入持续交付等新的实践时，会受到多种因素的制约，如系统升级和解耦的过程。单一团队在持续实践时，也会受到全局因素的影响，这可能会影响到整体效果。

毛倩影： 为了提供更高效的服务和管理，我们内部有一套 DevOps 工具平台（神兵 wizard），对外称为“E 敏捷”。目前，该平台有约 4 万左右的月活用户，除 3 万左右为 IT 研发人员外，剩下的 1 万左右则主要为业务侧人员。 这些业务人员会用平台进行多种类型的任务管理，如提业务需求，日常文档编写，事务管理，待办跟踪等非开发性质的任务处理。在用户覆盖范围方面，这个平台服务了集团内 20 多家子公司的日常需求管理及 IT 研发交付。 工具平台主要聚焦于研发流程管理，从需求协同管理，版本规划到研发 CICD，以及代码仓库管理，发布制品管理等。在数据安全合规方面特别增加多租户数据隔离管理机制，满足各家公司特有的需求和管理模式。

为了灵活服务于更多的业务场景的实践落地，我们建立研发管理体系工具平台化能力，提供更高灵活度的配置能力及开放自定义能力；在确保管理自主性的前提下，提供更高度的灵活性和开放度，各子公司应能便捷灵活地管理自己的业务，平台则提供必要的工具和服务支持。

毛倩影： 我们的安全团队与 DevOps 的工具团队实际上是极好的合作伙伴。这主要是因为我们的工具平台为他们提供了实施各种安全措施的极佳平台。以安全扫描工具为例，内部规定上线前必须进行全面的安全扫描。如果这些扫描工具不与我们的开发流程和版本交付流程紧密集成，那么仅依靠人工线下管理的方式来确保执行率会相当困难。

为了解决这个问题，我现在开放了接口，以便进行安全扫描。 这些扫描工具可以被集成到我们的开发流水线中。这样一来，安全团队的管理措施和要求就能自然地融入整个开发过程中，大大减轻了他们的管理负担，同时也提高了效率。

毛倩影：在过去的几年里，我们一直专注于 IT 的内功修炼，目标是自我提升和改善。 这种自我提升多是在我们自己的闭环中完成，通过各种数据和指标来证明我们变得更好、更快、更强。但遗憾的是，在这个过程中，业务方面的感受并不总是与我们的自我评价一致。他们可能认为，虽然我们有所改变和提升，但与他们的量化数据相比，还是存在明显的差距。

这种认知差异可能源于我们与业务方在需求提出阶段的不充分协作。 可能业务方自己还没有完全明确需求，或者还在与他们的领导进行审批，或者目标没有对齐等等。因此，我们需要更多地与业务方前置对接，以缩小这种认知差距。

随着业务的快速发展，我们也进入了更多未知和高风险的领域。在这样的大环境变化下，如果还用旧有的合作模式来支持业务，那将是行不通的。 一旦等到业务方把需求想清楚后再行动， IT 交付面临的时间压力会非常大，很可能要牺牲质量和工作健康度来满足需求。

因此，不仅需要持续地练好“内功”，还需要与我们的合作伙伴共同前进，适应不断变化的大环境。 这样，我们才能更有效地支持业务，并真正实现自我提升。

毛倩影：找准合作的时机是非常关键的。 如果我们突然一天跑到业务部门说要支持他们，没有一个合适的契机或实际问题需要解决，他们可能会觉得很奇怪。因此，当业务部门遇到挑战或问题时，这样的时机便是我们介绍 IT 组织中优秀实践的最佳时机。

除了寻找外部合作的时机，我们内部也积极进行技术分享。每年都会有一次全集团范围内的大会，如敏捷日，现在则是将敏捷开发和架构放在一起的全集团年度会议。 这些活动不仅仅是 IT 部门内部的事情，也是与业务部门互动和学习的平台。

分享一个去年的案例：我们的教练辅导了一个业务团队，反响非常好。在做完阶段性总结后，业务侧的领导表达了他想参与下一次全集团 IT 大会的愿望，因为他觉得在这个合作模式下受益匪浅。这不仅给了我们很多鼓励，也证明了我们走的方向是正确的。

最重要的是，当这样的成功案例从我们的合作伙伴口中说出来，其影响力远比我们自己宣称自己做得成功要大得多。 这种第三方的认可对于提升我们的工作价值和影响力是非常有帮助的。

毛倩影： 在走向 DevOps 的过程中，建立一个专家团队是至关重要的。这个团队不仅作为 IT 和业务之间的“润滑剂”，还以第三方的身份介入，这有两个主要优点。

第一，他们在相关领域内具有专业性，能得到各方的认可；第二，作为第三方，他们能更客观地推动项目，因为他们相对来说没有立场。在组织架构方面，DevOps 的整个运作模式也需要精心设计。 为了更好地与业务方合作，例如在我们的银行环境中，可能会推行“部落制”等模式，目的是要将所有人都拉到同一条线上进行合作。

另外，与业务侧的紧密合作也是必不可少的，包括与业务领导进行日常互动，以及在目标和 KPI 对齐方面也要有所考虑。这些配套机制和组织上的考量是为了确保大家在追求同一个目标时，出发点和终点能够保持一致。

毛倩影 平安科技 研发管理部副总工程师，深耕研发管埋领域 20 年＋，负责推动集团研效提升，BizDevops 业研一体及研发数字化转型等重大项目，并主导超过 10 家大型金融企业的 DevOps 项目合作。