DevOps和自动化之间有什么区别？

我发现每当有人进行DevOps时，主要是要实现诸如部署等自动化。

但是，自动化在哪里结束，DevOps从哪里开始？

DevOps的很大一部分使得可以非常频繁地发布。它带有自动化构建，自动化测试等。您可以说，要实现其目标，DevOps需要使用自动化来提高效率。

这是DevOps与自动化之间的关系。DevOps不仅是自动化，还有更多。相反，“ DevOps人员”并没有专门使用自动化。DevOps出现之前，IT部门已经实现了许多自动化。

请不要考虑上面的图表来代表所有DevOps或所有这一切都是自动化的。这是为了帮助读者了解这两个概念之间的关系。

自动化是DevOps的关键属性，但这不是全部。这个问题有点像“时间装箱和Scrum有什么区别？”。

您会听到DevOps被称为“文化”，“运动”，“方法论”，以及各种各样的东西，尽管这些描述是准确的，但它们并不能很好地使您理解它。简而言之，DevOps涉及敏捷方法论，自动化和虚拟化的融合，从而在软件项目的管理/控制/指导中实现新的反馈循环。

借助先进的自动化技术，过去需要很长时间并且容易发生人为错误的事情现在可以快速发生，而不会发生任何意外。结果，我们倾向于更频繁地执行它们。一个主要的例子是“生产部署”。我们过去经常保存大量工作，并在下班时间进行部署，以防万一“出事了”。但是现在，我们可以每天部署几次更改，以某种方式大大减少“出问题”的机会，并以某种方式在发生问题时减少影响。

一旦有了这个可重复的过程，我们就开始将其视为“管道”。需求进入，部署到生产中的代码就出来了。我们使该流程中的所有操作自动化-测试，文档，合并，部署和更多测试，等等...因为人们专注于自动化，所以他们看不到推动它的“流程思路”。 这是管理方法-管道上的关注-使DevOps比自动化更重要。

一旦我们实现了自动化，反馈循环就开始了。我们开始测量诸如周期时间之类的东西，以便我们可以找出之前尝试用估计来猜测的事物。关于使自动化/连续交付难以实现的体系结构的事情，倾向于被使自动化/连续交付更容易的替代体系结构模式代替（这方面的几个很好的例子在“进化数据库”一书中有记录。“绿色/蓝色部署”是另一本）。

注意，我能够提供此描述而无需谈论Jenkins，Check，Puppet，Ansible，Vagrant，AWS或任何其他支持它的工具。这就是我们所说的更大的流行词，例如“方法论”。最后，任何工具集都可以替换...我们剩下的是自动化实现的核心管理原则以及对管道的关注。

DevOps实际上是一种文化上的转变-旨在打破运营与开发之间的传统障碍（实际上也包括质量保证和其他业务！）。这个想法是，与其让部门“孤军奋战”，不如直接与其他团队合作，以更快，更高效地完成工作。

这一切都是为了消除约束并简化流程。自动化之所以如此重要，是因为拥有可重复的过程有助于消除约束。例如：如果来自ops的某人必须执行手动发布过程才能将代码发布到环境中，则可能会遇到很多问题-其中之一是ops中必须有某人可以自由进行部署，第二，由于手动操作容易出错，因此对发布过程的信心较小。

DevOps包括自动化，但这只是其中的一部分。DevOps是一种文化变革，旨在打破组织不同部门之间的孤岛，以提供完整的价值流。提供一种文化，使业务，开发，质量保证，基础结构，安全性，操作等共同协作，为最终用户提供价值。DevOps不是工具，您无法购买，必须改变自己的文化。

自动化是DevOps的关键部分，因为它可以提高交付速度和质量。部署过程的自动化是许多人首先关注的领域之一，因为它是快速获取价值的最佳方法之一，并且不仅通过减少部署时间，而且还通过标准化过程和取消部署来提供高投资回报。错误。

我想补充一下我的2美分：
1）自动化：
     我们今天必须朝着这个方向发展。越来越有必要，其中，如果不是整个过程，则首选方法将是使零件自动化。这种方法使用户（开发人员）可以灵活地使用固定步骤以及根据需要进行自定义。
     这种方法的优势在于，我们可以自动化所需的部件，而开发人员可以将各个流程捆绑在一起。自动化步骤越精细，它们的控制就越好。
     此外，还有许多用于空间自动化的工具，例如机器人自动化，SOP自动化（用于维修行业），报告自动化（例如Splunk）等
。2）DevOps注意：
     考虑到当前交付质量和及时性的状况，有必要扩展软件交付过程的自动化。为了实现这一点并以最快的方式为客户提供价值，DevOps确实广泛依赖自动化工具。
     这种方法的优势在于，可以自动执行各个步骤，以实现整个企业的一致性，同时可以修改整个业务流程以适应该项目所需的流程。
     各个自动化工具（以某种方式），例如用于部署的Chef，通过Dockerfile的Docker，用于构建的Maven等，可以通过Jenkins捆绑在一起，以提供所需的解决方案，同时减少实现或使用所需的时间。
希望这有助于为您可能已经拥有的思考过程增加任何价值。

编辑：忘记了补充，我已经谈到过流程和工具-DevOps中3个方面中的2个。正如其他人所提到的，第三个同样重要的方面是人。我认为这与自动化之间的主要区别之一是，与抵抗DevOps相比，人们更倾向于吸收自动化。我认为这是由于DevOps本身的性质所致，因为自动化通常与使他们变得更轻松有关，而他们认为DevOps正在改变他们的使用方式。

DevOps运动包括四个主要区域，缩写为CAMS：

1. 文化
2. 自动化
3. 测量
4. 分享中

这是2010年的原始定义文章。

在每个领域中，都有一些通常被接受的工具，过程和实践，尽管该主题没有为最佳实践进行很好的定义，但是在大多数情况下，还是要遵循一些良好实践。

自动化本身是一个较宽泛的主题，但是在DevOps的上下文中，它只是所涵盖内容的一部分。请注意，我们以文化为先导，尽管许多刚进入该领域的DevOps从业人员常常忽视了这一点，而直接跳入了自动化。

自动化和DevOps无关。DevOps更像是组合工程，其中站点或服务的开发人员都是该站点或服务的运营商。为什么这本小说？以我的经验，当发生比网络故障更令人兴奋的事情时，Ops团队要做的第一件事就是打电话给Dev团队。他们为什么这样做？因为Ops团队所做的只是监视并保留要拨打的开发人员电话列表。

注意，关于自动化我什么也没说。

自动化就是重复成功。如果我执行步骤a，b和c，并且过程X始终有效，则步骤a，b和c是自动化的理想选择。然后，我可以把时间花在过去通常是手工操作的事情上，以使自己赚到更多钱。简单就能实现自动化。部署新版本，运行集成测试，拧紧螺栓上的螺母，备份数据，平衡贷方与借方余额等都是自动化的不错选择，因为这些步骤是由人还是由机器人重复进行的。

注意：新功能是开发人员也是操作员。没有其他群组。就我而言，合作很少。如果《故障排除指南》（又名TSG）中没有任何内容，那么可以保证您可以拨打电话。以我的经验，Ops是发生反铲事故的第一个机会。服务之间的问题超出了他们的操盘手。