DevOps近成了热词，望文生义，你也能猜个八九不离十，它是在说“研发团队”与“运维团队”之间的那点事儿。那么，到底什么是“DevOps”呢？

　　WikiPedia上说：“DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。”这恰好体现了精益管理中的客户价值原则，即：以客户的观点来确定企业从设计到生产交付的全部过程，实现客户需求的大满足。我们也可以把DevOps看作是一种能力，在缺乏这种能力的组织中，开发与运维之间存在着信息“鸿沟”。

　　如何获得这种能力呢？关键有两点：一是全局观：要从软件交付的全局出发，加强各角色之前的合作；二是自动化：人机交互意味着手工操作，应选择那些支持脚本化、无需人机交互界面的强大管理工具，比如各种受版本控制的script，以及类似于Nagios这样的基础设施监控工具，类似于Puppet、Chef这样的基础设施配置管理工具。

　　有人评论说：“针对目前国内情况，DevOps还是很遥远。也许只有行业的公司，或者新成立的公司会有这样的尝试。大多数的企业还未开始进行敏捷的推进，传统的重重阻碍会使敏捷的推进进程无期。” DevOps真的离我们有那么远吗？DevOps应该从哪里开始呢？

　　一、让数据说话

　　让我们看一看百度某产品线在半年内的变化吧。首先要说明两个百度术语。“提测”是指某个项目开发完成后，在正式上线前，将其提交给测试组进行测试的活动。对于客户来说，“提测”这个动作本身并不增加什么价值，但也需要花费一定的时间。“上线”是指某个项目验证合格后，将其部署到服务器的过程，其中包括“上线申请”和“实际部署”两个活动。也许在各公司中对这两个活动叫法不同，但在软件生命周期中，“提测”、“上线”这两件事无论花长时间，大家可能都不会感到奇怪。下面两张图是该产品线进行改进之后的对比数据。

　　从图中不难看出，提测和上线部署的效率已大大提高。象百度这样的互联网企业，产品线多得数不清，几乎每个产品线每周都有新功能部署。仅从这两个数据来看，其收益可想而知。那么，半年前的状况是什么样的呢？

　　二、流程建模

　　既然DevOps关注于价值交付的全过程，那让我们看看该产品线常见的交付过程吧。

　　对于单个项目来说，它大体上是一个典型的瀑布开发过程。首先是需求收集与整理，撰写MRD（Marketing Requirement Document）或总体设计后，进行评审。如果涉及到多模块，每个模块的开发人员会对各自负责的模块进行详细设计，给出大致的开发计划，并商定联调时间点。之后，开发人员会从主干上拉出项目分支，并在该分支上进行开发。当到后联调点时，几个开发人员才会在将代码合在一起，进行联调。当调通之后，开发人员再申请提测。测试人员接到提测申请单后，进行测试，记录Bug，通知开发人员修复，直致质量达到标准。之后，开发人员会填写上线申请单，经运维人员确认后，运维人员操作进行上线部署工作。如图所示。

　　开发的复杂性还在于：该产品线有很多并行项目，为了避免互相干扰可能带来的冲突，每个项目启动后都会重新在主干上拉出分支，在上线前才进行合并。如下图所示。

　　另外，并行项目太多，导致每个开发人员会同时参与多个处于不同阶段的项目。那些周期较长的项目虽然会被分解成多个迭代，但每个迭代内都是同样的开发流程，只是后仅有一次上线而已。

　　总而言之，突出的问题表现在：

　　1、同一角色多个人员的合作开发；

　　2、各角色部门之间的协作以各自的产品物为目标，如MRD、产品代码、测试用例、上线操作单；

　　3、基于人机交互方式的内部流程管理平台。