九乡新闻网铁血豪情电视剧土豆:译言网 | DevOps不是个技术问题，而是个业务问题
来源：百度文库 编辑：九乡新闻网 时间：2024/10/06 00:04:43
DevOps不是个技术问题，而是个业务问题。
Since Patrick Debois called for the first DevOps Days event and unleashed the term "DevOps" upon the world, there is no denying that DevOps has evolved into a global movement.
毫无疑问，自从Patrick Debois召开第一届DevOps日活动并提出“DevOps”这个术语开始，DevOps已经演变成一个全球性的运动。
Of course, DevOps has its detractors. Negative opinions range from the misguided ("DevOps is a new name for a Sys Admin") to the dismissive ("DevOps is just some crazy Devs trying to get rid of Ops" or "DevOps is just crazy some Ops trying to act like Devs so they will be better liked") to the outright offended (whose arguments tend to defy logic).
当然，DevOps不乏反对者。反对意见不一而足，有人认为DevOps是个误导（DevOps只是系统管理的一个新名字而已，新瓶装老酒），有人对DevOps不屑一顾（DevOps只是一些疯狂开发者的疯狂想法，他们想摆脱运维人员，或者，DevOps只是一些疯狂运维人员的疯狂想法，他们想像开发者一样工作），甚至有人公开抨击（可惜的很，他们的言论往往毫无逻辑）。
在过去的九个多月时间里，我在公共论坛和客户公司内部竭力推进DevOps运动。正是在那段时间里，我开始注意到人们对DevOps存在一些常见的误解，我认为正是这些误解使得一些人在初次接触DevOps时产生消极的反应。在这里，我将尝试澄清这些误解：
DevOps不是个技术问题。
尽管在解决DevOps问题的方案中，技术是个关键的组成部分，但是，DevOps它自己本质上是个业务问题。
什么业务与DevOps有关？
The most fundamental business process in any company is getting an idea from inception to where it is making you money.
在任何公司里，最根本的业务流程都是这样：使一个最初的想法经过流程最终赚到钱。
Within that business process there are all kinds of activity that needs to happen, some technology-driven and some human-driven. This is where all of the different functions of IT come into play. Developers, QA, Architecture, Release Engineering, Security, Operations, etc each do their part to fulfill that process.需要各种各样的活动组成这个业务流程，这其中一些活动是技术驱动的，其他一些则是人驱动的。这里正是IT所有不同功能所发挥作用的地方。开发者、QA、架构、发布工程、安全、运维，它们都在这一流程中发挥自己的作用。
But if you take away the context of the business process, what have you got? You've got a bunch of people and groups doing their own thing. You lose any real incentive to fight inefficiency, duplication of effort, conflicts, and disconnects between those groups. It's every person for themselves, literally.但是如果抛开这一业务流程的上下文，看看我们还剩下什么？是的，我们有一伙人，还有一些部门，它们各自做着它们自己的分内事。但是我们失去了真正做事的动力，到处是效率低下的工作、浪费、冲突和部门间的孤立。从表面上看，每个人都在仅仅为自己工作。
But you know what else happens if you remove the context of the business process? Your job eventually goes away. Enabling the business is why we get paychecks and why we get to spend our time doing what we do.If there is no business to enable or we don't do any business enabling, this all just turns into a hobby. And by definition, it's pretty difficult to get paid for a hobby.
如果没有业务流程这一上下文，还会发生什么事呢？我们的工作将失去意义并最终消失。实现业务目标是我们得到薪水和花时间做事的原因。如果没有业务目标或者我们所做的事情根本对实现业务目标都没有助益又会怎样呢？糟糕，我们所做的一切都变成了一种爱好。想想吧，有谁会傻到给爱好付薪水呢。
The whole point of DevOps is to enable your business to react to market forces as quickly, efficiently, and reliably as possible.Without the business, there is no other reason for us to be talking about DevOps problems, much less spending any time solving them.
DevOps的立足点正在于对市场压力做出尽可能快速、高效和可靠的反应，从而实现业务目标。抛开业务，谈论DevOps问题毫无意义，跟别提花时间解决这些问题了。
DevOps听起来非常像敏捷所要达到的目标，难道不是这样吗？
If the goals of DevOps sound similar to the goals of Agile, it's because they are. But Agile and DevOps are different things. You can be great at Agile Development but still have plenty of DevOps issues. On the flip side of that coin, you could do a great job removing many DevOps issues and not use Agile Development methodologies at all (although that is increasingly unlikely).
如果DevOps和敏捷所要达到的目标听起来很相似，那是因为他们的目标就是一致的。但是敏捷和DevOps是两个截然不同的事物。我们可以在敏捷开发里做得很好，但是我们依然会面临很多DevOps问题。相反，我们完全可以不采用任何敏捷开发方法（尽管这越来越不现实），但是却在解决DevOps问题方面做得很好。
我喜欢将敏捷和DevOps描述为两个相关联的思想，它们都有一个共同的祖先，这个祖先就是精益，但是它们关注了不同的层面。敏捷深度关注于改善一个主要的IT功能（交付软件），同时，DevOps关注于对跨IT功能的流程和交互的改善（它拉伸了整个开发生命周期的长度，使其包括了运维）。
可是，我所理解的DevOps，全部是关于很酷的工具？
Technology is the great enabler for making almost any business process more efficient, scalable, and reliable. However, we have to remember that on their own, tools are just tools.
技术几乎能使所有业务流程更加高效、可扩展和可靠。但是，我们必须记住：工具始终只是工具。
It's just as likely that you'll use a new tool to reinforce bad habits and old broken processes as you will to improve your organization. It's the desired effect on the business process you are supporting that dictates why and how a tool is best used.很有可能，我们原本打算改善我们的组织，但是新工具的使用却使得原有的坏习惯和支离破碎的流程更加恶化。如果想在改善业务流程上取得理想的效果，那么我们必须明确为什么要使用该工具以及如何最有效的利用该工具。
实际上，当我们明确我们的DevOps问题究竟是什么，以及如何改善流程以减少DevOps问题时，对工具的讨论往往变得非常简单（如果还值得讨论的话）。
因为新兴的DevOps运动主要是技术人员在推动，所以很容易理解为什么人们很兴奋的直接去讨论工具。但是，在争论究竟是Puppet好还是Chef更好（译者注：Puppet、Chef都是开源的系统配置管理工具），应该围绕文件还是围绕包部署之前，也许我们更应该做的是：让所有人都知道为什么需要这些工具以及期望中的业务流程改进是什么，这才是重点！
If DevOps is about a business process then why is it called "DevOps"?
既然DevOps是关于业务流程的，那么为什么叫它“DevOps”呢？
In my opinion, one fault of the early DevOps conversations is that it wasn't immediately clear just how big the scope of this problem truly is. Now that we have a year of perspective behind us, it turns out that we have been attacking one of the biggest problems in all of business: How to enable a business to react to market forces as quickly as possible.
在我看来，早期DevOps的一个不足之处是没有直接地明确DevOps问题的真实范围，即它的问题域到底有多大。经过一年的观察和思考，事实证明，我们正在解决的是对所有企业来说最大的问题之一：如何面对市场压力做出尽可能迅速的反应从而实现业务目标。
But alas, the conversation had to start somewhere so it gravitated to the almost universal problem of conflict and disconnect between Developer culture and Operations culture. Every org chart is different, but it's fairly easy to cartoonishly divide the world into a Dev camp and Ops camp for the sake of having common reference points to discuss (even though we all know the world is much more complex and grey).可惜的是，DevOps必须从某个地方开始，于是我们碰到了一个几乎非常普遍的问题：开发者文化与运维文化之间存在的冲突和脱节。尽管每个企业的组织结构图各不相同，但是为了有个共同的讨论点，我们能够非常容易的将其划分为开发阵营与运维阵营（当然，现实世界远比这复杂和无趣）。
Within that cartoon Dev/Ops example, most of the early DevOps attention has been about improving deployment activity. Since change activity makes up the bulk of the work across an IT organization, that too was a logical and natural place to start.
如上图所示，在开发和运维之间存在着一面混乱之墙，在这种情况下，大部分早期DevOps的注意力都放在在改善部署活动上。因为部署活动构成了整个IT组织的大部分工作，所以从部署开始改善，这是一个合理而自然的选择。
也许Patrick应该将他的第一次活动称为“业务人员开发人员质量保障人员安全人员运维人员云服务用户日”或者“比敏捷更牛叉日”又或者其他的什么东西，但是我强烈怀疑有人会认为其炫耀，所以低调的结果就是DevOps叫了DevOps。