国外大型银行DevOps转型干货总结

一、背景信息
Capital One是美国最大的数字化银行之一，成立20年时间，有数百万的账户。据说国内互联网金融的高端人才多半来自Capital One，所以这个公司也被被誉为金融科技人才的“黄埔军校”。在金融科技创业者心中，Capital One是个神奇的存在，大家都期待自己成为中国的”Capital One”。

Capital One相比其他传统银行来讲相对年轻，所以它的IT管理方法和使用的技术也更为敏捷。他们认为自己有着与众不同的DNA：

自己开发软件。Capital One有80,000名员工或工程师；

使用公有云。尽管这听上去有些让人提心吊胆，但效率的确很高；

构建微服务系统。服务尽量解耦，每个服务由独立团队维护；

相信软件开源技术。不仅是消费开源软件，而且还贡献自己的力量；

DevOpsSec和持续交付。这里特别强调Security（安全），因为安全在银行业需要特别重视，所以把DevOps与Security组合在一起写成DevOpsSec，后面也会详细描述具体措施。

二、转型历程

Capital One 启动敏捷和DevOps转型大概五年时间，就像大家常说的“所有的成功都如此相似”，可以看到他们转型中这些耳熟能详的关键词：敏捷、自动化部署、自动化发布、自动化测试、使用云等等。作为一家银行，原来他们的软件交付过程也是采用瀑布模型，开发、测试、安全、运维各个部门竖井林立，隔墙抛砖，演讲者说这些场景还历历在目。但五年的时间，以上的这些痛苦就都不复存在了，他们进行了快速的转型。

从使用外包，转变为自有工程师开发。无独有偶，昨天我与一位银行业的朋友聊天，他说强烈感受到在传统按项目的外包模式下，跨公司的巨大协调成本和时间延迟，目前在进行DevOps转型的试点产品线，已经全部采用银行自己的开发人员进行研发的模式。

从垂直竖井，转变为产品团队。近期我与国内另一家银行交流时，他们也提到在试点中的某电子渠道产品，也对组织结构进行了调整，成立了跨职能的产品团队，目的是更快速完成软件交付。

从开发、运维、测试、发布经理等多种角色，转变为人人都是工程师。有的工程师负责写应用代码，有的负责基础设施代码，有的负责测试代码，有的负责开发构建和发布自动化工具，这些都是代码，写代码的人都是工程师。

从整体上，Capital One的转型历程为，在2014年主要完成了自动化能力建设，2015年主要进行DevOps的规模化、采纳开源技术并迁移到云，2016年主要完善度量体系、技术上的持续改进和成熟度模型的建立。值得一提的是，作为一家银行，拥抱开源而且能够向业界贡献开源工具，其实并不多见，后面也会提到他们的开源工具Hygieia。

三、改进的目标
除了低头赶路，我们也要抬头看天。有的时候我们要问自己一个问题，就是我们做敏捷、DevOps转型最终的目标到底是什么？做这个事情的第一性原理是什么？

我们要顺畅、高质量地交付用户价值。DevOps之”道”就是快速交付价值、灵活响应变化。Capital One总结出的转型目标也很类似，就是”Delivery High Quality Working Sofeware Faster”，即更快速地交付高质量的可工作软件。

高质量。不能有安全问题，尤其银行，必须合规，并且要尽量减少缺陷。

可工作。跨产品线、共享服务和依赖的第三方，端到端必须可用。其实持续交付和DevOps的难点问题在于跨系统，尤其是银行这类复杂系统，如何做好对齐，如何更有序的发版本，这些问题的解决方案较为复杂，我们后面有机会单独讲。

更快速。多快算快？半个月一次投产？一周一次？一天一次？这里给出的答案是ASAP，根据业务需求，能多快就多快!

四、关键技术方案

1、流水线的建设
DevOps与持续交付涉及的技术方案范围很广，由于篇幅有限，今天我们先聚焦在"Pipeline"，即交付流水线的建设上。
交付流水线相信大家并不陌生，我也讲过多次了。Jez Humble给出的概念，交付（或部署）流水线就是软件从版本控制库到交付用户手中这一过程的自动化表现。

那么交付流水线能够帮助我们什么？回答是：提高流动速度，减小压力。

演讲者使用瑞士物理学家伯努利的伯努利定律来做类比：流体速度加快时,物体与流体接触的界面上的压力会减小，反之压力会增加。如果我们使用小批量、在流水线中持续交付功能（价值），这样也会减小在流水线上工作的工程师的压力。

2、什么样的流水线是不好的
一图胜千言，为了更方便记忆，我们先来看看以下三种不好的流水线。

上面这幅图是输油管道，但是我们认为这样的流水线设计不够好。

因为这类比了大型项目并行多个长分支的研发模型。并行分支越多、分支存活周期越长，合并成本也就越高，而且如果是长分支的模式，本质上就无法做到持续集成。主干开发是推荐的分支协作模型，高绩效企业的特点是每天向共享主干合并一次代码、同一时间少于三条活跃分支、让分支的生命周期尽量短。

上面这幅图是管道损坏了，工程师在扎堆手工修复。我们希望交付流水线是高度自动化的、并且是稳定的。如果流水线因为环境问题、测试案例问题、数据问题常常处于失败状态，每次都需要大量人工修复时间和成本，久而久之就没有人愿意花时间修复，进而没有人关心流水线的成功与否。

流水线的另外一个最佳实践是：通过度量持续监控并改进流水线的稳定性，出现红灯时必须第一时间发现并立即修复。

上面这幅图是更复杂的多条流水线组合的场景。有多个相互依赖的组件耦合在一起，每个组件有自己的代码库和多条分支，通常不知道哪里是流水线的起点，流水线何时结束。

多流水线集成是很复杂的场景，但我们有时也要考虑：是否可以通过组件的解耦，减少流水线之间的集成，降低多条流水线聚合场景的复杂度，每个组件的流水线相对独立，通过契约测试等方式保证其质量和兼容性。

3、流水线建设设计的原则

以上通过几张图举了一些反例，那么良好设计的流水线应该是什么样的呢？图中给出了流水线设计的16条原则：

源代码版本控制

事宜的分支策略

静态分析

大于80%的覆盖率

漏洞扫描

开源扫描

制品版本控制

自动化分配资源

不可变服务器

集成测试

性能测试

每次提交进行构建,部署,自动化测试

自动化变更工单

零停机发布（蓝绿部署、金丝雀发布等）

功能开关

4、流水线的度量和改进
DevOps三步工作法的第一步是”流动”，通过上面我们建设的流水线已经实现了；第二步是”反馈”，建设自右到左的反馈循环。反馈就需要度量，度量就需要有数据。

前面提到过Capital One自主开发了一款名为Hygieia的仪表盘工具，并且已经开源了。这款工具就是用来对交付流水线全周期进行监控和度量，通过数据驱动改进。

图中显示了交付流水线各阶段的度量，其中一个重点是在各个阶段之间流转的等待时间。等待是精益思想七种浪费中很关键的一种浪费，提升速度的关键措施就是减少等待。

五、安全和合规性建设
前面也提到，DevOps的目标不仅是快速和高质量交付，还要确保安全和合规性，尤其是银行的场景之下。常见的确保安全和合规的方式是增加更多的流程和评审点，比如通过CAB（Change Approval Borad）组织很多大型的评审会议等，但这种方式实际有效性通常较低。

真正的风险其实是各种故意和非故意对生产环境的损害、未测试的代码部署到生产环境等，我们要通过一些方式减缓这些风险，我们需要一个更好的方式：应用DevOps的原则，通过在交付流水线中注入风险减缓措施、内建质量来降低风险。

以上总结了在代码管理、构建、构件库管理、测试、部署、支持等多个阶段中的共29个增强安全和合规性的具体措施，写的非常详细，大家可以详细参考。

六、结果数据

Capital One的DevOps转型非常成功，多个衡量IT效能的指标得到了极大提升，每天生产环境部署多次，发布频率和质量均稳步提升。

七、总结
Capital One的案例表明，在银行业这种对安全和合规要求很高的场景里，也同样可以进行DevOps转型，转型后的IT效能指标并不亚于互联网公司。通过采用DevOps的方法和实践对组织、技术进行转型，大象也可以翩翩起舞，而且是跳街舞!