字节跳动DevOps交付流程演进之路

近年来，各企业都已在实践 DevOps 的流程、方法和工具，来提升业务价值交付的效率。不同企业的业务团队背景和基础各不相同，因此都在走自身的 DevOps 之路，往往伴随着成功的经验和失败的教训，了解和学习不同背景下的 DevOps 实践大有裨益。

2023 年 QCon 全球软件开发大会上，字节跳动效能领域技术专家姚志坤就「DevOps 交付流程与演进」这一主题分享了相关技术成果及实践经验。

内容纲要：

第一部分，概述早期字节跳动 DevOps 发展的背景，整体演进的思路和框架的设计；

第二部分，演进的初期阶段，通过围绕自动化的建设，字节快速构建起可以落地的 DevOps 流水线平台；

第三部分，深入业务后，我们探索了协同式的交付流程，并如何实施落地；

第四部分，经验回顾及我们近期探索方向。

一、演进路径和体系设计

首先我先简介一下软件交付的痛点，我相信这是很多公司都会面临的问题。

我们常见的交付痛点很多，在需求阶段有易变的问题，在开发阶段有上下文交接损耗的问题，集成阶段有环境的问题，发布阶段有阻塞的问题，总之有各种各样的坑。这些痛点往往浪费了时间、浪费了资源、也降低了交付质量。

一般来说我们会将结论归于一些交付流程的问题，譬如流程不规范、流程冗长、缺少必要的流程等等，但往往又不知道如何改进，尝试改了这个又会引入新的痛点。

而实际上，交付流程来源于一系列的现实复杂性：

第一，业务的复杂性。

软件业务本身都有探索的部分，行业方向、公司策略的变化经常发生，不可避免造成需求的易变，同时质量速度平衡的天平也是在变化中。因此我们期望交付流程适应业务变化。

第二，团队的复杂性。

我们知道，大小团队都有各式各样的人组成，能力水平和成熟度是一个变量，团队角色和分工协作方式也各不相同，因此我们期望交付流程适应团队的情况。

第三，技术的复杂性。

大部分公司是有存量技术架构、工具基础，技术栈的优劣需要考虑， Python 还是 Go 、微服务架构还是单体架构，对交付的模式都有很大的影响。因此交付流程要适配现有技术架构。

总之，交付流程需要匹配所服务的公司的现实复杂度，这是一个需要动态调整的过程。

同样，我们在字节也会面临类似的问题痛点，除此之外还有一些特点：

第一，业务规模问题。

受团队规模和业务规模影响，不同微服务应用量级到数十万 ，技术栈和服务框架种类繁多。

第二，安全问题。

技术规模大之后，安全问题会被放大，很小的疏漏能造成不小的影响。

第三，多元的业务和团队。

不同业务和团队对于交付的诉求是不一样的，公司角度也是期望业务跑得更快。

第四，工具基础。

和很多公司初期发展阶段类似，基础设施不统一，每个业务自建了定制化的工具和平台，影响使用效率。

总之，很多规模化和多样性的问题摆在面前，如何设计匹配字节跳动这样的规模化场景的交付流程就是我们的重点解决的问题。

谈一下我们主要的破解方法，就是通过开放共建的流水线体系为底座，打造业务可自定义的自动化和协同流程。

第一个关键词是开放共建，为什么需要开放共建？

一，人力有限的情况下，开放可以最大限度地利用已有工具；

二，通用的工具和关键链路的工具可以集中力量优化，比如部署工具；

三，业务可以基于自身情况定制工具，不依赖平台方排期，快速达到业务目标。

第二个关键词是业务自定义，作为架构平台要支持所有的业务，我们的定位是赋能业务，只有一线的业务自身才能定义好优实践，而自动化和可视化协同是可以将交付过程中的一些复杂问题简单化。