恍惚间，DevOps 已经被讨论十年了

“如果系统是集中式的、环境是同质化的，从开发环境向生产环境推送程序变化的过程非常简单，不需要太多的自动化；但是今天的应用需要 7×24 小时运行、采用分布式架构、部署到多种环境，变更过程变得愈加复杂、难以自动化……不论在大型组织还是小型组织，施行 DevOps 在技术上都非常具有挑战性。”

上面这段文字如果放在今天，那只是段关于 DevOps 的、稀松平常的讨论，但是如果它写于十年前，各位读者会不会感到有一些惊讶？

这段文字写于 2007 年 8 月的下旬，很快就距今整十年了，这是我所知道的业内最早的关于 DevOps 的系统性讨论，我在整理收藏夹的时候偶然发现了它，这让我突然意识到：DevOps 已经十年了。

可是，为什么雷声大雨点小？

博客网站  （据说是   被抢注了，所以他们只能加个 2，而   至今仍是个空域名）的文章“What makes dev2ops so hard anyway?” 文中还罗列了阻碍 DevOps 施行的几个因素：

• 变更结果的可靠性和可预见性
  
  

• 不同类型的变更（数据、代码、配置、内容、平台等）对系统造成的不同影响未被充分评估
  
  

• 对分布式系统各部分的变更非常难以协调
  
  

• 开发与运维的组织边界难以界定
  
  

这几个因素在今天依然阻碍着 DevOps 的施行。由于滚动更新、金丝雀测试等方法和 Kubernetes 等系统的流行，前三个阻碍有了一定的改善，但是由于方法和系统仅仅提供了操作原语，所以带来的改善十分有限。而第四个阻碍在很多组织中依然如故。

而且，这四个因素远远不是全部，我想每个正在实践 DevOps 的读者在读到这里的时候，头脑中都会闪现出其他的一些因素，例如老系统的云化和测试自动化需要很大的投入、DevOps 的工具链过于繁杂等。所以，DevOps 的施行依旧非常的困难。说到这里，作者还很应景的补充了一句：“尽管如此，DevOps 最终仍然可以施行，办法很简单，让最强的技术人员通宵加班即可。”这句话简直是神补刀，前段时间我刚好支持了一个老项目上线，那感觉简直就像是误入了一个野蛮的原始部落，这使我不禁反思：十年来，DevOps 究竟改变了什么？

公认首个 DevOps 成功案例，Flickr 的每天 10+ 次部署

2007 年，比利时独立 IT 咨询师 Patrick Debois 参与了一个政府部门的数据中心迁移项目。在这个项目中 Patrick 需要交替的和开发团队还有运维团队一起工作：第一天在开发团队跟随敏捷的节奏，第二天又要以传统的方式像消防队员那样维护这些系统，两种工作的切换令他十分恼火。正是因为这段经历，Patrick 充分体会到了开发团队和运维团队的工作方式和思维方式存在巨大差异：他们简直是活在两个不同的世界之中，两个团队的工作之间到处都是冲突。Patrick Debois 开始思索如何弥补开发团队和运维团队之间的鸿沟，这些思考的结果就是 DevOps 的雏形。

两年之后的 2009 年，John Allspaw 和 Paul Hammond 在 Velocity 大会上发表了名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲，演讲的 PPT 有五十多兆，里面充满了来自 Flickr 的高质量的图片，DevOps 也由此正式走入公众视野。演讲中有两个想法在我看来非常重要：

• 运维工作的目的并不是保持系统稳定，而是 促进业务敏捷；如此，开发和运维工作的目的就统一起来。
  
  

• 开发团队和运维团队为了促进业务敏捷，应该 打造一系列支持快速发布软件的工具和文化。其中工具包括：自动化基础架构、共享的版本控制系统、持续集成、持续部署、共享的度量和消息机器人。
  
  

近年来，自动化基础架构、共享的版本控制系统、持续集成这三种工具已经普及，而持续部署、共享的度量、消息机器人这三种工具应用的还不是很多，也没有很好的标准化，相关的开源项目还处于战国时期，不过按照目前这个趋势，想必很快也会尘埃落定。在这三种工具也得到了普及之后，前文罗列的阻碍因素会得到相当大的改善，那么，DevOps 能够随之得到普及吗？

普及 DevOps，工具才是关键


1. 警惕空谈陷阱，文化转变不一定是必要条件

很多人认为工具的普及和 DevOps 的普及是两码事，因为 DevOps 不仅仅是一系列的工具，更是一种文化；甚至很多人认为文化要比工具重要的多。Cloud Technology Partners 公司的首席架构师 Mike Kavis 曾说：“DevOps 是一种文化转变，或者说是一个鼓励更好地交流和协作以便于更快地构建可靠性更高、质量更好的软件的运动。”

但是恕我直言，我非常反对这种说法，众所周知，一个组织在成型之后再对组织文化进行根本性的转变，难度之大超乎想象，如果把文化转变作为施行 DevOps 的必要条件，那无异于把 DevOps 送上了绝路。

在我看来，DevOps 更应该是一系列工具加上如何使用这些工具的知识，鉴于任何工具都需要相应的使用知识，所以简单的说，DevOps 就是一系列工具。

让我们回顾一下，持续集成和 Scrum 都已经提出了有二十余年之久，易于工具化的持续集成在近几年已经普及，而不易于工具化的 Scrum 却没有，在很多团队里仅仅是站会都会沦为一种形式。所以，你应该明白我的意思：如果 DevOps 更多的是一种文化，那么它的普及将遥遥无期。或者说即使 DevOps 是一种文化，那也需要有工具来支撑这种文化，否则极易落入空谈。

所以，DevOps 应该像个生产软件的流水线，开发人员、测试人员和运维人员在补充了必要的知识之后，就能在这个流水线上以 DevOps 的方式生产软件。

2. 这是一种软件开发模式和方法论

还有人认为 DevOps 是一种软件开发模式和方法论，从瀑布模式到敏捷模式、再到 DevOps，一脉相承，这个观点我基本认同。我们目前在做支撑 DevOps 的产品，有次我问我们同事：“如果 DevOps 也是一种软件开发模式或者软件工程方法论，那么它如何能成为一种产品呢？之前的瀑布、迭代、螺旋和敏捷又为何没有成为一种产品？”同事答到：“因为 DevOps 吹的大。”

我不认为他是在戏谑，因为拉里•佩奇曾经说过：“只要你想的足够大，那就很难全盘皆输，即使是失败，其中往往也会隐藏着珍宝。”吹之前当然需要想，所以吹的大也就包含想的大，所以我想，即使多年以后，DevOps 潮水退去，也会留下一些由 DevOps 工具链演化成的优秀产品。而且应该有很多人还记得， 统一软件开发过程，即 RUP（Rational Unified Process），就是一种和产品相辅相成的软件开发模式和方法论，其支撑产品 Rational 几乎是上一时代最为成功的软件开发套件。虽然 Rational 很贵，很多人都没有用过，RUP 也是一种重量级方法，但是很多组织都在或多或少的应用 RUP 的某些子集，它的迭代开发、可视化建模、需求管理和变更控制在今天依然有非常好的指导性意义。

我们应该从 RUP 和 Rational 的联合运作中学到一些东西，并把它应用到 DevOps 的推广和支撑 DevOps 的产品的开发中，那么，DevOps 会成为覆盖更广、更易用和更普及的全民 RUP 吗？随着 DevOps 会诞生一些像 Rational 一样成功的产品吗？既然用户有需求，历史上也有类似模式的成功案例，那么就值得我们这些工具类的软件企业努力去做。

3. 继续生长和完善的 DevOps 工具链

另外还有一点就是，虽然很多人在诟病 Java，尤其是诟病 Java EE，但是很多其他语言的开发者非常羡慕 Java 完善的工具链和周边， 有些开发语言甚至连个完善好用的打包工具都没有。DevOps 刚好可以提供这种补充，尤其是在微服务模式下，这种补充变得史无前例的重要，Docker、Kubernetes、Istio、Namerd、Linkerd 这些开源项目，对于其他语言就像 Java 的应用服务器和 Spring Cloud，当然它们同样也可以给 Java 使用。

它们都是 DevOps 工具链和产品的必备环节和组件。这是历史上第一有望将所有开发语言纳入到同一个全流程的管理框架之中，目标一旦达成，那将是软件工业的一次重大转变。

Mike Kavis 在说明 DevOps 是一种文化的时候，曾提到很多 DevOps 团队通过编写 Chef、Puppet 或 Ansible 脚本来施行 DevOps，而 Mike Kavis 认为大量的专有脚本实际上是增加了系统的浪费，而 DevOps 提倡的是效率，这些团队的行为并没有体现 DevOps 的理念。但是在我看来，这种状况的产生正是因为工具的缺失，如今 Docker 和 Kubernetes 在很大程度上提供了标准化的部署环境和流程，让很多用户不必再花大量精力编写专有脚本，还有一个更大的优势就是，Kubernetes 可以在让系统达到用户定义的状态之后继续维持这种状态，而 Chef、Puppet 和 Ansible 的脚本则不能。

所以，我想说的是，也许 DevOps 曾经是一种文化，但是正在越来越成为、也必须成为一系列工具，文化的比重逐渐变小，直至成为非常次要的条件，因为只有这样，DevOps 才能获得广泛的应用。

写在最后

持续集成在提出了十几年之后才获得广泛应用，而 DevOps 刚刚十年，虽然 DevOps 的战线要远长于持续集成，但是让我们保持乐观，也许未来的几年就是 DevOps 的加速阶段，我们还有几年的时间来打磨支撑 DevOps 的产品，以帮助客户解决开发和运维的效率问题，帮助客户实现业务敏捷。

十年了，如果你觉得 DevOps 改变的还不够多，那么 DevOps 自身首先应该做出改变，那就是由虚无缥缈的文化，变成看得见摸得着的工具。

原创：宋潇男

恍惚间，DevOps 已经被讨论十年了

“如果系统是集中式的、环境是同质化的，从开发环境向生产环境推送程序变化的过程非常简单，不需要太多的自动化；但是今天的应用需要 7×24 小时运行、采用分布式架构、部署到多种环境，变更过程变得愈加复杂、难以自动化……不论在大型组织还是小型组织，施行 DevOps 在技术上都非常具有挑战性。”

上面这段文字如果放在今天，那只是段关于 DevOps 的、稀松平常的讨论，但是如果它写于十年前，各位读者会不会感到有一些惊讶？

这段文字写于 2007 年 8 月的下旬，很快就距今整十年了，这是我所知道的业内最早的关于 DevOps 的系统性讨论，我在整理收藏夹的时候偶然发现了它，这让我突然意识到：DevOps 已经十年了。

可是，为什么雷声大雨点小？

博客网站  （据说是   被抢注了，所以他们只能加个 2，而   至今仍是个空域名）的文章“What makes dev2ops so hard anyway?” 文中还罗列了阻碍 DevOps 施行的几个因素：

• 变更结果的可靠性和可预见性
  
  

• 不同类型的变更（数据、代码、配置、内容、平台等）对系统造成的不同影响未被充分评估
  
  

• 对分布式系统各部分的变更非常难以协调
  
  

• 开发与运维的组织边界难以界定
  
  

这几个因素在今天依然阻碍着 DevOps 的施行。由于滚动更新、金丝雀测试等方法和 Kubernetes 等系统的流行，前三个阻碍有了一定的改善，但是由于方法和系统仅仅提供了操作原语，所以带来的改善十分有限。而第四个阻碍在很多组织中依然如故。

而且，这四个因素远远不是全部，我想每个正在实践 DevOps 的读者在读到这里的时候，头脑中都会闪现出其他的一些因素，例如老系统的云化和测试自动化需要很大的投入、DevOps 的工具链过于繁杂等。所以，DevOps 的施行依旧非常的困难。说到这里，作者还很应景的补充了一句：“尽管如此，DevOps 最终仍然可以施行，办法很简单，让最强的技术人员通宵加班即可。”这句话简直是神补刀，前段时间我刚好支持了一个老项目上线，那感觉简直就像是误入了一个野蛮的原始部落，这使我不禁反思：十年来，DevOps 究竟改变了什么？

公认首个 DevOps 成功案例，Flickr 的每天 10+ 次部署

2007 年，比利时独立 IT 咨询师 Patrick Debois 参与了一个政府部门的数据中心迁移项目。在这个项目中 Patrick 需要交替的和开发团队还有运维团队一起工作：第一天在开发团队跟随敏捷的节奏，第二天又要以传统的方式像消防队员那样维护这些系统，两种工作的切换令他十分恼火。正是因为这段经历，Patrick 充分体会到了开发团队和运维团队的工作方式和思维方式存在巨大差异：他们简直是活在两个不同的世界之中，两个团队的工作之间到处都是冲突。Patrick Debois 开始思索如何弥补开发团队和运维团队之间的鸿沟，这些思考的结果就是 DevOps 的雏形。

两年之后的 2009 年，John Allspaw 和 Paul Hammond 在 Velocity 大会上发表了名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲，演讲的 PPT 有五十多兆，里面充满了来自 Flickr 的高质量的图片，DevOps 也由此正式走入公众视野。演讲中有两个想法在我看来非常重要：

• 运维工作的目的并不是保持系统稳定，而是 促进业务敏捷；如此，开发和运维工作的目的就统一起来。
  
  

• 开发团队和运维团队为了促进业务敏捷，应该 打造一系列支持快速发布软件的工具和文化。其中工具包括：自动化基础架构、共享的版本控制系统、持续集成、持续部署、共享的度量和消息机器人。
  
  

近年来，自动化基础架构、共享的版本控制系统、持续集成这三种工具已经普及，而持续部署、共享的度量、消息机器人这三种工具应用的还不是很多，也没有很好的标准化，相关的开源项目还处于战国时期，不过按照目前这个趋势，想必很快也会尘埃落定。在这三种工具也得到了普及之后，前文罗列的阻碍因素会得到相当大的改善，那么，DevOps 能够随之得到普及吗？

普及 DevOps，工具才是关键


1. 警惕空谈陷阱，文化转变不一定是必要条件

很多人认为工具的普及和 DevOps 的普及是两码事，因为 DevOps 不仅仅是一系列的工具，更是一种文化；甚至很多人认为文化要比工具重要的多。Cloud Technology Partners 公司的首席架构师 Mike Kavis 曾说：“DevOps 是一种文化转变，或者说是一个鼓励更好地交流和协作以便于更快地构建可靠性更高、质量更好的软件的运动。”

但是恕我直言，我非常反对这种说法，众所周知，一个组织在成型之后再对组织文化进行根本性的转变，难度之大超乎想象，如果把文化转变作为施行 DevOps 的必要条件，那无异于把 DevOps 送上了绝路。

在我看来，DevOps 更应该是一系列工具加上如何使用这些工具的知识，鉴于任何工具都需要相应的使用知识，所以简单的说，DevOps 就是一系列工具。

让我们回顾一下，持续集成和 Scrum 都已经提出了有二十余年之久，易于工具化的持续集成在近几年已经普及，而不易于工具化的 Scrum 却没有，在很多团队里仅仅是站会都会沦为一种形式。所以，你应该明白我的意思：如果 DevOps 更多的是一种文化，那么它的普及将遥遥无期。或者说即使 DevOps 是一种文化，那也需要有工具来支撑这种文化，否则极易落入空谈。

所以，DevOps 应该像个生产软件的流水线，开发人员、测试人员和运维人员在补充了必要的知识之后，就能在这个流水线上以 DevOps 的方式生产软件。

2. 这是一种软件开发模式和方法论

还有人认为 DevOps 是一种软件开发模式和方法论，从瀑布模式到敏捷模式、再到 DevOps，一脉相承，这个观点我基本认同。我们目前在做支撑 DevOps 的产品，有次我问我们同事：“如果 DevOps 也是一种软件开发模式或者软件工程方法论，那么它如何能成为一种产品呢？之前的瀑布、迭代、螺旋和敏捷又为何没有成为一种产品？”同事答到：“因为 DevOps 吹的大。”

我不认为他是在戏谑，因为拉里•佩奇曾经说过：“只要你想的足够大，那就很难全盘皆输，即使是失败，其中往往也会隐藏着珍宝。”吹之前当然需要想，所以吹的大也就包含想的大，所以我想，即使多年以后，DevOps 潮水退去，也会留下一些由 DevOps 工具链演化成的优秀产品。而且应该有很多人还记得， 统一软件开发过程，即 RUP（Rational Unified Process），就是一种和产品相辅相成的软件开发模式和方法论，其支撑产品 Rational 几乎是上一时代最为成功的软件开发套件。虽然 Rational 很贵，很多人都没有用过，RUP 也是一种重量级方法，但是很多组织都在或多或少的应用 RUP 的某些子集，它的迭代开发、可视化建模、需求管理和变更控制在今天依然有非常好的指导性意义。

我们应该从 RUP 和 Rational 的联合运作中学到一些东西，并把它应用到 DevOps 的推广和支撑 DevOps 的产品的开发中，那么，DevOps 会成为覆盖更广、更易用和更普及的全民 RUP 吗？随着 DevOps 会诞生一些像 Rational 一样成功的产品吗？既然用户有需求，历史上也有类似模式的成功案例，那么就值得我们这些工具类的软件企业努力去做。

3. 继续生长和完善的 DevOps 工具链

另外还有一点就是，虽然很多人在诟病 Java，尤其是诟病 Java EE，但是很多其他语言的开发者非常羡慕 Java 完善的工具链和周边， 有些开发语言甚至连个完善好用的打包工具都没有。DevOps 刚好可以提供这种补充，尤其是在微服务模式下，这种补充变得史无前例的重要，Docker、Kubernetes、Istio、Namerd、Linkerd 这些开源项目，对于其他语言就像 Java 的应用服务器和 Spring Cloud，当然它们同样也可以给 Java 使用。

它们都是 DevOps 工具链和产品的必备环节和组件。这是历史上第一有望将所有开发语言纳入到同一个全流程的管理框架之中，目标一旦达成，那将是软件工业的一次重大转变。

Mike Kavis 在说明 DevOps 是一种文化的时候，曾提到很多 DevOps 团队通过编写 Chef、Puppet 或 Ansible 脚本来施行 DevOps，而 Mike Kavis 认为大量的专有脚本实际上是增加了系统的浪费，而 DevOps 提倡的是效率，这些团队的行为并没有体现 DevOps 的理念。但是在我看来，这种状况的产生正是因为工具的缺失，如今 Docker 和 Kubernetes 在很大程度上提供了标准化的部署环境和流程，让很多用户不必再花大量精力编写专有脚本，还有一个更大的优势就是，Kubernetes 可以在让系统达到用户定义的状态之后继续维持这种状态，而 Chef、Puppet 和 Ansible 的脚本则不能。

所以，我想说的是，也许 DevOps 曾经是一种文化，但是正在越来越成为、也必须成为一系列工具，文化的比重逐渐变小，直至成为非常次要的条件，因为只有这样，DevOps 才能获得广泛的应用。

写在最后

持续集成在提出了十几年之后才获得广泛应用，而 DevOps 刚刚十年，虽然 DevOps 的战线要远长于持续集成，但是让我们保持乐观，也许未来的几年就是 DevOps 的加速阶段，我们还有几年的时间来打磨支撑 DevOps 的产品，以帮助客户解决开发和运维的效率问题，帮助客户实现业务敏捷。

十年了，如果你觉得 DevOps 改变的还不够多，那么 DevOps 自身首先应该做出改变，那就是由虚无缥缈的文化，变成看得见摸得着的工具。

原创：宋潇男