金融行业DevOps转型案例：Capital One两年实现蝶变

背景：Capital One（Capital One Financial Corp. ）是一家以投融资及基金管理为基础，集国际贸易、项目开发、投资银行业务为一体的多元化国际企业集团，总部位于美国特拉华州。

DevOps缘起：说起来这家成立只有20多年历史的银行在美国银行业里绝对算是个初创公司。公司一直都是以信息技术优势见长，尤其是在数据分析、数据科学方面，但在软件开发方面之前都是采用外包的方式，并没有被定义成公司的核心业务。

随着银行业的数字化趋势，尤其是手机上的交易量已经远远超越了传统的交易渠道，促使他们开始把软件开发作为重中之重来对待。

创始人兼CEO RichFairbank能有如此深刻的认识很不容易

痛点：Capital One的DevOps之旅开始于2014年。当时，Capital One的软件开发实践和很多传统做法没有什么不同：大量外包，瀑布模型，季度发布，手工流程，变更请求。

和KeyBank从大事故中痛定思痛不同，他们是从一个小问题反思开始的。在某次代码检查会上，大家发现一个测试失败是由于某个XML文件里的tag不配对造成的。

按理说，这么小的问题改了再提交就可以了。但是：

1. 开发工作是由另外一家公司负责，他们需要发起漫长的变更请求；
2. 代码修改后的构建流程（编译、测试、部署等）就需要至少2天时间

这个小小的问题让Capital One的技术团队开始反思他们的构建流程，并决定从这里下手。

他们从一个小的团队开始优化构建流程（其实就是最小版本的Pipeline – 部署流水线），最终把时间从2天缩短到几分钟。于是，这个实践逐渐在Capital One蔓延开来，所谓星星之火，可以燎原。

编者注：这是DevOps转型与落地的典型思路，小范围（局部）改进见效果，然后自发蔓延或者公司整体推广改进。

尝到甜头之后，Capital One开始认真思索企业级的DevOps策略。Capital One的DevOps框架涵盖了业务、开发、运维，最后加入了信息安全策略（对金融业安全监管尤其重要），他们称其为DevOpsSec。

Capital One的企业级DevOps框架

Capital One继续改善流水线的效率，除了开发与测试，要想真正打通流水线，还需要搞定环境/服务器的搭建和管理。之前新建一个服务器要走完62个步骤，耗时60天，开发团队的抱怨很大。

Capital One决定：直接上云！

2015年的时候还是只有开发和测试等环境在云上，到了2016年，生产环境全部上云了。

Capital One的流水线（Pipeline）

另外，Capital One发现开源真的是宝。他们不止大量的采用开源工具（”Open Source First”,非开源系统会被严格审查），还积极加入开源社区。

他们发现开源自己的工具可以让代码质量大大提高，并且大大促进了持续体验和持续学习的DevOps文化。

Capital One的开源第一（OpenSource First）策略

2015年取得的成果：

1. 代码提交频率：从之前的不固定到每天100多次的提交
2. 集成频率：从每月1次到每15分钟一次
3. 部署流程：手工变成自动化
4. 部署到QA和和Perf（性能）环境频率：从每月1次到每天4次
5. 部署到生产环境频率：从每月或每个季度1次到到每个迭代1次
6. 单元测试覆盖：从没概念到>90%

2016年继续改进流水线，已经能够做到：

1. 发布到产品环境的频率：从每个Sprint一次到每天至少1次
2. 自动发布的应用软件数量达20个
3. 一个应用软件每天最多可以发布34次

所以说DevOps的转型可以很快。

现在，Capital One很骄傲地宣称自已有了和两年前完全不同的DNA：自己开发软件、所有环境都在云上、微服务、开源、DevOpsSec和持续交付。

确实，Capital One在DevOps之路上是远远超越了很多同业的。尤其这一旅程也只用了2年多时间。

Capital One认为转型有三个关键中的关键：

1. 外包转向自建开发团队（外包公司要努力了）
2. 功能团队转成产品团队（一个产品团队就像一个多兵种的行动小组）
3. 不再区分Dev、Ops、QA、RM（Release Management），大家都在写代码，都是Engineer

转型的的三个最关键策略/实践

总结下Capital One的转型之路:

Capital One的DevOps之旅时间表

从这两个演讲中笔者听到最多的就是流水线，开源和安全。

尤其是流水线，Capital One的DevOps转型其实就是围绕着这个核心进行的，不断优化，持续改进，在整个公司推广。

Capital One总结了要做到真正的流水线，以下15个特性是必须的:

1. 版本控制
2. 最优的分支策略
3. 代码静态扫描
4. 80%以上的单元测试覆盖率
5. 漏洞（Vulnerability）扫描
6. 开源工具扫描
7. 制品（Artifact）版本控制
8. 环境自动创建
9. 不可变服务器（Immutable Server ）
10. 集成测试
11. 性能测试
12. 每次提交都触发：构建、部署和自动化测试
13. 自动化变更请求
14. 零停机发布
15. 功能开关

读者可以对照检验自己项目的Pipeline是否达标。

我们拭目以待Capital One在2017年在DevOps的转型之旅上会给大家带来什么样的惊喜。

本文总结自Topo Pal于DOES15和DOES16的两个演讲《Bankingon Innovation & DevOps》以及《DevOps at Capital One: Focusing onPipeline and Measurement》