NoOps 来了，DevOps 工程师的未来在何方？

NoOps 是否意味着 DevOps 时代的终结？还是说它只是 DevOps 的下一个发展阶段？在这篇文章中，我们将深入探讨这一主题。

随着云技术采用率不断上升，应用程序架构的抽象级别也有所提高——从传统的本地服务器迁移到了容器和无服务器部署。自动化技术也已经发展到了让人工流程不再是首选的地步，即使是备份、安全管理和补丁更新等与基础设施相关的活动也更多通过自动化来执行。这种理想状态相当于一种 NoOps 环境，在这样的环境中负责管理你的应用程序生命周期的团队可以变得很小。理想情况下，在这样的环境中，你的运营团队所做的那些工作都没必要做了。

毫无疑问，DevOps 现在已经深深融入所有云优先组织的 DNA 中，如今成为了一种常态，而不是什么稀罕事物。云应用程序需要敏捷性，而 DevOps 提供了这种敏捷性。然而，NoOps 是否意味着 DevOps 时代的终结？还是说它只是 DevOps 的下一个发展阶段呢？

DevOps vs. NoOps

DevOps 的成功与否在很大程度上取决于你的开发和运营团队之间的协作水平，因为它将系统管理员和开发人员聚集在一起，打破了他们各自业务之间的障壁。与此同时，持续集成和持续部署的流程在 DevOps 中至关重要，它们有助于及早发现并预防问题，这反过来又会加快解决方案的交付速度。但请注意，DevOps 仍然需要运营团队的参与。组织仍然依赖运营团队来处理很多细节问题，例如：基础设施配置管理、安全设置、备份、补丁管理等。

有了云之后，抽象和自动化的发展水平日新月异。无论是计算、存储、网络还是安全性等等，随便什么事物都可以放在云端，“作为服务”来使用。云服务提供商也在他们的自动化生态系统上投入了大量资源。你可以使用自动化模板或只通过几个 API 调用就轻松配置你的应用程序组件。这些组件的持续管理过程也可以自动化，这意味着维护环境的开销变得越来越少，甚至不需要人力干预。这一趋势发展下去就是 NoOps——基础设施进一步抽象化，与开发工作流紧密集成，不需要运营团队来监督流程。

NoOps 是最早由Forrester创造的一个术语，旨在提高生产力并比 DevOps 更快地交付结果。在理想情况下，开发人员永远不必与运营团队的成员协作。相反，他们可以使用一组工具和服务，以安全的方式负责任地部署开发所需的云组件，包括代码和基础设施。托管云服务（如 PaaS 或无服务器）充当 NoOps 的支柱，并利用 CI/CD 作为其部署的核心引擎。因此，请注意，并非所有场景都适合应用 NoOps。

NoOps：优势和挑战

NoOps 和 DevOps 本质上试图实现的是相同的目标：改进软件部署流程并缩短产品上市时间。但是，DevOps 强调的是开发人员和运营团队之间的协作，而 NoOps 的重点已经转向了完全自动化。这听起来像是某种银弹，但这种新方法既有其优势，也存在着很多挑战。

优势

1. 自动化程度更高，人数更少

NoOps 将重点转移到了无需人工干预即可按设计部署的服务上。从基础设施到管理活动，它的目标是使用代码来控制一切，这意味着所有组件都应该作为代码的一部分进行部署，并且这些组件应该是可以长期维护的。NoOps 本质上旨在消除支持代码生态系统所需的人力资源。

1. 充分利用云的力量

NoOps 最适合利用 PaaS 和无服务器解决方案的云环境。微服务和基于 API 的应用程序架构完全符合它的要求，因为它们提供了较细粒度的模块化和自动化。AWS、Azure 和 GCP 等领先的云服务提供商非常注重在 PaaS 和无服务器方面提供更多服务和功能，这也会加速 NoOps 的采用。在今天的云端领域，越来越多的数据库即服务、容器即服务与函数即服务选项也有利于这一趋势，所有这些技术都支持高度自动化。

1. 从运营到业务结果的关注点变化

NoOps 还将重点从运营转移了到业务成果上。与 DevOps 不同的是，在 DevOps 中，开发团队和运营团队一起协作以向客户提供价值主张，而 NoOps 在理想情况下消除了对运营团队的任何依赖，从而进一步缩短了产品上市时间。NoOps 的重点转移到了为客户提供价值这一优先任务上——换句话说，“速度为王”。

挑战

1. 你仍然需要运维

从理论上讲，“不需要运营团队来照顾你的基础设施”可能听起来很诱人。但是，根据现实中你的组织可实现的自动化水平，你可能仍然需要运营团队来处理异常或监控结果。完全指望开发人员解决这个问题会抵消 NoOps 的优势，并让他们无法专注于交付业务成果。考虑到开发人员不一定具备解决运营问题所需的技能，这种办法也不是很现实。比如说在一个灾难恢复（DR）场景中，你仍然需要运营团队的支持来调用 DR 计划，并将流量切换到故障转移站点。

1. 考虑你的环境情况

此外，并非所有环境都可以过渡到 NoOps。混合部署和遗留的老旧基础设施会产生瓶颈——你的确可以部署一些自动化过程，但在这些情况下不能完全消除人工流程。虽然 PaaS 和无服务器都是针对 NoOps 的技术，但它们也可能成为限制因素，尤其是在数字化转型期间。重构遗留的单体应用程序以适应 PaaS 范式，需要很多提前可能想不到的额外努力。在开始采用 NoOps 方法之前，你需要根据具体情况仔细评估利弊。

1. 谁来负责安全性？

最后一点也很重要，那就是安全性和合规性问题。符合安全最佳实践的自动化部署并不会完全消除安全性方面的隐患。传统上，运营和开发团队之间的职责是分离的。运营团队与安全团队合作实施控制措施，保护应用程序免受威胁和漏洞的侵害。同时，运营团队还负责处理身份和访问管理（IAM）解决方案。

云端的威胁媒介和攻击方法日新月异，你的云端安全控制策略也应该跟上脚步。合规性也是如此。并非所有组织都可以将这方面的责任委托给一组自动化流程。减少或移除运营团队可能意味着你需要增加对安全团队的投资，才能确保你的环境的安全性和合规性。

NoOps 是目的地

人们更多把 DevOps 看作是一个旅程，而不是一个目的地，它的重点是持续改进。更合理的角度来看，NoOps 是 DevOps 的演变结果，其目标是实现高度自动化的完美最终状态。它可以让组织将时间、精力和资源从运营转到业务成果上。然而，这种变化不可能一蹴而就。

要让 NoOps 成为现实，组织需要做很多基础工作。你需要在云端选择正确的应用程序技术栈和托管服务（比如 PaaS 和无服务器），实现顺利过渡。你需要加入组件管理、配置和安全控制才能开始迁移过程。即便如此，也会有一些松散的组件（比如遗留系统），需要更多的时间和精力来完成迁移，或者它们根本就没法迁移。即使只剩下一个遗留系统，你也需要安排人手来处理它的运维需求。

在 NoOps 世界中，DevOps 工程师的角色也会发生变化，因为他们有机会学习 NoOps 所需的很多新技能和流程。与 DevOps 一样，NoOps 更多是关于文化和流程，而非技术层面的转变。组织需要有意识地做出这种转变，同时脚踏实地地处理转型过程中面临的种种实际挑战。

英文原文链接：https://codersociety.com/blog/articles/noops