我已经完成/创建了许多与SCM相关的演示，现在我正尝试“升级”为DevOps的后继者。

我总是在演示文稿中尝试做的是拿出一张简介幻灯片，其中以某种方式包含了我想传达的信息（然后在其余的演示文稿中进行详细阐述）。这样做时，我会尝试回答自己的问题，例如“如果我想在10到20秒（仅！）的时间内向刚接触的人讲1到3个短语，我会用什么？* ”。

我以为我知道DevOps的实际含义，以及它的含义。但是我已经看到了DevOps的一些奇怪用法/上下文（甚至在DevOps.SE ...上）。这让我怀疑DevOps到底是完全错误的。

那么，通常公认的DevOps定义是什么？

简而言之DevOps

来自维基百科：

DevOps的（一个剪辑复合 “的软件DEV elopment ”和“ 信息技术OP关合作小号 ”）是用来指一组强调双方的合作和沟通实践的长期软件开发和信息技术（IT）专业人员，同时自动化过程软件交付和基础设施的变化。

它旨在建立一种文化和环境，使构建，测试和发布软件可以快速，频繁且更可靠地进行。

从概述：

维恩图显示DevOps是开发 （软件工程），运营和质量保证 （QA）的交集

虽然没有用于DevOps的单个“工具”，但有一组工具，也称为DevOps工具链：

该图显示了DevOps工具链中的各个阶段

DevOps的插图

以下是一些关于DevOps.SE的问题的引文，它们似乎都可以以某种方式适合/确认上述DevOps描述的一部分：

• 从' SRE和DevOps有什么区别？'：

  ... DevOps与维护代码有关...

• 从（一个答案）到' 我该如何聘请适合我公司的优秀DevOps？'：

  ...人们普遍误以为“ DevOps”是公司中的角色。这个词仅表示软件公司的组织转移...

• 从（我的组织是否需要采用敏捷软件）。开发人员 在采用DevOps之前？'：

  ...仍然有一些组织没有在软件开发中实践敏捷，可能对采用DevOps感兴趣。

DevOps不是角色

以下是一些关于DevOps.SE的问题的引文，它们似乎都说明DevOps 不是角色：

• 从（答案为）' Sysadmin和DevOps Engineer有什么区别？'：

  ... DevOps不是角色（因此，它实际上不是真正的角色，而是一个时髦的词）。

• 从（一个答案）到' 我该如何聘请适合我公司的优秀DevOps？'：

  ...人们普遍误以为“ DevOps”是公司中的角色。这个词仅表示软件公司的组织转移...

在担任DevOps顾问之前，我已经与不同的客户一起为顾问服务并提供咨询服务已有近五年的时间，在我担任现职之前，我担任过软件开发，Web运营和系统管理方面的职务。以我的个人经验，DevOps具有许多特色。

组织模式

DevOps反模式：

• NoOps和NoDevs-从最严格的意义上讲，并不是严格意义上的DevOps，但是，这些团队都在构建和操作软件时没有在开发和运营之间划分界限。这些团队所面临的挑战归结为成熟，开发团队可能是专业的软件开发人员，但新手运营商则反之亦然。

• DevOps Bridge-在这里，一个或多个团队有责任从开发团队那里接管工作，并对其进行“ 生产化 ”以使其可操作。挑战归结为现在有两个交接点，即开发→DevOps和DevOps→操作。

• DevOps团队 -如果团队负责构建支持支持DevOps的运营模型的工具，那么可以说，这可以工作，但是，它可能应该称为“工具团队”或“平台团队”。

DevOps模式：

• 嵌入式DevOps（通常称为平台工程），在我看来，团队中有人负责但不负责提供自动化，工具和基础结构以供解决方案的配置和部署，有时还包括操作软件，后者实际上是DevOps的代表。

• 制度化的DevOps-项目团队将共同负责软件包的开发和运营，以建立共享所有权和积极的反馈循环。

实践

DevOps的实际实践是建立在其他几种实践之上的，即：

• 敏捷交付
• 持续集成
• 持续交付
• 持续部署

上面的每种实践都是在彼此之上建立的，有可能不遵循一种实践，但是，这意味着缺少重要的反馈周期，这可能表示“机会错失”。遵循任何其他实践和DevOps的关键区别在于生产中软件的操作。

三种方式

在《凤凰计划》中，吉恩·金（Gene Kim）及其合作者描述了DevOps的三种方式：

系统思维

第一种方式强调整个系统的性能，而不是特定的工作或部门孤岛的性能-这可以是一个大部门（例如，开发或IT运营），也可以是一个个体贡献者（例如，最小） ，开发人员，系统管理员）。

以我的经验，开始使开发人员考虑操作问题和非功能性需求可以实现此目标。这在DevOps 的文化方面非常重要。

反馈回路的放大

第二种方法是创建从右到左的反馈回路。几乎所有过程改进措施的目标都是缩短和放大反馈回路，以便可以连续进行必要的纠正。

我通常通过持续集成/交付/部署以及共享的监视和警报来实现此目标，因此它非常适合DevOps 的工具组件。

持续实验与学习的文化

第三种方式是建立一种文化，该文化可以促进两件事：不断的实验，冒险和从失败中学习；并理解重复和练习是精通的前提。

尽管这在很大程度上取决于使文化得以发展的工具和过程，但这非常适合文化空间。

我听过很多很多关于DevOps的定义。它们包括：

• 开发人员处理操作任务
• 一个人（在相同的时间内）完成两倍的工作
• 开发人员和运营团队相互合作
• 开发人员工具的操作工作（与“ Web Ops”类似）
• 创建和维护开发人员工具的人员的职位
• 在操作中使用自动化
• 在运营中使用公共云
• 结合了运营，开发和质量保证各方面的工作
• 这项工作需要帮助开发和运营团队一起工作
• 打破团队之间障碍的理念
• 将基础架构视为代码
• 前软件工程师投入运营后会获得什么
• 一个完全没有意义的流行语

对于DevOps实际上是什么，还没有公众的共识。几年前，我们在“敏捷”方面也遇到了类似的问题，并且有一个书面定义。

在向新手介绍您的概念时，我将重点放在引入概念上，而不是贴上标签，否则它们最终会听到相互矛盾的定义并感到困惑。例如，如果您试图将基础设施作为代码来谈论，请告诉他们您正在谈论基础设施作为代码。可以越具体越好，因为即使采用公认的定义，大多数公司也将更多精力放在哲学的某些部分上。

在这种情况下，我始终使用以下定义：

“一种软件创建文化，强调软件开发和运营团队之间的沟通与协作，同时使软件交付过程和基础架构变更自动化。DevOps的目标是使软件构建，测试和部署过程尽可能频繁，快速和尽可能地进行。”

但是，除了定义之外，让他们了解为什么我们需要DevOps也很重要。一定要告诉他们DevOps可以更快地缓解软件缺陷，允许更好的资源管理，更少的人为错误，更好的版本控制，稳定的操作环境等。

通过以下科学研究论文来确切地探索“什么是DevOps”这个问题，建议的DevOps派生定义为：

DevOps是一种开发方法，旨在弥合开发（Dev）与运营（Ops）之间的差距，强调沟通和协作，持续集成，质量保证和交付，并利用一套开发实践进行自动部署。

[Jabbari等]“什么是DevOps ？：关于定义和实践的系统映射研究”（2016年）

Devops是编写业务领域为运营的应用程序的开发实践。大多数应用程序开发的重点是构建用于财务，医疗保健，物流或猫视频的应用程序，而devops则重点关注可进行构建，部署，监视和指标收集的应用程序。

最重要的目标应该始终是使决策者，成为决策接受者。想象一下您银行的移动应用程序。当您请求转移时，点击按钮即会发生。你做出的决定，然后把决定。您的操作也一样。当适当的人决定准备将某些工作部署到生产中时，他们应该能够按一下按钮，并且“发生的事情正确”。同样，他们应该拥有做出正确业务决策所需的所有必要信息。

这并不是要给业务人员提供对服务器的外壳访问权限-这与实现的目的混淆了。这是关于向正确的人提供正确的旋钮和控制杆以及正确的信息和正确的护栏，使决策者成为决策者。