​

一、浅析 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 能力，并在过程中不断丰富、汇总、剖析与开掘数据，为研发效力持续性晋升提供数据撑持，实现数据驱动。

​