过去几年，自动化一直在推动整个 IT 行业向前发展。通过自动化某些任务，开发团队可以提高其能力，而无需感受到雇用新团队成员的预算压力。自动化还保证了更高的效率，特别是在操作和维护方面。

传统的软件开发工作流程涉及开发团队沿着预定义的管道移动迭代。一旦开发和初始隔离测试阶段完成，开发人员就会将代码移交给运营团队。

由运维人员来部署新的迭代。维护代码的未来也是运营团队的责任。这就是自动化发挥作用的地方，主要是为了进一步优化 DevOps 工作流程。

通过自动化维护和运营团队的其他职责，组织希望看到效率的大幅提升。目标是达到一定程度的自动化，之后就不再需要运营团队了。

从本质上讲，这就是无操作或 NoOps 的意义所在。然而，NoOps 在以可持续的方式实施之前还需要克服一些巨大的挑战。更重要的是，NoOps 比仅仅消除操作要深刻得多。

NoOps 到底是什么？
有两个关键组件充当 NoOps 的基础：自动化和云。以消除专门的应用程序管理团队为主要目标，NoOps 旨在自动化与开发和运行解决方案相关的所有维护任务。与此同时，它还旨在将应用程序从支持它们的基础设施中提升出来。

NoOps 在云计算时代有意义。由于大部分基础设施维护任务都由第三方服务提供商处理，因此实际上不需要专门的团队来监控服务器和云环境。例如，亚马逊的 EKS 从一开始就可以完全扩展和自动化。

另一方面，由于我们今天拥有更先进的工具，应用程序的部署和管理才成为可能。安全策略可以与开发过程集成。得益于 Kubernetes 以及该平台可用的丰富工具，CI/CD 变得更加流畅。NoOps 很有意义，不是吗？

挑战随之而来
推动 NoOps 运动的想法是合理的，但 NoOps 本身也并非没有挑战。首先，NoOps 基于这样的假设：自动化可以处理一切，完全消除对人类操作员的需要。但情况并非总是如此。在独特的情况下，人工输入可能是部署成功和可扩展性的决定因素。

基础设施也是如此。由于容器化微服务和云计算的使用，服务器维护不再是一项艰巨的任务。不再需要大型机来保持运行，也不再需要大型物理服务器来运行。一切都在 AWS 和 GCP 等环境中运行，其中大部分维护任务由服务提供商处理。

大多数组织没有意识到容器化微服务需要维护单个服务。此基础设施设计中不存在单点故障，但这并不意味着基础设施不会出现故障。此外，还有遗留系统和硬件需要维护，从这些遗留系统迁移从来没有看起来那么容易。

还有一个事实是，运维团队在数据相关任务中非常有效。IT 运营部门将数据的收集、存储和分析视为其职能的关键部分。是的，您可以定义性能指标并自动执行大部分数据收集任务，但这并不意味着您可以从自动化分析中获得相同级别的见解。

NoOps 在混合环境中也举步维艰。如前所述，即使在今天，遗留系统仍在使用，主要与云计算和更现代的解决方案结合使用。这些遗留系统并不总是准备好实现自动化，因为它们由于其整体性而往往需要进行大量修改。那些在遗留系统上推行 NoOps 的组织最终不得不进行这些重大升级并执行迁移；不幸的是，并非所有组织都将升级或迁移视为可行的解决方案。相反，对于这些场景，从头开始重新设计和重建一些全新的东西可能会更有利。

需要预见的主要瓶颈
我们甚至还没有到达 NoOps 的主要瓶颈：开发人员。我见过很多服务器管理员根据他们使用的编程语言学习如何编码。另一方面，开发人员并不总是对管理自己的解决方案感兴趣。