你以为你以为的DevOps就是DevOps？

大版本上线前，所有开发、测试、运维甚至各级技术领导都如临大敌、打着十二分的精神熬夜加班，在夜深人静的时候，把新代码偷偷的替换到线上。紧张的几个测试回合下来，就已经发现了数个严重的问题。原本静悄悄的办公室不再保持安静，顿时各种声音四起。“这是谁开发的模块，快过来看看？”“在测试环境没有问题啊，怎么又让运维搞砸了？”“快点快点，看看部署文档里面的checklist是不是都执行了？”……

一个紧张的夜间大作战后，天亮了。红彤彤的太阳照着大地，而参与战斗的勇士们却只能眯着星星松松的睡眼，用一杯速溶豆浆和几个包子来补充能量。新版本终于上线了，现在只祈祷那脆弱的系统在上帝的保佑下平稳的度过一天。

这不是小说，这是一个我们常见的软件或者应用发布与部署的场景。

在《持续交付：发布可靠软件的系统方法》一书中，作者列出了几种持续交付的反模式，简单来说有以下几种：

（1）手工部署软件。

（2） 开发完成之后才向类生产环境部署。

（3） 生产环境的手工配置管理。

同样，在这本书中，也给出了实现持续交付的方法，那就是构建一套部署流水线。关于如何实现部署流水线的构建，不是本文的主要内容，在此不做赘述。

不得不说，这本得到第21届Jolt大奖的著作深深影响了一代人对DevOps的理解。甚至有人说，DevOps就是持续交付。

DevOps不仅仅是持续交付，持续交付仅仅是DevOps整个体系中的一个组成部分。DevOps是以精益（Lean）作为支撑的，由敏捷管理、持续交付和轻量级ITSM（IT Service Management，IT服务管理）为3个支柱的价值流体系。DevOps的本质是以消除浪费为最终目的的精益思想在IT服务交付方面的实践。

以单件流（One PieceFlow）流式供应链方式构建的JIT（Just-In-Time）和自动化是精益理论的2个核心。传统的以批量方式运作的生产模式，往往造成大量的WIP（在制品，即没有完成价值交付的半成品）积压和流转不畅，因此而带来大量浪费。而单件流模式，则以Pull（拉）的方式，以需求拉动生产流水线，并尽力减少不必要的步骤从而减少浪费，尽可能让在制品的数量降低，以达到价值的交付。

想想吧，在我们的IT服务交付链中，有多少存在浪费的地方？有多少环节出现了等待？有多少处在在制品状态的项目、软件、系统过程？

DevOps的首要目标就是解决这些浪费。

让开发和运维物理上坐在一个办公室工作不是DevOps，让开发参与运维或者运维参与开发也不是DevOps。DevOps是以精益思想为指导，以实现价值交付和杜绝浪费为最终目的，通过构建协作的文化、高效的沟通和系统集成（自动化）来实现的IT服务价值链。