DevOps落地实践及案例分享

转载本文需注明出处：微信公众号EAWorld，违者必究。

引言：

银行业为了应对业务的快速变化、互联网层面不穷的业务形态和交易压力，IT“双态（或双模）化”无可避免，开始探索部分业务参考互联网的方式引入分布式架构，但对于银行业独特的强监管、高安全、强一致性的行业要求前提下，如何在业务发展、合规、IT革新之间找到平衡？

而DevOps被愈来愈多的金融企业所采用，来支撑软件生产过程的数字化转型，本文主要和你们分享在金融行业落地DevOps的一些坑，如何填坑以及一些心得体会！但愿你们可以在本身企业中，找到适合本身企业的DevOps实践之路！

目录：

1、关于DevOps实践的一些问题
2、DevOps在金融行业落地都有哪些姿式
3、DevOps在金融行业落地的套路
4、DevOps将软件生产线数字化
5、总结一些DevOps最佳实践
6、DevOps项目落地过程当中一些心得体会

1.关于DevOps实践的一些问题

来源：DevOps咖啡馆

咱们从国际信息科学考试学会（EXIN）关于DevOps认证体系来分析，DevOps Pre-Master（DOPM）中包含了敏捷、精益、ITSM和测试相关的内容，也就是说这四项实际上是做为了DevOps知识体系的基础，其中敏捷、精益和测试是和软件生产、开发工做Dev强相关，ITSM则与Ops运维工做强相关。因此DevOps知识体系更像是对于以往IT知识的再次提炼和融合，不是一门新的技术。

DevOps是什么？又不是什么？

DevOps是个开放的体系，从实践中而来，而且还在不断的发展，具体到某个组织也并无一致的套路，因此DevOps落地更可能是因组织而异、因目标而异、因人而异
你们愈来愈意识到IT是个系统工程，要提升IT组织的绩效，有不少好的通用的实践，好的DevOps落地实践会涵盖DevOps最核心原则和模式，避免走没必要要的弯路，有效地缩短我的和组织的学习曲线
在DevOps项目落地过程当中须要培养和训练全局的、系统性的思惟认知能力，而非某些工具和命令的用法（缘由是：原则和实践是相对稳定的，而工具和命令的变化是很是快的），DevOps落地不是单纯的CI/CD，也不是单纯的Jenkins + Ansible

DevOps是自动化运维吧？不是作运维的为何要学DevOps？

DevOps是跨部门的合做，里面涉及的部门和角色远不止开发和运维（其余包括产品、需求、架构、测试、安全、项目管理等），因此DevOps不是自动化运维
但DevOps项目落地须要服务于组织目标，能够从自动化运维开始

讲DevOps仍是在讲理论，会不会太虚了？

所谓DevOps落地本质上就是定义问题、识别问题可能的最优解、而后不断实验该解的循环过程。这里不存在一个通用的落地框架，重要的是能理解问题的本质，培养自主解决问题的能力。任何别人家的落地都只是别人家的，企业须要发展出独有的、属于本身的落地实践，没人能替代（就像家长嘴里的别人家的孩子，永远没法成为本身的孩子）
DevOps是高绩效IT企业实践的有机集合体。任何企业的IT都须要在竞争的环境下不断提高自身的绩效，以便有效创造客户价值、最大化业务产出、减小浪费、提高交付速度和交付质量，并使企业在数字化时代拥有市场领先的IT能力。那么，从这个意义上来说，只要是IT从业人员，学习和了解DevOps对组织和我的都是有很是有意义的

2.DevOps在金融行业落地都有哪些姿式



咱们先看看咱们对于CICD的定义：

CI持续集成，咱们一般定义为从代码提交到编译打包，再到SIT的过程
CD中的持续交付，咱们一般定义为从代码提交到UAT的过程
但项目里，没有用DevOps作CI的项目，也可变相为从编译打包到UAT的过程
CD中的持续部署，咱们一般定义为从代码提交到最后生产部署的全过程
但项目中，有可能变通为从编译打包到生产部署的过程

总结来看，项目结果不一样，或者接入DevOps应用系统也有可能处于不一样的阶段，这形成了，CI/CD的过程随项目实际状况会有些差别。



DevOps项目在售前、招标或前期阶段，咱们一般看到是小圈里面的内容：CI/CD、自动化部署及回滚、与现有云平台的接口、流程的图形化编排调度等，但这些只是DevOps的内核，真正去落地一个DevOps项目的时候，其实你会看到外面大圈的这些内容，换句话讲，须要梳理组织整个软件生产的全过程！

姿式一：小范围CI+CD，再全公司推广



先看看Capital one的案例，美国第一资本金融公司，美国排名前十的银行。

痛点：

2014年当时，Capital One的软件开发实践和不少传统作法没有什么不一样：大量外包，瀑布模型，季度发布，手工流程，变动请求。在某次代码检查会上，你们发现一个测试失败是因为某个XML文件里的tag不配对形成的。按理说，这么小的问题改了再提交就能够了。可是：开发工做是由另一家公司负责，他们须要发起漫长的变动请求；代码修改后的构建流程（编译、测试、部署等）就须要至少2天时间。这个小小的问题让Capital One的技术团队开始反思他们的构建流程，并决定从这里下手。他们从一个小的团队开始实践DevOps，最终把时间从2天缩短到几分钟。因而，这个实践逐渐在Capital One蔓延开来，所谓星星之火，能够燎原。

2015年的成绩：

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

2016年的成绩：

发布到产品环境的频率：从每一个迭代一次到天天至少1次
自动发布的应用软件数量达20个
一个应用软件天天最多能够发布34次

总结DevOps在Capital one的落地姿式：先小范围作全套，再全公司大范围推广。



某寿险也是用的姿式一：他们是与基于Spring cloud的微服务体系架构一块儿引入DevOps的，原来的想法只是对于这些新的微服务的应用适用DevOps，通过半年的时间以后，感受还不错，就将DevOps逐步向传统单体架构的应用中去推广了。表中的系统是目前已经接入到DevOps中的系统。对接的代码库有svn/gitlab/bitbucket，介质库是Nexus，CI和CD的流程目前仍是作手工触发，CI集成了Sonar和maven test单元测试，cd已包含测试和生产环境。组件包含：springboot、shell脚本和tomcat 3类，主要是全量的部署方式。

再总结一下：先小范围适用CI+CD，它是如今微服务架构适用的，取得经验积累以后，再大范围的推广。

姿式二：先CI，后CD

咱们看看中国银行的案例



在项目之初，中国银行首先对软件生产的全流程进行了从新梳理和规划，其中包含流程、规范、度量体系和反馈机制。

在实践阶段分了三步走，研发层面的持续集成、运维层面的持续交付，最终打通研发和运维实现DevOps全流程。

从试点效果来看，单就自动化部署层面就比以前提升了2-5倍的效率。而且在软件质量和规范落实层面有了长足的进步。

再来一个以姿式二落地的，某国家政策性银行。



它的科技局下属研发中心和运行中心是分开的两个大部门，两个部门之间的纽带就是介质，但以前代码基线与生产环境的介质版本一直对不上，这对生产的BUG修复、灾备部署都造成了很大困扰，因此它的研发中心引入DevOps是但愿能造成统一的软件出口，可以将需求、代码、配置、介质控制在同一个基线上。因此他们作法是先作CI，而且并行配合maven的框架推广及CMMI4的落地实施。但项目到了二期，它要引进建行建银科技的新核心，一是新核心短期内的多版本在多个测试环境的部署，二是配合改造的69个业务系统短期内也会有不少版本要快速部署，进行集成测试，这就要求必须有自动化部署的工具才行。因此DevOps二期的重点就定在了CD，主要是配合核心及配套改造系统提测后的快速自动化部署。

因此总结一下，DevOps落地的第二个姿式：一般都是先由研发部门主导作CI，以后再推广CD，最后将两个流程串起来造成CI和CD的全流程。

姿式三：先CD，后CI



这是一家地方商业银行，也是由于今年要上新核心，而且伴随新核心，有5个系统要从新建设，110套系统要配套改造，行领导提出的目标：在9月8日上线时，利用DevOps作一键式的统一部署！因此项目一期的重点就放在了CD上，短时间目标是知足110多套系统的短时间大量版本的提测后的自动化部署，最终目标，是要将1+5+110这些系统可以可视化的一键式部署。项目的二期重点，是在CI，配合诸多研发管理的落地实施，全流程的应用和推广以及自动化测试的接入。

3.DevOps在金融行业落地的套路



套路我总结了五步：肯定目标、选好姿式、梳理全流程、制定规范、最后分步实施。咱们细看一下这五步：

第一步：肯定目标

示例一：



这是农行对于DevOps设定的目标：1个平台、可以链接开发、测试、运维3个角色，打通需求、开发、测试、部署、运维5个环节。

示例二：



咱们再看看招商银行设定的目标：DevOps是做为打造精益研发体系的一个重要组成部分。

第二步：选好姿式

第一种姿式：小范围CI+CD，以后全公司推广CI+CD ， 并打通全流程
第二种姿式：先CI，后CD，打通全流程
第三种姿式：先CD，后CI ，打通全流程

第三步：梳理全流程

示例一：



这是对一家商业银行全流程的梳理，以及DevOps须要集成的IT系统，如项目管理系统、JIRA以及测试管理系统。

示例二：




这是招商银行的全流程梳理，将DevOps平台切成了两个平台协同工做平台和持续交付流水线平台。

示例三：




以上是农行的全流程梳理方式。

第四步：制定规范

在将整个软件生产全流程梳理完以后，会很对DevOps及各原有IT系统的集成界面和分工很是清晰。接下来就要进行第四步规范的梳理和制定，规范包含哪些呢？

开发规范
持续集成规范
持续部署规范
持续交付规范
介质管理规范
文档命名规范
开发分支管理策略
测试管理规范
运维管理规范
……

那规范制定的目的是什么呢？

有效管控软件生产线上的各个活动和环节
创建统一质量和衡量标准
软件生产活动能被持续度量、反馈、优化
经过DevOps进行有效落实

简单来说，没有规范的制约，没有统一标准，你们各作各的，DevOps项目不可能成功。

第五步：分步实施

接下来，就是第五步，要具体的落地实施了，但也要有前有后，分轻重缓急。咱们建议调些试点项目来，如何来调呢，原则是啥？

DevOps试点项目的选择建议原则：

基于互联网渠道，须要快速迭代的项目
需求、产品、开发、测试、运维都在一个团队的项目
有必定脚本化或CI/CD积累的项目
基于JAVA Maven的项目

DevOps试点项目执行原则：

制定规范与试点项目执行并行，来验证规范可落地、可实施，而非空中楼阁
经过试点项目总结出相似项目推行DevOps的规定动做，如：Demo脚本、CI/CD流程、自动化测试脚本、Maven二方库和三方库的管理经验等等
DevOps与试点项目团队混编，按期举行回顾会，巩固成果，总结教训，关键——确定成绩和收获

DevOps试点项目执行的苦恼：一个巴掌拍不响：

须要坚持对目标的执念
“两口子过日子”理论

4.DevOps将软件生产线数字化



从横向角度来看，DevOps产生的数据能够分3个部分：

管理数据、开发数据和运营数据，其实这些数据是涵盖了软件生产的全过程，咱们能够经过这些数据或直播，来反哺到咱们的生产过程，优化咱们的不足。



咱们从另外一个角度DevOps的质量视图、从纵向角度来看，咱们也能够从周期、效率、治理和技术的角度来去制定指标考核。

5.总结一些DevOps最佳实践

持续集成的原则

鼓励开发人员在开发分支上频繁的提交代码，随后触发CI流程，在CI过程当中能够加入单元测试和代码质量检查等动做，这样产生代码冲突的概率会降低，而且代码质量也会提升的；
在下班以前，构建必须处于成功状态，缘由是你的代码在次日有多是其它同事开发工做的基础，如何没法保证构建成功，会影响其它的人工做质量和效率，团队氛围也会产生坏的影响；
让开发环境上快速体现最新程序包
让程序、配置、数据分离，其实如今好多的单体应用开发时，是将程序、配置、数据裹在一块儿的，改一处，要解决一堆的依赖，改一处，牵扯到不少地方都要作更新，这些下降了版本迭代的效率，而且极可能会出现遗漏
maven模式下，pom依赖尽可能不要用system本地依赖模式，而是将二方库和三方库依赖到统一的相似Nexus介质库，整个组织一份，来屏蔽本地jar依赖差别致使的编译错误。

持续集成的最佳实践

构建过程，建议等待构建的结果，不要同时作其它的事情，尤为是构建失败以后不要提交新代码，这样极可能会错上加错，最后不知道究竟是谁的错，这些错误的回溯会产生很大的成本。
提交以前在本地运行全部的提交测试
提交以前请更新本地代码，保证代码是最新的，冲突解决了，再提交
记得更新数据库、配置文件等 
等构建成功后再继续其余工做 
下班以前，构建必须处于成功状态 
以十分钟为界限，若是代码提交后构建错误，十分钟以内没法解决问题，须要将新代码撤回，不然可能会影响其它同事的工做。

自动化部署的原则

原则1：确保从开发、各种测试到生产，使用相同版本的中间件和操做系统，保证从操做系统、到补丁包、到应用运行环境基线是一致的
原则2：同一套脚本，解决各种环境的部署问题，不要试图经过脚原本解决环境的差别性，由于环境的差别性本应该是不存在的，不然改了脚本，以前的各个环境还须要作脚本的回归测试
原则3：部署以前，事先设计回滚与零停机发布的策略
原则4：全量发布优先，尽可能不要用增量发布，由于引入增量发布，就会引入手工操做，人工去选择哪些作增量
原则5：详细记录部署活动的整个过程

自动化部署的最佳实践

要作到自动化部署，要确保自动化部署的成功，最最重要的关键为：保障一致性！将要部署的各个环境一致；在各个环境执行的部署脚本一致；要部署的安装包也要一致！ 

从提测以后，全部环境运行的是同一个介质包，不要在SIT、UAT、准生产和生产等环节重复的打包
保证各个环境的操做系统、补丁和软件运行环境的基线一致；
保证使用同一的二方和三方库依赖，推荐Nexus
关于配置文件，建议: 配置文件与代码的版本保持一致 
配置项清晰、规范、统一命名
配置项模块化、且封闭
每一个配置项都是惟一的，避免顾此失彼
避免过度设计，尽可能简单
建议逐步过渡到Apollo这样的统一配置中心，以key/value的形式管理各环境的配置项

6.DevOps项目落地过程当中一些心得体会

关于DevOps项目的复杂度，我画了一个矩阵图，但愿与你们造成共鸣：



图的X轴是软件生产的全流程，Y轴是DevOps要集成的各种IT系统，Z轴是要推广的各个项目，从这个图能够看出，要作好DevOps落地，复杂度仍是至关高的。

DevOps项目落地，我本身总结了一套扁担理论：



这条扁担就是软件生产的全流程，是整个项目的骨架，须要事先梳理全流程，并打通工具链，制定各种规划和规范
扁担一头挑着自动化持续集成，各项目组件构建的调研、设计、开发、适配，从标注化到脚本化，最后自动化，并落实开发规范
扁担另外一头挑着自动化部署，各项目组件部署的调研、设计、开发、适配，从标注化到脚本化，最后自动化，并落实部署和运维规范

但DevOps项目虽然落地困难，不管从管理者层面和一线人员层面也确确实实能给金融起来带来价值：

对于管理者：

将软件生产的各个管理环节前置，尽早发现软件质量问题，从而下降缺陷的解决成本和对生产带来的影响；提升软件产品的质量
缩短软件产品的生产周期，软件产品尽早的投产使用，给业务带来价值
实现从业务需求到产品上线的里程碑管理和成本统计
实现需求、开发任务、代码之间的闭环关联

对于一线人员：

引入流程化和自动化等手段，提升软件产品的生产效率
保证环境一致性、脚本一致性、介质一致性，缩短各环境的发布部署时间
在软件产品的生产过程当中，引入标准和规范，从而规避手工操做带来的混乱和风险 

但愿你们可以经过本文，了解一些DevOps在金融行业落地的套路和最佳实践，可以找到适合本身组织的DevOps落地经验。


关于做者：八爷，普元架构师，擅长DevOps、基础架构层IaaS/PaaS/虚拟化、系统分析和架构分析；参与九江银行持续集成项目、国家开发银行CDP二期项目、中投移动办公平台项目、山东城商联盟服务治理项目咨询工做。


关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！