一、关于DevOps实践的一些问题

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对组织和个人都是有非常有意义的

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

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

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

痛点：

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

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

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

某寿险也是用的姿势一：

他们是与基于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

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

姿势三：先CD，后CI

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

三、DevOps在金融行业落地的套路

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

第一步：确定目标

示例二：

第二步：选好姿势

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

第三步：梳理全流程

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

第四步：制定规范

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

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

简单来讲，没有规范的制约，没有统一标准，大家各做各的，DevOps项目不可能成功。

第五步：分步实施

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

• 制定规范与试点项目执行并行，来验证规范可落地、可实施，而非空中楼阁
• 通过试点项目总结出类似项目推行DevOps的规定动作，如：Demo脚本、CI/CD流程、自动化测试脚本、Maven二方库和三方库的管理经验等等

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

四、DevOps将软件生产线数字化

五、总结一些DevOps最佳实践

持续集成的原则

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

持续集成的最佳实践

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

自动化部署的原则

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

自动化部署的最佳实践

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

六、DevOps项目落地过程中一些心得体会

图的X轴是软件生产的全流程，Y轴是DevOps要集成的各类IT系统，Z轴是要推广的各个项目，从这个图可以看出，要做好DevOps落地，复杂度还是相当高的。

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

对于管理者：

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

对于一线人员：

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

精选提问：

答：这些我们在项目中已经积累了好多规范，并且在基本所有客户也都有自己先行的一些规范，只不过是不全面或者没有落实。我们是希望和客户一起DevOp涉及到的规范都梳理一遍，通过DevOps能过落实下去。当然这个过程也是持续规范、持续递进的过程，不太可能一下爬到珠峰顶。

关于作者

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