In recent years, enterprises have been practicing DevOps processes, methods and tools to improve the efficiency of business value delivery. The business teams of different companies have different backgrounds and foundations, so they are all on their own DevOps path, often accompanied by successful experience and failure lessons. Understanding and learning DevOps practices in different contexts is of great benefit.
At the 2023 QCon Global Software Development Conference, Yao Zhikun, a technical expert in the performance field of ByteDance, shared relevant technical achievements and practical experience on the topic of "DevOps delivery process and evolution".
Content outline:
The first part outlines the background of the development of early ByteDance DevOps, the overall evolution of ideas and the design of the framework;
The second part is the initial stage of evolution. Through the construction around automation, Byte quickly builds a DevOps pipeline platform that can be implemented;
In the third part, after in-depth business, we explored the collaborative delivery process and how to implement it;
The fourth part, experience review and our recent exploration direction.
1. Evolution path and system design
First of all, let me briefly introduce the pain points of software delivery. I believe this is a problem that many companies will face.
We have many common delivery pain points, such as variability in the requirements phase, context handover loss in the development phase, environmental issues in the integration phase, and blocking issues in the release phase. In short, there are various pitfalls. These pain points often waste time, waste resources, and reduce the quality of delivery.
Generally speaking, we will attribute the conclusion to some problems in the delivery process, such as irregular process, lengthy process, lack of necessary process, etc., but we often don’t know how to improve it. Trying to change this will introduce new pain points.
In fact, the delivery process comes from a series of real-world complexities:
First, the complexity of the business.
The software business itself has an exploratory part. Changes in the direction of the industry and company strategies occur frequently, inevitably resulting in variable demand. At the same time, the balance of quality and speed is also changing. So we expect the delivery process to adapt to business changes.
Second, the complexity of the team.
We know that teams big and small are made up of a variety of people, that capability level and maturity are variables, and that team roles and collaborations vary, so we expect the delivery process to adapt to the team.
Third, the complexity of technology.
Most companies have an existing technical architecture and tool foundation, and the advantages and disadvantages of the technology stack need to be considered. Whether Python or Go, microservice architecture or monolithic architecture has a great impact on the delivery model. Therefore, the delivery process should be adapted to the existing technical architecture.
In short, the delivery process needs to match the real complexity of the company it serves, which is a process that requires dynamic adjustment.
Similarly, we will face similar problems and pain points in Byte, in addition to some other features:
First, the issue of business scale.
Affected by the size of the team and the scale of the business, different microservices can be applied in the order of hundreds of thousands, and there are various types of technology stacks and service frameworks.
Second, security issues.
When the scale of technology is large, security issues will be magnified, and small omissions can cause considerable impact.
Third, diverse businesses and teams.
Different businesses and teams have different requirements for delivery, and the company also expects the business to run faster.
Fourth, the tool base.
Similar to the initial development stage of many companies, the infrastructure is not unified, and each business has built its own customized tools and platforms, which affects the efficiency of use.
In short, many problems of scale and diversity lie ahead, and how to design a delivery process that matches a large-scale scenario like ByteDance is our key problem to be solved.
Let’s talk about our main cracking method, which is to use the open and co-built pipeline system as the base to create business-customizable automation and collaborative processes.
The first keyword is openness and co-construction . Why is openness and co-construction needed?
First, in the case of limited manpower, openness can maximize the use of existing tools;
Second, common tools and key link tools can be optimized intensively, such as deployment tools;
Third, the business can customize tools based on its own situation, without relying on the platform's scheduling, and quickly achieve business goals.
The second keyword is business customization . As an architecture platform, we must support all businesses. Our positioning is to empower businesses. Only the front-line business itself can define good practices, and automation and visual collaboration can integrate the delivery process. Simplify some complex issues.
Therefore, from the concept map of the solution, there are three layers from bottom to top, corresponding to different target levels. The lowest level points represent atomic capabilities, such as requirements, development, and testing fields, to achieve single-point automation and efficiency improvement; the middle level is connected in series through pipeline links to improve the efficiency of the entire link; the upper level is further integrated on the pipeline , through unified view management, to achieve synergy and improve efficiency.
在最上层的典型业务场景中，有一些交付特点，比如 ToC 业务，要敢于试错，常用 A/B 实验小流量，保障基本的质量，能快速地交付需求。而商业类业务如广告，则需要控制资损，需要更严格的交付验收标准。
中台业务支持很多上层业务，需要有统一的升级节奏支持不同的业务线。也就是说，各业务接口人会根据自身情况，在标准的交付流程框架下定义研发流程和规范，并落地。
而在业务场景之下，我们提供了 3 套基础的交付流程框架：自动化为特点的单服务流水线、协同视图为特点的需求交付模式和版本火车模式。三者分别提供从灵活多样到协调一致的方案。除此之外，效能度量、安全管控、开放共建的方案也需要支撑业务落地。
第三层就是平台层了，我们自建了一个以流水线为核心的效能平台，通过标准的对接系统，流水线的标准化、原子服务的标准化、变量参数的标准化，对接了字节的各种基建能力，包含需求、开发、测试、发布等领域的工具和平台。
这是今天主要介绍的，三套主流交付流程解决方案，介绍一部分特点和业务逻辑，单应用的流水线交付，协同的两套模式。
当然，这样一套体系也不是一次性完成的。这是我们实际的演进节奏，主要分成 3 个阶段。
第一阶段，我们在 2019 年及之前是在做流水线基建部分，建设了标准的环境系统、版本和发布的能力，也就是说早期是在做标准化的工作，基本完成了有能够支持业务使用的最基础的 CICD 流程。在那个阶段，字节业务需要的是基本的流水线能力，替换自建的一些开源工具，提升稳定性和可用性。
第二阶段，从 2020 年开始，我们发力提升开放能力，因此业务的自建工具纷纷接入进来，随着生态的扩大，越来越多的业务在流水线系统上固化自动化的流程。在那个阶段，字节业务高速发展并直面大规模的用户增长， QA 团队纷纷建立起来，也急需开放式的工具链使得业务跑得更快。
第三阶段，就是 2021 年后，随着字节业务进入质量效率并重的阶段，业务的角色分工进一步加强，加上一些 ToB 业务的启动需要更规范的流程。协同场景被提出探索和构建起来，开始满足团队管理的一些诉求。
二、自动化
自动化在软件开发中是属于入手不难，做好却不容易的主题。
我这样分析自动化和交付流程之间的底层逻辑：我们做软件工程最基础的要求，无非就是效率、质量、可持续维护和迭代。而现在流行的持续集成、持续交付、精益 DevOps 这些理念都有一个共同的关键词，那就是自动化，比如说持续集成，强调频繁的自动化，持续交付强调可靠可重复的流水线，精益关注过程损耗、流动效率，人工和自动化能有机结合。
所以自动化提效的典型路径方案有 3 种：
一、提升单点的自动化效率，尽量让人工的过程自动化，频繁地跑起来。
二、建设自动化工具链，单点的自动化能串起来，形成规模效应。
三，更进一步，因为软件开发还是有很多人工决策的部分，现在还没有办法自动化的，需要和我们的自动化流程结合起来，避免一会儿线下操作，一会儿再跑流水线，也就是说，让我们人工活动和自动化的协作更加顺畅丝滑。
最后的落地就是通过这样一个能力丰富的、高可用的、交互顺畅的流水线了。
这是字节最常用流水线交付类型，以单个微服务为维度，用两条流水线分别对应需求开发分支和发布主干分支。分支策略其实就是分支开发、主干发布的双分支模式。
为什么双分支模式会成为字节的主流？因为字节大部分微服务拆的比较细，维护人员不多，通常在 2 到 7 人。双分支并不需要特别复杂的设计，特性分支和发布分支各承担一部分的测试职责。当然比较极限的主干开发主干发布也是存在的，毕竟在字节跳动，个人维护的微服务不少，也能通过流程编辑出来，而三分支或者 GitFlow 之类在字节的服务端并不常见，分支的复杂性需要额外的管理成本来处理。
如图上的三套流程，需求过程通常不在流水线上，需求开始、环境、拉分支等活动仍然是由线下完成。从研发提交特性分支开始，实际进入了持续集成的流水线，也就是特性分支流水线，下面都是比较常规的代码检测、个人环境、提测等过程。而到了发布阶段，是由研发发起主干 MR 开始，然后执行回归测试，直到线上小流量，灰度，线上监控阶段。
下面说到流水线原子服务，我们的方案特点就是自定义。流水线需要保证自动化的“车同轨”，有三大功能点支持自定义。
第一个就是 API 和 Hook 能力。
在此之上，我们的业务可以支持这些场景，将流水线集成到聊天机器人中，定制一些便捷的自动触发和自动通知的能力。
第二个是原子服务的市场。
通过这个开放性的市场，我们的业务可以定制自己的自动化能力，调用自己专用的工具和平台，通过这个市场，也可以找到类似的原子能力，多个业务共建，同时，将一个内部平台的能力抽象为一个原子，在其他业务或整个公司推广。我们的原子服务覆盖了多个阶段，比如能在需求领域流转状态，在代码领域自动做合码做 rebase 等等。
第三个是模版市场。
通过模版市场，自动化的流程可以在多个业务复制，也可以在一个业务线起到规范团队流程的作用，也就是说，虽然流水线是业务线自由编排的，但针对某个业务团队来说，流程编排仍然是可以统一的，做到规范落地。
再说一下变量系统，如果说流水线是“车同轨”，那么，强大的变量系统是“书同文”。原子服务、流水线和团队的模式就是靠变量系统做的数据交换。首先变量系统是标准化的，其次，也提供了一些扩展的能力。
变量系统主要有 3 种相对标准化的数据交换范围：原子服务的变量，流水线的变量，团队流程的变量。它们分别可以实现分支信息、版本信息、产物传递、团队分支规则、门禁参数等等。
同时我们也赋予变量一定可编程的能力，就像我们我们日常生活中的各种转接插头，很方便地将数据格式做一些转换，适配不同的原子能力的输入输出。
再介绍一下决策节点，流水线和变量是车同轨书同文，那么决策节点是必要的关卡和中转站。众所周知，软件研发的生产过程还有相当的手工活，没有人参与的自动化是不完整的，我们这边有很多对决策能力的支持。
分为两种类型，第一种是各种人工卡点和门禁，第二种是选择器和逻辑决策。
人工卡点比较好理解，诸如审批、提测节点之类，用于批准后续的执行；而选择器是一种逻辑判断，在流水线中实现逻辑分叉。
当我们需要根据变更代码的覆盖率，走不同的决策流程时，比如覆盖率低时，我们认为需要人工介入，覆盖率高时能自动通过，那么可以在选择器中编辑一行 if 逻辑，系统会自动决策下一步的流程。
而在另一个场景下，我们传统流水线设计中可能有常规流程和紧急流程，常规流程和紧急流程可能在不同的流程中，中间必然存在着一些沟通成本、维护成本，而通过选择器可以合二为一，我们通过流程发起时就可以在每个阶段固化哪些原子必须做哪些是可以跳过的。
有了决策节点后，流水线看上去会变长，但实际的效率却是更高了。省去了很多线下沟通的成本，清晰地刻画流程了。而有了一些开放能力的加持，字节的流水线可以做非常丰富的功能性的扩展。
一方面，自动化建设得好，强大的自定义能力，覆盖几乎所有的交付场景，复杂场景有上百节点。另一方面，繁荣生态，覆盖了需求到监控的能力，上千的开发者和原子。
然后进化为自动化不是免费的，自由也有代价。前期我们对标准化的投入，对于自动化的维护，稳定性、治理都是必要的。从稳定性来说，流水线的稳定性逻辑是这个样子的， 10 个节点的可用性 99.9%， 原子能力串在一起，可用性就成 99%，何况并不是所有的原子都能到 99.9%，实际落地的时候自动化流水线就需要确保这些基础投入，才能保证持续可用。
三、以价值流为主线的协同模式
关于协同，不得不先提一下价值流的概念。
我画的这个图叫价值的漏斗过程，揭示了人力在流程阶段中一步一步增值和损耗的过程。人力投入像一个水龙头一样流入到价值漏斗，我们有很多过程阶段，我们在每个阶段都有价值产出，要从用户的诉求出发提炼出用户痛点，设计方案，代码编译，验证，让业务流量；人不是机器，一定会有损耗，错误的决策容易造成很大的资源浪费。这些在每个阶段的损耗看似很小，但是整体会做乘法，就难以忽视了。甚至所有人的努力可能在一个阶段完全流尽，完全体现不出价值，比如在产品需求和用户诉求南辕北辙的情况下。
在这个过程中，有很多人、很多的事、很多的产出物，我们在研发过程中就是面对这些，也容易迷失掉重点，每个人都在忙，以为很高效，实际并没有产出价值。因此我们认为过程管理需要识别软件开发到底交付的价值是什么，以什么为中心进行交付活动的组织。
面向我们交付的内容，可以形成一个中心的价值产出，那么围绕这个价值产出，我们做协同是有效的。比如开发测试阶段，我们围绕的价值产出是代码。而如果是开发到运维，代码是不够的，就需要变更我们围绕着的这个价值产出。更大的协同中心就是业务需求，或者 ToB 领域的直接交付。
因此以价值流为主线的协同，我们需要识别出协同的核心是什么，并且协同的范围越大，我们越需要一致的节奏和模式，人越多，越需要劲往一处使，这是我们的理念和底层逻辑。
实际实践角度来看，我们的协同层次有代码、需求、版本，就好比单车、拼车、火车，单车就是研发灵活交付一个代码，没有什么复杂的协作，完成交付。拼车就是业务需求，需要很多角色共同参与推进。火车就是版本式的交付，限定了一个时间或者交付需求的范围，大家赶车，交付最终的价值产出。
下面讲解我们的需求全流程模式和火车模式。
这是我们以需求为中心的协作方案概念图。
这种协作也是分支开发主干发布，特点是提供一个需求的视图，来管理一个完整需求端到端的研发活动，并提供聚合能力，方便业务使用。
在需求模式下，交付物的核心是业务需求，流转的建模有这么几个部分：多个微服务的变更版本记录、多配置的变更、过程质量的数据、发布依赖的编排。说一下发布依赖的概念，在微服务场景下，单个需求并不是对应单个的微服务，为了上线某个业务需求，需要多个微服务发布，但微服务的依赖在实操过程中很难做到完全绝对的前后兼容，所以研发在上线过程中期望能够按照既定的顺序发布多个微服务。
略微不同于我们日常在需求管理平台如 Jira 管理的需求工作流程，传统的需求管理平台，主力用户其实是产品经理，并不是研发的工程师，而且很多时候，要求工程师操作需求流转状态其实并没有那么好落地、或者说达到预定的效果。这个需求协同研发模式则更倾向于工程开发角色的流程视角，从开始开发时，这么多角色如何在一个协同流程里协作，研发人员真正花在这个需求上的活动将被整合进来，并与需求平台能打通信息。
对于业务团队来说，他们的需求是并行交付的，研发人员工作在需求的流程中，每个需求分为固定的几个阶段，阶段间提供一些准入准出条件，阶段内业务可以自定义一些流水线或者工具来使用，可视化过程。
在字节落地时，适合很多 ToC 业务和一些全职能特性团队，比较契合持续交付的理念，对于这些业务来说，大部分情况下，需要根据市场变化，持续地交付一个个独立的功能点，这些功能点同时涉及到多个后端的微服务，随时并行开发、独立地测试和上线。通过协同也降低同一个需求下的多个开发独立上线测试带来的协调成本，敏捷程度刚刚好。
上图是一个业务的需求全流程的典型设计方案，需求会被划分为几类，不同的需求等级定了了不同的流程，通过这样，复杂的需求可以准备地更充分，而简单的需求可以更快地交付。
再介绍一下火车模式，如果说需求全流程的协同范围仅仅限于单个业务需求。那么火车模式就是版本式多个需求的协同。借鉴了火车的概念，简单来说，普通研发人员的研发活动类比为一个凭票上车的动作，而 QA 、安全、发布人员更像检票员，或者是自动化的门禁。大量微服务的开发、测试、发布在发布火车中被分开了，大量的变更统一地进行提测、集成和发布，做到有节奏的按批次交付。
通常来说，火车主要适配的是分支开发分支发布的模式，在需求模式的基础上，扩展了多需求的维度。因此，在交付物建模时，引入了一个车票的概念，定义一个不可分割的交付物，一个车票可以绑定了多个需求、多个应用版本、多个配置类型的变更。一个车票下的交付内容统一上车，如果出问题统一下车。
在概念图中，火车发布在一个团队通常是串行的，每趟火车分为集成、冻结和部署阶段，分别对应一些研发活动。
火车模式比较适合较大协作范围，或者影响面较大的团队。在一些 ToB 类型的业务线，或者整体业务模式比较重的团队适用，比如中台类型的业务。火车并不是说很慢的模式，它是一个更高效的模式，按单个需求交付的不确定性被约束了，对于大团队和重要业务来说，不可控的交付才真正可怕。
这是我们主要的分支策略，是一个比较常规的三分支模型。分支合码的操作和火车的阶段做了映射。版本火车的好处是，通过一致性的规范提升整体的效率。同样，火车更需要多个微服务的依赖发布，并且在需要合规审查的发布中，大量微服务一起发布的优势更明显。
字节跳动的协同模式介绍完了，说一下做落地。为什么协作模式是需要落地对接的呢？其实像这样的协作流程，相对于自动化流水线来说，难度是比较高的。两者都定义了很多角色和规范，只提供了有限的灵活度，对业务的现有流程大概率是有影响的，那么不匹配的流程和工具设计怎么适配，是业务流程改还是平台支持？就需要专家角色来判断，因此落地需要有对接有策略。
而我们在字节的落地推广方式是一个分工分步的模式，在组织层面，有 4 个角色，一线研发 QA 、业务 POC 接口人、平台解决方案 SA 、平台产研，这是一个典型的 ToB 的对接方式。业务 POC 是负责定义业务的流程，对一线人员负责，解决方案 SA 则解决业务 POC 的诉求、提供方案建议，并和 POC 一起做到一线的落地推广工作。
在流程层面，流程改进遵循这 4 步:
第一，平台产研一定要自己吃狗粮，解决基础的问题；
第二，树立试点和标杆，通常选择收益最大的小组或难度最高的小组，快速突破业务痛点，产出有信服力的最佳实践；
第三，大业务推广，和大型业务接口人立项推进，做好培训、配置、尤其注意流程和体验优化等工作；
第四，长尾业务运营，例行解决一些推进过程中的定制化需求。
当然好的理念和工具并不一定能够落地，还需要考虑“天时”、“地利”、“人和”。
天时讲的是时机，例如一些内部事件如事故复盘，或者团队外部的事件和流程要求，还有业务架构或组织架构的变动，需要确定一套新交付流程和协作模式的时候。
地利讲的是收益，要有一定的势能，确保实施的自动化基础都已经具备，另外随着协同交付流程的落地，业务的收益大于实施成本。
人和讲的是各个角色的支持，整体要有信心，自上而下，影响团队决策层，明确收益和计划，自下而上，做好一线的布道和培训。
在内部落地，最讲究的是天时，作为业务和技术负责人来说，识别出团队交付流程的问题是一方面，更重要的是抓住合适的时机，在正确的时候做正确的事，达到事半功倍的效果。
四、总结与探索方向
看一下成果的总结，字节目前来看服务端交付流程的比例，基于应用的流水线模式占大头，需求交付的模式次之，版本模式最小，属于金字塔式的分布，从这点来看是比较符合现状，近 50% 的团队完成了存量 CICD 流水线的模式，已经进入强协同的模式。从单个团队的分析来看，从流水线的模式切换到强协同的模式，一些主要指标都有改善，包括交付周期、回滚率、测试左移等等。
不管是自动化，还是协同等方面，字节 DevOps 解决方案还有很多领域要探索，例如通过 GitOps 声明式的方式管理大团队的研发模式、客户端和服务端的协同方案等等，仍然有很多实际的问题要解决。
最后这里有几个经验沉淀点做一下总结。
一是自动化优先，如果你不知道如何改善交付流程，做自动化是永远考虑的选项之一，单点的自动化、自动化链路、人工过程线上化等等。
二是梳理团队价值流做协同流程改进，尤其团队业务复杂时有助于理清主线，当然有条件的可以平台化。
三是推广落地讲究天时、地利、人和，不管是自动化、协同流程落地，均需考虑好时机、收益和团队角色的配合。