DevOps 在银行系统里的神秘事实

概括地说，我的职业生涯就是做为一名软件工程师在四家全球投资银行中度过的，工作内容也很错综复杂，主要是维护一个用来处理各种交易、风险管理和中间办公的网络系统。我花了大约五年左右的时间来研究在这个行业里的软件开发和 DevOps 两方面的进展。

自从 DevOps 转型咨询公司 Contino 成立之后，我的工作内容就变的丰富多样化了，包括零售，媒体，保险，教育和制造业，我主要是给客户提供一些在 DevOps、持续交付和敏捷实践方面的咨询建议，主要目的当然是为了加快软件交付和发布周期。作为一个观察者，我所掌握的资料和信息都是一手的，当和银行业以外的 IT 行业相比之余，只要跟 DevOps 有关的，银行总是显得那么与众不同，或者说格格不入，但它们有自己的挑战，也有独一无二的机遇。虽然很多人会觉得这很不可思议，但是银行在使用 DevOps 的很多方面都表现出较高的成熟度，而且有足够的能力提高 DevOps 在更多方面的使用能力。

本文首先会讲述和同行业相比，银行在 DevOps 转型方面有哪些高效的举措，有哪些表现不错的地方，或者说有哪些抢得先机的案例。然后我会重点讲讲银行在 DevOps 转型过程中有哪些低成熟度和需要改进的点。

这是一种工程协作文化

DevOps 的核心思想就是打破开发、运营、架构团队和测试团队之间以往各自为营的孤岛关系，并且让这些部门里的工程师们在人与人的基础上更有效的合作。

银行的 IT 部门一般和别的部门在组织架构和工作汇报流程上完全不同，而且有的时候还会受到地理位置的限制，团队成员的远程办公等方面的障碍。令人欣慰的是，在整体的公司文化推广上还没有出现太多的磕绊。

在我的开发团队中，我们通常与测试人员保持积极的关系，在高度协同的发展环境中一起工作。我们理解他们的，他们也理解我们的工作内容和流程，为了提供高质量的软件，我们互相激励，而且拥有相关联的目标和 KPI。

开发者对产品的归属感

由于银行系统的特殊重要性，一旦失败后将承担严重的后果，所以开发者必须具备对产品的高度理解能力和对产品的拥有意识。同时要了解产品的服务方式，代码如何更科学的部署，代码和基础设施如何实时互动，如何执行系统，如何监控系统，以及会出现哪些故障模式，解决方案是什么。这些都要了然于心。

开发者一旦把产品当做是自己的孩子或者杰作来看待，那么就一定能能催生出更具操作性的软件产品，因为他们更了解如何维护产品，他们的代码和部署技巧直接影响着产品的使用结果。尤其是在出现问题的时候，解决问题的速率更体现他们的责任心。

正因为有这样的优秀的 DevOps 基础，在银行工作的 IT 开发者一般都具备较高的责任感，所以他们能够提供高质量、可靠和可信的产品系统，而不仅仅是敲代码那么简单。这也是 DevOps 得以实行的最佳理由。

对全栈的理解

传统的银行系统开发团队通常考核一个开发者的技能，都是结合开发者的开发技能、UNIX 技能、脚本编写技能、对数据库层的理解，以及考察架构元素的性能和可扩展性。只不过后来对这些所谓的“全栈”工程师进行了优化。银行技术团队的开发人员了解服务器环境中，熟悉代码的调整部署，并知道如何从前端到应用程序服务器，再到数据库上来管理和运行他们的系统。

在很多情况下，前端和后端代码，中间层代码和数据库代码都是由相同的开发者撰写的，其实这也存在弊端的，因为这样极其容易出现问题很难查找的问题。对全栈工程师最好的理解就是能够熟练掌握代码技能、系统管理理念和基础设施运维，这才是对 DevOps 有利的，因为它固有的简化沟通流程，支持协作，并降低在大的团队越区切换人员的必要性。

应用和企业架构的模块化

今年我接触了很多银行组织，他们想要打破以往的以“整体应用”为精卫的模式，并将进入微服务作为转移到 DevOps 和持续交付的部分组织工作。但是，说起来简单，做起来却需要大量的时间成本。在一般的银行系统环境中有很多大的、传统的应用程序，但是，银行的技术部门都比较钟爱面向消息的中间件，这是一种罕见的银行应用程序，因为它不是围绕 Tibco，WebSphere MQ 或 Informatica 等类型中间件而构建的。

这就给银行一个很好的契机，帮助他们打破原有的老旧的应用程序平台，可以独立开发，测试和部署组件。但这并不意味着可以抛弃旧有的精锐之师，但是构建一个比较紧耦合的整体架构也算是一个很好的开头了。

矛盾重重的技术遗产

银行算得上是从古至今都和数字有关的一类机构，固然存在很严重的技术遗产问题。他们的平台已经发展了几十年，在许多核心部位都和主流技术相结合，但是目前这样的情形正在遭受到银行业务和技术不断扩张所带来的威胁：过去将不同的技术部署在不同的环节，而很多应用程序是用不同的技术搭建的，可以说就是一个将现成的和定制的软件混合在一起。银行的技术遗产看上去就像是一根链子上有很多大大小小的球一样，严重限制了银行快速前进和灵活转型的能力。

从协作和自动化的角度来看，技术遗产对 DevOps 的实施确实是一个不小的挑战，例如，专家人员，遗留技能会对原有的关键人物产生较强的依赖关系，从而不利于我们正在创建的较为开放的开发合作环境，势必也会影响到银行系统的构建，测试和自动化部署和发布周期，违背了 DevOps 所倡导的快速、轻量级和可实验的理念。

至关重要的开发者体验

在银行工作过的开发者体验对 DevOps 来说是相当痛苦的，感觉就好像你是在不断地跟你的工具、基础设施和网络进行斗争一样，而不是利用这些东西更好的完成工作。例如，Vagrant 是一个 DevOps 工具，利用它可以创建可重复的开发环境来运行虚拟机桌面。最近我试图在最后几个银行工具中使用 Vagrant，但常被告知虚拟桌面系统没有足够的能力运行这个程序。台式机也被阻止使用 Vagrant 的某些关键功能。最后，不得不抛弃这一工具，并转移到其他的平台上。

为了达到快速发展，高效利用现代自动化的 DevOps 工具，开发团队和发布团队需要从开发到产品的路径来对桌面环境有更多的控制能力。通过开放的环境（同时保持必要的保障），可以允许开发者利用这些工具和方法，DevOps 会让优秀行为从底层突现出来，而不是自上而下地做出规定。

结论

当我跟客户一起对 DevOps 进行探讨交流的时候，我们谈论一般都是改进的方法，流程的优化和技术的创新。我相信在一些更具挑战性的领域——文化，架构准备，敏捷成熟度和最佳技术实践上，银行的评分都是比较高的。总之，银行是现代 DevOps 软件交付方式最好的实现场所。

关于作者

Benjamin Wootton是英国咨询公司 Contino 的联合创始人兼首席顾问，帮助公司采用 DevOps 方法和持续交付工具。

查看英文原文： The Surprising Truth About DevOps in Banks