​

一、浅析 DevOps

互联网的发展形同潮水，来势汹汹、快而迅猛，企业业务日益庞大的同时伴随着团队规模的扩大，业务的复杂度与关联性显著提升的同时对效能也有了更高的要求，高效协同之间，我们既要追求快速交付，亦要保证产品的质量与稳定，两者之间产生了矛盾。DevOps 作为这个矛盾平衡点，其概念最早于 2009 年被提出，并在近几年受到企业广泛的关注与实践。促使 DevOps 近年高频出现的原因，我们总结出以下两点：

传统研发模式下的运维之痛。以往的研发模式经历了瀑布式开发、敏捷开发两个阶段，前者严格按照“本阶段完成、下阶段开启”的形式，过程风险大、后期出成果，研发追求改变、运维追求稳定，双方筑起一道信息及信任的壁垒；后者虽然不再拘泥于各阶段的严格、完整执行，且更注重快速改变的能力与阶段性成果的展现，但是其对环境资源利用、人为流程处理、测试质量与自动化，以及过程中需要保证的固定消耗等所涉及到的浪费与瓶颈缺少有效的处理与升级。传统研发模式在效率与资源利用率上表现出了自身的欠缺。

图 1：传统研发模式演进

微服务、容器技术等的配套发展所提供的技术支撑。微服务架构下，对应用程序进行解耦，成为相互独立并协调配合的服务组，避免重复开发，具备轻量级通信及易扩展的特点，研发独立负责各自功能模块的全流程处理；容器技术基于虚拟化，解决了应用程序对操作系统的依赖，在操作系统之上划分多“运行环境”，隔离环境减少相互间影响，占用资源更少、部署速度更快。

​图 2：容器技术演进

DevOps 便是在这些背景下应运而生，那么究竟什么是 DevOps？我们先来看下维基百科给到其的定义：“DevOps 是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。”人们通过概念也衍生出形形色色的解读，然而 DevOps 的定义并没有标准答案，它不是一个标准化产品，企业不同，DevOps 亦不同，DevOps 代表着企业的生产文化，关乎企业的基础设施、生产流程、工具和自动化，它是一家企业成熟的必然产物。

本文接下来将结合数栈产研近两年遇到的研发效能问题分享下数栈 DevOps 建设实践。

二、数栈 DevOps 由来

作为企业数字化转型基础设施平台，为满足各行业客户的需求，数栈需要不断地更新迭代，业务和架构也随之日益复杂。业务量持续增加的同时，团队规模也在日渐扩大，流程制约和异地协同等影响产研效能的问题因此逐渐浮现。提升产研效能、确保产品质量，对实现快速交付至关重要。

经过近几年的快速发展，数栈产品体系已具备离线开发、实时开发、数据服务、数据资产、数据质量、智能算法、智能标签、指标管理 8 大产品，随着数字化转型进程的推进，新的产品线仍在持续孵化，数栈更是于 2021 年下半年完成了超过 80 次的需求迭代。

为确保研发效能和产品质量，数栈制定了完善的研发流程规约，覆盖代码分支规范、开发规范、提测流程、提测标准、封板标准、发布标准、缺陷管理标准等诸多方面，然而流程规范大多依赖人的执行力，且执行结果无法标准化，部分流程规范落地困难，过程中不断涌出新的问题与挑战，迫使我们尽快制定对策、引入并落地数栈 DevOps。

数栈研发流程规约

​图 3：数栈研发流程

如图所示，开发在接到需求后进入研发工作，研发完成经由 Gitlab 提交代码并完成联调自测，自测通过后于禅道发起提测单，测试人员将利用 Jenkins 进行环境的构建与部署，并完成一系列测试与结果的反馈，测试通过后利用 Jenkins 完成产品打包，并利用数栈部署平台完成部署上线，由测试完成上线后的自动化回归并产出测试报告，最后运维人员会在数栈运管平台及配置中心维护相应的产品包及配置。

整体流程其实已经比较清晰与规范，但不难看出其中较为明显的问题，以及全流程涉及到的 6 个平台之间的协作很难形成标准化串联，多数环节过于依赖人为主观处理，断层比较严重，流程细节处也存在不少隐藏问题：

1. 研发环境不隔离

不同产品开发过程中换包、调试相互影响，研发环境不稳；

2、自动化能力复用率低

数栈当前有现成的自动化能力，但是无法被各类角色、在多个环节轻松复用，自动化需要人为与其他流程进行衔接，呈现出“半自动化”状态，未有效发挥出其最大的价值；

3. 工具多，存在使用门槛

老人操作繁复、新人/异地团队上手困难，需要反复宣导，各角色对于彼此的工具也不甚熟悉，并且多个工具在整个研发流程的各个节点行为割裂，完全依赖人为主观串联，流程多而杂、连贯性差、整体效率低下；

4. 数据分散不透明

迭代流程数据分散在各自平台，不完整且不完全透明，需要人为收集整合与对比分析，在关心功能实现之余，需要额外分散精力汇总数据且易遗漏，不但增加人工成本，其问题暴露难、流程优化难的情况也未得到便捷有效的改善；

5. 历史基础设施包袱

数栈发展至今，衍生出的基础设施如代码管理、需求管理、构建管理、配置管理、环境管理、质量管理、部署管理等，都是从能力的角度独立建设，存在孤岛问题，其中配置管理、部署管理采用了自研系统，需求管理和质量管理对开源系统做了二次开发。市面上成熟的 DevOps 平台往往集成了部分能力系统，对企业自研的能力系统一般无法兼容，这就对我们直接采购成熟 DevOps 平台或产品形成了制约。

​图 4：数栈产研基础设施发展图

数栈产研部在总结以上问题之后，最终决定自研数栈 DevOps 去帮助更好的解决现有的问题，降低学习成本、释放部分人力、提高产研质量、提升交付效率。

下面我们将对数栈 DevOps 的实践经历进行展开分享。

三、数栈 DevOps 实践

1. 能力平台建设

​图 5：数栈 DevOps 功能架构图

从架构图中可以看到，数栈 DevOps 规划集成目前正在投产中的部署管家、测试平台、Jenkins、Gitlab、运维管理、配置中心、禅道等平台，根据平台进行能力集成与插件开发，通过能力集成需要在平台中灵活配置流程流水线。基于相关事件的自动捕获或人为手动触发运行的形式，平台将根据配置顺序依次执行各阶段流程，例如自动化测试阶段中的“构建 - 部署 - 自动化测试”流程，无需像以往人为逐个执行。

​图 6：能力集成

数栈 DevOps 经过一系列探索与实践将研发和运维的壁垒破除于平台之上，提升了二者间衔接效率和可控性。但实现这一效果其间还有一个不可忽略的角色——测试。数栈测试团队将自动化测试与数栈 DevOps 深度融合，实现测试左移、测试右移，降本增效的同时让产品问题尽早暴露、更早解决，时刻关注线上稳定运行，从各个节点严格把控数栈产品的质量。

数栈 DevOps 通过集成上述多样化能力，串联多平台工具，以此呈现上下游连贯的执行关系，确定好规范与标准，将以往的人为依赖更多转化为自动化处理，提升了执行效率，同时平台也更好的实现了自动化测试能力的复用，降低了员工对工具的学习成本及对专业角色的依赖。

2. 流水线能力建设

在数栈 DevOps 平台上可根据项目分别进行流水线管理，可配置适应企业内部不同部门、不同产品线的研发流程流水线。可以自主在流水线上定义不同阶段，如开发阶段、测试阶段等，用来详细描述整条研发流程，实现阶段的规范有序、多次可持续执行能力，通过增设阶段卡点、绿色通道，增强关键环节的约束力。下面结合具体场景，给大家讲述一下数栈 DevOps 实践。

3. 实践场景

实践场景一：0-1 产品包自动化测试

如上文所述，2021 年下半年数栈产品线做了超过 80 次的产品迭代，每次迭代流程包括了开发阶段、测试阶段、制品阶段、发布阶段等，打包人员在制品阶段打产品包，该产品包可以通过自研部署平台 EasyManager 进行部署、升级。在原有的打包流程里，打包人员打完产品包，流程就结束了，运维同学直接取产品包到环境部署，这个过程存在两个问题：

◽ 打包之后未对产品包执行测试，产品包本身可能存在质量问题；

◽ 应用的初始化 sql（全量 sql）未经过测试，可能存在质量问题。

​图 7：原有打包流程

为解决这两个问题，打包人员利用数栈 DevOps 平台的流程能力，联合测试进行流程共创，把产品包制作和产品包自动化测试配置到一个流水线里，实现产品包 0-1 的自动化测试，打包人员通过这个流水实现打包和产品包测试自动化，新的流程如图所示：

​图 8：优化后打包流程

为了在数栈 DevOps 平台上配置这个流程，打包人员确定需要集成的能力为产品包制作能力、部署能力和自动化测试能力，能力分布情况为：

产品包制作能力：打包人员基于 Jenkins 建设了自动化打包工程

部署能力：自研部署管家 EasyManager 具备部署产品包的能力

自动化测试能力：测试团队基于 Jenkins 建设了完善的自动化测试工程

在数栈 DevOps 平台配置流水的过程即是能力集成的过程，能力集成通过插件开发表达，在 0-1 产品包自动化测试试点里，根据需要集成的能力，开发了 Jenkins 打包、Jenkins 自动化测试和 EasyManager 部署插件，插件面向能力开发且可以不断复用，插件在数栈 DevOps 平台导入后成为可以配置流水线的动作卡片，添加动作卡片和卡片编辑如图所示:

​图 9：添加动作卡片和卡片编辑

​

图 10：流水配置结果

打包人员通过操作这个流水实现打包和产品包测试自动化，这样可以提前发现打包质量和产品包质量问题。这个试点充分复用了现有能力和自动化成果，数栈 DevOps 平台通过开放的插件机制实现了流程可视化创建，并可以按照配置的流程调用工具链工具，帮助打包人员在一个平台上完成了出包和包自测工作。

实践场景二：开发环境隔离

研发阶段作为整个软件产品的源头，是修复问题成本最低的阶段，那么对于开发而言，一个稳定可独立自测的环境就显得尤为重要了，如果这个环境只和本次迭代需求有关，那就有了可以自动化检测和设立质量门禁的切入点。

目前在数栈中，开发环境是根据大版本分成了多套，经常会出现后端在排障，其他服务访问时“卡住了”的情况，开发共用这多套环境，只能通过人为主观判断是否联调自测通过之后再移交至测试阶段。

那么下面一起来看看在数栈 DevOps 平台中，我们是如何解决这个问题的，下图是开发环境隔离示例：

 图 11：开发环境隔离示例

确定环境隔离的粒度。这个隔离环境和迭代需求有关，迭代需求涉及的变更服务要有自己的隔离环境，而没有变更的服务则可以共用基础环境，解决方案是在添加流水线实例或者启动迭代时指定本次涉及变更的服务。一次以需求出发的环境隔离在数栈 DevOps 平台上表达为一条研发流水线实例。

​

图 12：启动实例选择变更服务

动态拉起变更服务。这个在数栈 DevOps 平台上是内建的 CD 能力。整个数栈按照大版本分成了多套环境，这里同样也要对应拉起多套基准环境，环境除了服务本身外，还有一系列的运维属性。

数栈 DevOps 平台集成了基于 OAM 实现的 KubeVela，作为平台内建的面向 Kubernetes 的 CD 模块。在数栈 DevOps 平台上定义服务时会关联自定义的 ComponentDefinition，定义环境时会关联相应的运维属性，创建流水线时绑定相应的环境，创建流水线实例时选择变更的服务，流水线实例运行时拉起相应的 Application。我们发现，需求也是存在依赖链路的，比如离线应用的需求，涉及到公共服务的改造，需要设置好本次需求下发生变更的服务，新需求拉起新的 Application，新 Application 对外暴露新的域名，且其服务都会有一个 VirtualService，新 Application 拉起的服务（pod）发往基准环境的请求会转向自己，用新域名访问的即是只跟本次需求相关的隔离环境。

四、数栈 DevOps 展望

​

数栈 DevOps 是对整体流程中各个环节、各个角色的规范化建设与合理约束，为团队制定严格化标准提供流程保障和数据支撑。数栈 DevOps 也是一个短期性“试错”和长期性完善的过程，内部的流程标准需要我们持续去充实它、完善它，并逐步把流程标准沉淀到统一的数栈 DevOps 平台上。目前我们已经实现流程的可视化配置，并且可以按照配置流程调用现有的工具链和功能平台，接下来需要不断的跟开发、测试、运维等角色进行共创，帮助各个角色更高效的完成工作，在这个过程中不断迭代、持续优化。

多数工作都不可能一劳永逸，DevOps 亦然。结合不同部门、不同角色的效能诉求，不断集成和沉淀 DevOps 能力，并在过程中不断丰富、汇总、分析与挖掘数据，为研发效能持续性提升提供数据支撑，实现数据驱动。

​