乔梁：DevOps，使持续交付提速

作者简介

乔梁
腾讯高级管理顾问，轻敏捷”方法创始人，持续交付先行者，《持续交付》中文版译者。魅族、搜狐、上汽、平安、映客、卷皮、墨迹天气等多家平台型公司高级管理顾问。

前言

我在百度、腾讯做过各种各样的工作，只有一件事情没有做，就是没有做过甲方。我改了一下我这次的题目，刚才讲 “DevOps 使持续交付成为可能”，我说 DevOps 使持续交付提速。

为什么呢？因为 “DevOps 让持续交付成为可能”是我在2011年的一个话题，这是我在 DevOps 刚刚开始不久的时候，看到的一种趋势，也是我在工作实践中发现的问题和解决的问题。

1. DevOps的预言

在2011我在一次大会上预测，我说现在“敏捷”是一个热词，在这个会场上我今天讲 DevOps ，那么我想用不了几年，“DevOps” 也会成为一个热词。现在“敏捷”在这里，“DevOps” 在这里，我预言用不了多久 DevOps 也会跟上敏捷的节奏，成为一种常态。

在做这个预言的时候，我在百度还是传统的 Waterfall 的工作方式。我带团队进行了一个持续交付之旅，经历了两个过程：

一个过程是 Water-Scrum-Fall ，然后我们走向持续交付。

我们在 Water-Scrum-Fall 的时候，交付用了25周，之后都是小迭代的交付。我们做了哪些？

需求拆分、主干开发、持续集成、自动化测试，这是敏捷标志性的活动。我们又是怎样在更短的周期去交付呢？这就涉及到从软件开发这个领域，如何让我的软件真正快速的达到持续交付的状态？

2. 持续交付的变革

我和运维的一个Partner，对我们的软件做了二进制与配置分离，DTO一键部署。

做这件事一起合作的运维小伙伴现在应该是百度的T9了，当时我跟他说要变成3周发布一次，他非常惊讶和抵触。原因很简单，他负责的是稳定性，他说，“原来团队三个月交付一次都Bug百出，每次实施部署都要花两天的时间，现在要3周做一次交付，如果每次还要花费两天的话，那我别的活是不是不用干了”。

我说“这个不需要，我们只要做一些简单的改造，就让你的生活变轻松，也让我们的生活变轻松”。

这个故事说明什么呢？这是一个非常传统的软件开发、制造的流程，也存在各个部门墙。现在很多的组织都是这样的组织架构，从最开始概念的提出到产品的上线要经历这四个不同的角色和部门。

最开始那个案例说，我们花了25周的时间去构建产品团队里面的一些沟通方式，做事方式，这个时候我们叫它“敏捷”。

我刚才说了，当我们从 Water-Scrum-Fall 走到持续交付的时候，不得不引进更全链的人员，产品研发要和运维打成一片，做开发与运维的协作，构建敏捷的基础设施和自动化的运维。做了这件事以后，我们才可能达到持续交付这个链路。

持续交付认为它本身是一种组织能力，涉及到人员、组织、流程、技术等方面，最终的目标实际是高质量、低成本、无风险的快速交付服务，提供业务价值。

3. 运维领域的发展

让我们回顾一下应用运维领域的发展，这也是我在这么多年，这么多咨询过程中看到的一些真正的运维发展，当然是应用运维里面，运维还是一个很复杂的专业项目。

刚开始我们的公司都不是很大的时候，运维人员为了提高自己的生产力，让自己的生活变得好一点，都会自己写一些脚本放在服务器上，当他做日常工作时可以使用这样一些脚本。

大概在2004年、2008年时候，我们上线的时候运维还要填一个纸质的上线单，不知道大家有没有遇到过。

当我在2009年、2010年的时候，我们有一个自动化运维系统，那个时候其实我叫它“运维的办公自动化”。因为在自动化运维系统上，可以看到很多的表单，填写很多的步骤，只是将纸上的上线单，放到了网上，可以不用人来回跑签字了。

在往后发展，实际上就是在2008年、2009年以后，我们会把原来有的一些脚本，都放到版本控制器内，有一些受控的脚本。

再往后在应用运维领域，对运维做了建模，有很多的工具出现，出现的是什么？是把我们软件开发里面的技术应用到运维领域，然后抽象出来运维领域的一些建模，可以看到 Puppet 、 Chef 、 Ansible 、 Saltstack ，他们都有自己的领域语言，你通过这样的配置文件书写，可以很容易地做好自己团队内的运维工作。而且这些都受制于版本控制，而不依赖于人的手工操作。

很多人认为手工操作是最可靠的，我的观点是人是最不可靠的，只有计算机是最可靠的。

那么 Puppet 、 Chef 、 Ansible 、 Saltstack 都有些历史了，那接下来容器化的发展让我们更加进一步，同时也改变了我们软件开发的一些方式和方法。这个时候有技术上的支持，让我们的软件开发变得怎样？一方面变得更容易了，一方面变得更复杂了。

什么样的容易呢？这里提到了微服务，那么我们可以单一职责，当我们有很多单一职责的东西时，将他们组合起来就变得相当复杂。这个时候我们需要有更多的技术手段去降低我们运维的复杂度，同时保持我们应用开发的灵活性。

在过去的几年里，我所经历的过程，走过的路，基本上可以看到是这样的几个大的阶段。最开始的时候，我在百度和百度之前，基本上是做基础设施的改造、构建，然后再往后我们真的要做持续交付的时候，你只做基础设施的改造和构建是不行的，你要做架构的调整，你的软件架构仍旧满足不了业务的发展，最终你还是要触动到最终企业的组织形式。

4. DevOps能力与挑战

基础设施包括包构建、分支、测试、发布，基础监控等这些，这些是最容易发现问题，最容易上手，你不用经过其他人同意你就可以改进的。

但是当你做了这些以后，你会发现你做的其实是非常痛苦，而这个时候你有动力去说，我要做软件架构的调整，应用架构的调整，软件要能够容易测试、容易监控，这些都触发到你原来对软件的改动。

当你做了这些以后，就会有一个更高的要求，什么样的要求呢？我有这样的架构，需要有这样的人来做这样的事，这个时候你就会发现，最终你还要涉及到你的组织结构、你的人员能力，在你组织中协作的机制和激励体系。如果你想做得更好，那这些东西你可能最终都会遇到。

可能有同学发现，这个东西是中国传统的玩具七巧板，我为什么画这样一个图。原因是中国的七巧板可以拼出很多的形状，我在这里强调的七巧板是任何一个组织可以用七个板子组成各种各样的适合你自己企业的一个模式，而不一定是大家都是一样的。

在我过往的经历中，即使在腾讯，我指导过很多的部门，他们的解决方案也都不是一样的。原因很简单，因为每一个部门的人员不一样，产品形态不一样，那你的产品所处的竞争商业周期也是不一样，最终你是采用不同的方式来实现你的业务目标。所以虽然基础维度不会变化，但是最终的结果和展现形式应该是千差万别的。

未来可能是契约式高内聚、低耦合、服务化架构，服务化架构不仅仅是软件架构，同时也是组织架构。

我们现在非常明确的趋势是什么？我们有一些 Infrastructure Service Team ，有一批人维护 Infrastructure ，还有一些人负责 Application ，这些组合起来实现交付价值。

现在更多的人聚焦于你的生产环境，因为谁都知道生产环境是不能出问题的，都会把生产环境的问题作为第一优先级去处理。但是不久的将来，我认为可能有更前进一步的趋势，因为我们会提供一个非常强大的基础团队对系统的支持。

那么在我们的生产环境上，假如B出了问题，B这个 Service 团队马上扑上去把它救活，你有没有想过这是生产环境，这个软件是正在运行的？但是要创造更多价值的时候，你必然是会更快速地生产你的服务。然而越来越多的小的单例的服务是不可能提供整块价值的，必然是多方协作，在多方协作的前提下有一个非常大的要求。

作为高内聚、低耦合、契约式的要点，我们的 Application Team ，不仅仅是把生产环境作为第一优先级，同时要把所有团队在开发过程中的开发环境和测试环境也应该作为第一优先级，甚至是放到KPI里面，去保证你对外提供的，帮助别人实现新功能的测试是OK的。

因为只有这样才会保证你是最快速的，最响应式的把你最好的价值提供给你最好的团队。这里面大家都强调微服务，单例是没有什么意义的，只有服务的组合才能产生最大的价值。

如果你只为了你自己快速，那对于整个组织来说，其实价值并不大，唯一的方式是能够帮助其他人交付才是最大的价值。所以这里我讲的契约就是，对于组织来说，对 Service 团队的要求，不仅仅是生产环境上的稳定，同时要求联调开发、测试环境上，要求它对质量进行负责，也作为同样高的优先级去处理开发、测试环境上的问题。

当然这一方式现在很多人无法接受，我线上环境忙不过来，我还能管别人的开发环境吗？现在的确是这样的，在现实生活中无论你们怎样做和想，都是这样的问题，你提供给别人的一个服务，然后别人用你服务调试的时候发现了问题，你第一反映是什么？没有问题，然后大家找一帮人讨论这是你的问题还是我的问题。

怎样解决这个问题，一定是更多强契约式的服务，才是真正让你团队实现自律运转的模式，让组织更加高效。

作者简介

前言

1. DevOps的预言

2. 持续交付的变革

3. 运维领域的发展

4. DevOps能力与挑战

更多相关文章

随机推荐