案例 | 从一次严重的系统停机事件说起....

本文根据John Rzeszotarski和Chris McFee在DOES16（DevOps企业峰会16）的演讲《Banking on DevOps》整理而成。

背景：KeyBank是北美15家最大的银行之一，有超过190年的历史，主要服务于企业客户。总资产大约为940亿美元。Keybank银行及其子公司，提供了一系列的零售和商业银行服务，包括商业银行贷款，投资管理，金融，投资理财产品，以及个人服务等。 经过多年的发展和并购，该金融机构的IT系统变得异常复杂。

灾难：2年前KeyBank经历了一次严重的系统停机事件，在修复该事件的过程中，由于对系统复杂度理解不足，导致更大的服务终止问题。该事件引起KeyBank高层高度重视。这也说明没有痛点企业很难下决心解决问题。

首先，KeyBank成立了一个4个人的资深技术小组（START），负责了解KeyBank采用的系统复杂度到底是怎么样的。

该小组历经三个多月的时间，把银行每个主要交易事务所涉及到的硬件（服务器，网络）和软件服务都绘制到一个图示中。结果发现历经多年发展，KeyBank维护的IT系统的复杂度着实惊人：仅仅一个用户登录（Login）行为，就要经历190个网络跃点（见下图）！

一个登录动作会历经190个网络跃点

其它发现的问题主要包括：

· 缺少统一配置（服务器，网络等） · 缺少自动化 · 团队之间职责不清、缺少沟通 · 不同环境迁入导致的高额技术债

这些问题使大家意识到要想类似（或更严重）的服务停止事件不再发生，需要从根本上解决这些问题，从此KeyBank开始了DevOps转型之旅。

当然，首先这个小组要说服高层接受DevOps理念，他们用数据来说服老板们：

给公司高层的DevOps价值分析

基本上就是跟老板说，通过实践DevOps，可以：

· 优化50%的测试资源（想说可以减掉50%的人工吧？？） · 优化40%的发布和代码管理工作 · 优化20%的基础设施工程师 · 降低85%的产品上线周期（测设、安全、发布）！ · 降低30%的新产品Defects！ · 再降低50%的部署失败率！

(这几个哥们够拼的，把自己都逼上绝路了)

KeyBank的高层看了还是很心动的，但是搞DevOps要花钱，再增加IT预算也不现实（刚刚出了事故），最后他们达成一致：

· 老板自掏腰包搞了个天使投资（估计是从现有IT预算里挤出来的） · 先成立一个4个人的DevOps小组（后面会说这个小组做什么），后期发展到10~12个人的规模 · 先找一个业务价值大的项目开始（网上银行）实践

这个4人DevOps小组的重点攻关方向只有三个：容器，自动化测试，持续交付。

关于这三个重点方向的确定，是KeyBank对该企业硬件和配置环境复杂度，测试质量和低测试效率（顺便说下，他们之前建了很多外包测试中心），还有自动化程度不足的深思熟虑的结果。当然对很多类似的企业也有很多参考价值。

KeyBank的三个DevOps重点方向

容器使得KeyBank可以采用Immutable Server（不可变基础设施）的策略，大大简化了环境管理的复杂度。另外在Docker之上，他们也采用Kubernetes来保证高可用性，热部署，和环境的自我修复。两位倾情推荐！

通过Kubernetes把Docker连接和管理起来

两位继续谈到了自动化测试的重要性，也提到了转换到自动化测试需要比较长的培训和试错时间，但一切都是值得的。现在他们每个Build要运行超过5,000个测试，而执行时间只有15分钟！这在手工测试时代是不可想象的。

接下来是持续交付。持续交付使得整个交付周期形成一个无缝的流，也让每个不同的部门/角色都能协同在一起工作。业务现在分析人员也开始写Gherkin（Cucumber提供面向非程序员的编程语言）代码，而运维人员则写基础设施即代码的脚本。

经过一年半的努力（并不算长），KeyBank达成了以前不敢想象的IT能力：

比如测试执行时间，以前的测试84个场景要执行1200小时，而新的自动化测试覆盖195个场景，只需要12分钟。

最令他们骄傲的是，2016年KeyBank收购了First Niagara，一下子网上交易量暴增。而即使在并购后最初上线运行的前4天的高峰期，他们还热部署了10个发布到生产环境，结果没发现一个产品缺陷！更多效果见下图。

只用了一年半时间，KeyBank的IT就达到了非常惊人的结果

以上就是KeyBank的DevOps转型简介。有兴趣的读者可以访问https://www.youtube.com/watch?v=xgSkva_Eq5s观看完整视频。

最后一张图送给工具控们：

KeyBank 的DevOps工具链