【工程实践思考】百度DevOps提高之道

本文做者：francisk84

我是百度工程效能部资深敏捷教练--金锐，也是百度 DevOps 解决方案的运营负责人。从今天开始，我将在 开发者中心 经过一系列的文章，为你们分享百度在软件工程领域的思考和实践。今天我先从百度工程效能部对提高百度软件工程能力的实践和思考介绍开始:

 

什么是工程能力

 

工程是科学和数学的某种应用，经过这一应用，使天然界的物质和能源的特性可以经过各类结构、机器、产品、系统和过程，是以最短的时间和最少的人力、物力作出高效、可靠且对人类有用的东西。 --百度百科

上述定义摘自百度百科，从这里咱们能够看到，广义的工程能力定义很宽泛，涵盖了软件，建筑，机械生产等多个行业。当我在讲百度的工程能力的时候，我更多提到的时百度的软件工程能力，下面是几年前公司内部一次会议上，公司领导层对软件工程能力与公司业务竞争力的阐述:

 

百度如何看待软件工程能力

百度是一家技术公司，研发工程能力的高低直接影响公司的持久创新力和公司在市场上的做为。只有不懈追求卓越的工程能力，才可以带来长期的核心竞争力，才能为每一个用户、每一个企业客户以及整个社会创造价值。

百度软件研发体量
百度内部有多个业务形态万千，团队规模不一样的产品线，下面一系列数据出自 2018 年工程效能部的数据统计：

从数据上能够看到，平均每一个工程师天天要进行 3 次构建；执行 7 次以上的流水线；平均每一个披萨团队，天天要进行一次服务的发布。并且在这些数据的背后，是 10000 多名有着强烈的自驱意识，敢于不断尝新的软件工程师。所以对于百度工程效能部来讲，提高百度工程能力，是一件挑战巨大的系统性工程。

 

百度工程能力的发展历程

百度工程能力的发展历程，大体经历了三个阶段, 分别是:

- 以瀑布式和 CMMI 标准为研发模型的阶段
- 以敏捷开发为主要研发模型的阶段
- 全面拥抱 DevOps，云计算和 AI 的阶段

在每一个阶段，百度在软件工程领域要解决的问题和面临的挑战各异，下面我来简单介绍一下:

瀑布式和 CMMI 阶段

在这个阶段，百度在软件工程领域要解决的首要问题是: 百度的软件研发管理对象是什么？对象之间的关系是什么？一个标准的，符合规范的研发流程是什么样的?

如今回顾起来，咱们很是感谢那个时代工程效能部门的同事，为咱们后续的管理奠基了坚实的基础，具体规范以下图：

从这张图上能够看到，咱们当时定义了几个最基础的元素:

- 最小的可发布代码集合--模块，以及代码和业务的对应关系--产品线
- 服务发布的版本关系: 线上版本和测试版本
- 围绕发布进行的一系列研发过程管理: 项目

当时的一切软件研发工做，是围绕着模块级别发布进行的: 每个项目在启动的时候，RD（开发工程师）会从当前模块基于线上的 3 位版本拉一条分支，创建一个新的 4 位版本；当开发完成后，RD 经过一个叫作"提测"的动做将构建产物传递给 QA（测试工程师）, QA 在测试过程当中发现的 BUG 会记录在当前的 4 位版本上，RD 修正后从新生成一个 4 位版本号再次交付 QA 直至最终测试完成，模块发布上线后，更新三位版本号，作为下一次拉取分支的基线。这样的流程也很好的支持了当时百度的主营业务--核心搜索。

 

敏捷开发阶段

时间前进到 2012 年，随时互联网思惟的普及，更重要的是，移动互联网时代的到来，咱们发现: 当时百度的软件研发效率跟不上市场竞争的需求了。2012 年 8 月，咱们作过一个统计，当时百度单个模块的发布周期平均值是 21 天，而当时小米号称每周迭代。所以，当时咱们要解决的首要问题是如何缩短模块的发布周期。

基于这个目标，咱们引入的敏捷开发的概念，弱化项目的概念，强调产品的迭代。同时将原有的工具按照研发的不一样阶段，拆分红三个独立的产品: 负责项目和产品管理的 icafe，负责代码和协同开发的 icode，负责持续交付的 ipipe，造成了目前研发工具链的雏形。咱们也创建了百度的敏捷教练团队，引入了一批又一批业界优秀的软件工程人才，将敏捷开发的理念带入到产品线中。如今 DevOps 和敏捷圈中的各路英才，有至关一部分都曾经在百度工程效能部任职

通过 4 年的努力，截止 2016 年，咱们将百度的模块发布周期从 21 天，缩短到不到 6 天的样子。敏捷开发已经成为百度的主流研发模式，95%的模块从 SVN 迁移到了更加适应互联网研发模式的 GIT 上，咱们发布了百度内部的研发方法论专辑: 百度方法+。

反思这个阶段，咱们发现：

- 虽然总体的交付周期缩短了，可是团队的交付能力并无特别明显的提高
- 一部分团队在专家实施改进并撤出以后，出现了不一样程度上的倒退
- 公司内部平台林立，技术上重复造轮子的现象严重

同时，DevOps，云计算，AI 成为主流的技术，咱们面临着更大的挑战:

 

百度工程能力的提高策略

前面铺垫了这么多的内容，终于进入到咱们今天要讲述的内容主体: 当云成为主流 IT 架构，以模型训练为表明的 AI 开发兴起，DevOps 成为软件研发的主流思想时，百度工程效能部如何继续带动百度工程能力的提高。

关于总体提高的策略，咱们能够用下面一张图来表示：

 

能力策略--人

首先，咱们来看一下人的方面，工程能力提高的根本仍是人（工程师）自己的工程素养提高。即便咱们有好的流程、方法和开发工具，若是开发者自己的能力和工程素养不够的话，工程效率也会很是低。

为了提高工程师的工程素养和工程能力，咱们作了一些实践。例如招聘时，咱们必定招优秀的工程师。新人入职以后，咱们会为新同窗提供工程师能力培养和文化建设的工做坊，这也咱们一直在作的事情。工程师入职后，会有“码神训练营”，这个训练营除了介绍编码的规范及开发流程、工程实践以外，还会让你们在工具平台上实际操做，自主开发一个示例产品，促进你们在短期内了解百度工程开发的流程和规范，创建工程规范意识。除此以外，公司内还有不少培养工程师文化的项目，好比 Hackathon ，还有 Good coder、Excellent Coder 认证等。

 

提高策略--数据篇

和 16 年之前最大的变化是，咱们将**数据**也归入了总体的提高策略中。
在 DevOps 的理念中，有一个很是重要的核心理念: 创建反馈闭环。咱们认为在软件研发过程当中，从 RD 天天的拉取分支--coding--提交代码，到模块测试--系统测试，最终到服务发布，产品更新。都应该创建不一样的闭环，而在每一个闭环中产生的数据，应该以最高的时效性反馈给研发/测试/运维人员。而且不断的引导用户去使用数据，信任数据，最终经过数据的驱动实现团队工程能力的不断提高。

而在以往，这些数据在生产出来以后便被束之高阁，只有在按期汇报的时候才被拿出来使用，为了改变这个现状，咱们首先明确了百度软件研发的一系列闭环：

从上面的图中能够看到，在咱们的治理思路中，整个软件研发的过程被划分红 4 个闭环：

- 开发闭环: 起始于 RD 创建 Feature Branch，终结于分支合入当前的 release branch，开发闭环持续时间以天为单位，一般是 1-3 天
- 迭代闭环: 起始于每周的开发计划更新，终结于当前的 release branch 经过验收测试，迭代闭环持续时间以天为单位，一般是 5-10 天(1-2 周)
- 项目闭环: 起始于一个 release plan 的启动，终结于当前的服务/产品上线后业务数据的 review，其中对于一部分产品来说，项目闭环=迭代闭环；而对于移动端开发来说，一个项目闭环包括了多个迭代闭环。项目闭环以周为单位，一般是 1-3 周。
- 产品闭环: 结合 OKR 或业务阶段性目标，起始于目标的拆解和制订，终结于阶段性业务目标的 review。产品闭环的周期比较长，每每以月为单位。

 

在以上闭环中，咱们认为下列数据是须要被相关人员关注并使用的：

 

- 开发闭环: 代码冲突；CodeStyle；代码漏洞；CodeReivew 的反馈；单元测试的结果，覆盖率；模块测试的结果，覆盖率；流水线执行结果；流水线执行时长；需求的开发进展；PM(产品经理)功能验收的结论，没错，在百度咱们提倡产品经理对每个用户故事进行验收，而不是对迭代进行验收。
- 迭代闭环: 分支的集成进展；系统测试结论；非功能性测试结论；测试中发现的 BUG 以及修复进展；团队的迭代速率；
- 项目闭环: 线下 BUG 的修复进展；系统测试结论；非功能性测试结论；研发进度的累积图；线上服务的稳定性；上线后的业务效果；上线后用户的反馈；回顾会议的结论；
- 产品闭环: 阶段性业务效果；产品下阶段的规划；技术下阶段的规划；团队交付的散点图；团队工程能力地图；

这么多的数据，咱们是如何将其一一呈如今整个研发团队的视野中的呢？这就离不开工具的贡献了: 咱们在 17 年，自建了研发数据仓库，前面提到几大研发工具平台: icafe, icode, ipipe，以前是每一个产品保存本身的数据，建了数据仓库以后，咱们将数据如下面示意图的形式组织在一块儿，造成了从需求到发布的完整研发数据链：

另外，除了这些基础数据以外，有大量的测试结果，覆盖率数据是如何被记录下来的呢？这就得益于持续交付平台 ipipe 的插件式架构设计：

百度内部有几十个不一样类型的测试，发布，环境管理工具。为了让百度内部的用户更好的使用这些插件，iPipe 平台改善了底层的架构设计，使这些工具能够经过简单的改造接入 iPipe。作为改造的一部分，这些工具须要经过统一的数据格式将本身生产的研发数据导入到研发数据仓库。这样，研发和测试人员只须要关心本身的平常工做，而数据很天然的就保留了下来。

接下来，数据是怎样应用的呢？首先最频繁的应用在流水线的执行结果中：

这是我在内部代码库提交的一次提交记录, 在图中看到咱们配置了一条简单的流水线，只分为编译和测试两个阶段，如今展现的是编译阶段的全部 job。如图所示，用户能够很是直观的在流水线上看到每一个 JOB 的执行结果。一旦有错误发生，iPipe 会经过邮件，即时通信工具向用户推送消息。同时，在展现结果的同时，QA,RD 也能很是方便的观察每一个阶段的执行时长，方便流水线的优化。

除了在流水线中应用，咱们根据产品，团队，工程师的不一样维度，将数据概括整理:

产品维度：工程能力地图

这即是工程能力地图的主页面，如图所示: 工程能力地图以产品线(多个代码库)为维度，按照不一样技术类型(Server, App, SDK)的代码库分类, 将产品线在整个研发过程当中对管理，技术实践的采纳状况进行记录和评分，而全部的记录都来源于插件的数据录入。也能够说，页面上每个色块中的实践，背后都对应着一个标准的实践工具。数据天天进行更新，而产品线的研发经理，测试经理，研发总监根据工程能力地图上数据的变化趋势便可了解本身团队工程能力的改进进展。在百度内部，大多数产品线在创建本身 DevOps 实施目标时，已经将地图上得分的提高作为重要参考。

 

团队维度：交付周期散点图

 

交付周期散点图显示的是一个团度随着时间的推移，交付周期的变化趋势。怎样解读这张图表呢？横轴是时间轴，纵轴是交付周期(天为单位)，图表上的每个点都表明了一张需求卡片(统计粒度可自选)从创建到上线的确切时间流逝。从这张图上，咱们能够解读到如下信息：

- 交付周期的标准差: 在图上用浅蓝色阴影显示，阴影面积越小，表明该团队的交付周期越稳定，可预测性越高
- 交付周期中位数的移动趋势: 在图上用绿色的曲线代替，该曲线表明了交付中位数的变化趋势，曲线越走低，表明交付周期的不断缩短
- 团队的交付模式: 这个解读颇有意思，从上面的图咱们能够看到，在 5 月 19 日以前，该团队进行了屡次不断的发布，能够认为是在持续的交付价值；可是到了 7 月 19 号以后，咱们会发现交付周期较长的项目/需求开始出现，发布的时间点相对集中，能够认为团队在 5 月到 7 月集中作了几个大型的功能，并在 7 月下旬进行了集中的发布

 

工程师维度：工程师我的画像

 

如图，这是展现在代码托管平台 iCode 上的某位内部工程师的研发活动数据，上半部分表示了该工程师的提交频次，每次的代码提交量；下半部分的数听说明了具体的量化信息。这个图表是和咱们内部所提倡的工程师文化是密切相关的。什么是百度工程师在工程方面应该作的事情，那就是持续的提交代码，而且积极参与代码的评审工做。每次工程师在申请晋级的时候，技术委员会会直接查看该工程师的这个页面，并作为晋级的重要参考。咱们常常说，是牛 X 的工程师就把我的页面亮出来。

能力策略--技术篇

平台化治理

为了解决前文提到的技术重复造轮子问题，提高技术的复用，咱们也进行了百度内部的平台的建设和治理

平台建设包括平台复用和源码复用这两方面。在平台复用方面，咱们梳理出公司内部的几百个平台，将这些平台划分红若干个类别，每一个类别都成立一个 TOC 组织来负责规划这类平台将来的发展。发展的目标就是让这类平台可用性增强、复用度提升，让平台自己的能力加强，以便让每一个业务方可以更快速地使用平台去搭建本身的业务，提升工程效能。

 

内部开源

上面介绍平台复用会带来一个问题：若是多数平台逐渐收敛成少数平台后，许多需求都会涌向这些平台，会致使平台研发团队不能按时、高质量完成全部的需求，从而使研发效率降低。那么咱们怎么在平台化的基础上去作更好的工程复用呢？

那就是源码复用。在代码管理平台（iCode）上，咱们作了内部开源功能。在平台化治理的过程当中，平台是否可以达标，有一个考察点是它能不能实现内部开源。若是一个平台的 API 已经对外开放，而且又作到了内部开源可以让其余团队贡献代码协做开发，咱们才认为它是一个优秀的内部平台。

 

C++的依赖治理

百度 C/C++模块开发采用跨模块依赖的形式，其中 97%为固定版本依赖(表现为 Depend on TAG 和 Depend on BRANCH:VERSION 两种形式，本文统一使用 Depend on TAG 表示)。固定版本依赖会致使严重的版本碎片化问题，两年前咱们作过一个统计: 百度 top 200 的基础库，在用的大约 5000 多个版本。

版本碎片化问题背后，是严重的技术债务: 维护基础库的同窗很难保证不一样版本间代码的兼容性，业务方为规避版本不兼容的问题不肯意升级依赖模块版本，致使基础模块发布新版本后，三个月内只有十分之一不到的团队主动升级。如此一来，一方面在基础库维护上浪费了大量没必要要的人力，另外一方面，大量的业务线也没有办法享受基础库升级带来的好处。

参考 Google 的 Head 依赖模式，即全部的类库引用方，都直接引用类库的 head 标签。考虑到咱们内部改造的成本和业务方的稳定性，咱们决定推出 stable 模式--即每一个类库维护一个 stable 标签，全部的引用方都来引用 stable 标签，基础库的维护团队将基础库的更新发布到 stable 标签上，这样保证了基础库的稳定性，也极大的收敛了基础库的版本数量，减轻了团队负担。

百度工程能力的标准产出
百度 DevOps 产品解决方案--百度效率云

2019 年 5 月, 咱们正式将百度内部的研发工具链对外输出，成为百度智能云的子产品，并命名为百度效率云。效率云包括内部的三大平台(iCafe, iCode, iPipe)，并与智能云上的容器引擎，微服务平台一块儿，支持云原生 DevOps 的场景。目前产品处于免费试用阶段，欢迎你们试用

百度效率云首页

百度工程师手册

以上就是关于百度工程能力提高的介绍，欢迎你们提出建议和意见。

 

对于云原生 DevOps，AI 服务开发感兴趣的同窗，能够关注"效率云官方公众号"，咱们会按期发布产品的最新动态, 以及百度工程实践的思考和经验

再次感谢你们对百度软件工程技术的关注

 

 

==========================

本篇文章转载自:"百度效率云官方公众号"

欢迎搜索关注

 

原文连接地址：https://developer.baidu.com/topic/show/290270