百度王一男： DevOps 的前提是拆掉业务-开发-测试-运维中间的三面墙

由数人云、优维科技、中生代社区联合发起的

系列 Meetup 《 DevOps&SRE 超越传统运维之道》

先后在深圳、北京举行过两场

7 月 15 日上海站，敬请期待

▼

王一男老师在《 DevOps&SRE 超越传统运维之道·北京站》活动中，结合百度的实践，讲述落地 DevOps 时，首先要拆掉业务→开发→测试→运维中间的这三面墙，一起来看一下吧！

数人云友情提示：前方全文约 9000 字，且不含标点符号~建议先收藏~

效率=工具+方法+实践的结合

最近有一篇比较火的文章大概说 DevOps 不是工具的堆砌。现在出现一种概念：将研发流程自动化就是 DevOps，个人不敢苟同。在百度内，研发效率的提升除了工具之外，更多是这些工具与方法以及一些实践的结合，来共同支撑研发效率的提升。

再往前一步，在一个大版本开发的闭环中，产品如何更好地管理、需求如何更好的确定，百度也总结了一些比较好的实践。这些实践一般都方法和工具的集合，同时在实际项目中，将其落地实践，最后归纳总结并分享出来。所以并不是仅有工具就能把所有事情都做好，但没有工具也很难做到。

任何事情想要达成，都依赖于人、方法和工具的结合。

任发科老师也提到：最好不要做一个大而全的工具。之前百度的工具也曾是 All in one 的，那时候发现虽然一个工具能解决所有问题，但一线同学感觉工具特别重，不灵活。

当公司的规模或者团队逐渐扩大以后，就会发现工具适用于所有团队，让工具去适应团队的需求也不方便，所以在几年前百度就把 All in one 的工具拆分成了三个更专注的工具：

项目管理或需求平台 iCafe，它主要做需求管理和项目管理，目标用户是项目管理的角色：产品经理以及一些研发团队的 Leads。

代码管理工具 iCode，全公司所有工程师都在使用 Git 的时候会遇到 Git 规模化的问题，一万多名工程师每天频繁的向这个 Git server 中提交代码，此时会遇到一些性能问题，所以 iCode 工具首先要解决的就是 Git 规模化的问题。同时还要保证万人研发的“快”和“有序”。

持续交付平台 iPipe，它负责把从把从代码到发布到部署的过程通过可视化流水线串联起来。

软件交付过程中的三面墙

当 DevOps 的概念逐渐被了解后，大家就一直在致力于实现持续交付，怎样能让业务的想法、或产品经理的想法、抑或是客户的需求能快速通过开发和测试，并能快速发布上线，真正做到持续交付？

其实交付的不仅仅是产品功能，更是交付客户的价值，怎样能做到这一点呢？要想达到持续交付的这个过程，团队之间的“墙”要拆掉。

DevOps 在拆墙，敏捷研发实践也要拆墙，到底有几面墙呢？将它画了出来，在一个团队里面，无论团队规模或大或小，即便角色分开后，这个墙可能也还存在。

主要能感到这三面墙（上图）的存在，业务和开发之间有一面墙，开发同学可能会有非常深刻的认识。开发和测试之间是有一面墙的，有一些团队可能开发测试间合作比较紧密。但在一些大的产品线上，开发和测试的墙还是存在的。

最后的是测试和运维的墙或叫开发测试团队和运维的墙。今天谈的 DevOps 是要重点拆除的墙。但前面的墙是怎么被拆掉的呢？前面两位老师讲到：用精益的方法、敏捷的方法去打通前面的墙。

如今大家都在学习 DevOps，可是实践 DevOps 真正解决了最重要的问题吗？个人表示怀疑。

都在说 DevOps 有一个好处是能让运维自动化、可视化，使得工作更高效，但是 DevOps 只是为了解决运维的问题吗？

让价值能快速地流动到客户那里。如果想让价值从前至后快速流动，必须要把前面的墙打掉，若业务和开发那面墙、开发和测试那面墙仍旧存在，即便打通了测试和运维这堵墙也没太大意义。以下有一组数据来证明观点，其实关于 DevOps，国内可能尚未准备好。

真的只剩最后一面墙了？

这是 CSDN 在 2016 年对国内敏捷方法覆盖的一个调查。假设精益、敏捷方法能够把前面的两堵墙打掉，在 2016 年的国内，用 Scrum、用看板、用 RUP 这种方法和实践的企业及团队加起来不到 30%，更多的国内企业或团队一方面是在自己定制的流程，用瀑布的在 20%左右，所以一个结论——去年国内敏捷方法、实践的覆盖率也就 30%左右。

大家会看到企业里面有一部分团队是在尝试使用敏捷方法，但整个企业还处在所谓“敏捷转型”的过程中。

再对比一下欧美 2016 年类似的一个统计——

• 首先统计显示 8%的企业或者是团队全部使用了敏捷的方法，则里面所有敏捷的方法涵盖的实践比较多，可能只要有一些敏捷实践的都算。

• 其次 32%的企业和团队超过了一半的团队在用敏捷的方法和实践。

• 最后 58%的是什么呢？就是这些企业内部有少于二分之一的团队在使用敏捷实践。只有 2%的没有用敏捷的方法。 所以个人感觉现在国外为什么都在讲 DevOps，可能是因为他们的敏捷已经做到了一定程度，前面两堵墙已经拆的差不多了，只差最后那堵墙了。

实现持续交付的道路上，是否先 DevOps，应该看前面两堵墙有没有打通。

以上是个人观点，但是我们一起学习 DevOps 包括去实践，这是没有问题的，因为它确实能提高组织的效率，并且能提高交付的能力。是否要先去做 DevOps 实践，要从整个价值交付的角度来看，在百度不会强调用敏捷的方法、用 DevOps 的实践来改进业务团队，而是要从价值角度出发，需要依次把这几面墙打掉，所以总结的方法和工具实践只要能把墙拆掉，就是管用的。

打通业务到开发的墙

下面简单介绍下有哪些比较好的实践帮助拆墙，第一个比较好的实践是需求管理。

当产品经理决定要做一个功能，首先要写一篇需求文档，然后把文档交给开发同学。写需求文档有各种各样的方法，如写个 Word 文档、或者用 Excel 来管理多个需求点，或者在系统中录入一个个需求卡片，其实这都是常用的方法。

写 MRD 的过程非常痛苦，因为研发同学基本不看，他们更希望你当面讲清楚。写得越长，他们越不愿意看，写得越短的话，他们觉得你干脆给我讲讲就好了，所以总在自问，为什么要写个文档？ 一直在想怎样能更好地把需求管理起来，其实写文档目的是让产品经理的想法快速进入到开发同学的脑海里面，让大家把产品的想法对齐了以后快速进入开发，所以怎样能让这个过程更高效？

下图是沟通成效和沟通方式的关系，左下角是沟通方式最“冷”，沟通成效最低的，就是 Paper，文档。说明用文档的形式来传递思想、传递需求的沟通效率是最低的。

什么样的沟通方式效果最好？右上角是 Face To Face At Whiteboard，大家面对面的在一个白板面前沟通，这种效果是最好的。这也就是为什么现在很多的研发优秀实践大多是把这些流程、方法可视化出来，在看板上面对面沟通。

既然用文档来进行需求传递效率最低，那么，用什么样的方式能更好地管理和传递需求呢？一种比较好的方式就是——用户故事地图。这种方法把需求拆成一个一个用户故事，并且让所有的用户故事在一个看板上能全部看得到。用户故事地图的方法介绍有一本书，书名就是《用户故事地图》。

很多时候，习惯用一个 Story 的列表排列需求优先级，我做产品经理时，感觉这种排列需求优先级的方法不太灵，会发现排出的需求分散在产品的各个板块上，没有连成一个完整的用户体验，用户看到每次产品更新的功能，却不知道产品到底升级了什么。

用户故事地图能够很好地解决这个问题，它一般分为三层结构，上面两层从左到右用来把产品的骨架梳理出来，如产品的一级模块、二级模块。产品经理在写需求文档时会写 1、1.1、2、2.1。有一个比较好的实践：如果这个产品是一个用户类的产品，比如一个手机 App，那可以从左到右把用户的体验进行排序，然后可以把详细需求点拆到更细的颗粒度。

需求在用户故事地图上拆分以后——

• 首先，最下面层级的需求颗粒度基本上是一个 Story 的大小。这样，研发同学比较愿意接受大小颗粒度的需求。

• 其次就是把需求平铺在看板上，能够可视化整个产品的全貌。

• 第三点对产品经理的帮助，可以方便地排列需求的优先级。

• 最后是排开发计划，无论是从精益的角度还是敏捷的方法，大家都认为最小、可用的产品需求集合是最优先要开发且验证的，在用户故事地图上做一个横向分组，分组内的需求最终连成一个完整的用户场景，并且可以快速的开发出来，这就是 MVP。

以上就是用户故事地图在需求管理方面的实践。

现在，用户故事地图做成了工具，放在百度效率云，越来越多的团队产品经理不再用 MRD 文档来管理需求，使用故事地图和研发团队沟通，能更高效地把需求快速传递给研发，工具的好处就在于不受物理条件限制。过去做用户故事地图的时间，让大家在墙上贴便签，最后发现便签不够用或场地不够大，所以这个实践用工具做比较好。工具内能记录下产品每一个版本的演进，不用考虑卡片数量和场地限制。

打通测试到开发的墙

第二个实践是快速地做计划。严格的 Scrum 流程，要求必须一个一个迭代去做。现实中有许多团队做敏捷开发其实都有自己的开发节奏，除了做迭代，上层还有版本计划，版本上层可能还有里程碑计划。所以工具并没有限制必须采用哪种计划的组织方式，而是大家可以很灵活计划的层级结构，方便把计划做的卡片拖拽到计划中，并且能很方便看到每一个计划里面每人的工作量以及计划总体的工作量。有了这些功能的配合，就能让这个计划做的更快速以及更合理一些。

计划完成后要做进一步追踪，之前提到，好的沟通实践是大家共享一个看板把项目中的工作呈现出来。百度公司现在基本上都使用百度效率云 iCafe 工具中提供的电子看板方式，开站会时打开这样（上图）一个板子，就能知道进度和风险。

邱戈川老师提到燃尽图挺难画的，因为在线下用卡片的形式做看板，确实很难。但用工具就能很方便计算并画出燃尽图，它能帮助我们看到很多项目中的风险和问题。

当实践时首先要有这样的意识：怎样把质量提高？大家都认为质量不应该由测试来保证，而是应该由开发同学自己搞定。其实在许多外企，如谷歌、亚马逊等，测试角色更多的是提高自动化测试能力，基本的质量保证大多是由开发同学来完成的。百度也是这样学习和实践的。

怎样让产品的质量做的更好？比较深刻的一点是开发同学自己保证质量，但是仅仅说这句话去告诉每一个开发同学，请你自己来保证质量。这仍不够，还得需要有工具保证这个流程或者保证这个思想的实践和落地，所以在百度效率云中 iCode 的这个产品上做了一些比较严格代码质量保证的功能。

首先是代码提交前的检查。研发同学不能直接把代码提交到一个分支或者一个主干中。在提交代码以后，代码工具先自动生成这样一个评审单，上面首先要做的是自动检查编码规范，如果这次提交的代码没有满足公司的编码规范，那是不允许继续提交的。

构建流水线被越来越多的 DevOps 提倡，其实它也是保证质量一个非常好的实践。从前提交前构建流水线可能是在云端编辑一下即可。现在越来越多的研发团队，提交前的构建流水线做的越来越丰满，除了编译，还有自动化测试，包括单元测试，功能测试，甚至说集成测试，都得在提交前先跑一遍，保证这个代码提交前把完整的自动化测试运行完。

一些优秀的实践已经能够做到 Review App，就是说真正能发布出来，研发同学自己在这个 Review 环境上去看运行得到底怎样，直至没有问题。

此时再做提交前的最后一步：人工代码评审。

每次代码提交后，仅运行自动代码规范检车和自动流水线还不能根本上保证代码质量，需进行人工评审，必须由同行来给出这次代码提交的评审结果。由嗲马裤的 Owner 总和分析这段代码实现了哪个需求，解决了哪个 BUG 以后，觉得没问题了，打出评审通过，最后这次代码提交才真正进入到公司的代码库内。

这些代码开发实践，能够有效保证代码及整个产品的质量。并且由于有了研发工具的支撑，现在百度每位工程师每次提交代码，都能严格遵守整个规则。

一次代码提交的质量保证是单人的视角，但是如果团队扩大，如何保证不同类型的产品、团队能够快速有序的开发？像一些业务的核心团队可能有两三百人，他们每天都要提交代码，此时如何能更好的协作，怎样更好去保证质量，确实是一个问题，所以说就需要代码研发的工作流。

其实代码的工作流对于大家来说应该都非常熟悉，如主干开发的工作流，分支开发的工作流。但是仅在团队内部口头约定有这些工作流，效果不会太好，因为这是团队内部的约定，一旦新人进入不知道工作流的事情，可能就把重要的代码分支冲掉了。所以团队执行代码工作流时更好的方式还得需要工具来保障。

iCode 有这样的功能——在代码库管理配置里面，可以开启此代码库的工作流，开启后就强制要求代码库按照工作流去提交，如此设置以后，无论团队有新人进入后者团队有人忘记工作流的事情，研发同学都只要提代码即可，因为入托提交方式不满足工作流的要求，代码是无法正常提交的，同时 iCode 会提醒该如何正确提交。

做代码提交前的严格检查，加上团队代码协作工作流，基本上能保证让开发同学提交的每一行代码都是经过比较严格的质量保证。如此，测试同学就能更好的去专注于一些自动化测试工作。

前两面墙基本上都打掉了，我们终于到了 DevOps 要打掉的这么墙。

打通测试到运维的墙

DevOps 要打掉的这面墙，从前面往后看，就是前面这些团队看运维同学：运维要求是稳定的，而且不能随便变化，这样就不能满足快速开发的要求。若从后往前看，就是运维团队往前看，会如此想：测试测的不太好，上线以后总出现问题，质量无法保证，让运维如何上线？

另外运维排期紧张、上线存在等待，好多工作需要手工部署，比较容易出现人为错误，故而这都是现在 DevOps 要解决的问题。

首先用流水线的方式把整个软件开发流程串起来、从代码编译一直到发布上线 iPipe 这个工具的特点在于流水线可以分成多个阶段，阶段里面可以设置多个任务，任务既可以并行执行，也可以串行执行，如此，流水线配置也就非常灵活。有了这样一个端到端持续交付工具框架以后，测试就能把自动化测试挂接到流水线上，用自动化的方法来保证整个产品的质量。

为了更好的指导自动化测试工作，QA 同学们做了自动化的测试分级。

测试会把自动化测试分成多个级别，根据不同的测试框架、方法、脚本能够对应不同的测试级别，再把不同级别的测试脚本挂载到 iPipe 流水线上，此时大家看到的流线如下图：

在流水线上，代码编译后，经过单元测试、系统测试、性能测试，就会到一个检查点，如之前任发科老师所说，这条流水线不完全自动化，会有一个或多个检查点。并不是每一次提交都要自动上线，而是说可能挑选一次或者几次，最后认为这次功能已经比较完整，然后手动验收测试执行，完成后再去执行后面的任务。

iPipe 让流水线可视化，它能把从开发到测试、发布、再到最后的部署都可视化，可以使团队中的多个角色的信息共享。通过这样一种“半自动”流水线及可视化的方法就能够有效打掉运维和开发和测试之间这堵墙，因为流水线可视化把这些信息串联起来了。

iPipe 工具的思路，就是把各种各样公司内部的、为外部的优秀工具能力都集成上来。测试过程中可以接入多种测试工具、环境资源管理工具，发布时可以对接公司运维部门的多种部署和监控系统。

如今都在学习 Docker 技术，这是百度在 iPipe 上的一个用 Docker 发布和部署流水线例子，编译完成以后就自动部署镜像，可以去走准入测试、镜像转推、发布。其实把更多通用的功能挂到流水线后，就看每个团队需要什么，灵活地配置流水线，帮助团队更高效地持续交付。

DevOps 带来了另外一个技术概念是微服务化，目前百度很多产品项目都开始实践微服务化，那么流水线及 DevOps 的工具怎么能够帮助团队去做多模块发布或者微服务的发布和部署？

iPipe 采用了这样一种可视化的方法，左边都是每一个代码库微服务模块的版本，然后流水线自动将它集合在一起，去测试、发布、部署。集成的流水线确实是 DevOps 工具的一个重要功能。

度量与改进实践

刚才讲的是如何拆墙。但墙是否存在、改进后有没有被拆掉，需要大家的一个评判。如果没有一些数据的支持或没有一些可视化展现，就很难了解墙是否存在，更不知是否被打掉。所以在整个研发工具的角度，除了做这些工具意外，还要做一个事情就是数据的积累和度量展现。

百度效率云中，需求管理平台 icafe、代码管理平台 iCode 和持续交付平台 iPipe，它们的数据是完全打通的，打通后可以看到一个需求产生了多少代码，做了几次评审，评审市场，以及需求最后发布到哪个版本上、发布到哪个环境上。这些信息都是可追溯、可视化的。

有了这些研发数据后，在后台做了一个研发数据中心，把所有研发数据全部汇总到一起，做一些研发数据的分析。

目前主要分析一些有助于团队持续改进的基础数据，做一些对比数据，比如现在看到的就是一个团队完成一个需求的平均周期，用散点图、累积流图看。

举例子，这是我们的项目团队从开发到上线的交付周期的数据，每一个点表示一个 Story，纵坐标表示此 Story 停留的市场，横坐标表示它在什么时间完成的。这个绿色线显示 Story 的交付周期在缩短，说明团队交付 Story 的速度是越来越快的。具体为什么会快呢？哪儿变快了呢？或者说过去哪儿慢呢？通过数据分析我们发现有一个测试等待状态的时间，原来是非常长的，大概是 10 天，有了这个数据才能知道——开发和测试的这面墙是存在的。这面墙通过我们不断的努力打没打掉呢？最后发现打掉了，测试状态等待时常降到了四五天左右，整体交付率有明显提升。

总结

所以说怎样去拆墙？有没有数据来证明墙的存在以及墙被拆掉？这是工具能带来的便利，如果手中工具是第三方开源工具搭建出来的，也要思考怎样把这些研发的数据汇集到一起做数据的分析。

此外，之前提到分级测试在公司各个产品线做的如何？如果想真正 DevOps 起来，就得先把自动化测试、分级测试做了。做了以后还会问做得如何？谁做得好？谁做得不好？百度也有这些数据帮助团队了解它们的自动化测试完备程度。每一个团队或者每一个大的部门的测试能力数据，像红灯修复时长，测试完备度等，QA 部门都提供很好的数据支撑。当把这些数据给团队看的时候，他们就会比较客观的了解自己的工程能力，从而根据自身的需要主动改进。

所以有了这些方法和实践加上工具的支撑，百度在最近这几年有了一定的工程效率提升，以上都是一些项目的实践，希望对大家能有帮助。