金融行业-KeyBank银行DevOps转型案例

我行我素

: b) ]' M7 {2 k9 x8 m+ w$ M7 U8 z

本文根据John Rzeszotarski和Chris McFee在DOES16（ITILxf.com" target="_blank" class="relatedlink">DevOps企业峰会16）的演讲《Banking on DevOps》整理而成。

- k7 F" {* T$ X3 c5 ~6 z, O% s

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

! ^# J8 n; J' P9 H" ^

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

- N0 e7 y: s2 ]; }% f5 [% o

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

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

1 d, p! ]( w. w" F" O$ w& ^

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

9 `7 _/ W$ m5 \% U' E0 A  \

; ^  ?# q3 `" D0 Z5 u9 F- q

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

. E  Z2 O% k6 ^/ Z/ c  I! f

·     缺少统一配置（服务器，网络等）

·     缺少自动化

2 g) u2 e! p  O5 V  A( k

+ q" \! L6 m' A" g6 r4 _

·     团队之间职责不清、缺少沟通

  h  }$ [% I9 ]( X. D' w8 |

·     不同环境迁入导致的高额技术债

* C6 \, P6 l0 Z* J" g

" J2 H4 f# X- _" G

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

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

5 Q. w8 [3 [1 p

, O# |7 y+ e4 L) q

给公司高层的DevOps好处分析

- k$ i: F% ?/ ^. |% J, H/ \

, _, k/ A9 ~/ R& v( B

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

. H- X, I6 y- E1 a; h5 _- D) `

$ J; J6 j  |, m: r

·     优化50%的测试资源（想说可以减掉50%的人工吧？？）

  ~5 d; q" t8 r1 @

  R# ]+ N5 H; V" D/ {

·     优化40%的发布和代码管理工作

0 T2 j. E9 c" X) O3 D9 w

+ L: Y+ _* a& ]. q! Z; A7 W

·     优化20%的基础设施工程师

# g+ [9 n- f" ^( [1 B4 P- E

·     降低85%的产品上线周期（测设、安全、发布）！

5 x5 C" `6 \, Q9 G# @! h3 a: \

  c0 o" z+ p0 C6 S8 x; C

·     降低30%的新产品Defects！

·     再降低50%的部署失败率！

4 c$ `% T4 e7 j: Z' u3 y/ z

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

4 e3 J6 P2 F2 v5 k9 T9 U* j- Q9 q( }5 @

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

·     老板自掏腰包搞了个天使投资（估计是从现有IT预算里挤出来的）

" x2 }0 p3 |  l$ q* C% a5 G

' Q  x( I7 y- q0 g

·     先成立一个4个人的DevOps小组（后面会说这个小组做什么），后期发展到10~12个人的规模

+ i  ^. O- \' U! ]2 R) g/ _

·     先找一个业务价值大的项目开始（网上银行）实践

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

$ D7 L; i  e( T& Q( Z

6 s+ `8 v! y) h5 K6 z9 z

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

& e; Z1 y% }2 V( F1 }

1 H+ T/ {1 L, }+ I) v

KeyBank的三个DevOps重点方向

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

" E: ]+ V. w- k* y. r) E

$ F" P3 j- _% T! Y2 a$ l) X

8 Z7 }- I7 p4 u: ^: c

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

3 }8 P* G- a$ u

! D% g: R) g6 _: d

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

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

: t1 d; M. y4 Y, U7 E+ s2 _5 _3 P# q& n

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

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

/ V8 V/ Y* H; A- C

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

2 A( t( s/ r9 {5 u# f

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

5 I1 l) B6 G# Q) j" I8 v

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

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

. n. d) b8 |) Y

KeyBank 的DevOps工具链

% D3 c7 q* R2 a$ y" U' g

4 t# h1 h  u0 c" o) P

原创：DevOps咖啡馆

$ S2 ^2 w+ `3 m; f3 R1 I
* \# U' K" Y3 T" a5 h

* l8 C$ ]% C1 K: |; \1 Y" h

8 W9 q9 M. `1 U
2 D- [- ]$ d. i2 r8 p; C- c