原文地址：演讲实录丨DevOps之十倍速原则
大家好！很高兴社区能邀请我来杭州参加这个年会。我来杭州应该是上个月来过一次是在云栖大会，讲了类似的topic，不知道有多少人去。在过去十年里，在连续十年QCon大会，我每年的topic和内容都不同。但从今年年初开始，我打算把这个topic重复讲几年。只有重复不断的讲，才能让人记住。
介绍一下我自己，我叫乔梁，在IT行业有很多年了，已经老到不再写生产代码了。这是与我相关的几本书。2009年我在Thought works工作的时候，翻译了《Thought works文集》，我认为其中大概有5、6篇文章所讨论的方法，对目前80%团队仍旧非常有效。尽管在当时，“敏捷”就像现在的DevOps一样，开始广泛流行，但是，根本没有几个团队做得好。现在大家就开始做DevOps。我想，从今年开始，DevOps也应该进入一个平台期了。
2011年的时候，我翻译了一本书叫《持续交付》我称它为 “持续交付1.0”。当时我找了国内很多出版社，希望引进这本书，但很多个出版社并不看好它，几乎都拒绝了我的要求，说这本书不好卖，受众太小。我心想：”不管能不能出版，我先把它翻译了再说“。所以，我自己向作者Jez Humble（也是我的同事和朋友，我们在同一个项目组）要了英文文档。当翻译到一半的时候，终于找到一个出版社，这本书才能顺利出版。也许，这个是国内IT领域翻译的最快的一本书，我只用了8个月时间，基本上占用了我所有的休息时间。
最近十年，我一直从事相关领域的咨询工作，中间没有间断。2017年，我决定把我的经验与心得写下来。于是有了这本《持续交付2.0》。这个副标题”业务引领的DevOps”，也是我多年来的思考。一切皆是业务引领，所谓的技术驱动也是业务引领的结果。很多人认为，敏捷开发就是就是IT部门的事情，但实际上任何一个组织想要做好，都不是单一部门的问题。现在，大部分组织中的IT团队都还有一点儿“技术外包团队”的味道，在toC互联网企业可能会相对好一些，因为它有个特殊的优势，就是它的软件产品就是企业命脉，这个命脉正好和IT技术相吻合的，所以这也是为什么现在的很多软件工程方法都来自于互联网公司的沉淀。
说到“业务引领“这一点，我就要提一下硅谷的这两位大佬。一个是做电商的贝佐斯，一个是做社交的扎克伯格。但是几乎使用同一种方法，来发展各自的公司，这个方法就是“一万次实验法则”。
大家都知道“一万小时定律”，一万小时定律是针对个人技能修练的方法。而在一个快速变化的商业领域里面，一个组织如何应对变化，如何找到先机，这个定律是不二法则。而这种能力，通常是传统软件公司不具备的能力。这种业务快速尝试的诉求，必然就会导致原本作为支撑团队的IT部门必须想到各种各样的方法，建立各种各样的软件基础设施，来支撑“一万次实验法则”。
他们为什么会有“一万次实验法则”的说法？以Facebook为例。Facebook公司内部经常提到的一个词是“Data Inform”。是的，你没有听错，不是“Data Driven（数据驱动）”，是“Data Inform”。它提醒我们，不能成为数字的奴隶，但是一定要掌握数据信息，为自己的判断提供依据和佐证，或者用于深入了解用户。
《持续交付2.0》是指从端到端交付业务价值的角度看待组织能力的提升，而不仅仅是软件的交付。它强调端到端的交付业务价值。这需要组织中各种角色之间能够打破部门墙，角色墙，建立一些新型组织。我这里要提醒大家的是：虽然大家都说“我们打破部门墙”，但目前看，人类社会中是不可能没有“墙”的。因为人是社会型动物，无论如何时都需要某种组织形式，人们需要身份识别与身份认同，以及群体归属感。当拆掉一面“墙”的同时，也在建立另外一面“墙”。
在《持续交付2.0》这本书中提到的双环模型与DevOps标记所指的范畴不同。不同点在于，左手边的环更多倾向于业务价值探索，而并只不是“Plan”，它具有高度不确定性。在高度不确定性的条件下，如何发现那些确定性的方式、方法，找到其中的一些确定的点，能够快速实施，这就是价值探索环的意义所在。
这个价值探索环一共有4个步骤，它们4个步骤之间并不是一个完全的单向顺序关系，实际上可能是双向反馈关系。在价值探索环完成了第4步“选择精炼”时，通常就进入了传统DevOps和持续交付1.0所涵盖的内容。这一部分基本上可以被认为是一个“相对确定性”的过程，因为你已经明确地知道你要做什么。如果此时你还不知道确切要做什么，说明你还没有准备好。而现在我们行业里面，基本上都处于没有准备好就开始干的状况。
进入第二个环后，我们追求的是“工程卓越”，通过我们工程技术的手段快速实现，高质量的交付，最终能够快速的拿到数据，从而与第一个环中“锚定”的目标对比，用于验证“提问”的问题。
今天，我也不会讲特别多关于价值探索环和业务创新的内容，而是讲“工程卓越”。
如何追求工程卓越，我认为可以从以下三个方面进行：工作流程、支撑工具、工程素养。此时，所有的改进都可以围绕这三方面来去实施。大家一看“流程、工具、人员能力”好像千篇一律。但是，我今天想讲的一个要点是：“我们之前在制定工作流程，建设支撑工具的时候，一个最大的出发点是匹配现有人员的能力去做出对应的工作流程和支撑工具。恰恰是这一点，让我们的软件工程基本上十年没动。真正行之有效的方法是：流程与工具不应该适应现有的人员和组织能力，而是要稍高于它。”如果三者恰好匹配，说明组织及组织中的人正处于舒适区，而不是“学习区”。
作为一个组织，当你去制定流程和工具的时候，一定要稍稍超出你现在现有人员的能力，而不是适应现有人员的能力。
关于工程素养我只是简单地讲一讲，后面熊节也会分享他的想法。今天我主要讲前面这两个，就是对于组织如何去思考工作流程和工具。我认为，组织应该考虑采用“十倍速原则”。作为一个组织，一定会追求更高的效率，更高的目标来实现业务增长。而定义流程，制造工具需要思考的是，未来3个月组织应该是什么状态运转，未来6个月呢，未来一年呢？十倍速原则正是一种思考方式。要想达到“一升汽油让汽车跑500公里”，在现有汽车设计上，一定是不可能的。必须想其它办法才行。也就是说：当你设定一个远超现状标准的目标时，你就需要去重新改变你的结构来找到一些新的方法达成，现有方式是不可能达成这种挑战目标的。这个就是我今天的主题：“十倍速原则”。
当然十倍速原则本身是挺简单的过程，要持续的实现十倍速原则是一个非常痛苦的事。下面看一小段魔方的视频来理解“十倍速原则”。前面那个是我自己拧魔方的时候，大概是26秒，不是我的最好成绩，我在“刻意练习”。中间那位是世界记录创造者，大概4秒多就可以复原三阶魔方。我还不会玩魔方的时候，我就想达到30秒以内。找到了10个公司，记住，练习，每天大概练4、5个小时，1—2周你就可以达到大概40秒左右，做到“十式走天下”。
再想提高，可以继续练，但提高很慢。而且无论怎么练习，都不会达到20秒。所以必须换方法。这才有了“119式“的练习。因为119式是右手公式，我是左利手，所以速度再想提高，可能就要创造方便自己的左手公式了。所以，简单重复无法提高，只有刻意练习才行。而“刻意练习”也有瓶颈，必须改变模式才行。
所以，做同样的事情，不同的流程、不同的方式、不同的制作工艺，会产生不同的结果。如果你想达成十倍速原则，你不可能一直沿用现有工作模式。而目前所有研发管理都还沿用传统模式，基本上没有改变。所以说，中国软件行业十年基本上没有什么变化。
关于工作流程的改变，我讲一个例子，大家会更加深入的理解。2013年，我到一个大约400多人的团队，负责一个PC客户端的互联网软件，去帮他们改进软件交付模式。在当时，他们原定的计划是：每年12次发布，每个月一次。每月的前3周进行版本开发，最后1周进行测试，然后就发布了。我估计现在有很多团队都是按照这样的模式计划的。
不幸的是，他们无法按照这个达成计划目标。他们的工作基本是这种状态：前面三个星期都在开发，到了开发阶段的最后一天（马上到提测时间点了），开发人员还没有可以提测的软件包呢。这时怎么办？开发人员迅速把他的代码提交到代码仓库，然后匆忙打一个包给测试人员，并说：“你们可以开始测了，赶快测吧，有bug我们就修”。然后就是一轮一轮的集成测试，然后不断地发现bug。到了最后时间点，老板说：“必须把x需求加到这次发布中！”为什么一定要要在这个发布中呢？因为如果这个需求无法进入这个版本的话，它要再等一个月，才能与用户见面。
那么，请我去指导的目标是什么呢？就是达成这个团队的原始目标：每个月准时发布一个全网版本。现在团队已经有一整套工作模式，并形成了非常稳定的模式。如果只是在此基础上改进，很难在较短的时间达成目标，并能持续保持下去。而且，不断重复原有的一贯做法，只会得到与以前一样的结果。只有达到远超要求的水平，才能轻松实现被要求的结果。所以，必须彻底改变现有的工作流程模式。
最后，目标是做到三个“1”，即：（1）每个月都要有一个正式版本（全网版本），要想达成这一点，（2）我们就要每周发布一个Beta版本（要有200百用户试用）。而要想达成每周一个Beta版本，（3）就要每天能够发布一个Alpha版本（要有50万用户）。
原来的组织是按职能划分的，产品、开发、测试，有各自独立的部门。每个版本在同一时间点启动开发，在指定的时间点统一提测。我们做的一件事情就是流程再造，即：改变团队协作流程。另外，也对软件架构做了改造。整个组织的运行模式如图所示。整个团队被分成几个子团队，每个团队有自己的运作节奏，而整体版本也有整体版本的节奏。这样，我们可以实现，每个功能完成都可以随时发布出去，验证功能反馈，部分实现了持续交付。
这种运作模式带来了一个原来根本不存在的问题。原来的模式中，每个月才发布一个版本，现在每个月发布数十个版本。如何高效地管理这些版本。作为技术人员，就要去找到一些方式或方法解决这类技术问题。从这一点可以看出，“十倍速原则”的应用一定会带来前所未有的挑战。而对于应用“十倍速原则”的团队来说，这种挑战不再是一个可选项，而是必须完成的任务。
在这个组织中，很多人第一次看到这样的运作流程时，首先想到的是“这个很难，基本上是不可能的”。然而，最终我们花了4个月的时间，还是做到了。4个月之后，基本上可以保证每天可以发一个Alpha版本（甚至两个），所以每个月底发一个正式版本，就不再是个问题了。
当团队达到这一状态以后，突出问题不再是交付问题，而是业务成长问题。原来的业务成长问题被所谓的“交付问题”所掩盖。现在交付不再成为瓶颈以后，我们发现业务想法的靠谱度成了主要矛盾。当然，这里不展开这个话题，它与刚才讲的持续交付2.0双环模型的第一个环有强关联。
流程的改造，必然会带来一些冲突需要管理。最显而易见的冲突就是：（1）不同团队的发布时间的冲突，以及发布质量的冲突。每个团队都有自己开发的节奏，但是，作为组织级的一个大产品，必然要管理各个团队的时间与质量，否则的话就会互相影响。怎么来做管理冲突和管理质量呢？
我们也应用了“十倍速原则”。搭建了一个工具平台，管理所有代码，包括代码的合并、代码的分支，所有常见操作都不需要开发人员操心，只要遵守规则，工具平台就可以把这些事情做完。当然这些规则就会改变开发人员的行为。为什么团队成员要遵守这些规则？因为这些工具平台为团队员工提供了非常方便的工作方式，减少他的工作负担。在这一点上，是很多企业内部工具团队做得不好的地方。如果只是给他们定流程，定规范，但是你不能让他的工作生活变得更美好。那很可能会受到开发人员的抵触。
第二点，关于“管理质量”，我们就选择了可以说是“非常简单粗暴”的原则。这个大团队被拆成了多个小团队之后，每个小团队要负责自己的软件质量，同时也负责自己的业务目标。而我们的原则就是：如果你的交付在Alpha版本质量不达标，那么就禁止你在Alpha版本中加入自己新开发的功能，直到修复原来的质量问题，并达到标准。由于，每个团队都有业务目标，如果不发新功能做试充分，就很难达成业务目标，所以，每个小团队的产品人员、技术人员都会非常关心产品质量。
事实上，这种改进并不是无迹可循。在《持续交付2.0》一书中，我总结了“持续交付七巧板”，我讲的这些内容都在其中有所体现。例如，本案例中，最开始的时候我们做的是“软件架构”这个版块。为什么是“软件架构”这个版块？因为没有进行改造之前，版本项目经理制定项目计划，规定了提测日期和时间点。如果在这个时间点，有开发小组无法合入代码，打包提测的话，开发组长就要缴罚款。最开始是10元，不行，还是做不到！那就20，还是做不到！50，还是做不到！甚至有的开发组长在计划提测当天的早上就把50块钱准备好，交给版本项目经理了。从这个小事上，我们也可以看出，瀑布开发模式下，大版本的最后集成提测有多难了！软件架构不清晰，互相耦合太严重，技术债务太多。因此，我们先做了软件架构的解耦。然后做了团队解耦。当然，七巧板中的基础设施部分一直在不断改进。
流程的改变，势必影响到工具建设。我认为，好的工具平台要满足下面三个要求：它们是标准化、高要求和简单易用。很多企业内部负责软件工具平台开发的团队，都最先强调标准化。其次是高要求。即对开发人员的日常工作行为提出更高的要求。当工具满足这两点以后，做到“简单易用”就非常难了。
举一个工具建设的例子。Bazel是Google很早就已经开源的一个C++构建工具。这个构建工具支持很多种编程语言。所以，在Google开发人员基本上不需要了解不同语言的构建方法，使用Bazel统一描述语言即可。这让团队成员在团队之间换岗时根本没有这方面的学习负担。
这样的标准化之后，开发人员的负担就轻了。而且，Bazel的一个优点是：依赖管理做得非常好，因为它只允许单一依赖，如图所示。你可以看到非常清晰的单向依赖拓扑图。这个好处是什么呢？
第一个场景：当修改了图中最下面一个基础组件的时候，Bazel就知道它会影响上面所有的组件，因为运行自动化测试时，会自动运行所有的自动化测试用例。
第二个场景：当仅仅修改了其中的一个组件，例如youtube Client，Bazel就不会运行所有的自动化测试用例，而只是有针对性地运行那些受到影响的组件自动化测试用例。
十倍速原则下的收益，就是通过巨大的改变，完成那些看上去不可完成的任务。通过流程再造，消除原有流程中的很多浪费，让你有更多的时间去做有价值的活动。对于软件开发这件事情什么是有价值的活动？把语言变成代码是有价值的活动，其他的都不是。
这张图截到自网上的一篇文章，它提出了一个很好的问题：“为什么Google Bazel这个构建工具流行不起来？”是因为我们的软件项目比Google的项目更复杂么？我想，不是的。因为使用这个工具需要非常强的纪律性，它有很大的约束。如果管理能力没有达到，的确很难应用起来。但我们不就是要不断提升我们的管理能力么？
事实上，Google在2005年的时候，和现在在座各位的组织在软件项目管理上没有太大的区别。只是它在很早的时候就意识到了这一点。从2005年起，开始进行工程效能方面的变革。他们认为，释放开发人员的能量是最为重要的，所以会有这样的工具出来。
由于时间关系，我简单讲一下工程能力与素养。
Google对代码的要求很高，国内对代码要求很高的公司不多。Google工程生产力的三个支柱分别是Code Health、Debuggability、Infrastructure。你可以明显的感觉到，国内公司对这三项是基本不强调的。
举个最简单的例子，就是Code Review。Code Review是公认非常有价值的活动，但是在国内基本上就没有实行起来，为什么？因为我们根据我们现在的情况，只有重要的需求才做review，紧急的情况时不做review，各团队规范不一致。
然而Google每行代码都要review，代码规范全部一致，必须具备可读性。
我们在自己的代码库中经常见到大量复制/粘贴的，无法写出自动化测试的代码，随处可见。
最后，再提醒大家，在DevOps建设中，一定要当心“烟斗曲线”。无论是敏捷也好，还是DevOps也好，都会follow这个“烟斗曲线”。是这样走过来的。敏捷实在搞不下去了，现在又开始搞DevOps了。
这个烟斗曲线是指什么呢？大家都说：我们要选一些简单的，能够快速上的改进活动。比如敏捷开发中的站会，故事墙等。这些事情在刚开始会有一些作用，但作用有限。
我们以自动化为例。最开始做工作流程自动化，大家纷纷上了Jira，jenkins。然后，测试团队开始写自动化测试了~为什么呢？因为开发人员都不写自动化测试。因为他们认为测试是测试人员的事情。而测试人员不想一遍一遍的手工回归。最开始写自动化测试用例，初期没有太大的成绩，当达到一定数量以后，至少冒烟自动化测试有了以后，可以在开发人员提测时拦截一下。
此时，领导会给时间积累一些测试用例。积累到一定的时候，比如说测试用例达到2000了，这个时候会有一些稍微明显的效果。此时，会加大这方面的投入，增加更多的自动化测试。当你以原有方式增加更多的自动化测试以后，你就会发现，自己到了平台期，即：投入多，效果并不明显。这个时候老板就对你失望了，然后你自己也坚持不下去，然后就跑到那个沟里了，基本上是这样一个状况。
其中常见的一个问题，测试人员写的自动化测试通常是集成自动化测试，从UI层驱动的自动化测试比较常见。这些用例并不稳定，经常是“随机成功”。测试人员很大精力都是在维护这些“随机成功”的用例上。要想突破，做得更好，一定要应用“十倍速原则”。挑选容易做的事情进行改进，当然没有错，错就错在只选容易的做，而且一直做。这一定是错误的。因为，组织此时仍旧是在自己的舒适区中行动，并不会有真正的提升。
最后，总结一下“十倍速原则”在DevOps方面的应用。
流程方面：以终为始，具有颠覆性才能有大的飞跃。
工具方面：高标准下的简单易用，才能创造更大价值。
能力素养：有了时间，才能学习，提高工程能力与素养。
互动问答
提问：您刚才说那个测试，测试是集成测试还是单元测试？
乔梁：我见过有些测试团队试图写单元测试。我认为，这么做是错的。单元测试就是应该由开发人员来写，而不应该是测试人员。
提问：所以我的问题是：您刚才说的2000个测试，测试人员写的是单元测试还是集成测试？
乔梁：我的例子中是指集成测试。
提问：集成测试本来就应该他们写，没有问题。
乔梁：但是，写的不好，没有能力写好，这就是问题了。这个不是应不应该的问题，而是能不能做好的问题。很多领导说：“你就应该做……”，但是，如果不具备相应的能力，赶着鸭子上架，最终导致结果也不会太好。
作者
乔 梁
腾讯高级管理顾问
《持续交付2.0》作者
独创双环模型与组织文化四步法。DevOps领域顶级大师，国内第一位持续交付布道者，率先于2010年将DevOps和持续交付相关理念、原则和最佳实践引入中国，并辅导华为和百度进行实施。
目前作为腾讯外聘高级管理顾问，指导多个事业群的产品研发管理工作和相关工具平台建设。同时，为多个（toB和toC领域）移动互联网公司提供组织管理咨询服务。曾辅导过亿注册用户量的互联网产品十多款。曾作为敏捷&精益组织转型导师，就职于ThoughtWorks、百度和Nokia。
原文地址：演讲实录丨DevOps之十倍速原则