theagileadmin.com 原文链接
Ernest Mueller, Aug 2, 2010 – Last Revised Dec 7, 2016
翻译：邵栋 2017.5.21
DevOps作为一个术语，包含了一组概念，虽然这些概念并不全是新的，但 DevOps已经演化成了一个在整个技术社区迅速蔓延的运动。像任何新的和流行的术语一样，人们对它有很多困惑，有时是相互矛盾的印象。在本文中，我尝试给出一个有效的DevOps定义。我将这个定义作为一个框架，以便我们可以更清楚地讨论DevOps涵盖的各种问题。像“质量”或“敏捷”一样，DevOps是一个非常大的概念，需要掌握很多细节才能完全理解。
[2016年12月更新：我们非常高兴发布了The Agile Admin的新资源。我们为lynda.com组织了一个全面的DevOps基础课程，该课程涵盖从DevOps历史到DevOps功能领域的所有内容，我们希望你喜欢它。]
DevOps的定义
DevOps是一个与两个相关趋势有关的新词。第一个趋势是“agile system administration, 敏捷系统管理”或“agile operations, 敏捷运维”；它采用了较新的敏捷和精益方法来进行运营。第二个趋势是，在开发和运营服务的过程中，我们对于开发和运维人员在开发生命周期各个阶段的协作价值，以及运营在日益增长的面向服务的世界中的重要性（cf. Operations: The New Secret Sauce），有了更广泛的了解。
Jez Humble向我提出的一个定义是，DevOps是
“致力于研究创建、演化和运营大规模快速变化弹性系统的跨学科实践社区”。
这是个不错的定义，但它可能有点太深奥和偏向于互联网创业公司。我相信可以更精确地定义DevOps为：
DevOps是在整个服务的生命周期中，运维和开发工程师共同参与的，从设计到开发过程到生产支持的完整实践。
对此定义的一个重要推论是，对比以前实践， DevOps有了一个重要的变化：
DevOps中运维人员使用许多与开发人员相同的技术来进行系统的工作。
这些包括敏捷开发过程中使用的的从源代码控制到测试等一系列技术。
为此，“DevOps”不区分不同的系统管理子分支 - “Ops”是系统工程师，系统管理员，运维人员，发布工程师，DBA，网络工程师，安全专业人员以及其他各种有关的职务的通称。 “Dev”被用作开发人员的缩写，但实际上它更为广泛，意味着“所有参与开发产品的人”，包括产品，质量保证 QA和其他相关工作人员。
DevOps与敏捷和精益方法有很强的关联。旧的观点认为“Dev”方面是“制造者”；而“Ops”方面则是“ 处理产品被制造出以后工作的人” - 认识到行业中这两者被分割所造成的伤害是DevOps背后的核心驱动力。这样，DevOps可以被解释为敏捷软件开发的扩展。敏捷软件开发描述了客户，产品管理，开发人员，和（有时）QA的密切协作，以填补各自之间的鸿沟，并快速迭代以得到更好的产品。DevOps说：“是的，但服务最终交付以及应用程序和整个系统如何交互也是实现客户价值的基本部分，因此产品团队需要将这些内容作为最高优先级考虑。”从这个角度来看，DevOps只是将敏捷原则扩展到超越“代码”边界的完整交付服务。
进一步定义
DevOps对于不同的人来说意味着很多不同的东西，因为它的讨论涵盖了很多方面。人们谈论DevOps是“开发和运营协作”，或者将“将代码视为基础设施”，或者是“使用自动化”或“使用看板”或“工具链方法”或“文化”或许多看似松散相关的内容。 进一步定义它的最好方法是借鉴和它类似复杂的一个词-敏捷开发。根据维基百科和敏捷宣言，敏捷开发由四个不同的“层次”组成。 我添加了第五个，工具级别 - 敏捷和 DevOps可能会太痴迷于工具，但假装工具不存在也是不对的。
敏捷价值观
顶级哲学，被认同在“敏捷宣言”中。 这些是塑造敏捷的核心价值观。
敏捷原则
支持这些价值观的被广泛认同的策略方法。 “敏捷宣言”中描述了十二项更具体的原则。你不必认为将它们全部实现才是敏捷，但如果你不认可他们中的许多内容，你可能不是在做敏捷。
敏捷方法
根据上述原则的更具体的流程实现。 XP，Scrum，您自己的自制过程 - 这是哲学让位于“我们打算如何在现实生活中实现”的操作剧本的地方。它们都不是强制性的，只是可能的实现。
敏捷实践
高度具体的战术技术，倾向于与敏捷方法结合使用。这些实践并不是专属敏捷的，但许多敏捷实现已经看到了采用它们的价值。比如站立会议，计划扑克，产品需求条目（backlog），持续集成，开发人员用于工作的所有特定工件（artifacts）。
敏捷工具
团队根据这些方法进行工作实践的具体技术实现。JIRA Agile（又名Greenhopper），planningpoker.com等。
理想情况下，较高级别可以赋予较低级别内容价值 - 在不了解基本原理的情况下使用某种工具和实践的人员或组织可能看到，也可能看不到工具和实践的价值，这种“货物崇拜”方法通常被认为具有次优结果。
我认为人们谈论的DevOps的不同内容可以直接映射到这些相同的级别。
DevOps价值观
我认为，敏捷宣言有效地包含了基本的DevOps价值观，或许应当更加强调将整个服务或软件完全交付给客户，而不是简单的“可工作的软件”。以前有一些对DevOps的定义，如Alex Honor的“人超越过程，超越工具”，呼应了敏捷宣言的内容，并鼓励开发和运维的协作。
DevOps原则
没有一个所有人都同意的列表，但有几个广泛接受的- 约翰·威利斯的“CAMS”，詹姆斯·特恩布尔的定义。 “基础设施作为代码”是经常被引用的DevOps原则。我在“DevOps宣言”中削减了现有的敏捷宣言和原则。我个人认为，DevOps在概念层面上主要只是敏捷原则的扩大，它包括系统开发和运维，而不是停止在代码完成阶段。
DevOps方法
一些方法是一样的；您可以使用在运维中使用Scrum，看板等（虽然通常更倾向于将运维、开发、QA和产品团队集成在产品团队中）。存在一些更特别的方法，如可视化运维风格的变更控制，使用事件命令系统进行事件响应等。这些方法的集合正在增长：例如，更周全的监测方法是常见敏捷方法未明确定义的领域。
DevOps实践
作为实现上述概念和过程的一些特定技术。持续集成和持续部署，“使您的开发人员随时在线”，使用配置管理，指标和监控方案，工具链工具的方法...使用虚拟化和云计算也是一种常见的做法，用于加速现代基础设施。
DevOps工具
用于实施这些原则的工具。在DevOps世界中，发布（jenkins，travis，teamcity），配置管理（puppet，chef，ansible，cfengine），编排（zookeeper，noah，mesos），监控，虚拟化和容器化（AWS，OpenStack ，wagrant，docker）等等。而与敏捷一样，说一个工具是“DevOps工具”，意味着它将神奇地将DevOps带给你是不正确的。当然，正在开发的一些具体工具，其目的是促进上述原则，方法和实践，并且符合对DevOps的理解，应该包含在DevOps 工具中。
就像它的前辈 Agile 一样，DevOps有些难以定义。 但尽可能的给出 DevOps 的定义是值得的。 当停留在纯粹的哲学层面时，两者可能看起来都像老生常谈，受到批评“你只是告诉我把工作做的更好些...”,但相反，只有实践而没有更高层次的指导会变成货物崇拜。 “我做这个只是因为Scrum书上是这么说的，所以我在做敏捷”是错误的，因为我正在使用 Chef（一个集群自动化管理工具），所以我在做DevOps对吗？成为一个成功的敏捷或DevOps从业者要了解所有层次的知识，一个具体DevOps实现可能包含或不包含的内容。
最后，DevOps希望为敏捷带来的是一种理念和一组实践，软件在成功交付给用户并满足他们对可用性，性能和变化速度的期望之前尚未完成。
网友评论