最佳实践：CI/CD交付模式下的运维展望丨IDCF

李洪锋启迪万众数字技术(广州)有限公司，产品研发中心-系统运维部、研发效能（DevOps）工程师（中级）课程学员

一、DevOps现状

据云计算产业联盟《中国DevOps现状调查报告2023》显示，国内DevOps 落地成熟度处于全面级 的受访企业占比高达 41.2%，具备自动化、规范化的特点；17.83% 企业的DevOps实践成熟度处于优秀级 ，具备平台化、自服务化与度量驱动改进的特点；0.85% 的企业处于卓越级，能够实现 DevOps 的高度智能化、数据化及社会化的特点。

数据来源：中国信息通信研究院

特别需要关注的是，2020-2023 年 4 年间无流水线工具企业由 26.89% 逐步下降至 19.11%；19.59% 的企业内部虽然无流水线平台，但也实现了构建、部署、测试自动化；流水线平台自动化程度由 17.11% 逐步上升至 28.16%；直接通过流水线进行生产环境交付数据由 16.30% 波动上升至 20.64%。充分说明企业正在通过流水线自动化的编排流程大幅降低交付成本，已经成为持续交付环节重要生产工具。

数据来源：中国信息通信研究院

**持续集成、单元测试、持续部署、持续发布、自动构建成为企业在持续交付域提升开发效能的主要方向。**从数据反馈显示占比分别为 45.78%、40.40%、34.94%、32.58%、 32.14%。

数据来源：中国信息通信研究院

综上所述，为灵活应对快速变化的业务需求和日益复杂的市场环境，快速提升交付高质量软件或服务的能力，强化组织、技术、流程的结合，加快推动企业数字化转型，一个具备效能度量和质量管控的CI/CD工具链平台是团队生产能力稳步提升的基石，是IT组织"降本增效"的底座，其重要性不言而喻。

二、CI/CD能力级别

持续集成和持续交付(Continuous Integration &Continuous Delivery，CI/CD)：以自动化方式，持续地完成软件产品和服务的构建与集成、测试、部署等过程，维持随时可以交付软件产品并发布上线运行的状态。

持续集成和持续交付是 DevOps 产品研发模式最为重要的能力和核心特征之一，是缩短从代码提交到发布上线的周期时间的关键。围绕价值交付 的核心，构建可度量、可延续、可优化、可追踪的工具化自动化交付工具链路，通过DevOps产品研发交付模式，以度量管理过程，以反馈检查优化，最终达到效能和质量的提升。

参考GB/T 42560-2023国家标准《系统与软件工程开发运维一体化能力成熟度模型》，结合实际情况，进行分级别、分阶段的CI/CD能力建设。

|---------|-------------------|----------------|------------------------------------------------------------------------------------------------------------------|
| 等级1 | CI/CD 1.1 | 1.1.1.建设目标 | 在 DevOps 流程开展 CI/CD 活动。 |
| 等级1 | CI/CD 1.1 | 1.1.1.建设目标 | 搭建 CI/CD 的环境，以自动或者半自动方式开展 CI/CD 实践。 |
| 等级2 | CI/CD 2.1 | 2.1.1.建设目标 | 建立 CI/CD 实践标准和规范，并保持更新。 |
| 等级2 | CI/CD 2.1 | 2.1.1.建设目标 | 标准先行，帮助研发团队规范构建与集成活动。 |
| 等级2 | CI/CD 2.1 | 2.1.2.典型活动 | 梳理现有 CI/CD 规范标准； |
| 等级2 | CI/CD 2.1 | 2.1.2.典型活动 | 梳理现有 CI/CD 工具平台； |
| 等级2 | CI/CD 2.1 | 2.1.2.典型活动 | 确认 CI/CD 现状及问题； |
| 等级2 | CI/CD 2.1 | 2.1.2.典型活动 | 定义并发布 CI/CD 工程规范和分级标准。 |
| 等级2 | CI/CD 2.2 | 2.2.1.建设目标 | 建设自动化系统以支持 CI/CD 实践。 |
| 等级2 | CI/CD 2.2 | 2.2.1.建设目标 | 持续建设、集成整合 CI/CD 实践所涉及的多个系统，包括但不限于：代管理(配置管理)系统、代码检查系统、编译构建系统、制品管理系统、自动化测试系统、部署变更系统、自动化流水线系统等，能够促进CI/CD 能力的提升。 |
| 等级2 | CI/CD 2.2 | 2.2.2.典型活动 | 建设代码管理(配置管理)与变更评审系统； |
| 等级2 | CI/CD 2.2 | 2.2.2.典型活动 | 建设代码质量检测系统； |
| 等级2 | CI/CD 2.2 | 2.2.2.典型活动 | 建设编译构建系统； |
| 等级2 | CI/CD 2.2 | 2.2.2.典型活动 | 建设制品管理系统； |
| 等级2 | CI/CD 2.2 | 2.2.2.典型活动 | 建设自动化测试系统； |
| 等级2 | CI/CD 2.2 | 2.2.2.典型活动 | 建设部署变更系统； |
| 等级2 | CI/CD 2.2 | 2.2.2.典型活动 | 建设自动化流水线系统。 |
| 等级2 | CI/CD 2.3 | 2.3.1.建设目标 | 依据标准规范，基于自动化系统在开发和交付中实现 CI/CD。 |
| 等级2 | CI/CD 2.3 | 2.3.1.建设目标 | 统一标准且用统一的系统平台落地实施标准，能够保证标准能够被有效执行，也能够加快标准推广实施的速度。 |
| 等级2 | CI/CD 2.3 | 2.3.2.典型活动 | 按照 CI/CD 规范标准使用系统平台开展 CI/CD 实践。 |
| 等级3 | CI/CD 3.1 | 3.1.1建设目标 | 在组织标准的研发过程中融入 CI/CD 实践。 |
| 等级3 | CI/CD 3.1 | 3.1.1建设目标 | 把 CI/CD 与研发过程的其他环节相结合，在研发流程中内嵌 CI/CD 实践，使得 CI/CD 成为研发流应执行的环节。且 CI实践宜在研发流程中多次执行，以保证研发流程各阶段的质量，保证软件持续保持在随时可以发布的状态。 |
| 等级3 | CI/CD 3.1 | 3.1.2.典型活动 | 本地开发时随时 CI； |
| 等级3 | CI/CD 3.1 | 3.1.2.典型活动 | 代码提交至中央仓库前自动触发 CI |
| 等级3 | CI/CD 3.1 | 3.1.2.典型活动 | 分支合并前自动触发 CI； |
| 等级3 | CI/CD 3.1 | 3.1.2.典型活动 | 分支合并后自动触发 CI； |
| 等级3 | CI/CD 3.1 | 3.1.2.典型活动 | CI 应通过后才能触发CD |
| 等级3 | CI/CD 3.2 | 3.2.1.建设目标 | 设定 CI/CD 准入标准。 |
| 等级3 | CI/CD 3.2 | 3.2.1.建设目标 | 在项目进展过程中持续丰富 CI/CD内的检查项，不断提高 CI/CD 准入标准，进而提升软件产品或服务的质量。 |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加单元测试，并设置质量门禁； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加代码规范检查，并设置质量门禁 |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加代码安全检查，并设置质量门禁 |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加代码缺陷检查，并设置质量门禁 |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加代码可维护性检查，并设置质量门禁、圈复杂度、注释率； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加代码重复度检查，并设置质量门禁； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加 P0自动化回归测试，并设置质量门禁； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加测试环境部署，开发人员可以自测功能； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加自动化回归测试，并设置质量门禁； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加制品安全扫描，并设置质量门禁； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加全量源码安全扫描，并设置质量门禁； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加服务安全扫描，并设置质量门禁； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加多种自动化测试类型，并设置质量门禁，如性能测试、压力测试、稳定性测试、异常测试、隐私合规测试、系统兼容性测试等； |
| 等级3 | CI/CD 3.2 | 3.2.2.典型活动 | 增加制品包管理规范，并设置质量门禁。 |
| 等级3 | CI/CD 3.3 | 3.3.1.建设目标 | 定期审视 CI/CD 过程和实践，提升工作效率 |
| 等级3 | CI/CD 3.3 | 3.3.1.建设目标 | 解决 CI/CD 检查项增加所带来的自动化任务执行时间长、消耗资源多、系统不稳定等问题，以提升CI/CD自动化效率，保障软件开发的速度和质量 |
| 等级3 | CI/CD 3.3 | 3.3.2.典型活动 | 审视当前 CI/CD 过程和实践； |
| 等级3 | CI/CD 3.3 | 3.3.2.典型活动 | 持续提升 CI/CD自动化效率。 |
| 等级3 | CI/CD 3.4 | 3.4.1.建设目标 | 定位CI/CD 失败问题并加以解决。 |
| 等级3 | CI/CD 3.4 | 3.4.1.建设目标 | 运用各种技术、方法和工具，在 CI/CD 自动化任务失败的时候,快速定位和解决问题。 |
| 等级3 | CI/CD 3.4 | 3.4.2.典型活动 | 区分并定义 CI/CD 失败问题类型。例如是程序问题还是 CI/CD 平台问题。 |
| 等级3 | CI/CD 3.4 | 3.4.2.典型活动 | CI/CD 任务失败及时有效通知相关人员。及时：例如通过即时通信工具发送消息；有效：例如自动分析问题根因并告知相关人员。 |
| 等级3 | CI/CD 3.4 | 3.4.2.典型活动 | 建设自动化构建系统。例如解决问题后可以不用完全重新执行整条流水。而是可以选择继续执行上次失败的流水线。 |
| 等级4 | CI/CD 4.1 | 4.1.1.建设目标 | 使用统计和其他量化手段管理 CI/CD 过程。 |
| 等级4 | CI/CD 4.1 | 4.1.1.建设目标 | 开展CI/CD 效能度量，通过数据驱动 CI/CD 能力的持续提升应用统计方法找出CI/CD 过程瓶颈或问题并加以解决。 |
| 等级4 | CI/CD 4.1 | 4.1.2.典型活动 | 建立研发大数据仓库，对接 CI/CD 平台，收集研发过程数据； |
| 等级4 | CI/CD 4.1 | 4.1.2.典型活动 | 根据 CI/CD 标准，制定度量实践过程和结果的指标； |
| 等级4 | CI/CD 4.1 | 4.1.2.典型活动 | 基于研发大数据仓库，开发度量指标并可视化； |
| 等级4 | CI/CD 4.1 | 4.1.2.典型活动 | 深入分析度量数据，持续运营 CI/CD 优秀实践。 |

三、CI/CD运维展望

CI/CD可实现更快的迭代速度、更高的软件质量和更高效的团队协作。同时CI/CD对运维发展和转变呈现以下趋势和方向：

自动化程度的加深：随着技术的进步，CI/CD流程中的自动化不仅限于构建和部署，还扩展到了测试、配置管理、监控、日志分析等多个方面。自动化工具和平台的集成能力不断提升，减少人工干预，实现从代码提交到生产环境部署的端到端自动化。
智能化运维（AIOps）：结合人工智能和机器学习技术，AIOps能够自动分析海量运维数据，预测故障、优化资源分配、自动处理常见问题，从而提高运维效率和系统的稳定性。CI/CD流程与AIOps的融合，使得运维更加智能化、主动化。
安全性集成：安全不再是事后考虑，而是被嵌入到整个CI/CD流程中，即DevSecOps，包括静态代码分析、动态应用安全测试、依赖项扫描等安全检查，确保每次部署都是经过安全验证的，减少安全漏洞的风险。
容器化与微服务：容器技术和微服务架构的普及，极大促进了CI/CD的发展。容器标准化了应用的打包和部署，微服务则让系统更易于维护和快速迭代，两者结合使得CI/CD流程更加灵活高效。
可观测性和监控：随着系统复杂性的增加，集成强大的可观测性和监控工具变得至关重要。这些工具能够提供实时的性能数据、异常检测和故障定位功能，确保快速响应问题，优化用户体验。
文化与流程的变革：CI/CD不仅仅是技术的变革，更是文化和流程的转变。强调跨职能团队的合作，鼓励持续学习和实验文化，以及建立快速反馈和迭代的机制，是CI/CD成功实施的关键。

以可观测性工程和可靠性工程为例：

可观测性工程

基于CI/CD的可观测性工程是确保软件系统稳定运行、及时发现并解决问题的重要实践。可观测性工程关注于通过收集、分析和展示系统的指标、日志和跟踪数据，能够帮助团队在快速迭代的同时，保持对系统健康状况的精确掌握。体现在以下几个关键点：

集成监控工具：在CI/CD流水线中集成监控和日志管理工具（如Prometheus、Grafana、ELK Stack等），确保新部署的服务或应用能够自动接入监控体系，及时生成并上报监控数据。
日志与跟踪：配置应用以在每个CI/CD阶段生成详细的日志，包括构建、测试、部署等环节。利用分布式跟踪技术（如OpenTracing、OpenTelemetry）捕获服务间调用的完整链路，便于问题追踪和性能瓶颈分析。
健康检查与就绪检查：在部署阶段自动执行健康检查和就绪检查，确保服务部署后即刻可被正确监控，并能迅速响应健康状态查询。这些检查可以是简单的HTTP请求，也可以是更复杂的逻辑判断。
性能与负载测试：将性能测试和压力测试作为CI/CD的一部分，确保新版本在高负载下仍能稳定运行。通过工具（如JMeter、LoadRunner、Gatling）模拟真实用户场景，提前发现性能瓶颈。
指标与阈值设定：定义关键性能指标（KPIs）和业务指标（如响应时间、成功率、吞吐量），并在监控系统中设定合理的报警阈值。当指标超出预设范围时，自动触发告警，及时通知相关人员。
持续反馈与优化：建立闭环反馈机制，收集监控数据，分析部署后性能变化和用户反馈，定期回顾并优化CI/CD流程和可观测性策略，不断提升系统的稳定性和运维效率。

通过将可观测性工程深度融入CI/CD流程，团队可以更快地发现并解决问题，减少故障影响，同时提高开发和运维的效率，为持续交付高质量的软件产品奠定坚实的基础。

可靠性工程

基于CI/CD的可靠性工程是一种集成方法，旨在通过自动化和最佳实践确保软件系统在整个开发生命周期中的稳定性和可靠性。可靠性工程不仅关注于避免故障的发生，还包括了快速检测、隔离和恢复故障的能力。在CI/CD流程中实施可靠性工程主要涉及以下几个方面：

自动化测试：在CI/CD流程中实施全面的自动化测试策略，包括单元测试、集成测试、端到端测试和性能测试，确保代码变更不会引入新的错误或降低系统稳定性。
持续监控与日志管理：集成监控工具和日志管理系统，实现实时监控应用程序性能、资源使用情况和异常行为。这包括配置警报系统，以便在关键指标偏离正常范围时立即通知团队。
混沌工程：通过混沌实验（如使用Chaos Toolkit、Gremlin等工具）故意引入故障，模拟真实世界中可能发生的各种故障场景，以评估系统的健壮性和恢复能力，并据此优化架构和配置。
蓝绿部署/金丝雀发布：利用CI/CD工具支持的部署策略，如蓝绿部署或金丝雀发布，能够在不影响现有用户的情况下逐步推出新版本，快速回滚以减少故障影响范围。
自愈能力：设计系统具备自我检测和自我修复能力，如自动重启故障服务、资源自动扩展、熔断机制等，减少人工干预，提高系统的稳定性。
安全性集成：在CI/CD管道中集成安全扫描和漏洞检测，确保每次部署都经过安全审查，实现DevSecOps，提高系统的安全性，这也是可靠性的重要组成部分。
故障恢复演练：定期进行故障恢复演练，验证灾难恢复计划的有效性，确保团队成员熟悉紧急情况下的操作流程，提高应对突发事件的能力。
性能与稳定性测试：在部署前进行性能和稳定性测试，模拟高负载情况，确保系统在预期的最大负载下仍能稳定运行，优化资源配置，防止性能瓶颈。
持续反馈与改进：建立一个反馈循环，收集生产环境中的数据和用户反馈，分析系统性能和稳定性，持续优化开发流程、测试策略和基础设施配置。

基于CI/CD的可靠性工程不仅增强了软件的可靠性，还缩短了故障恢复时间，提高了团队对复杂系统的管理能力，为用户提供更加稳定可靠的产品和服务。

四、总结

基于CI/CD的运维正朝着更加自动化、智能化、安全和高效的方向发展，在提升软件交付的质量和速度的同时拓宽了运维的技术视野，呈现出前所未有的广度和深度。未来的CI/CD下的运维将更加智能化、自动化、安全和可持续，以支持企业更快地创新，更稳定地运行，提高运维效率，降低运维成本，进一步提升软件交付的效率，最终提升业务价值和业务竞争力。

参考文献：

1\] GB/T 42560-2023 《系统与软件工程 开发运维一体化能力成熟度模型》，国家标准化管理委员会 \[2\]《2023年企业数字化转型技术发展趋势研究报告》，中国信通院 \[3\]《中国 DevOps 现状调查报告2023》，云计算产业联盟 \[4\]《DevOps IT 效能新基建》，顾黄亮