打造易于落地的DevOps工具链（附PPT还送新书）

Posted 2021-04-16 DBAplus社群

本文根据王青老师在〖Gdevops 2018全球敏捷运维峰会成都站〗现场演讲整理而成。

（点击“阅读原文”获取王青演讲完整PPT）

讲师介绍

王青，JFrog中国首席架构师，曾在新浪、爱奇艺、IBM、HPE、VIPKID从事研发架构和咨询工作，曾在中兴通讯、宜人贷、顺丰、易保科技等大型企业负责DevOps落地。专注于微服务架构、持续集成、持续交付、DevOps、容器化平台建设等等。

大家好，我是来自JFrog的王青，今天主要想跟大家分享一下关于传统企业如何真正落地DevOps的实践经验，首先会带大家简单看看几家传统企业实施DevOps的典型案例，再重点介绍如何使用一些工具链迈出DevOps落地的一步。

主题简介

1、DevOps现状

2、传统企业DevOps案例

3、DevOps工具链落地之路

上图是做持续交付需要掌握的工具。以前研发这一块用到的技术比较多，现在可以看到，如果要做微服务的部署，运维要掌握的技能是越来越多。这里面比较有意思的是研发与运维的博弈，如果你的运维能力跟不上，就会引起研发的吐槽，觉得你支持得不够好，他就会往后推自己的DevOps工具链，所以研发与运维之间会有博弈在这里面，是一件挺有意思的事情。

DevOps现状

从全球的角度来看DevOps的现状，上图是17年Puppet Lab发布的数据，可以看到，占最大比率的是在北美，因为硅谷这块有大量的DevOps工程师在里面，但亚洲只占到全球的10%，今年我相信这个数据肯定要大很多。

从薪资的角度来看，Stack Overflow网站做了一个统计，从全球调研了6万名工程师，排名第一的大家肯定没有想到，是DevOps专家，第二是机器学习专家。如果你是做DevOps的，那你可以给领导看一下是不是应该涨工资了。

要评价企业的IT效能，部署频率高效的是一天部署多次，低效的是一个月部署一次来算的。从代码提交到上线，这个时间概念很重要，大家可以自己内部去收集一下数据，如果是小于一小时，那就相当超前了；然后是故障恢复率，如果小于一小时，也说明是高效能的企业。

从上图可以看到，黄线是高效能的团队部署频率，从16年到17年，它的部署频率是越来越高，黑线的低效能团队则没有什么变化。但是低效能的团队从16年到17年，它部署系统的恢复时间越来越长了，这是因为现在业务压力越来越大，一次性上线的东西越来越多，交付的东西变多了，就肯定会出问题。这个数据是公开的，在网上可以搜得到。

传统企业DevOps案例

传统行业，比如说ING，是一家非常超前的公司，13年开始就做DevOps，所以DevOps不是说落地，而是一个很长时间的旅程。他们600人的研发团队，是很难管理的，13年的时候他们就是手工来做，现在完全达到了自动化的流水线交付方式。德国工业制造4.0的概念对我的影响很大，因为交付方式已经发生了变化。在工业4.0的流水线里，人与人之间是不说话的，他们怎么去协作？完全依赖系统，每个人的工作台上有一个大屏幕，屏幕会把在他前面的所有交付信息呈现出来，前面发生了什么事情、有什么需求、下一个环节要发到什么地方……所有软件工程和现实中的工业工程的理念是一样的。

上图是ING目前所用的工具，可以看到非常多编排和检查的工具，一个团队很难管理这些东西。交付方面也有不同的部署工具需要支持，这样就带来一个什么问题呢？开发团队想用的工具，运维团队支持不了，那开发就说我可能不需要运维支持了，因为申请一个Jenkins机器跑测试，到运维这边发账号过来需要一个星期，但是开发可能等不了这么长时间，所以开发会考虑自己搭一套，可能半天就搭好了。这样会导致一个什么情况？

 

每个团队自己维护自己的交付流水线、自己运维，这时运维做的事情就很被动，这个研发要这样部署，那个研发要那样部署。这样运维想从后往前推交付规范，是根本推不动的。

ING的解决方案就是，不改变开发现有的流程，还是让你去用，只不过让你来用运维团队的工具，把账号、权限等设置好，之前怎么做的还是怎么做。你可以看到这个时候运维的能力和价值就体现出来了，不光是运维你的应用，还要把前面的工具管理起来，这是运维从后往前推的成功案例。

其实研发也不愿意去管这些工具，他们每天压力很大，有问题还要每天去重启。所以运维做的这个事情是价值很大的。管理工具现在还不够，ING内部还有一个社区，他们会邀请一些团队上来做一些实践，比如说同种类型的，会给你列出来怎么做，然后其他团队来复用这个流程。这样是一种见效快、对业务改造少的方式，不管用什么语言，都用这个方式来做。他们落地这个方案，所有的服务都会统一管理。

打通整个过程也比较直接，因为这些开源工具都比较支持LDAP打通认证，它们对密钥的安全要求比较高，所有的密钥通过Vault去进行加密存储。回到公司的角度来看整个流程，每个业务团队看到的流程都是一样的，代码扫描，把这些扫描的结果放到二进制里面，再做后面的东西。银行业对这个要求比较高，他们也有一定的需求。最后总结的是，ING DevOps落地大概有4年的时间，发布频率每个月达到12000次，但是减少了50%的线上发布事故。

美国的数字化银行CapitalOne的报表工具Hygieia也是很出色的，他们的痛点也是从传统开发方式转型，用5年的时间做了这个规划，实现每天发布4次。他们有很多的测试开发，从手工测试的角度变成写case、写自动化脚本的角色。所以他们从手工部署慢慢转型变成了自动部署，也有公有云的一些服务。他们会设置很多质量关卡，比如说用Sonar进行静态分析，这个也是开源工具，像腾讯也会使用Sonar去扫每个人提交的代码。

他们开发了基于持续交付工具提供的报表，提供了软件交付生命周期里面的一些可视化页面，比如说频率、代码、从构建到上线的一些数据化的指标，都是通过这个大屏显示出来。这是开源的，大家可以去安装测试一下，也是JAVA开发的。它能收集各个工具的数据，基于这些数据做一些查询、做报表的展示。CapitalOne在5年之内实现了刚才的这些转型，所以一个银行能做到这种以社区为中心、能够推动这种自主研发能力是非常难得的。

国内一个比较大的银行最开始是用FTP管理二进制包，这样做有很多痛点，研发的部分在不同的地点，各个中心很难协同。比如说你的包比较大，那达到50Gb/s时基本就挂了，所以要经常维护。首先评估，用一个专业的工具去管理起来，还有镜像的实时分发。使用Artifactory之后，可以实现持续交付，根据环境，每个环境有一定的仓库权限。现在互联网上有大量的开源软件漏洞，公司内部要提供一个统一受监管的仓库，不是什么包都可以直接下载。

DevOps工具链落地之路

那么，怎样迈出DevOps的第一步、用一些工具去做公司内部的实践？我接下来将分享一些工具链落地的经验。

代码和需求要进行关联，关联之后才能看到需求从代码提交、需求创建、测试再到上线这个平均时间是多少，还有就是提供给运维部门包相关的信息，以前拿到这个包什么都不知道，这个包解决什么问题和需求都不确认。如果把代码提交时把需求ID带上，就可以用Jira-Jenkins插件把Jira信息收集起来。Artifactory上面会有一个记录，是可以点到一个内容上面去，同样的数据，用其他的管理工具也是可以做到的。

上图是很多大公司的痛点，公司内部有各种各样的私服，需要独立维护，配置权限、高可用、容灾备份、配置管理，同时你的部署脚本要对接各种私服，难以标准化你的CICD流水线。

 

第一步应该把这些进行统一管理，在构建的时候统一存在一个地方，这样有什么好处呢？以前需要指定版本去发包，现在可以让机器自动地找到这一次适合发包的一个最新版本。这也是工业生产线的一个概念，京东、亚马逊的物流都是机器人在送包，现在京东的无人车已经送到大学里面了。

把你的包上传到二进制仓库，如果通过单元测试，测试会收到通知，进行测试环境的验证，验证通过了，会记录通过的元数据到包上。可以手动，也可以自动化，测一些兼容性接口。很多工具的测试接口，可以把它的结果分析出来，再写到你的仓库里面。这样做之后，开发、测试及运维之间无需沟通交流。之后我们再发布到新的测试环境，模拟的一个生产环境去测试，同样这些测试的信息，手工的测试覆盖率是70%，也写在这个包上。最后运维拿到这个包，会拿到测试团队的一个评价，是不是能够上线，之后运维用自动化脚本把包放到生产环境。

这是单团队交付的一个流程，通常这个流程会配合工具来调度，这里面包含了很多自动化的步骤，当然也支持人工的步骤，很多的环境是需要人工的，比如说审批、审核测试。

 

从二进制包的角度来看，Jenkins构建的时候，应该是统一下载受信任的第三方包，不应该是从多个的文件夹/私服去拉取依赖包，保证每个人提交的时候，依赖都是一样的。避免同一个版本，有的用1.0有的用2.0。测试环节的数据都是写在交付件上的，会根据拿到的这些数据进行自动化的测试环境的发布，通过了之后，会升级到生产环境仓库，同时可以自动触发生产环境的发布，减少手工部署环节。

所以在公司内部，我们运维团队就是定义这个质量关卡。流水线落地的时候，可能研发团队不愿意配合，所有最开始的标准不能定得太高，可能覆盖率最开始只有20%，没有关系，就从20%开始。雅虎花了一年时间，把单元测试从0上升到90%。

从二进制的交付角度来看，交付流程里会记录所有的测试结果，这是流水线里的信息共享，打通研发测试信息沟通的一个屏障，打通部门墙。这个事情是很难的，但是我们可以从信息系统上去做信息的分享。前面讲的是写了很多元数据，但是怎么去消费，让机器自动化挑包来做环境部署？根据质量关卡去写部署的脚本，去帮机器过滤，让机器知道这个包应该是什么环境，而不是去向测试团队确认。

光有应用还不够，还要有环境的配置，应用相关的配置文件怎么去做到不同环境不同配置？不同测试环境的应用配置应该存在不同的代码分支里，然后在部署应用时，把这些配置文件从不同的分支拉下来，这里是通过配置中心实现统一管理。还有数据库版本化的脚本，这些脚本也是存在的，数据库的每一次变更应该变成一个版本化的变更，运维拿到这个包的时候，同样从一个分支拿到相对应的变更列表，保证每一次发布拿到的是全量的东西，包含所有变更历史，而且可以进行自动化特定版本的发布。

现在比较火的就是容器，但容器里有很多漏洞，大家会去关心容器镜像漏洞扫描，这个也是银行案例，会去做包的第三方依赖的漏洞扫描。如果没有漏洞才会推到生产环境，同样的到生产环境，他们的安全级别比较多，所以还要做第三方软件漏洞扫描，保证线上环境的安全。

 

有了配置、运维、数据库的统一化管理，可以考虑再往前面推，提供公司基本的CICD工具。这个时候一般是一个团队一个团队地落地DevOps，绝对不是强制性地去做这个事情。部分团队落地之后，不需要研发任何的改造，上来就可以看到扫描的结果，就会看到效果了。可以把这个报告发给各个业务团队的领导，他们就会知道每个团队的成熟度，会去要求研发提高代码质量。由此，运维团队的责任会越来越大，因为他们负责整个公司的流水线，而研发则越来越轻松，他们要关心的就只是业务了。

再往前走一步，当管理了所有工具之后，你的需求比较明确了，就可以自己研发一个DevOps平台。这适合研发能力比较强的企业，当然你也可以运用第三方来做，可以实现整个公司的耗时展示，可以调接口来做这个事情。然后你的研发效率是不是碰到瓶颈了，有了这个工具之后，可以进行封装。这是包含成本的，我们建议先打通工具链，确认你的研发比较平稳了再做这个设计，并不是一开始就来平台改造大量的业务交付流程，需要有一个过渡的过程。

有了这个平台之后，可以做很多想做的事情。底层的这些开源工具给你接口返回数据，你的代码平均测试通过率，可以做一个团队交付能力的画像，看看团队的交付能力是什么样的，发现了问题如何做改进。这里面可以看到，你可以定义一些曲线，曲线就是同行业的平均指标，通过这个可以看到你的企业是否达到业界平均水平。

DevOps新书相送

在本文微信订阅号（dbaplus）评论区留下关于DevOps的真知灼见，小编将在本文发布后的隔天中午12点选出留言被点赞最多的前二位，以及留言最精彩的一位读者，送出以下新书一本~

注：同一个月里，已获赠者将不可重复拿书。

特别鸣谢图灵社区为活动提供图书赞助。

想了解更多关于DevOps落地的实操案例？

JFrog中国区总经理George Hurn-Maloney

将出席2018 DAMS中国数据资产管理峰会

分享针对金融行业的DevOps实践

扫描以下二维码，可查看详情及报名↓

↓↓↓ 点这里下载本文PPT