现在似乎每个人都在谈论DevOps。从会议，到文章和书籍，这个词已经席卷了整个IT世界。这种说法是可以理解的，因为许多IT团队都在寻找一种方法来摆脱项目延迟、质量问题和交付失败的泥沼，而这些问题往往是他们自己发现的。很明显，DevOps有潜力解决它所面临的许多挑战。已经接受它的组织——包括Etsy、Netflix、Target、Walmart、Amazon和Facebook1等公司——已经表明，DevOps原则可以通过使团队更快地交付更高质量的软件而带来竞争差异。因此，可以毫不夸张地说，它正在成为软件开发的行业标准。然而，伴随着所有这些兴奋，人们潜移默化地怀疑，在谈论DevOps时，并不是每个人都在谈论同一件事。CTO声称他们在"做"DevOps，或者供应商在销售能够神奇地让您"做"DevOps的工具，这一点更加强化了这种怀疑。它可能有助于调和对它的许多解释，这些解释搅浑了水，并可能抑制了人们的采用。自从DevOps的早期，关于它是什么的争论就一直存在。幸运的是，在过去几年里，人们似乎越来越达成共识。那么DevOps是什么，真的？要清楚地理解它是什么，它有助于理解它不是什么，它不是一种方法或过程，也不是一种单一的工具或技术。事实上，它甚至不能被严格定义为严格的开发和运营，尽管它的基础是显而易见的。而且，尽管许多以DevOps的成功而闻名的组织都是软件即服务（SaaS）公司，但它肯定不仅仅适用于SaaS应用程序。最后，这绝对不是你要做的事最近关于DevOps是什么的共识集中在它主要是关于文化的观点上。DevOps文化基于一组组织最初渴望并最终遵守的原则。采用这种文化的组织重视协作、实验和学习。在DevOps文化中，软件交付生命周期中的所有参与者（不仅仅是开发和操作）都围绕着一个共同的目标：从概念到客户快速交付稳定、高质量的软件。因为它是一种文化的东西，从技术上讲它不需要自动化。然而，通过持续交付实现软件开发、测试和部署的自动化被广泛认为是一个关键因素。自动化使组织能够更快地交付软件，同时确保运营部门对正在部署的内容有信心，并且客户获得他们所需的质量、安全性和稳定性。德沃普斯三位一体一个以简化的形式来观察DevOps文化的镜头集中在它是关于让所有软件开发生命周期参与者在三个层面（人、过程和工具）或者我们可以认为的DevOps三位一体的方面取得一致。在实践中，对什么是DevOps的误解或匆忙实现它的捷径常常导致组织在尝试DevOps转换时不考虑三位一体的所有三个组件。不尊重所有组成部分几乎总是导致失败和未满足的期望。例如，假设一个组织拒绝将文化变革作为一项要求。为了加速交付更高质量的软件，这个团队将DevOps视为一个工具和技术挑战。该组织在自动化测试工具上投入了大量资金，但忽视了将文化焦点放在质量第一上。如果没有对质量的文化关注，团队会走过场，但不会积极地采取措施来确保持续一致的质量。质量的重要方面包括制定有效的质量目标、实施适当的自动化水平或跨筒仓协作以尽早、快速地纠正问题。如果不关注质量的这些方面，组织就不可能看到质量的改进或缺陷的减少。相反，他们发现他们可以更快地交付，但代价是质量下降，并且在不可避免地出现缺陷时进行更多的灭火。相反，一个完全致力于文化变革但不愿意或无法采用敏捷方法和自动化工具的组织会发现，文化变革在实践中实在太难维持了；由于手动步骤、重量级流程以及不合适、笨重的遗留工具仍然存在，人们对更快交付的期望值很高如果没有得到满足，转型最终会作为失败的计划而放弃。框架DevOps到目前为止，我们已经从基于某些原则的文化和人、过程和工具三位一体的角度讨论了DevOps。事实上，有几种模型可以用来定义和描述它，所有这些模型都可以导致更深入、更全面的理解以及更顺利的实现。一个很好的例子是Gene Kim和他的合著者在他们有见地的书《凤凰计划》中描述的DevOps的三种方式。当然，这些方法——系统思维、反馈回路的放大以及持续实验和学习的文化——与前面概述的原则有很大的重叠。另一个很好的例子是CAMS模型，它与对文化、自动化、管理和共享的关注相似地重叠。回到三位一体的概念，还有一种方法可以构建与许多人产生共鸣的DevOps。在这个框架中，软件开发生命周期被视为具有上游（开发）和下游（操作）两部分。这两个部分是同一个软件交付过程的一部分，但在许多非DevOps IT组织中，这两个部分是高度不相关的（图1）。图1。上下游人员、流程和工具之间的脱节。在上游，开发文化通常优先考虑速度和创新，而下游的运营文化则侧重于维护质量、稳定性和正常运行时间。在上游，开发使用点工具来定义和使用敏捷方法构建软件。下游，企业级工具是管理软件测试、发布、部署和操作的规范。与看板和最新的scrum相比，下游会议更多的是讨论信息技术基础设施库（ITIL）和项目管理知识体（PMBOK）。DevOps是为了连接这些世界，消除上游和下游之间存在的鸿沟。看看DevOps的"如何"随着对DevOps状态的更好理解，组织的下一个问题是，"我们如何实现目标？"这是一个很深的问题，到底有多少篇文章和整本书被写出来。改变一种文化所需的步骤不容易总结，很大程度上取决于进行转型的组织。然而，任何组织都可以采取一些步骤来开始铺路。你不能"做"DevOps，但首先，你可以在上游使用持续集成（CI）进行敏捷开发。类似地，您可以在下游进行连续交付（CD）。CI和CD的成功很大程度上取决于自动化，因为自动化不仅节省时间，而且还可以减少缺陷、提高一致性并实现自助服务。通过自动化CI和CD并鼓励开放的通信和协作，组织开始跨越将上游与下游分离的鸿沟，并为DEVOPS转换奠定基础。图2。敏捷方法、CI和CD为DeVoP转换提供了基础。通常，关于DevOps的讨论过于狭隘地集中在从开发人员提交代码到软件部署到服务器的整个过程的技术核心。但实际上，确保客户的需求得到理解同样重要。从那以后，有一个计划来定义一个解决方案，一个交付它的计划，一个一旦投入运行就支持它的计划。整个反馈循环不仅仅涉及开发和运营，这就是为什么认识到DevOps从概念扩展到客户是很重要的。请记住，一旦组织达到了特定的状态，DevOps转换的好处不会突然出现。更确切地说，随着转型势头的增强，利益也在不断累积。随着组织变得越来越强大、越来越一致，一个组织更快地交付更好的软件的能力成为一个竞争优势，使组织能够创新、消除浪费并快速响应市场需求。布莱恩·道森布道者云蜂1 10家公司在DevOps杀了它，2015年9月25日，TechBeacon， 了解更多现在似乎每个人都在谈论DevOps。从会议到文章和书籍，这个词已经席卷了整个IT世界。这种说法是可以理解的，因为许多IT团队都在寻找一种方法来摆脱项目延迟、质量问题和交付失败的泥沼，而这些问题往往是他们自己发现的。在本白皮书中，我们看一下：DevOps是什么为什么你必须关心它（提示：你的生意取决于它）不管是一时的流行还是在这里停留