DevOps不是个技术问题，而是个业务问题

　　当然，DevOps不乏反对者。反对意见不一而足，有人认为DevOps是个误导（DevOps只是系统管理的一个新名字而已，新瓶装老酒），有人对DevOps不屑一顾（DevOps只是一些疯狂开发者的疯狂想法，他们想摆脱运维人员，或者，DevOps只是一些疯狂运维人员的疯狂想法，他们想像开发者一样工作），甚至有人公开抨击（可惜的很，他们的言论往往毫无逻辑）。

　　在过去的九个多月时间里，我在公共论坛和客户公司内部竭力推进DevOps运动。正是在那段时间里，我开始注意到人们对DevOps存在一些常见的误解，我认为正是这些误解使得一些人在初次接触DevOps时产生消极的反应。在这里，我将尝试澄清这些误解：

　　DevOps不是个技术问题。

　　尽管在解决DevOps问题的方案中，技术是个关键的组成部分，但是，DevOps它自己本质上是个业务问题。

　　什么业务与DevOps有关？

　　在任何公司里，最根本的业务流程都是这样：使一个最初的想法经过流程最终赚到钱。

　　需要各种各样的活动组成这个业务流程，这其中一些活动是技术驱动的，其他一些则是人驱动的。这里正是IT所有不同功能所发挥作用的地方。开发者、QA、架构、发布工程、安全、运维，它们都在这一流程中发挥自己的作用。

　　但是如果抛开这一业务流程的上下文，看看我们还剩下什么？是的，我们有一伙人，还有一些部门，它们各自做着它们自己的分内事。但是我们失去了真正做事的动力，到处是效率低下的工作、浪费、冲突和部门间的孤立。从表面上看，每个人都在仅仅为自己工作。

　　如果没有业务流程这一上下文，还会发生什么事呢？我们的工作将失去意义并最终消失。实现业务目标是我们得到薪水和花时间做事的原因。如果没有业务目标或者我们所做的事情根本对实现业务目标都没有助益又会怎样呢？糟糕，我们所做的一切都变成了一种爱好。想想吧，有谁会傻到给爱好付薪水呢。

　　DevOps的立足点正在于对市场压力做出尽可能快速、高效和可靠的反应，从而实现业务目标。抛开业务，谈论DevOps问题毫无意义，跟别提花时间解决这些问题了。

　　DevOps听起来非常像敏捷所要达到的目标，难道不是这样吗？

　　如果DevOps和敏捷所要达到的目标听起来很相似，那是因为他们的目标就是一致的。但是敏捷和DevOps是两个截然不同的事物。我们可以在敏捷开发里做得很好，但是我们依然会面临很多DevOps问题。相反，我们完全可以不采用任何敏捷开发方法（尽管这越来越不现实），但是却在解决DevOps问题方面做得很好。

　　我喜欢将敏捷和DevOps描述为两个相关联的思想，它们都有一个共同的祖先，这个祖先就是精益，但是它们关注了不同的层面。敏捷深度关注于改善一个主要的IT功能（交付软件），同时，DevOps关注于对跨IT功能的流程和交互的改善（它拉伸了整个开发生命周期的长度，使其包括了运维）。

　　可是，我所理解的DevOps，全部是关于很酷的工具？

　　技术几乎能使所有业务流程更加高效、可扩展和可靠。但是，我们必须记住：工具始终只是工具。

　　很有可能，我们原本打算改善我们的组织，但是新工具的使用却使得原有的坏习惯和支离破碎的流程更加恶化。如果想在改善业务流程上取得理想的效果，那么我们必须明确为什么要使用该工具以及如何最有效的利用该工具。

　　实际上，当我们明确我们的DevOps问题究竟是什么，以及如何改善流程以减少DevOps问题时，对工具的讨论往往变得非常简单（如果还值得讨论的话）。

　　因为新兴的DevOps运动主要是技术人员在推动，所以很容易理解为什么人们很兴奋的直接去讨论工具。但是，在争论究竟是Puppet好还是Chef更好（译者注：Puppet、Chef都是开源的系统配置管理工具），应该围绕文件还是围绕包部署之前，也许我们更应该做的是：让所有人都知道为什么需要这些工具以及期望中的业务流程改进是什么，这才是重点！

　　既然DevOps是关于业务流程的，那么为什么叫它“DevOps”呢？

　　在我看来，早期DevOps的一个不足之处是没有直接地明确DevOps问题的真实范围，即它的问题域到底有多大。经过一年的观察和思考，事实证明，我们正在解决的是对所有企业来说最大的问题之一：如何面对市场压力做出尽可能迅速的反应从而实现业务目标。

　　可惜的是，DevOps必须从某个地方开始，于是我们碰到了一个几乎非常普遍的问题：开发者文化与运维文化之间存在的冲突和脱节。尽管每个企业的组织结构图各不相同，但是为了有个共同的讨论点，我们能够非常容易的将其划分为开发阵营与运维阵营（当然，现实世界远比这复杂和无趣）。

　　如上图所示，在开发和运维之间存在着一面混乱之墙，在这种情况下，大部分早期DevOps的注意力都放在在改善部署活动上。因为部署活动构成了整个IT组织的大部分工作，所以从部署开始改善，这是一个合理而自然的选择。

　　也许Patrick应该将他的第一次活动称为“业务人员开发人员质量保障人员安全人员运维人员云服务用户日”或者“比敏捷更牛叉日”又或者其他的什么东西，但是我强烈怀疑有人会认为其炫耀，所以低调的结果就是DevOps叫了DevOps。

　　声明：本文已获原创作者Damon Edwards的许可。

　　原文链接：http://article.yeeyan.org/view/139551/170318

　　英文链接：http://dev2ops.org/blog/2010/11/7/devops-is-not-a-technology-problem-devops-is-a-business-prob.html