云原生最佳实践 | PNC银行如何用TriggerMesh实现软件供应链合规性的自动化

导读：当前，云原生已成为企业实现应用现代化、抢占数字化转型先机的最佳路径。因此我们开设「云原生案例集锦」栏目，深入剖析企业如何利用云原生技术来赋能业务增长。

本篇文章介绍了美国资产管理总额达3670亿美元的最大银行之一PNC银行如何用TriggerMesh自动化软件供应链合规性，实现IT敏捷化。

业务挑战

作为美国资产管理总额达3670亿美元的最大银行之一，PNC银行拥有庞大的IT规模和一个开发团队，他们不仅需要交付创新的代码，还需要始终符合监管合规要求。PNC银行希望开发一种方法，以确保新代码自动符合安全标准和审计合规要求，取代他们现有的繁琐的30天手动流程。

解决方案

使用Knative，云原生无服务器和事件框架，PNC银行开发了内部工具，可以自动检查新代码和现有代码的更改。开发人员立即知道他们的代码是否符合公司范围内的标准。Knative的事件和无服务器功能的强大功能使PNC银行能够在Apache Kafka和CI / CD工具链事件之间桥接流程，并实现此自动化状态。PNC银行还利用TriggerMesh声明性API来解决基于事件的工作流程的具体问题。该流程允许PNC银行在缺少任何要求概述的部分时阻止代码进入生产环境。

自动化合规以实现持续交付

每个CI/CD的改进都会加速代码到部署的速度，从而增加软件团队的效率。在金融组织中，开发高效、可靠的CI/CD流水线的探索不可避免地遇到合规要求。确保应用程序符合组织和监管机构的要求是复杂的，并且冒险很大。错误会导致进一步的延迟、罚款和可能的尴尬。PNC拥有9,500名开发人员和20,000个代码库，始终在寻求提高规模生产效率的效率。PNC的DevOps主管及其小团队的开发人员被赋予了一个重要的任务：减少代码合规性审核所需的时间和成本。由于数百个团队交付代码，PNC现有的37天手动流程是软件部署的巨大障碍。

在PNC六年前发起的DevOps转型之前，新代码从完成到生产需要超过300天的时间。使用自动化和DevOps最佳实践，PNC将代码到生产窗口缩短到37天。

手动合规性流程是PNC CI/CD的最后一英里问题。对于开发团队，合规性需要在代码完成后进行120小时的工作。这项工作花费在制作幻灯片演示文稿、会议和与多个业务单位沟通以确保合规性。

消除手动合规性流程

PNC的组合管理团队负责监督DevOps，并需要找到一种方式消除30天的手动合规性流程，同时确保监管机构和内部客户的满意度和生产力。

解决方案涉及使用Kubernetes、Knative和TriggerMesh构建本地云基础设施。PNC构建了一个名为Policy-as-Code的复杂内部服务，利用Knative自动事件和无服务器功能的强大功能。使用TriggerMesh的声明式API，团队能够利用事件日志记录来构建一个桥梁，将Apache Kafka和Jenkins与银行的Policy-as-Code应用程序连接起来。Helm负责实施规则，提供了一种让合规团队使用该系统而无需与后端交互的方式。

虽然Policy-as-Code在部署管道之外，但仍保持着与其工具链交互的能力。这个工具链因团队而异，但通常包含超过15个工具。由于PNC内部的不同团队不使用相同的工具，因此灵活性成为该项目的一个重要要求。

“要使Policy-as-Code工作，需要有可靠的事件捕获，”总监说。“这是因为该应用程序需要了解信息在工具链的不同元素之间如何传递。我不仅需要知道事件发生了，还需要知道事件影响了什么，事件的结果是什么。例如，如果我们谈论静态代码质量扫描，那么设置Web钩子告诉您扫描已完成会非常容易。但是，我们需要在丰富内容上进行回调，并将扫描结果归属于我们计划部署的实际二进制文件。这更加困难，而这仅仅是一个工具。如果您将其乘以我们所有不同的工具链集成，再加上不同的程序变化，就可以感受到其复杂性。”

于是，他们转向Kubernetes、Knative和TriggerMesh，以实现这种自动化水平。

“我们想要构建云原生应用，但是我们的MVP很快变成了一个运行着成千上万个不同线程的 Golang 单体应用程序，它几乎要崩溃了。我们看了看我们已经做了什么，再看看我们的路线图，然后说：‘这样不行’。”— PNC银行总监

幸运的是，团队在进程的早期阶段就寻找了另一种方法。在Knative环境中实施TriggerMesh从根本上改变了体系结构，将策略与过程分离。

因此，策略团队不必维护庞大的代码库。对于这样一个复杂的工具，团队能够修复问题而不会陷入泥潭也非常重要。Knative通过提供独立测试Policy-as-Code的每个组件的能力来解决了这些问题，而不需要进行端到端测试。

此外，使用Knative连接到Kafka要容易得多。切换到Knative架构将基础镜像从1.3 GB缩小到约10 MB。

“使用TriggerMesh和Knative路由系统的另一个很酷的事情是它非常模块化。在所有交互点上，我们都可以读取负载而不需要编写太多代码。我们可以更好地看到整个流程，”团队的首席软件工程师说道。

在Knative架构上操作，TriggerMesh（一个CNCF成员）的开源解决方案提供了高效、易于管理的事件捕获。通过TriggerMesh进行编排意味着公司中的其他人不需要了解整个后端系统。“我们将其中很多东西抽象出来了，”首席软件工程师说道。“团队只需要担心构建那个小的无服务器函数。”

PNC的技术基础设施始终处于负载之下，每天处理约200亿个查询。在高峰时段，每秒可能会有50万个查询。当开发人员推送代码时，所有的部分都需要就位，以保持系统的运行，因为事件必须实时处理。

更快的代码部署和自动审核跟踪

作为一个独立的自定义无服务器应用程序，Policy-as-Code为内部客户提交的代码提供了一个通过/不通过的状态。开发人员可以立即知道他们的代码是否符合标准，所有这些都在一个友好易用的界面内完成。没有通过合规性检查的代码不会进入生产环境。

目前，PNC有6,000个应用组件正在使用Policy-as-Code。原本需要一个团队30天才能完成的流程现在可以在几乎实时的情况下完成。团队在代码进入生产之前不再被长时间的等待时间或代码审核会议和沟通所拖累。

“我们真正的成功在于我们能够说，如果你的代码更改完全符合要求且不影响复杂的身份验证或资金转移，只需要运行管道所需的时间，即可将新代码推向生产环境。不再有120小时、37天的非代码合规工作阻碍生产。成千上万的 PNC 软件开发人员已经看到他们的部署窗口缩短到接近实时。我们的团队实现了真正的持续交付。这是我们的巨大胜利。”— PNC银行总监

企业收益

部署变得更加容易、清晰和快速。一个自动化、瞬间的过程取代了需要准备演示文稿并召开会议长达37天或更长时间的过程。内部开发的基于策略的代码服务可以实时检查代码。开发人员获得了更多的自由，并且代码审核不再受制于人工审核中固有的错误。开发人员利用高度发达的CI/CD流程维护PNC银行中超过6,000个应用程序。合规性所有者创建和实施测试，并自动集成到工作流程中。