银行业 DevOps 状态：来自 DOES 2018 伦敦大会的报告

关键要点

• DevOps 开始在整个企业中扩散，因为来自跨职能团队的技术专家和业务人员越来越多地通过跨价值流的方式一起完成工作。
• CI/CD 几乎已经成型，尽管银行在这方面的既定实践仍然处在扩散过程中。
• 银行正在认真考虑项目管理办公室和项目组合管理职能，并正在设计、理解和分享新的模型。
• 系统和团队间的依赖关系被认为是银行业的一个关键约束，银行致力于打破这种局面，让系统变得松散耦合并使用内部开源模型。
• 在实践 DevOps 原则的过程中，外包带来了很多地域、沟通、预算和技能方面的挑战。

在 DevOps 2018 伦敦企业峰会上，一些银行发表了演讲，分享了他们在学习和实践 DevOps 原则方面的经验：CapitalOne、巴克莱、劳埃德银行集团、Key Bank、渣打银行、荷兰银行、瑞士银行和苏格兰皇家银行。在这篇文章里，我们总结了他们演讲的关键要点，并指出了演讲内容的相关性和重叠部分。

DevOps 在银行企业中不断发展

来自 CapitalOne 的 Aimee Bechtle 和 John Schmidt 的演讲主题为“When the Business Partners with Tech and They Do A Dojo”，他们分享了他们的 DevOps 加速服务，这项服务旨在让技术人员在企业中为业务人员提供支持，消除之前业务人员难以从技术负责人那里获得承若的情况，比如，技术负责人总是说：“我们现在没时间，你需要去找产品负责人”。

Bechtle 解释了他们最初是如何将开发和 IT 运营结合在一起的，而现在将技术和业务也结合在一起。他们还首次将 DevOps、数据科学和机器学习结合在一起。她说：

我们的速度不够快，DevOps 是外来的，但也很有趣，我意识到我们的积压待办事项中需要超过一个或两个 NFR 才能有所作为。

Bechtel 和 Schmidt 建议听众“寻找具有创新意识和前瞻性思维的产品经理”，并得出结论：“建立业务和技术之间的关系是最重要的事情。”

来自渣打银行的 Shaun Norris 描述了他们目前的状况：

五年前，我们遵循瀑布模型。现在我们大约有三分之二已经采用了敏捷，剩下的三分之一正在转向敏捷的路上。运营越来越成为瓶颈，并且仍需要数周的手动过程来配置环境。做出一个变更需要经过三十五个步骤，这是一个手动的过程，容易出现延迟。你需要依靠良好的人际关系才能顺利走过这个流程——因为某些人的心情可能会影响结果。现在，我们看着康威定律在发挥作用，看着一个事故涉及到了 13 个团队。我们把赌注压在网站可靠性工程上。卓越没有终点——所以我们永远不会满足。

荷兰银行的 IT 工具和软件开发部门负责人 Stefan Simenon 的演讲主题为“Scale Your DevOps Initiative Beyond its Awkward Teenage Years”，他在演讲中分享了他们当前的 DevOps 状态：

我们曾经使用瀑布模型。我们的很多时间花在了等待上，用来启动项目，用来构建、测试和部署，但在后期仍然发现了不少软件质量问题。我们有很多手动切换和批准流程，代码合并通常发生在后期阶段，我们有一些大型但不频繁的生产部署。

在成功的 CI 试点之后，荷兰银行在整个组织中部署了 CI/CD，同时转变为敏捷组织。他们花了三到四年时间，并在 2017 年完成转型，每个人都采用敏捷的工作方式。Simenon 说，新组织的项目管理和项目开销要少得多，而且更专注于交付软件。

Key Bank 的高级副总裁兼持续交付和反馈主管 John Rzeszotarski 表示，目前约有 10％的工作采用了敏捷，他们看到 IT 运营一直在推动团队变得更加敏捷。他们认识到，将持续集成与瀑布结合在一起只不过是重新让 PMO 以不同的方式发挥作用。他们在小规模的高价值、高变化、以客户为中心的领域具备很高的能力。

来自巴克莱的工作方式负责人 Jonathan Smart 和国际投资组合管理部门的 Morag McCall 在他们的演讲“The PMO is Dead, Long Live the PMO”中描述了他们在 2014 年之前处于敏捷孤岛的状态，然后创建了实践社区，有超过两千名成员自愿参与进来。2015 年，他们推出了企业级敏捷计划，旨在“更快、更安全、更快乐地交付更好的产品”。他们让精益组合管理和 PMO 在敏捷组织中发挥了作用。

现在，他们的关键工作单元是业务成果假设。业务成果预计每三个月交付一次。他们的投资组合历时十二个月，其中包含四个业务成果，然后是投资组合目标、与战略目标相媲美，这些目标与 CEO 的前五个优先事项保持一致。

从财务角度来看，他们正在使用季度成果，并拥有一些价值流资金。他们发展了一个轻量级的商业案例，以便能够尽快开始实验，并且在采购中采用了敏捷的工作方式。他们的重点是缩短交付周期。

原则上 CI/CD 是完整的

从大方面看，银行认为 CI/CD 已经是完整的，尽管可能并未在整个企业中全面采用。

Simenon 认为，他们需要合适的工具来实现必要的组织变革，他们把目标转向了“零接触”部署。他们有多个 CI/CD 管道用于部署 Java、Python 等，他们的 DevOps 工具链包括 Jira、Xebia Labs 的 XL Release 和 XL Deploy，以及安全、Sonarqube、Fortify 和 Sonatype Nexus Lifecycle。

最初，他们在 Jira 中遇到了与非标准工作方式相关的一些不稳定性，但现在人们开始意识到管道的关键原则：在本地运行管道，进行快速和频繁的集成，采用测试驱动开发，保持小型的变更，获得持续的反馈，拥抱功能分解，建立快速管道，自动化单元测试以及采用基于主干分支的开发方式。

在 IT4IT，他们在 Jira、应用程序部署支持、软件物流、测试工具、变更和配置管理、管道、CI/CD 指标、项目组合管理、应用程序监控、应用程序日志记录和大型机现代化方面都有专门的团队。他们提供了标准的管道，不过也允许人们在进行版本控制的前提下构建自己的管道，并开发和增强他们的 DevOps 工具链以及银行社区。

Jonathan Smart 说，在巴克莱银行，他们采用了“专注于最大限制”的方法，因此最初他们专注于 CD 生命周期，而现在关注投资组合管理和 PMO。

苏格兰皇家银行（RBS）业绩和业务管理负责人 JenniferWood 表示：

过去，一个团队的部署周期为 14 周，现在只需要几个小时进行蓝绿部署。

心理安全与人类情感之旅

Bechtle 和 Schmidt 表示，通过将人们的价值流更加紧密地联系在一起，通过使用道场环境来尝试新的工作方式，他们已经达到了“无所畏惧改变”的状态。

当不确定性程度非常高时，会造成同等水平的焦虑。这是正常的，也是可以理解的——我们应该接受它，而不是试图去平息它。

Schmidt 说，他们设立了道场，创造一种心理安全的环境，团队可以在这里进行实验。他们清楚地认识到，要让 IT 变得“人性化”同时又能够不产生给未来文化带来成本的不现实的期望和工作负载是一项巨大的挑战。

Bechtle 和 Schmidt 也意识到，他们也正在经历着一次情感化的旅程，并确定他们经历了两次低潮：“信仰 / 恐惧”和“我们还没有到达那里”。他们强调，相信“这是一种信仰的飞跃”非常重要。

敏捷教练也做了一些“心灵挖掘”，为数据科学家提供情绪状态的证据、指标和证据，以便更深入地了解在道场进展中发生的事情。

来自苏格兰皇家银行的 Wood 明确表示，她使用 DevOps 原则改善组织的关键目标是让技术团队的生活和工作变得更轻松，让他们能够自由地做他们想做的事情。在苏格兰皇家银行，他们的价值观是“跟随领导者”，组织中的每个领导对他们的回顾模式有很好的理解。她说：

我们的工作人员告诉我们，在这里工作很艰难。其中一些症状是因为有太多正在进行中的工作而引起的。我们并没有责怪流程或技术，但管理层不允许进行改革。解决办法是进行测试和学习，并学会容忍失败。

Wood 说，他们的领导者需要专注于他们的“床边方式”，并学会协作的领导方式。她将敏捷文化定义为：体现在价值观中的思维方式，通过实践和工具来实现。她说：

最大的杠杆是思维方式的改变，这确实会让人感到不那么舒服。我们设置了一套松散指导原则，告诉他们我们不希望他们做什么。我们让他们找出他们需要学习的下一件事。他们说我们什么也没做，并问我们要做什么，我们说：“不，你告诉我们你想做什么”。这是一个学习和忘却的旅程。你不能强迫人们加入赋权计划。

Key Bank 有一个关键目标，即解除安排在周末的发布以及期望员工加班的期望。

道场和加速的 DevOps 采用

CapitalOne 的 Schmidt 曾访问过 Target 道场，而 Bechtle 也一直在追随道场的修改版本。他们说，六周是最短的道场可行时间，即养成一个新习惯所需的最短时间。他们说：

道场是采用工程文化最快、最有效的方式。

很多银行都提到，在外包方面缺乏人才已经成为一个现实的问题。出于多种原因，DevOps 和外包很难一起实施：

• 在合适的时间获得合适的技能；
• 时区和语言的差异；
• 不同的文化和员工的持续性；
• SLA、合同和预算机制。

安全、监管和安全仍然是银行关注的主要问题

CapitalOne 认为，对于他们来说，速度并不是一个“纯粹、简单的目标”，但为了避免“不可避免的崩溃”，它必须与安全相结合。专注于安全性、稳定性和弹性降低了他们所谓的“哎呀税”，对他们而言，安全始终是优先考虑的事项。

巴克莱银行的 Nick Funnell 描述了该银行如何将功能性专业知识带入产品交付，以及如何以安全的方式提供安全产品，而不只是提供安全的产品。他们通过在团队中嵌入安全顾问来实现这一目标。在采用这种方法之前，与很多银行一样，基础设施和安全性是两大阵营，当它们无法获得达成共识时，事态必然会升级。

银行法规要求职责分离，这意味着你不能让开发团队进行生产部署，IT 运营必须是按下部署按钮以及接收变更请求的团队。因此，他们将 IT 运营代表嵌入到团队中，因此获得了更多成功的结果。

渣打银行的 Norris 描述了他在金融监管和安全方面面临的挑战：

如果的心态是悲观的，那么这个任务看起来就会是个大麻烦。每个国家至少会有一个监管机构，而且在数据主权等问题上总是存在共识和分歧，这意味着我们需要管理六十个复杂的关系。在每个新环境上线时都有 250 个安全控件需要映射和记录。我们的流程已针对合规性进行了优化，而非速度，我们每年发布两个版本。

他继续解释监管机构如何影响他的云策略：

我们期待与所有三大云提供商建立合作关系。监管机构想要这样做是因为他们希望降低运营风险，我们喜欢它，因为它提高了可移植性，我们可以使用正确的平台来做正确的事情。

Key Bank 强调了安全作为代码的重要性。他们说，在很多公司中，安全性是一个完全独立的组织，通过 CIO 向上汇报，而基础设施是另一个独立的组织，向 CIO 汇报。他们说，唯一可行的方法是尽早转型——它们必须“向左移”。虽然他们的团队中没有专门的资源，但确实存在可以“说得上话的人”。他们还指出 XL 发布流程如何自动化所有的步骤，并允许他们在发布级别对工具进行风险评估。有些扫描发生在部署过程中，有些则发生在发布过程中。

Nomura 银行的首席技术官 Nick Wadge 发表了题为“Securing Open Source in Nomura’s Software Supply Chain”的演讲：

我想知道我们是否真的从开源角度理解我们的风险。我想知道我们如何控制风险，同时仍然能够为开发人员提供所需的速度。

在进行成功的概念验证之后，Wadge 确定了 Sonatype 的 Nexus Lifecycle 就是解决这个问题的良方，但他需要申请预算：

我想做的最后一件事是花两周的时间写一个 35 页的商业案例，这显然是正确的事情——所以我使用了一页精益商业案例。关键的是分析，你定义结果，而且结果必须是可衡量的。

巴克莱的 Funnell 描述了他们的 AWS 环境如何实现整体的分散隐身安全。他指出：

如果能够做好这点，开发人员将不会意识到在安全方面都发生了什么。

DevOps 原则打破依赖性

来自劳埃德银行集团的 James McCleod 谈到了“Enabling Innersource”的概念。他解释说，在银行，工程师很难共享代码，但 Github 现在正在推动社区工程。这个平台让他们可以在外部进行协作，并共享开源项目，但内部协作和为组织带来合适的人才也很重要。

他将“ Innersource ”描述为内部开源，允许共享工作，让人们可以阅读和改进彼此的文档，fork 其他人的代码库和评审拉取请求。Nexus 是所有人都可以贡献的共享注册表或存储库。他们正在从集中模式转向分散模式，在这种模式中，团队可以选择他们想用的工具。IBM 正在提供和运营 GitHub，他们也参与了工作组。但他们并不能就这样开放整个系统，所以目前还有很多想加入其中但但没有访问权限的工程师。

Key Bank 将成本、复杂性、遗留系统和容量视为制约因素。

来自渣打银行的 Norris 说：

很少有人对事情的运作方式有完整的了解，并且没有一个团队会提供 API，电子邮件和会议就是他们之间的协议——我们因此感到非常沮丧。我们已经经历过一次失败的转型——通信不透明，交付的成果很少，我们看不到太大价值，而且成本非常高。

Norris 给出了很多对未来保持乐观的理由——特别是他们的工具链、云平台和 RunDeck。渣打银行有超过 200 个团队使用他们的 DevOps 工具链，并且周转时间缩短了 90％，每周进行六千次构建。他解释说：

迁移到云端是一场艰苦卓绝的斗争，私有云是一个战术上的止损，直到我们可以轻松进入公有云，但提供私有云的体验带来了一些好处，并且可以通过使用容器和 Kubernetes 之类的东西来加快速度。

Norris 讲述了他们的管理者必须通过观看团队员工的工作视频（生产访问和变更评审）进行评审以及 Rundeck 如何移除了这个“可怕的”需求。Rundeck 现在是他们下一代 DevOps 工具链的关键部分。与很多 DevOps 计划一样，RunDeck 先是在组织中的一小部分开始受到关注，在证明它的价值之前不会投入太大的资金，而且是非战略性质的。

CapitalOne 表示，“拥抱开源、微服务和 RESTful API 始终是首要任务”，这些架构方法都旨在用于构建松散耦合的系统，允许设计、构建、测试和部署小型变更。

荷兰银行的 Simenon 解释了他们是如何让一个专注于 SOA 的团队对记录系统和参与系统进行解耦，并且像渣打银行一样，已经采购了一个私有云，并且正在努力迁移到公有云。

Key Bank 解释了他们如何使用 XebiaLab 的技术作为加速器，从传统的 Microfocus 平台迁移出来，并提供更好的兼容管道。在他们的环境中，他们的 IT 运营人员为开发人员提供自助服务的能力：

我们更加注重于提供更多培训。我们提供了管道，将 IT 运营人员嵌入到开发团队中，帮助他们构建工具集。我们的目标是实现赋能。

Funnell 介绍了“巴克莱精益控制”，这是一项关注长期服务（与价值流一致）和“持续一切”的倡议。他们有一个“控制部落”，与团队密切合作，以避免“治理剧院”和 Jira 早期的限制。他说：

技术并不是最困难的部分，也不是阻碍我们的因素。赋予聪明人权力并让他们了解正在发生的事情才是我们要面临的挑战。

来自巴克莱的 Smart 介绍了他们两年多以前的情况，以及他们通过敏捷和 DevOps 缩短了交付时间，但仍然需要等待集成测试（每月），因为有太多的依赖，然后还需要等待 UAT（季度），然后等待发布时间表（发布很难，每季度进行一次）。

他还指出了业务场景、产品积压项和开发积压项之间的大量等待时间——大约 18 到 24 个月，他将其称为“模糊前端”。但是，一旦到了开发团队这里，就显得很紧急。他说：

这种“紧迫性悖论”导致了不可持续的工作——即使团队正在使用现代化的工作方式。我们发现了一些反模式。第一个反模式是我们在不知道实际吞吐量的情况下盲目答应客户的要求，因此积压项就越来越多。第二个反模式是饥饿和过度生产，以及创造“假工作”：一个“特色工厂”，它的发展与公司的战略相脱节。第三个反模式是“盛宴和饥荒”，一次性涌入大量的要求，然后什么都没有，这种流动是不可持续的。

Smart 强调了高内聚和低耦合的必要性，并且需要打破依赖关系而不是管理它们。

从组织依赖的角度来看，我们可以反思所有银行业务贡献者所描述的跨职能团队的创建：

• 在团队中拥有测试人员意味着我们不依赖于测试团队。
• 在团队中拥有用户验收测试功能意味着我们无需等待“业务”批准部署。
• 将 IT 运营嵌入到团队中意味着可以及早理解和满足基础设施的需求，并将非功能性需求（如性能、负载和安全性）嵌入到设计中。
• 在团队中拥有安全专家意味着我们可以专注于应用程序的安全方法，而不是等待基础设施可用，或是等待做出决策或等待执行渗透测试。
• 在团队中拥有客户或业务人员意味着我们能够尽早了解不断变化的需求。
• 当我们拥有跨职能团队时，我们更有可能设计跨职能系统（即康威定律），从而改善端到端的流程。

成为技术组织的银行也正成为学习型组织

来自劳埃德银行集团的 James McLeod 分享了他们看着像 Monzo 这样的创业银行在一个月内从概念转为现金，以及他们在当前的工程转型计划之前需要三百六十五天的时间将一行代码部署到生产环境中。他认为“工程是未来”，也是他们能够加速赶上曲线需求的关键。他表示：“我们是一家工程公司”，并表示拥有正确的工具和信息才能帮助他们吸引到合适的人才。

巴克莱银行是一家拥有三百多年历史的银行，年收入达到了 200 亿英镑。他们拥有 4800 万客户和 8 万名员工，其中有 2 万名技术人员。GTO 开发实践主管 Nick Funnell 在他的演讲“From Racks to Cloud”中说道：

没有技术，我们就无法在金融领域做任何事情，而且随着利润受到挤压、利润收紧和监管力度的加大，我们不得不做更多的事情以便将来可以少做一些事情。我们是一家技术公司，我们将全力投入到公有云。

苏格兰皇家银行的 Wood 描述了银行业变革的条件：监管、提高客户期望、持续的经济表现不佳、颠覆性的新技术。她说，银行业的基础和银行业务的运作方式正在因开放式银行业务而发生变化，因此，苏格兰皇家银行别无选择，只能变得更加敏捷。

Key Bank 对未来的劳动力愿景是经过自动化和智能机器增加的劳动力，并在整个企业中嵌入了微型学习。

MaCall 回忆起她以前在一家正在向敏捷转型的金融服务机构中工作的场景，因为项目经理被视为障碍，因此她变得多余。在巴克莱，她描述了他们经历过的三个阶段：

• 第一阶段：幼儿时期——专注于持续改进和建立使用敏捷教练、物理工具、自我优化团队的灵活性；
• 第二阶段：启蒙时期——转向长寿命产品概念和价值流概念；
• 第三阶段：尤达（Yoda）时期——限制了正在进行中的工作组合，并优先考虑战略性工作——做完手头的事情再开始新的任务——关注结果而非产出。

MaCall 说：

项目管理办公室更具咨询性，侧重于依赖和发布管理。我们已经成为一个学习型组织。

几乎所有演讲者都强调指导是一个重要的学习推动力。

混乱、协同办公、沟通和社区

McLeod 将他的演讲重点放在社区工程和代码协作上，以及这些方法如何通过促进使用代码作为讨论的基本构建块而不是 Powerpoint 来推动开放性和教育性。他描述了劳埃德银行集团对内部开源的使用（他的“innersource”，本文前面已经介绍过），也谈到了他们如何开始就组织外部的协作以及企业代码共享进行对话。从安全角度来看，这是具有挑战性的，但他们认为这是吸引人才来满足他们重新关注工程和成为技术公司的关键。

除了这一举措之外，他们还参与各种会议，并在伦敦牛津街的哈利法克斯分部为儿童举办了代码训练营。

巴克莱的 Funnell 描述了他们如何使用 Jira 来推动协作，特别是在不同的站点之间进行协作，并试图获得对混乱工作的一些见解。他们并不是一开始就很顺畅——因为使用这些工具可能是在拿自己开玩笑。后来这被认为是积极的，因为它允许出现健康的紧张情绪，并引发了很多有趣的对话。

他们还设置了网络摄像头，这样就可以看到其他办公室，他们发现这种方式非常强大。他们每天都通过视频开展会。Funnell 说：

协同办公自然是最好的，但现在这种方式也算得上次佳。我们知道我们必须做什么，然后发现要做的事情太多了，特别是对于测试人员而言。看板上显示了需要完成的工作，但后来发现很多任务没有被处理，测试人员也不知道它们代表了什么。后来，我们让测试人员尽早加入，并逐个解决积压问题，然后我们发现质量得到了很大改善。

瑞士银行资产管理负责人 Jelena Laketić谈到了他们的 UBS 全球黑客马拉松，它被作为四个地区和十五个地点关键的 DevOps 推动者。

总部设在日本的野村银行也发现黑客马拉松是提高数字意识并将人们聚集在一起进行创新的有效方式。他们的年度全球黑客马拉松活动将他们的全球开发人员聚集在一起二十四小时，他们最近的黑客马拉松的主题是在消息传递平台上构建聊天机器人。他们还举办“Tech Fayre”：一个内部贸易展览，为内部开发者提供了一个通过主题分享他们的作品的机会。去年的主题是“创新”。

荷兰银行开展了 CI/CD 意识计划，主要关注管理方面。他们有一个夏季活动计划，包含了各种活动，其中就包括领导力和外部演讲。Simenon 说：

让高级管理层参与进来非常重要，他们不仅要表达出来，还要展示，并将信息持续不断地传播到整个组织。

Key Bank 的社区教育方法是午餐和学习、“Brow Bag”会议和演讲日。

在此处观看主题演讲的视频、分组会议的视频，在这里下载演讲者的幻灯片。

关于作者

Helen Beal 是一名 DevOps 顾问、教练、培训师、演讲者和作家。她致力于帮助组织通过行为、交互和技术改进来优化从创意到价值实现的整个流程。她喜欢美洲驼，曾经看着火烈鸟下蛋。你可以通过 helen.beal@infoq.com 与她取得联系。

查看英文原文： The State of DevOps in Banking – Report From DOES London 2018