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

我行我素

, z: Y+ y* f0 e, ]

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

3 C$ e! n0 q: c

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

' M# W0 Z5 q6 s. M0 V) u

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

0 n' L* A' z* X& w

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

7 s3 \& |8 |/ N3 S$ q  O

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

$ e/ H; m- y1 p# W2 ?" j8 k+ y

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

  M4 G1 D. c! B0 F4 O

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

/ A8 b+ z# z" Z5 C4 s' ~

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

- X8 p9 [: _4 }0 P" a

. d7 ]4 A: z$ z- j7 {9 _

·     缺少自动化

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

4 c+ |& _+ b& ]. u; t

$ l5 q5 j5 f! X* j

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

0 K2 f( C' V; D$ o! B! G0 q8 `

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

, H1 ?" d7 H* a$ z9 i

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

9 h9 O7 X7 z4 {+ ~9 Z

8 G9 {) |$ k8 [) Q3 p

$ H. z* Y/ r  c

9 Z1 M- [- K. ]2 G. @8 b( G2 u" i

给公司高层的DevOps好处分析

% c3 u3 ]: C" l+ N- D

2 @+ F0 X9 H, }

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

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

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

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

( M* [4 c& O4 m# a' c3 {

: m  B% @! O4 J* X0 k  L9 B. C

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

7 ^) @7 x# J9 J

·     降低30%的新产品Defects！

7 M' T- M3 c" c8 I" n# e% v

5 v2 {2 y' D6 n1 S- ], }

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

3 S) ^' K3 w. m  ?2 a! w. \$ M6 J

6 p8 w- d/ }2 P( Y) Y& p

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

3 _3 @" I1 z3 i3 w) f

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

7 I+ \7 x3 s, o. J. W7 G: T4 w

4 A$ v; \8 Z' a% M  E4 W9 b: y

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

# p& V2 [1 S6 T8 J7 d

* m- n5 G4 N2 m! {3 Z* a: ~

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

( e& T* x0 i' I9 o. _- S$ K

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

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

+ |: y3 _& k0 e3 u7 m

, x! c/ z7 G2 E3 i; D" x# r! N

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

% B1 ?. U  w/ j5 H1 a

KeyBank的三个DevOps重点方向

1 X# H6 \: K; z+ G; a( W' J

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

, G9 ^( k: G  L4 B$ W

8 i6 [0 ]" F! Z+ ^

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

; p) h) R0 E( |2 Y. x

. F( A' A1 N+ m+ R$ I* B

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

) |1 S0 w* }3 V3 @0 b; v; h& W" a5 d+ O

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

! |( k5 r  }+ R

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

4 E7 v6 |+ @8 E$ a$ Z# r1 Z5 z; h/ ]; r

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

5 U  U* ]  Z" p7 `- v' {4 a

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

$ x  b' |7 `2 t, r+ A

( a: Y. R/ V; o: d; |

" H- c5 I$ s- L" W

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

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

, n' u. G$ Y" z' l. Z  f6 F3 b

5 [, e. ]( P, q1 r

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

% C! M+ M3 Y2 }& F" T& |

KeyBank 的DevOps工具链

原创：DevOps咖啡馆

- T: f5 S6 E! \2 T
( ^# n$ s6 e4 {3 L
1 X: s1 V) t8 n+ q7 l1 C

7 ]1 o" O* s5 e. p' J! r
0 a( |* G1 J, ?( L/ ~  j