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

标签: devops 技术 问题 | 发表时间:2011-02-04 22:39 | 作者:ronghao Allen
出处:http://www.yeeyan.org

原作者:
来源DevOps is not a technology problem DevOps is a business problem
译者ronghao

DevOps is not a technology problem. DevOps is a business problem.

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。


添加新评论

相关文章:

  基于Web的IT部门管理

  什么是DevOps?

  月球采矿业

  3款增强实境开发工具介绍

  风雨20年:我所积累的20条编程经验

相关 [devops 技术 问题] 推荐:

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

- Allen - 译言-电脑/网络/数码科技
来源DevOps is not a technology problem DevOps is a business problem. 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..

DevOps的“定义”:DevOps究竟要解决什么问题?

- - InfoQ - 促进软件开发领域知识与创新的传播
近些年来,DevOps 在我们身边出现的频率越来越高了. 各种大会上经常出现 DevOps 专场,行业内的公司纷纷在都招聘 DevOps 工程师,企业的 DevOps 转型看起来迫在眉睫,公司内部也要设计和开发 DevOps 平台……这么看来,DevOps 似乎无处不在. 可回过头来想想,关于 DevOps,很多问题我们真的想清楚了吗.

不同技术团队的配合问题及DevOps(不错的文章,来自infoq)

- wangdei - BlogJava-首页技术区
在IT企业里产品从创意到交付给用户,从整体上看是由技术部门负责,但如果深入到技术部门,会发现由不同的技术团队负责不同的部分或者阶段. 一般会分产品团队、开发团队、测试团队以及运维团队,在互联网公司里,运维团队一般还分基础运维和产品运维两个团队,基础运维负责基础设施(包括机架、网络、硬件)和操作系统的安装,为整体公司的所有产品提供基础设施的运维服务.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.

你的团队里没有DevOps文化?

- Quantum - LinuxEden开源社区-Linux伊甸园
本文是从 Do you have a DevOps Culture. 全球很多的系统负责人和程序开发者都在 撰写 、 聚会 和 讨论 关于DevOps的事:如何能更加有效的协作、让我们更快的创造商业价值. 阅读全文 | 邮件推荐 | 评论回复.

再谈DevOps实践和价值(12.11)

- - 人月神话的BLOG
今天再谈下DevOps过程实践和实际的收益价值问题. 对于DevOps先引用网上的一段总结如下. 这里我们先分析一下DevOps是什么. 大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化,其实这样理解很片面. 其实我们不难从Patrick提出DevOps的过程得出结论,DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应,也就是DevOps = Dev Agile Ops Agile.

2019十大最佳DevOps工具

- - IT瘾-tuicool
【编者的话】DevOps落地重要的一方面是选好工具集,本文介绍了最流行的DevOps工具. 开发和运维的集成翻开了软件开发的全新篇章. 如果你还是DevOps的新手,或者正在寻求改进已有流程的方法,那么第一道关卡就是调研哪些工具最适合你的团队. 本文整理了工具列表,为大家选择所需的工具提供详实的参考信息.

Twitter技术问题导致抓取和URL规范化问题

- iVane - SEO每天一贴
6月27号Google工具条PR更新了一次,然后很多人注意到Twitter首页PR降为零. (Google首页也降到9,不过这不是重点. )7月19号Google居然又更新一次工具条PR. Google更新工具条PR值从一个月一次变到3个月一次,甚至半年一次,所以这次不到一个月就再次更新有点蹊跷. 据目前透露的信息,这次更新PR貌似主要就是为了修正Twitter PR值的问题.