(翻译)正确实施DevOps-The Lay of the Land

原文地址:http://www.drdobbs.com/architecture-and-design/getting-devops-right-the-lay-of-the-land/240062639，作者Scott W. Ambler。

对于不同的利益相关人DevOps含义不同，但是基本组成部分是相同的。

在过去的1，2年，媒体上有很多关于DevOps的争论。有关DevOps的声音越来越杂乱，导致听众也越来越困惑。DevOps提供了针对IT市场的敬业精神和生产力一个潜在增长点。但是，与在它之前的所有运动一样，误解和误用DevOps是非常危险的。本文章以及随后的系列文章，将提供有条理的严肃的建议来解开这些困惑。

让我们先从一些定义开始。首先，在本文章中我会用两种方式表述词条“产品”。当我使用IT短语“发布产品”时，如果上下文与商业产品有关，我也隐含了“发布到市场”。当我使用单词“产品”时，意味着运营和支持（有时也被称为“help desk”）的结合。一些组织认为运营和支持是两个概念，但其它组织结合了这两个概念。”DevOps”是开发（development）和运营（operations）两个单词组成的混合词。在该上下文中的开发包括了解决方案被发布到产品环境之前发生的所有活动，即项目初始化时明确初始概念一直到可以部署。DevOps上下文中的运营包括了部署之后的所有活动。即“与产品相关的东西”（production stuff），包括了对所部署的解决方案的运营和支持。

定义DevOps词条，说起来容易做起来难，这是因为需要综合考虑多个视角，即主要的DevOps利益相关者的视角。你的谈话对象不同，DevOps是什么的定义的回答也不相同。DevOps的利益相关者以及他们的视角如下：

*开发人员，尤其是有经验的敏捷开发人员，认为DevOps是交付产品的一个持续的流程，有可能一天数次。

*运营专家往往认为DevOps提倡与开发团队建立更有效的关系，不仅包括整个开发生命周期，也包括解决方案被部署到产品环境的过程。有经验的运营人员也意识到他们内部过程往往基于ITIL或ITSM，需要被精简以便更好的与开发团队协作。

*支持专家（有时也被称为help desk专家）对DevOps的认识与运营专家类似，但稍微有点区别：他们想和开发团队一起工作来保证解决方案被发布到产品环境前他们的需求能被正确理解和满足。他们也想确保有一个流程，一旦当解决方案被使用后，能够处理需求更改（包括缺陷）。

*高级管理团队认为DevOps是可以通过简化所有人一起工作的方式从而提高IT部门整体效率的一种成果。

规范DevOps

现在来看看规范DevOps。图1展示了采用规范DevOps前以及规范DevOps努力想达到的效果的对比图。目前在很多组织中，开发团队和运营团队间尽管有流程和组织级障碍存在，但仍努力达到有效协作。

开发团队的部署并无规律-“快速”的团队一年进行1到2次发布，偶尔为发现的产品问题打个补丁。

运营团队反而推进变更请求，包括缺陷报告，返回给开发组织。这两个组织一起协作就可以保证这些活动是成功的，但仍有一个明显的地方可以提高。规范DevOps通过增加开发，运营和支持人员之间的协作这一策略来提高这一点。向开发团队引入持续交付实践，向IT引入新的组织级架构；采用商业智能工艺和技术来支持开发智能和运营智能，即支持改进的IT管理。不规范的DevOps和规范的DevOps的不同之处在于，规范的方式以整体视角来考虑所有DevOps利益相关者的渴望，而不仅仅关注于一个视角。

图1：缩小DevOps差距

要想成功实践DevOps，你需要在5个方面实现提高：人，准则，实践，产品及流程。这些问题以从高到低的优先级顺序排列。人及他们相互交互的方式是任何IT努力达到成功的决定因素。而规范DevOps清楚的需要人们重新思考他们的技能，如何定义自己的角色，如何一起工作。IT组织采用DevOps需要重新思考他们所做的决定的底层准则。例如，采用与业务更紧密交互的准则将激励他们采用更频繁的发布产品的方式。组织需要采用诸如持续集成，持续部署，运营智能，协作支持等实践。如果他们决定采用DevOps，有更多新鲜的事情需要去做。新的产品，包括开发工具，商业智能工具，以及运营监控工具等需要被采用。最终，流程框架（比如规范敏捷交付，DAD），将DevOps策略变为开发流程，还有ITIL或ITSM的更新版也需要考虑是否使用。

误解

组织运行DevOps似乎有着普遍的方式。我担心这样的观点，即“云=DevOps”，这种观点似乎越来越受欢迎。采用云技术可以早点接触到DevOps的一些方面，但只是5个方面的其中之一（即产品方面）。相似的，一些厂商的工具驱动的消息工具，以及一些开源社区（的产品）也令人不安，新的工具仅仅是DevOps大局观的一部分而已。第三个误解之前有提到过，即过于关注于一个DevOps利息相关人的视角。特别常见的是过于关注开发过程，因为效果显而易见，特别是持续交付实践可以带来潜在的更高效的提高。该问题是仅关注了5个方面的实践部分。

这些误解，确定会导致他们遇到问题，在之后的文章中会详细讨论这些问题的解决之道。

---

Scott Ambler 在IBM Rational工作了6年时间，在这里他帮助客户采用及适应敏捷技术。现在是该领域的咨询师。他也是Dr.Dobb’s的长期撰稿人。