DevOps 的现状和痛点

如果你是公司内部希望做 DevOps 的领导或者技术负责人，那么首先要了解业界 DevOps 的趋势，我比较喜欢看各种报告，例如下面的：

这是2017年 PuppetLab 发布的报告，全球 DevOps 工程师分布的情况，首先，北美占据了54%的份额， 我去国外的招聘网站上搜索 DevOps 工程师，搜出来的职位还是蛮多的。亚洲只占有10%，所以可以预测未来2-3年之内国内的 DevOps 发展会有很大上升的空间。

这是2017年 Stack Overflow 发布的程序员平均薪资的调查报告，样本来自于全球64，000名工程师和设计师。可以看到排名第一的就是 DevOps 专家，其次是机器学习专家。那么在2018年如果你没在做机器学习，那么就去做 DevOps。

DevOps 要解决什么问题，看看大家的回答：

这是来自 Gartner 的 DevOps 报告，他们拜访了367个企业家和 IT 领导，反馈的结果如上图所示。其中比较关键的点是如何定位交付流程中的瓶颈，如何修复，如何评估团队做得好不好，如何集成 DevOps 工具链等等。

业界公司的 DevOps 实践

为了回答上面这些问题，我们看看业界比较超前的公司是怎么做的。

先看看甲骨文的 DevOps 平台，名字叫 Carson：

第一阶段，中间件团队搭建了一个 Jenkins 的集群，但这样的架构如何支持6000人的团队成为一个挑战，因为，从软件来看，一个 Slave 节点的并发连接数上线是2048，从硬件来看，网络带宽也会受到网卡带宽的瓶颈。

 第二阶段，中间件团队开始大规模使用 Carson，所以每个子部门开始有自己独立的 Master 节点和 Slave 集群，定义每个子部门的 Quota。所有的 Slave 节点均跑在容器里，按需申请，按需使用，用完即销毁。这样有什么好处？极大的提高 CI 服务器的资源利用率，来适应大规模的并发构建任务。

Carson 平台打通了整个 DevOps 工具链，从需求（Jira），开发，构建（Jenkins），到计算资源（甲骨文容器云），二进制管理（Artifactory），报表，Build Farm，Test Farm，文档，补丁系统，数据中心。实现了端到端的 DevOps 平台。

从 Carson 的架构图来看，左侧是集成的所有工具，右侧是 Carson 平台，包括编排的 Server，任务调度系统，支持可插拔能力，提供 DSL 语法去简化各种任务的编写，以及 Rest API 供 UI 模块和第三方系统调用。

其中在 Carson 系统里很重要的一个组件是消息中间件，通过消息中间件，实现对不同工具的调用，流水线的编排。Carson 的用户可以使用可视化的编排工具，通过拖拽的方式进行流水线的编排，Carson 也提供了 DSL，在编排流水线的同时进行构建产出物上传，测试结果的回写，部署集群的信息回写。

通消息的调度，加上 JenkinsFile，使得 CI 服务器能够按需的启动，并发执行任务，

如果大型公司内部考虑搭建自己的 DevOps 平台，可以参考这个架构，把 CI 服务器放在容器里进行并发构建，构建产出物存储在 Artifactory，需求 ID，Commit ID，测试结果，部署结果等信息写到 Artifactory 的仓库里。

实现了统一持续交付平台之后可以带来很多数据，这些数据是跨工具，跨平台的，这也能够解决目前工具烟囱化的痛点。

例如跨团队，跨 Slave 节点的构建，测试时长，去定位 DevOps 流程中的瓶颈。平台构建任务的平均耗时，最好/最坏的场景。

Carson 也提供了查看跨系统之间依赖关系的能力，使得复杂的系统在构建，和测试时，能够清楚的定位哪些阶段是耗时很长，哪些阶段是团队的瓶颈，用数据可视化的方式驱动更快速的持续交付。

这张图是展示的如何尽可能的做并发构建和测试。当团队使用的自动化工具越发成熟时，自动化测试的时间也会随之增加。也是得益于 Carson 将 Jenkins 跑在容器里，所有可以将 CI 任务放在不同容器里并发运行，大大减少流水线的运行时间。

得到的收益，甲骨文中间件团队内部有460条编排流水线，有515个 Slave 节点，供170+产品共享使用，每天的流水线事件有81K。

下面看看 Netflix 的案例：

 Netflix 是硅谷做 DevOps 非常超前的公司，他们也是 Artifactory 的早期用户，使用 Jenkins+Artifactory+Nebula 做构建和包管理，打出来的镜像是 AWS 的 AMI 镜像，然后使用 Spinnaker 部署到 AWS 的集群里。Spinnaker 是 Netflix 开源的部署编排工具，能够实现跨 LaaS 的部署，例如部署到 AWS，或者是 Kubernetes，Mesos 等等。Netflix 总共有500种微服务，每天实现4000的发布

业界 DevOps 的数据标准

了解了其他公司做 DevOps 的案例，来看看业界做 DevOps 的一些标准。

Grafeas 是由谷歌，JFrog，红帽，IBM 的厂商发起的 DevOps 中元数据的一套标准 API 规范，包含了包的漏洞，构建详情，镜像详情，包管理，部署历史，测试信息几个大的环节。其中，JFrog 提供了漏洞和包管理的实现。

从 Grafeas 的工作流程图来看，它是一个运行时的元数据收集系统，每个系统在执行任务时，按照约定的 API 向 Grafeas 提供数据，Grafeas 负责进行数据处理和存储。这意味着将来不论你使用什么类型的 CI/CD 工具，都能收集到统一数据格式的数据，基于这些数据可以生产报表，展示你的持续交付流程的瓶颈，从而进行持续改进。

我该怎么收集 CI/CD 中的元数据？

首先先确定收集什么数据是对你有帮助的。可以从多个维度来看这个问题，比如流程，你可能关心想法到变现的时间 TTM，故障恢复时间 MTTR，代码到上线时间 Lead Time。如果你是 PM，你可能关心 项目的质量，例如测试覆盖率，测试通过率，代码扫描结果。如果你是运维，你可能关心服务的监控，故障，告警等信息。

很多公司已经用 Artifactory 进行二进制包的存储和元数据管理。首先 Artifactory 可以管理公司内部所有类型的二进制，例如 Jar, War, Docker image, NPM, Nuget， Kubernetes Helm 等等，并且能和任意测 CI 工具集成收集包依赖关系，例如 Jenkins 和 VS Studio 上都有 Artifactory 的插件。同时可以和测试工具例如 Selenium，Sonar，Jmeter 等工具集成收集测试元数据，与 JFrog Xray 集成收集漏洞扫描数据，与部署工具集成，例如 Ansible, Salt, Puppet, Chef 等等。

持续交付的三驾马车：Jenkins + Artifactory + Ansible。流程如下：

• 程序员合并代码。

• 触发 Jenkins 构建。

• Jenkins 从 Artifactory 下载所需依赖。

• Jenkins 上传构建产出物 app.war至 Stage 仓库。

• Sonar 进行代码扫描，JUnit 进行测试，Jmeter 进行测试，且记录测试结果为 app.war 的元数据: JUnitPass=100%。

• 如果所有测试通过，自动触发 Ansible 部署 UAT 环境，并通知测试人员进行测试。

• 如果 UAT 测试通过，则自动记录 UAT=Pass 作为包的元数据，Artifactory 自动将包从 Stage 仓库升级到 Release 仓库。

• Artifactory 通知 Ansible 进行生产环境的部署。

收集后的效果如图，发布的 War 包会记录软件生命周期的所有信息，从需求，到代码，到构建，依赖关系，测试结果，部署信息。同时也提供 Rest API 供第三方系统进行数据调用。

总结

在企业中落地 DevOps 不仅需要理论支撑，还需要分析行业报告，看看业界超前公司的做法，明确要解决的问题，带来的收益，更重要的是落地一套成熟的 DevOps 工具链，配合最佳实践，规避弯路，从小项目开始试点，然后水平推广，相信通过工具链的落地结合实际项目，一定能够快速推动 DevOps 的进展，提升公司软件交付的速度和质量。