DevOps 不等于 CI，也不等于 CI /CD

Posted 2021-04-16 twt企业IT社区

原题：DevOps实施探索

大多时候，基本上概念从国外传进来，我们也跟着炒，概念满天飞。曾经也是不懂装懂，自以为懂，不过还好逐渐学会了独立思考的能力。特别换了立场，做了甲方，成为客户，在普遍技术系统相对落后的情况下想了很多。在容器云、微服务、DevOps等快速发展变化的时候，希望借助新技术、新思想提升我们的技术能力和业务能力。

DevOps是什么？从概念上说，DevOps 是一种方法论，是一组过程、方法与系统的统称,用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。概念有了，怎么落地？很多公司在实施容器云时实现CI（Continuous Integration， 持续集成），或者CI/CD（Continuous Integration/Continuous Delivery or Deployment， 持续集成/持续交付 or 持续部署）就叫DevOps。我们觉得这只是实现DevOps的一部分，但不等于DevOps。

一、CI 不等于DevOps

CI持续集成是编码、构建的过程。容器云DevOps从CI起步，也是一个很好的切入点。但这仅仅是一个开发构建过程，都在开发端，是实现敏捷开发的一种方式，研发过程自动化，这也是我们考虑采用容器云和DevOps的一个因素。但仅有开发端的敏捷还不等于DevOps。

二、CI /CD也不等于DevOps

现在我们也总是听到一天要上线多少次多少次的。是一个应用吗？频繁上线是需求不明确还是代码质量不高？厂商在这里可能有点偷换概念。一天上线几十次几百次，肯定不是一个应用。象阿里等，那么多系统那么多应用，每天那么多的更新次数很正常。持续交付、持续部署的好处是基于自动化的过程支持。也就是开发、测试、交付部署过程工具链集成实现自动化。

但CI/CD依然没有解决开发、运维、质量保证部门之间的协作和整合。职责依然没有划分清楚。而且目前的容器云CI/CD流水线设计，不足以支撑企业生产环境部署要求。更多象是PoC概念验证阶段。这也是为什么很多公司即便采用容器云也只是在开发测试环境使用的原因。

三、我们理解的DevOps是什么？

DevOps在概念上理解其实很简单，但落地很难。很多厂商也提出要建立领导小组、委员会什么的，就是要调整企业组织结构。我们觉得这就是技术人员思维方式，理想化！组织结构的调整是大事，牵扯的利益很多，很难要求一家公司为了一个项目去调整组织架构。其实云计算已经有了一个很好的解决方案：多租户。这也是我们对多租户设计要求比较高的一个原因。

我们采用容器云的需求是：

1．提升敏捷开发能力。这是DevOps能力

2．建立开发测试甚至生产环境一致性。 这是容器云和DevOps能力。

3．实现应用全生命周期自动化管理。这是DevOps能力。

4．弹性伸缩、灰度发布等。 这是容器云和微服务的能力。

这也是我们为了适应公司互联网业务发展和应用快速迭代开发的要求，让生产端也更加敏捷起来；逐步建立标准化、一致性的开发、测试、运维环境，专注于业务应用研发而不操心资源管理；满足公司内私有云环境内的应用托管、应用开发、自动化运维等应用服务全生命周期管理需求；实现应用服务的弹性伸缩、灰度发布等能力，满足促销、秒杀等业务需求；从而逐步提升自主研发能力，促进业务创新和快速迭代。

从我们采用容器云的需求上看，前三项都是涉及DevOps能力的。DevOps要求开发、测试、运维一体化，谁开发谁运维，实现敏捷开发、敏捷部署和敏捷生产。

DevOps从计划、编码、构建，到测试、发布、部署，以及运营、监控，形成一个环路。这也是我们实施服务化或者采用微服务持续改进的要求。结合容器的搭建和微服务架构的采用，我们把DevOps分为下面几个流程：

• 持续集成，需求的不断变动触发持续的编码、构建流程。

• 持续交付，完成测试的业务应用以合适的方式交付到适当的节点。

• 部署发布，将交付的业务应用按照规则部署到生产环境，完成测试后发布。

• 持续监控，时时监控业务应用以及系统平台的运行情况，形成监控报告。

• 持续反馈，是基于监控和业务应用的使用情况，持续的数据分析，持续地提出完善意见。

• 持续改进，基于反馈的意见，启动新的改进计划流程。

这些流程的实现，需要众多工具的支持，形成一套DevOps工具链。这些流程如何落地？我们觉得可以从这些方面考虑：

（一）持续集成

持续集成阶段，考虑实现计划流程自动化、资源选择自动化、代码质量控制自动化、构建自动化等流程。借助相应的工具链，来提升对业务需求的响应能力和敏捷的开发能力。

计划流程自动化，是从最初的想法提出，或者反馈的意见建议，有自动跟踪的工具。经过可行性分析讨论，最后形成业务需求，安排开发计划。这个阶段的信息我们觉得应该对所有人开放。有人会觉得这样的话你一言我一语、乱七八糟的信息就特别多，我们反而觉得这样才能收集到真实的需求、真心的建议、真正的意见！我们有大数据平台，可以通过大数据平台来初步分析这些信息，提取有价值的想法建议，由相应的业务人员、分析人员作出初步的评估，形成初步需求，和技术分析师、业务分析师等进行评估讨论可行性、疑难点、紧迫性、资源投入、风险特性等，然后根据实际排进研发计划。计划流程使用什么工具？我们觉得Jira就是一个不错的工具，可以满足这些需求。

资源选择自动化，其实我们是考虑把人力资源做成一个资源池，或者仅仅把软件技术人员做一个人力资源池，这样可以结合Jira实现技术资源的自动化选择。同时也可以作为技术人员评估考核的一个量化依据。不过人力系统需要做点扩展，同时需要提供集成接口。

代码质量控制自动化，是实现代码质量的自动检查。编码当然还是离不开人，研发人员完成编码之后，提交到SVN或Git，可以借助于Sonar等工具来实现代码质量的自动检查。代码提交，触发代码质量检查。Sonar插件集成到IDE工具，自动实现编码质量扫描，比后期的提交之后再做扫描会更好。

构建自动化，采用容器云后就是构建镜像。在代码检查完毕，没有什么缺陷的情况下，可以自动启动构建流程，Maven或Gradle是目前比较受欢迎的工具。说起构建，一般都离不开Jenkins。它可以集成SVN或Git，JDK，Sonar，Maven等众多工具，是非常方便的构建自动化实现方式。

（二）持续交付

镜像构建完毕，上传到镜像仓库。开发工作暂告一段落，需要准备测试环境进行测试。实现自动化测试，需要实现环境准备自动化、测试用例生成自动化、质量监控自动化、交付自动化。

测试环境准备，传统测试方式是非常花费时间的事情。借助于容器云，实现开发、测试甚至生产环境一致性，提高测试的效率，提高敏捷性。我们希望通过申请，容器云构建分配测试需要的环境和资源。测试环境由QA来维护和提供，测试环境用到的基础设施资源，由运维人员来维护和提供。研发人员在此阶段专注于业务应用的测试。这里我们定义一个测试域，就是一个业务应用的范围。业务应用之间的调用测试通过虚拟接口模拟数据的方式实现，一个测试环境一次测试不会超越这个域。QA可以很明确很方便的去维护这些域环境。这样其实也和我们多租户的设计相关。不同的租户都有自己独立的明确的边界，和其他租户的交互通过标准的协议和接口实现。

测试用例生成自动化，这可能需要QA团队实现一些工具，根据业务需要自动生成测试用例数据。

测试过程中，不可避免会发现一些缺陷和漏洞，需要自动记录测试数据和异常信息，以备进一步分析。完全的质量监控自动化比较困难，结合自动测试和人工测试，自动检测和人工记录，形成测试报告。测试工具有很多种，这可能需要QA去做一些工作，比如用Jmeter测试业务服务时发现异常或缺陷，如何自动和Jira系统集成自动把缺陷信息记录。

测试完成没有问题，自动交付到生产镜像仓库。

1、镜像仓库

容器云中镜像仓库我们作为持续集成和持续交付的终点，也是开发和业务部署运营的中介、中间节点。所有的开发测试工作到此已经完全完成，所交付出来的是可以部署到生产的业务应用镜像。每个镜像备注说明，包括配置说明，部署事项，依赖关系等。

镜像仓库中的镜像需要实现镜像的自动安全扫描，确保使用的镜像是安全的。

（三）部署发布

部署首先涉及到基础设施资源，资源供给实现自动化。不同的应用可能对资源的要求不一样。就象AWS，提供了几十种不同的资源类型，不同的业务需求可以选择不同的资源类型，在容器云上也可以通过简单的标签来实现资源类型匹配，从而实现资源选择的自动化能力。

容器云还有一个重要的特性是弹性伸缩的能力，这也是我们考虑采用容器云的一个因素。弹性伸缩非常适合促销、秒杀等业务活动。我们在《容器云之弹性伸缩》中详细讨论过这一点。大部分厂商也基于CPU、Memory实现了自动弹性伸缩能力。如果能更完善，更能满足业务弹性伸缩的需求。需要说明的是，即便有自动弹性伸缩的能力，在一些促销、秒杀业务开始前，还是需要提前根据预测部署足够的实例，准备足够的备用资源。自动弹性伸缩是为了避免意外，不是为了放任不管。

业务运营过程中，会涉及到一些定时任务或批处理任务。这些工作可以通过任务调度自动化能力来实现。可以通过自动调度组件来实现，也可以通过脚本来实现。

业务运营中很重要的工作是服务治理。服务治理和服务部署也密切相关。不同的服务架构、不同的服务治理实现方式，都可能会影响到服务部署的方式。服务的路由、熔断、容错、优先级等也需要实现自动化能力。当然这部分大部分组件都已提供了相应的能力。

（四）持续监控

日志、监控是业务运营过程中判断业务运行是否正常的重要的基础能力，持续监控就是实现平台各层次的健康检查能力。包括基础设施层、平台层、应用层等。基础设施层就是我们通常所说的IaaS层，存储、网络、计算资源等。平台层是容器云平台的能力，比如Docker引擎、容器编排调度、服务发现、负载均衡等。应用层需要实现对应用的进程、使用资源（存储、计算资源等）、网络流量等进行监控检查，收集日志。

持续监控是实现日志收集、健康检查监控的自动化。

（五）持续反馈

持续反馈是基于日志和监控的基础上，实现数据分析自动化、告警自动化、反馈自动化等。日志中心对收集到的数据可以进行分析，监控中心对监控数据也需要进行分析，不只是有异常才提示、告警，其实这些数据也可以和大数据平台进行集成，使用大数据平台实现一些关联分析，从而提供更多有价值的反馈。

反馈的形式可以是简单的短信、邮件告警，也可以是分析报告。集成短信、邮件、微信、设置是Jira等系统可以实现反馈的自动化。当然在实现的时候也需要相应的过滤规则。

（六）持续改进

基于反馈的信息，继续改进应用服务。实现了业务应用的全生命周期管理。在各个阶段实现自动化，也提升了效率和响应能力。

四、开发、运维、QA之间的关系

前面说了那么多，还没有说明开发、运维和QA之间的关系。到底谁该做什么？我们认为：DevOps中，开发专注于业务应用的生命周期管理，运维专注于自动化环境资源的维护，QA专注于自动化业务运行环境的供给和质量跟踪保证。

上面我们谈到的大部分工作，其实是开发人员的职责。也就是业务应用的全生命周期的管理。也是因为运维和QA都是在做幕后的工作。运维人员主要负责资源，软硬件资源的维护，要保证应用服务整个生命周期所需的软硬件资源具备。比如运营过程中磁盘损坏的修复，主机计算资源的增删、分配等。QA则承担提供开发、测试、生产运行环境供给和测试用例自动生成，以及测试自动化、运维自动化工具研发，质量跟踪保证等职责。

五、形散神聚统一体

DevOps和容器云是相辅相成的，容器云提供基础设施资源，为DevOps的实现提供了资源基础。很便利的实现环境一致性。容器云并不包含DevOps，所以不是在容器云里实现DevOps，所以容器云中去做CI或CD流水线，是不合适的。CI应该是独立于容器云而存在的，即便不采用容器云，同样可以实现CI 或DevOps。

DevOps和容器云不是天生一体的。没有容器云DevOps也可以实现。容器云是微服务运营的一个便利的载体，微服务生命周期管理可以是DevOps的一个重要部分。容器云的架构非常适合微服务的架构。微服务的开发部署和运营又和DevOps的理念和方法论很匹配，所以采用容器云和微服务，实现DevOps，是一个很好的选择。

不管再怎么变化，人是总控，是master，需要协调定义好人在各个流程各个环节的角色和职责。DevOps也是一个不断优化、持续改进的过程。

更多相关文章，请点击阅读原文