Leading DevOps in the right way

白凡

分享：乔梁
编辑：白凡

讲师介绍：解释一下为什么叫乔帮主在这个领域大概工作了十几年的时间，最早在百度，大家现在可以看到百度有各种各样的工程能力的建设，但是我在10年前，我在百度的绰号乔帮主来自于，把我们自己的组织称之为丐帮，乞讨为生的一群人，帮助百度去走向持续交付，持续集成的这条路，那个时候，这个概念是很难被很多人接受的，很少有接受的这样概念，但是的确我们在百度改变了很多，在过去的10年里，我走过这样的路，在不同的企业，在很多的企业里面，去做实施。今天算是我对过去10年的总结。当然也是期望把我自己的这些收获或者是一些经验，写到这个书里面，分享给大家。这本书（持续交付2.0），在这个会场见到非常不容易，所以你拿到这本书的时候，这本书是一个刚才萧帮主说是非法的出版物，不能卖的，只能送，在这一版是绝版，很少的一部分，大部分在萧帮主的会场上。

开始我的分享，那么在过去的这些年里面，我遇到了什么？最开始的时候，我是一个工程师出生，一直做做项目软件产品，那么做了各种各样的角色，当我在2008年的时候，加入了乔帮主发现，真是一种不同的软件开发方面，在那里我才相信，的确有这样的开发方向，可以让软件交付得非常快。外面的世界并不相信这一点，所以我就开始了我的布道之旅，在过去的十年里走过一些弯路，今天的总结可能不会像其他同学给大家介绍那样非常得细节，但是这个的确是我在过去的十年里面，收获了一些点点的积累。提醒大家一点，这条路不太好走。

1. DevOps运动诞生的必然与发展

在软件行业有很多的名词，在不同的时期，软件时期交付面临不同的困难，在上个世纪70年代出现危机，那个时候软件第一次被大规模请求应用于我们计算机的发展，被大规模请求，我们这个专业人力实际上是不足的，所以我们从建筑行业引来了软件工程这个概念，出现了瀑布模型，那个时候瀑布模型在项目立足上面的.

在90年代很多很多小的顶尖软件开发方法开始诞生。标志着顶尖这个词正式确实的话应该在2001年，这个时候我们强调的是敏捷开发叠加。是不是有了叠加以后，瀑布模型就没有的，不是这样的，当时我们在做叠加的时候，在叠加的力度上，基本上也是这样的一个瀑布的模式。经过几个迭代以后，把软件发布到线上。

到2010年出现了一种新的模式，持续交付这样的模式。频繁向生产环境去部署，随时处于发布状态，随时可以发布。这个时候，瀑布模型仍旧没有消失，只是它在一个更小的力度上开始发挥作用，它是在一个需求的力度上开始发挥作用。

在过去的正常时间里头，软件工程就是为了快速完成这样的环，从我们开始计划、生产什么样的软件到构建这个软件，把它放在生产环境上运行，那么到了互联网时代，我们更强调，在生产环境上的监测与一种大数据的方式让我们生产环境更加立体。

我们可以看到，在过去这么长时间，持续集成和敏捷软件开发方法，它更关注与计划到构建这样的一个阶段。构建完成可以放到产品发布会，这个时候通常软件开发团队完成工作，马上返回到计划阶段。

乔帮主DevOps强调的是软件开发团队和运维团队的协作，让软件更加平滑、快速进入到生产环境上发挥作用。在2011（QCON英文）大会上，DevOps让持续交付成为可能的主题。

我当时对DevOps的主体，只有让开发团队和运维团队协作起来，才有可能发生，因为在那个时候运维和开发基本上可以认为是对立面，运维强调稳定，开发强调快速，运维有自己的一套标准，开发有自己的一套想法，只有在那个时间点，大家才开始去思考，如何让团队像一个整体一样运作，仍旧让它运行得非常平滑和顺畅？

持续集成和敏捷打破了产品开发和测试之间的一个部门墙，让他们更加快速的能够迭代起来。那么，迭代完之后呢，我们需要把它部署，这个时候出现了DevOps，DevOps让我们的软件交付团队和软件运维部署监控团队能够合作起来。持续交付1.0，只有把敏捷和DevOps能够从上到到下贯穿下来才可以时间，持续交付并不是说，每天发布多少次就是持续交付，你要想清楚这一点。

DevOps到底是什么呢？DevOpsHANDBOOK这本书我仔细翻了一下的作者，DevOps在这里头没有定义，没有行业上统一的定义。如果从我自己的理解的话，敏捷本身是一场运动，它是希望能够寻找一系列的方法和实践，那么以提升不同的提升在软件交付上的质量和效率，注意我把“质量”放在前面，从而提高软件交付的速度。DevOps是什么呢？其实，如果你从深层次理解，从宗旨上理解并没有发生变化，仍旧是这样的。

那么，DevOps过去已经成长近10年，有很多很多的做法，这个是我截的图，在这张图里面可以看到很多工具可以称之为DevOps工具。很多企业说我要做DevOps了，我要去雇佣DevOps工程师，而且现在DevOps工程师相对来说，我听说还是比较薪资比较好的。但是，是不是这些做法拿了一个工具，拿了雇了一些DevOps的工程师，你的DevOps就可以做得很好了呢？

很多的企业想，我要做持续交付，我要做DevOps，我要做敏捷，他们想我可以把我现在的软件交付速度从一个月两个星期一天等等等等，快速提高上面。但是真正的现实中的历程通常是这样的。大家可以注意到，在后面的这些线里面是一些虚线，
为什么是虚线？因为只有很少的企业，才可能跨过鸿沟，走向更高的层次。

为什么会这样？最开始我们要做DevOps，然后我们有一类的工具，找一些DevOps的开发工程师，将我们现在的流程进行自动化，非常好，我们得到了一些收益，我们快开始做DevOps，我们要做自动化测试，平均下来我们人力跟不上做自动化测试，加了一些自动化测试，大家觉得这个效果也不错，然而到了某一个时间点以后，你现在做的这些事情，如果你持续做下去的时候，你会发现我加了更多的自动化，会有更多的测试。但是你的效果并没有显著地提升，这个时候，有两种做法，一种做法是什么呢？我继续这样做，继续保持现在这样做。这个时候，你会效果会下降。

还有一种就是停在这个时候，不再动了，我遇到的企业大部分时候，要么没有走到这里，要么就是往回缩了。举一个例子，最开始的时候，我们都是在做部署流水线，所以有一批的团队在做部署流水线的工具。那么，最开始的时候我们有很多很多的锁工，都变成自动化了。

这个时候，我们把所有的自动化之后，随着你的自动化测试你会发现你原来的过程非常非常复杂，如何跨越这个鸿沟呢？我们想，刚才一直强调敏捷开发就是强调迭代，迭代到一直到需求这个力度上面。一个需求从计划开始到运行我认为是一个环的话，在这个环里面，有一部分是增值活动，有一部分是固定成本，这部分固定成本是什么呢？

所有的测试活动都是你的不增加价值的固定成本。用户而不会因为你不做测试而买你的产品，我们希望把固定成本变得更低，增加更多的增值活动的时间。这个时候，我们实现DevOps的一个首要目标是什么？别变动太多，找一些容易的事情，这里没有错。因为在最开始的时候，我们有很多很多的工作，需要把它变得低成本。然而，这种方式不应该保持太久，为什么？当我们把我们的以现在的工作方式，把我们的固定成本降低之后，当我们把它变成短迭代以后，你会发现在每一个短迭代里面，你的增值活动时间和固定成本的时间，基本上持平，这个时候让团队非常得恼火，无论从上到下都非常得恼火。我们都坚信快速的交付是好的，但是很难衡量它的收益，不是在前面的上升阶段，而是在平滑期和下降期。

因为什么？因为对于单个迭代这个时候的固定成本会增加比例。举一个例子，最开始我们说要做持续交付，要有大量的自动化测试，开始现在补很多很多自动化测试，这个测试的职责实际上在我们的测试部门的时候，他们也有他们人员，也有他们的想法，所以他们写了很多自动化的测试，他们自动化的测试差不多都是在湾道的测试，我们测试用力都是在端到端测试……，随着端到端的测试增加，你会发现这部分的自动化的测试很难被维护，这个时候经常有人得到否定，你投入这么多自动化测试的成本，收益是什么？这就是自动化测试很难再坚持下去的原因，也是不断加自动化测试的时候，成本不断升高，不断被质疑的原因。

2. 实施持续交付的两个关键思考

2.1 正确认识“度量”

怎么解决这些问题，首先我们再强调DevOps非常强调的一个度量，度量通常会有三个纬度的思考，不一定在哪一个纬度，就包括它的可视性、时间性和可行动性。那么，有一些指标是可直接观察的，但是没有办法对它采取行动，必须对其他的指标采取行动，可能影响到你的观察性指标，有一些指标做引导性的，那么有一些指标是滞后的结果，把所有的度量结果去区分，到底现在度量是结果性指标还是引导性指标，是可观察还是可行动的。

比如说提测后的缺陷数量，这个是滞后性指标，它已经是一个结果，自测的测试用例数量和提测后缺陷的数量相比是一个引导性的指标，我们假设我们自测的用例数量增高后，提测后的缺陷会减少，但是这个并不一定是事实，但是必须能够同时关注这两个指标才能够有一个更好的度量体系。就像我们刚才提到频率是不是重要的，是重要的，但是只关注频率，也是有问题的，在朋友圈的问题，讨论W10持续发布，大家可以关注一下，它的频率上来之后，带来很多很多的问题，所以您只强调频率是一个不正确的事情。

那么，在软件工程里面最难的点是什么？是度量。一直有人问，这个软件开发效率的度量是什么？我也没有，我做了这么长时间的持续改进，也没有发现一个非常非常有效的可以说服所有人的一个度量的体系。但是，我认为在所有的这些指标里头，每一个度量指标都是有效的，但是，对当时的企业您用的是不是有效？那么，取决于你自己组织的能力和状态和人员。但是你必须知道你所衡量的指标必须要考虑是可观察，还是可行动，是引导性指标还是滞后性指标。这里面举一个例子，越往屏幕的右侧其实更多的是更多是引导性指标，那么往屏幕的左侧，更多的是结果性指标。他们之间的因果关系，并不是那么强烈，甚至有一些是循环因果关系。所以，当你去考虑如何去持续改进的时候，必须想清楚这些目标到底是哪一个，某一个指标发生变化以后，是否会引起其他指标的变化？

因为引导性的指标通常会有一些延迟才可能持续传导性后面的指导性指标，甚至传导不到。同时度量是有成本的，如果真的想度量到我刚才说的指标，其实要花很大的一部分成本。除了我刚才讲的度量以外，如何进一步改变呢？有一本书“改变”这本书有一个概念，讲了这个问题的形成和解决的原则，留下深刻的是，第一句改革，以系统本身不变为变化，从简单入手从小入手，不要改变太多。到了一定程度，必须寻求第二去变化，系统本身结构的变化。

2.2 寻求第二序的改变

你可以改变测试用例的使用者，通常我们自动化测试用例给谁用的？通常是测试人员用的，但是如果你把它开发人员用，这个时候看待测试用例的视角完全不同，因为给开发人员用的话，你必须符合四个原则，快捷信时，每一个运行速度非常快，开发人员必须能够非常方便地使用你的测试用例级，力争完之后你的结果是可信的。而且，用力的及时性是至关重要，如果是测试用例级，只是用来测非常稳定的功能，那么它对当前的开发没有任何的促进作用。原来写得很多测试用例基本上都是针对不太变化的进行测试的，这个对开发是远远不够的。我还有10分钟，可能要快一点。当你改变使用者的时候，我要改变测试用例在不同层次上的分布比例。

那么当你去改变测试用例在不同程度的测试比例，团队的角色、职责也会发生变化，不发生变化，不会产生第二序的变化，不会有一个更多的突破性质结果。

改变什么样的职责？把我们的质量保证职责向前面移动，我们叫测试、转移。

看待问题的角度。我们刚才讲的都是屏幕上的快速验证这一环，但是如果你们是一个产品团队，假如说你能够从左面这样的环里面去思考问题，从提问开始做什么样的功能，为什么要做？做它的对我的指标有哪些可能产生哪些影响，从这个角度去思考问题，让你的思考角度或者是迭代速度变得有所不同。这个才是一个真正的、完整的交付的环，从提问开始，到是否回答这个问题结束。

3. 实施DevOps的关键思考

那么未来，会是什么样子的呢？这也是我想的，就是当你去思考从文化开始思考，如何交付软件价值的话，那么你应该打破很多很多的墙，对你的组织可能有一些翻天覆地的变化，这个决定于到底这个变化程度有多大，决定自己组织的文化和自己组织的一个发展动态。那么将来可能是很小的，一个组织有很多的小的业务单元组成，这些业务单元我认为不止是面向客户叫业务单元，包括在下面做的基础设施都是属于业务单元，当我们有这么多小的业务单元的时候，你希望提高它的沟通效率的话，必须为减少沟通更多的协调一致的行动，这个是巨大的挑战。

刚才萧老师也说，个体的效率是最高的。但是，个体的能量是有限的，所以你仍旧需要把你的组织变成很少的个体同时，同时要组织一个高效的沟通。那么什么是高效的沟通，面对面的沟通是高效的吗？我见过很多很多面对面的沟通，其实都是非常低效的。所以，你要想什么才是高效的沟通？我们应该减少沟通，更多的协调一致的行动。我们应该在组织当中应该有不少的UNITS，让更多的人组织起来。那么，大家都讲在大中台概念，很多公司都在讲我们要有一个大中台，但是无论如何，即使你是一个大中台，最终你也应该在大中台内部有很多很多的商业伙伴，来共同完成大中台的职责，而不是大中台组织结构本身。
那么，稻盛和夫非常提倡阿里巴巴做法，它在书里面讲了一句话，我如何把日航三万名员工变成以10个人为单位的团队，让他们自己组织起来，这个就是阿里经营所面临的挑战，同时也是它的魅力所在。要想让你的团队，变得高效，能够持续交付起来，你必须就考虑这三个内容，一个软件架构，一个组织机制和一个基础设施。从哪一个部分入手，都有成功的案例，从哪一个部分入手都有失败的案例，在我这本书里面，后三章讲了三个案例，讲如何应用叫持续交付七巧板，拼凑出自己团队的改变之路，希望大家有机会和大家进一步交流！