KeyBank银行的DevOps实践分享

该文分享的是如何在Kubernetes和 Docker 上运行网上银行、采取开源软件，进行数据库演进和引入断路器等IT改革方式。

这是一家有着二百年历史的银行，拥有近20,000名员工，在美国排名前15位的银行中排名第一，拥有1370亿美元的资产。有大量的旧的信息系统需要处理，如何使用DevOps将业务推向二十一世纪？KeyBank技术基础设施高级副总裁John Rzeszotarski在今年的欧洲DevOps企业峰会分享了他对银行如何解决成本，复杂性和遗产约束等方面的经验。

一年的收购，容器和每周发布

公司内部突然发生的架构变化通常有两个原因 ： 文化要求或商业要求。在KeyBank，肯定是因为后者。早在2015年秋天，KeyBank宣布了收购First Niagara的交易。Rzeszotarski表示要求新的数字应用程序到位，然后快速安全地迁移First Niagara的客户，KeyBank技术方面由此迅速发展。该项目开始于2015年12月，一直到2016年7月，该银行在一个新的、有点大胆的基础设施上实现了在线和移动银行业务。

“早在2016年，没有银行在Kubernetes和Docker上运行网上银行，”Rzeszotarski在他的谈话中说。

此次收购成为推动了该银行经历一年快速变革，在应用程序发布的前四天，它能够安全稳定地进行12次更改，从而可以快速修复提高用户经验，关键是Kubernetes使其能够进行滚动部署。

Rzeszotarski说主要的好处是Kubernetes允许他们安装新版本的应用程序，同时仍然管理其他应用程序。

经过一段时间的快速变化后，您如何决定下一步？

在第一次Niagara收购完成并且这些应用程序发布后，Rzeszotarski说：“当时由于我们没有这些催化剂，我们发现快速行动具有挑战性。”

该银行仍然有许多源自这个行业最佳实践的应用程序,有遗留系统，需要各方面的集成。

对于他来说，银行业又回到了对运营，安全，发展，风险和架构如何协调发展，尽可能地找到妥协点，努力避免相互阻碍。

考虑到这一点，Rzeszotarski和他的团队在KeyBank的技术运营中选择了这些挑战点：

1. 成本 - 你如何用更少的资源做更多的事情？

2. 复杂性 - 您如何管理可以通过许多不同的复杂集成进行高度细分的大型企业？

3. 遗产 - 您如何现代化和处理遗留系统，包括一些没有路线图的系统？

如何改变成本博弈

Rzeszotarski表示，大多数企业基础设施预算都在下降，是因为基础设施资源通常随着时间的推移而变得越来越便宜，包括降低成本的虚拟化和容器，因此银行能够在现有资源上获得更多的数量。

此外，开源开始主导新的技术采用决策了。

“不是因为开源是免费的 - 因为它无论如何都不是免费的，”Rzeszotarski解释说。“它确实可以让您在没有重大投资的情况下开始创新，它减少企业付出的代价 - 至少不会超过我们的能力范围。“

该银行仍然购买商品化软件，但他表示，典型的开源订阅模式对于其购买的产品而言更为公平的，这是“与专有商业软件附带的长期不公平许可协议”相比而言的。

说白了，采取虚拟化和容器 以及开源软件，降低成本。

如何改变复杂性的博弈

这里的头号游戏改变者肯定是容器和Kubernetes。

Rzeszotarski强调了容器的重要性，“不再需要有15个团队专门负责发布了，采取容器和k8s以后，交付都是在代码中构建的，可重复使用的，将发布这一责任交还给应用团队来管理它，使其成为可测试的，我们正在使用Kubernetes来保护它并确保它具有高可用性和高可靠性。“

他继续说道：“对于应用程序框架和平台，已经弥合了修补、升级和热修复解决方案，因为只在应用程序之上进行部署，容器和k8s消除了跨组织团队的复杂性。

Rzeszotarski谈到关于容器和Kubernetes的好处：“它更准确 - 哪怕你只构建一次，我们都可以在较低的环境下进行测试，然后该映像不会在其他步骤中发生变化。”

但它仍然没有给他们一种管理基础设施的万无一失的方法，克服复杂性约束的下一步当然是解决与传统基础架构的集成问题。

如何改变遗产系统的博弈

KeyBank的团队采用传统的方式，遵循Martin Fowler的建议，包括演进数据库设计、断路器和Strangler应用程序。

为了实现敏捷方法，演进数据库设计可以持续交付，并且无需停机即可更改数据库和应用程序。演进数据库设计规则如下：

1. 数据库管理员与开发人员密切合作。

2. 所有数据库工件都与应用程序代码一起进行版本控制。

3. 所有数据库更改都是迁移。

4. 每个人都有自己的数据库实例。

5. 开发人员不断整合数据库更改。

6. 数据库由架构和数据组成。

7. 所有数据库更改都是数据库重构。

8. 这些重构是自动化的。

9. 开发人员可以按需更新其数据库。

10.所有数据库访问代码都明确分开。

11. 经常进行发布。

在KeyBank，跟随Fowler的做法意味着“我们现在已经成功测试了数据库更改，然后才把它发布到容器世界中”Rzeszotarski说。

这在KeyBank是一个持续过程，意味着许多数据库环境尚未满足这些标准，Rzeszotarski表示它并不总是在银行内部业务中进行，这涉及与众多外部合作伙伴的集成。

“如果与供应商进行集成，但是不版本化他们的服务，该怎么办？”

他说银行应该在自己和合作伙伴之间建立一个安全墙，防止外界流量的冲击或网络断路，为此银行使用断路器模式 - 就像什么时候关闭，我们通常只在一个电路上打开开关，而不是切断整个房子的电源，KeyBank的应用程序与许多外部合作伙伴集成，包括账单支付，个人对个人支付和信用卡服务。

“有时应用程序会开始报错甚至放慢速度，我们使用断路器保护了我们的应用程序，”Rzeszotarski说。

该银行使用Netflix的开源工具Hystrix对断路保护实现了自动化。他说这个 工具 寻找封闭和开放的电路，如果请求失败，它将关闭与该片断的连接。它将继续每秒尝试一次请求，直到可以安全地重新打开它。这意味着虽然一项服务可能暂时停止运营，但客户仍可查看其余额并进行转账。

该银行还在关注MF的Strangler模式，以安全有效地取代传统系统。Strangler是一种以会慢性自杀的澳大利亚葡萄树命名，这涉及到遗留的应用程序慢慢消失 - 而不是重写它。Rzeszotarski说，如果你试图一次性完成所有这些，你就会创造出太多的风险，你可能无法理解，而且你永远不会完成任何遗留作品，因为你总是想要用新功能来更新它。

Rzeszotarski指出他的观点是他自己的，并不代表KeyBank的观点。