DevOps金融行业转型案例：Capital One两年实现蝶变
本帖最后由 adminlily 于 2018-10-26 16:21 编辑背景：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（ReleaseManagement），大家都在写代码，都是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.零停机发布
功能开关
读者可以对照检验自己项目的Pipeline是否达标。
我们拭目以待Capital One在2017年在DevOps的转型之旅上会给大家带来什么样的惊喜。
本文总结自Topo Pal于DOES15和DOES16的两个演讲《Bankingon Innovation & DevOps》以及《DevOps at Capital One: Focusing onPipeline and Measurement》
原创：许峰
页:
[1]