传统的软件交付过程是通过架构、业务、技术运维、保障等团队之间一步一步把交付物交给下一个环节，最后产生交付软件的价值。这种交付方式的一个明显缺点是各角色仅关注于自己本身的工作，在中间的流通环节产生了很多不必要的浪费，如时间成本和沟通成本等;同时，这种阶段性的交付通常时间较长，一旦产生问题造成的影响也较大。
敏捷开发是为解决这一问题而提出的解决方案。在这种方法里，业务人员也深入到开发当中，这样需求、开发、测试前面三个环节被打通了，但是，到部署的时候仍会出现问题：因为项目是直到最后才交给运维人员部署到线上，部署时经常出现比如IP问题、机器资源问题、与线上已有程序的冲突等，要花费大量时间解决。出现这种结果是因为，虽然整个团队共同的目标是项目的最终实施，但是作为两个不同角色的部门，开发团队和运维团队对具体的目标仍有不同的追求。
那么如何解决开发团队和运维团队之间的这种隔阂?DevOps应运而生。
百度DevOps团队：从三个月到三周
百度项目管理部高级架构师乔梁
10月22日，在 “QCon杭州2011全球企业开发者大会”上，来自百度项目管理部的高级架构师乔梁与大家分享了百度的一个交付团队是如何利用DevOps，在半年的时间内让交付周期从每三个月一次提升到每三周一次的。
“我改变了他们的工作方式”，乔梁说，新的制度的确影响到了团队的日常工作，在开始的三个月，团队的开发速度降了下来。不过这种代价是值得的：三个月之后，团队的交付周期就变成了三周一次，并在接下来的三个月里一直保持这种频率。
实际上，乔梁说，三周交付并不是该团队的极限，还可以优化到两周或更少，不过，在一种工作方式产生变革并取得成功的结果后，乔梁认为，应该把这种结果持续一段时间以使之固化下来，然后才可以进入下一个阶段。
转变的过程当然是痛苦的，乔梁说，“但是得到的收益也很大”——DevOps带给团队的“不仅是技术上的改变，还有行为上的改变”。
很多与会者都关心这种工作方式的可行性，在会后的提问中，大家的焦点也集中在这一块：开发团队和运维团队真的能够那么协调的工作吗?他们是怎么解决一些工作和技术上的冲突的呢?
在会后的交流中，乔梁向51CTO记者表示，目前DevOps这种方式尚没有在百度的整体技术团队中应用，但是他所负责的high level的团队使用这种方式取得了明显的效果。而且，把交付周期变更为三周一次，是这个团队的开发人员和运维人员共同提出的，对于KPI进行整体考核的要求，也是团队成员提出的。
“你要培养一种文化，要建立一种机制。让运维人员参与到更早——只要项目开始，启动阶段就要把运维人员引入进来，一起开个会，让他们知道项目的进程”。同时，开发人员也需要了解到运维人员的工作状态，因为一旦他们了解到运维人员每天要处理多少条告警，再开发的时候就会注意。据乔梁介绍，有些公司是通过轮岗的方式来促成这种相互理解的。“最后一点也是最关键的一点”，乔梁说“任何一种产品的成功，不只是你开发团队的成功。我希望DevOps里能为同一件事请来鼓掌，来建立一种沟通协作的文化”。
DevOps首先是一种文化转变
改变交付团队各个环节各自为政的局面，建立一种全新的工作方式，这是DevOps的第一步。然后，我们需要检视开发运维过程中的每一个环节，减少不必要的浪费。
这些浪费包括：一些容易造成高风险问题的不必要的多分支开发;问题被发现的时间推迟;基于流程平台的沟通;浪费很多人工在常规的例行工作上等。
为减少浪费，DevOps团队做了很多工作。首先，持续交付的一个前提是持续集成;其次，将大量的工作通过自动化手段来实现;部署脚本，所有的变更都走同样地流程;所有的事情都要做版本控制。DevOps要求所有的人都要做主干开发。
提高工作效率，自动化是一个很重要的手段。乔梁在演讲中也多次提到“自动化”这个特点，那么自动化是不是DevOps的一个前提呢?
在回答51CTO记者这个问题的时候，乔梁表示，“Devops本身第一Culture(文化)是最重要的，你得让所有人都参与进来，至于自动化，它只是一种手段一种工具，因为当你用传统交付的方法你的人力的消耗会很大，会对运维、测试等造成很大的压力，如果你不解决这个问题的话，那你测试和运维都不会同意的”。
至于实现自动化脚本的手段，乔梁介绍百度是有自己的一套管理运维平台，其他企业可能会通过puppet之类的工具去做。在不同的环节都有不同的自动化工具可以选择。“你不用这些工具没关系，但是比如环境准备，还有应用度等等你必然要有一套自己的方式。” 乔梁说。
针对目前DevOps在国内外的发展情况，乔梁说，DevOps本身还是比较新的东西，国内外并没有很大的差距，“我觉得还是意识层面的差距。因为DevOps里面很多技术很多国内的公司也在用，但是他还是把我只把我自己运维的这一部分做了，他连不起来，大家还有隔离。”
正如乔梁在一张演讲PPT中所写道的：“DevOps=Culture+Tools”，它是工作思路的转变辅以适当工具的结果，首要的还是文化转变——“包括我们之前提到的敏捷开发，基本上也是一种文化的变化，而不是一种工具的变化。”乔梁说。
【编辑推荐】
