NoOps 是 DevOps 的终结吗？

在 NoOps 中，您不需要一个操作团队来监督您的生命周期，因为一切都是自动化的。但这真的是个好主意吗？

NoOps 真的是 DevOps 的终结吗? 要回答这个问题，你必须更好地理解 NoOps。

随着云中的自动化和伸缩性每天都达到新的高度，开发世界的发展速度令人难以置信地快。几乎任何东西都可以使用“作为服务”ーー无论是存储、 络、云、计算还是安全。云供应商也越来越多地投资于自动化生态系统。这将我们引向 NoOps，在这里您不需要一个操作团队来监督您的生命周期，因为所有的事情都是自动化的。

您可以使用自动化模板来提供您的应用程序组件和自动化组件管理，这意味着您的开销更小，最小到没有人为干扰。听起来不错吧？

但是，这是一个明智的选择吗? 在实施过程中有哪些优势和挑战？

这是一个明智的选择吗？

你已经知道 DevOps 的目标是让应用部署更快、更顺畅，重点是持续改进。由 Forrester 的 Mike Gualtieri 提出的“无业务”(NoOps)一词，其核心目标与此相同，但缺乏专业的业务人员。

在理想的 NoOps 场景中，开发人员永远不必与操作团队的成员协作。相反，NoOps 使用无服务器和 PaaS 获取需要的资源。这意味着您可以使用一组服务和工具来安全地部署所需的云组件(包括基础设施和代码)。另外，NoOps 利用 CI/CD 管道进行部署。

操作团队在处理与数据相关的任务时非常高效，他们将数据的收集、分析和存储视为其职能的关键部分。然而，请记住，您可以自动执行大多数数据收集任务，但是通过自动执行此分析并不总能获得相同水平的洞察力。

从本质上讲，NoOps 可以作为一个自助服务模型，云供应商成为您的业务部门，自动化底层基础设施层，并消除团队管理它的需要。许多人认为，一个完全自动化的、不需要人类参与的 IT 环境(真正的 NoOps)是不明智的，甚至是不可能的。

NoOps vs DevOps: 优势与挑战

DevOps 强调开发人员和操作团队之间的协作，而 NoOps 强调完全自动化。然而，它们都试图实现同样的目标ーー更快的上市时间和更好的软件部署流程。然而，当考虑 DevOps 与真正的 NoOps 方法时，存在优势和挑战。

好处

更多的自动化，更少的维护

通过使用代码控制一切，NoOps 旨在消除支持代码生态系统所需的额外劳动。这意味着不需要人工干预，而且从长远来看，每个组件都更易于维护，因为它将作为代码的一部分部署。但这会影响 DevOps 的工作吗？

使用云的全部力量

有很多支持极端自动化的新技术，包括容器即服务(Container as a Service，CaaS)或功能即服务(Function as a Service，FaaS) ，因此领先的云服务提供商可以帮助采用 NoOps。这是个好消息，因为与 DevOps (开发人员和开发团队一起决定应用程序在哪里运行)相比，操作系统可以根据需要增加云资源，从而实现更高的容量规划。

快打慢

NoOps 通过将重点转移到为客户提供价值的优先任务，消除对运营团队的依赖，进一步减少上市时间，从而关注业务结果。

挑战

你还需要指挥中心

理论上，不依赖运营团队来管理底层基础设施听起来像是一个梦。实际上，您可能需要它们来监视结果或处理异常。期望开发人员专门处理这些职责将使他们的注意力从交付业务结果上转移，并且考虑到 NoOps 的好处，这将是不利的。

单纯依赖开发人员也不符合您的最佳利益，因为他们的技能集不一定包括解决操作问题。另外，你不想让更多的任务进一步压倒开发人员。

Security, Security, Security

您可以遵守安全性最佳实践，并将它们与自动部署保持一致，但这并不能完全消除您精心照顾安全性的必要性。攻击方法每天都在发展和变化，因此，云安全控制也应该如此。

例如，你可能为你的 AI 引入错误的规则或者自动化有缺陷的过程，在你的自动化中引入错误或者为成百上千的基础设施组件或服务器创建有缺陷的脚本。如果您完全删除了您的操作团队，那么您可能需要考虑向安全团队投入额外的资金，以确保为您的环境注入最佳的安全性和遵从性方法。

考虑你的环境

考虑到 NoOps 使用无服务器和 PaaS 获取资源，这可能会成为一个限制因素，特别是在数字转换时期。遗留基础设施和混合部署仍然可以实现自动化，但是在这些情况下不能完全消除人为干预。因此请记住，并非所有环境都可以转换到 NoOps。您必须仔细评估切换的利弊。

那么 NoOps 真的是 DevOps 的终结吗？

简短的回答: 不。

长话短说: NoOps 不是一个放之四海而皆准的解决方案。您知道它仅限于适用于现有的无服务器和 PaaS 解决方案的应用程序。由于一些企业仍然运行在单一的遗留应用程序上(需要完全重写或大规模更新才能在 PaaS 环境中工作) ，因此即使只剩下一个遗留系统，您仍然需要有人负责操作。

从这个意义上说，NoOps 距离处理长时间运行的应用程序还有一段距离，这些应用程序运行专门的流程或生产环境，需要的应用程序。相反，操作发生在生产之前，因此，对于 DevOps，操作工作发生在代码进入生产之前。发布包括对每次提交的监视、测试、 bug 修复、安全性和策略检查，等等。

您必须让团队中的每个人(包括关键的利益相关者)从一开始就参与进来，以实现快速反馈，并确保自动控制和任务的有效性和正确性。持续学习和改进(DevOps 团队的支柱)不应该只发生在事情出错的时候; 相反，成员必须一起合作解决问题，改进系统和过程。

此外，当您考虑 DevOps 时，您考虑的是“人”与来自所有业务领域(包括 QA、市场营销、设计师、安全、产品经理等)的团队成员一起构建更好、更快的软件，将继续是他们朝着共同目标一起工作时的最佳选择。记住，在我们构建一个高速开发团队的文章中，一个平衡的团队可以让所有成员都参与进来，并为他们提供成长和相互学习的机会。

好的一面

谢天谢地，NoOps 符合一些 DevOps 方式。它专注于学习和改进，使用通过持续和开放协作开发的新工具、新思想和新技术，而 NoOps 解决方案消除了摩擦，增加了有价值的特性通过流水线的流动。这意味着 NoOps 是 DevOps 的成功扩展。

换句话说，DevOps 是永恒的，而 NoOps 只是与 DevOps 一起发生的创新的开始，所以说 NoOps 是 DevOps 的终结意味着没有任何新的东西需要学习或改进。

终点站，目的地: 不行

真正的 NoOps 需要做大量的基础工作ーー您需要在无服务器或 PaaS 之间做出选择，并在开始时考虑配置、组件管理和安全控制。即便如此，您可能仍有一些未完成的工作ーー比如遗留系统ーー需要花费更多时间进行转换(或者根本无法进行转换)。

但有一件事是肯定的: DevOps 不会去任何地方，自动化也不会使操作过时。但是，随着无服务器自动化的发展，您可能不得不在某个时候考虑一种新的开发和操作方法。值得庆幸的是，您有很多帮助，比如自动化工具和 FaaS，如果您选择切换，它们可以使您的转换更加容易。