英文原文：Three Aspects of DevOps: What’s in a word 原文作者：Ben Rockwood
云和DevOps是最近非常火的两个名词，很多人都会思考它们到底是什么。
“云”这个名词，相对比较模糊，也引发了不少疑问，诸如“云到底是什么？”、“如果云真的意味着在云中，那为什么又会有私有云的概念？”。
而“DevOps”，则更让人迷惑，对于这个名词，不同的人会有不同的理解和认识。
针对DevOps，至少有三种不同的定义，我会一一列举出来，以便大家重新完善自己的理解。
为了达到这个效果，我会把Dev和Ops作为两个关键词，然后在它们中间加入一个操作符，这个操作符表明了不同的人对DevOps的不同理解。
事实上，三种不同的定义，也就是DevOps发展演进的三个阶段：
第一阶段：Dev > Ops
在这个阶段，Ops多会遵循Dev的方法和思路。
根据我的预测，DevOps群体中90%的人处于第一阶段。
这个阶段是DevOps的开始阶段，也是DevOps群体应该关注最多的阶段。
在这个阶段，会有如下的一些情况出现：
（1）
在这个阶段里，IT服务人员、系统/网络管理员会把自己定位为“Ops（Operations）”。
对于大多数人来说，Operations是一个比较新的概念，很多人不会认为自己是从事Operations的，而会认为自己是从事IT（信息技术）的。
如果你所负责的仅仅是运行一个网站，那“IT”的确比较符合。
但在企业中，你所做的其实并非运维一个网站本身，而运维的是公司的业务和生意。
（2）
敏捷，正在被逐步的应用到Ops中来。
从某种程度上讲，敏捷是在逐步回归到它的设计初衷。
我们会尝试将一些最佳实践（如ITIL）与敏捷开发原则相结合，但经过事实证明，类似SCRUM这样的敏捷方案并不适用于Ops，不仅效率无法保证，而且每个公司都需要对敏捷方案进行不同的个性化调整和适配。
不过，实践表明，可视化的工作流和工作进度控制方法，却可以很好的融入到Ops中来。
这也说明了，我们需要在“做对的事”和“对的做事”之间不断的平衡，但这需要些时间。
（3）
为虚拟化而重构。
我们平时所讲的“云的世界”其实并不准确，因为其他人在建立一个大规模的内部VMware部署集群或一个外部的AWS部署集群时遇到的各类问题，在你建立集群时也同样会遇到。
这就是DevOps的现状，这也就是DevOps Toolchain项目所要解决的问题。
对于配置管理（从自动化的角度，而非ITIL的角度）来讲，要达到一种平衡。
目前有三家公司在进行这方面的宣传推广，他们是Puppet Labs、OpsCode和DTO Solutions。
（4）
监控逐渐成为重要环节。
正如虚拟化引发我们在配置管理和命令控制方面重新评估现有工具一样，监控也需要不断的前进，面临新的挑战。
这正是我们需要不断改造监控系统的时候，我们需要扩展其功能，重新设计其日志和趋势分析功能。
或许，现状还能维持，但我们无法避免的需要接触和尝试所有有关报警、日志和趋势分析方面的新技术。
你或许需要克服掉接触新事物的恐惧心理，比如尝试使用基于ruby编写的工具集。
第二阶段：Dev < Ops
在这个阶段，Ops的方法论和经验会被Dev所采用。
据我估计，在DevOps群体中，当前仅有不到10%处于这个阶段。
这个阶段通常预示着Dev和Ops开始走向结合。
如下的一些事情通常会发生在这个阶段：
（1）
无处不在的度量。
这是John Allspaw所拥护的东西。
在第一阶段中，Ops便已经开始进行各类度量，但那是由Ops来收集并受益于Ops。
不过，在第二阶段中，Dev会越来越关注度量，并开始花精力在这上面。
不仅OS层面需要度量，应用程序的代码和策略也需要度量。
因此，Ops所建立的仪表盘需要吸纳更多更广泛的度量信息。
（2）
实现持续集成（Continuous Integration）。
Ops是无法独自实现CI的，所以和各角色合作是必不可少的。
（3）
工具和实践的交叉融合。
开发者开始诚心地关注Ops日常工作和挑战的时候，便是需要在Dev和Ops之间建立统一工具集的时候。
第三阶段：Dev <> Ops
在这个阶段，Dev和Ops实现结合，分担责任，分享工作。
我想这是DevOps的基本原则，坦率的讲，这是DevOps的真正含义。
DevOps更多的内容集中在第一阶段和第二阶段中，但第三阶段仍然是一个未定型的阶段，这是我们努力的方向。
在这个阶段，常常会发生如下这些事情：
（1）
Dev和Ops责任共担，不会互相推卸责任。
Dev会负责创建项目，Ops负责部署和维护项目，双方共同对项目的成功负责。
各角色的责任并非在代码提交、部署完成或某一环节后就结束了。
在业务下线前，双方都会对业务负责。
业务的性能瓶颈，需要Dev/Op共同解决。
当业务出现问题或异常时，无需设定负责人，因为双方是一个团队，需要共同去解决。
（2）
开发者也需要轮岗。
这种方式是通过“WebOps商店”流行起来的。
这种方式并不是对任何企业都可以直接适用的，但是基本的原则和思想是普适的。
应该针对开发问题，建立轮岗机制，在业务的代码贡献者中轮流设定“问题第一接口人”。
（3）
持续集成不断升级。
在这个阶段，Dev和Ops不再是两个团队，而是一个有不同侧重的跨角色团队。
无论你是代码开发者或系统管理员，新的工具、新的实践、新的项目都平等地呈现在大家面前。这样，便可以毕其功于一役。
总结
你正处在DevOps的转变进程中么？
大多数的人正在优化已有的运维实践和工具。
或许你每周的Dev和ops例会只是简单的把名字更改成了“DevOps周例会”。
你或许认为第三阶段将不可能发生在你的公司。
每个人都处在不同的环境中，但也都处在同一个不可阻挡的趋势中。
这个趋势的第一步是改变传统，请相信，DevOps行动已经开始。
从上述理论来看，你或许会发现使用DevOps作为职位名称，是存在一些问题的。
这个职位名称到底指的是三个阶段中的哪一个？
是指第一阶段中处于运维工具和运维实践改革中的系统管理员？
还是第二阶段中使用持续集成的开发者？
还是指任何一个对整个业务负责的IT工作者？
描述“DevOps到底是什么”的内容，并不是新的。
但他新的地方在于“能够使从老的传统转变到新的传统并能让大家接受”。
在以前，希望越界的员工往往会受到打击，因为他们过于多管闲事、过于冒进。
但DevOps或许能改变这一切。像cloud一样，DevOps不仅一个流行名词，它还向我们证明了开启一个新世界的可能性，在这之前，我们是不敢想象的。
曾经，使用AWS（Amazon Web Services）是不可想象的，而现在大家已经有了认同和共识。
曾经，如果开源解决方案中不采用Tivoli，是非常疯狂的决定，而现在这是很受欢迎的。
曾经，要求开发者在代码中加入度量逻辑是会被取笑的，而现在这是被鼓励的。
所以，我应该拥抱所在行业的这个时代，多和它保持对话，抓住新的机遇！
