摘要：NoOps被错误地定位为将终结DevOps的实践。不幸的是，这只是建立在对NoOps真正是什么的误解之上的炒作。

   NoOps被错误地定位为将终结DevOps的实践。不幸的是，这只是建立在对NoOps真正是什么的误解之上的炒作。
　　
　　2009年在软件和技术史上具有特殊的地位，因为它是DevOps正式诞生的一年。同年6月，JohnAllspaw和Paul Hammond在O'Reilly Velocity会议上发表了他们的演讲，“每天10次部署：Flicker的开发和运营合作”。传说帕特里克•德布瓦(PatrickDebois)并未亲自出席演讲，但他确实看到了演讲的录音。正是这次演讲激发了他去创造“DevOps”这个词，并于当年10月在比利时根特举办了第一届DevOpsDays。
　　
　　从那时起，DevOps的影响在整个行业的学术界、演讲、博客和白皮书中都有很好的记录。这个概念的整个目标是在保持稳定性的同时提高速度，成功采用这种文化的人看到了实现这一目标的巨大好处。
　　
　　自从DevOps诞生以来，我们已经看到了一些突破性的概念，包括GitOps、AIOps和ChatOps等主题。在出现的所有这些“Ops”文化和实践中，最容易被误解和最具争议的是NoOps的话题。这是因为NoOps经常被吹捧为DevOps的替代品，有些人甚至说NoOps将是DevOps的死亡。
　　
　　这个所谓的概念在各种文献和网络上的其他资源中重复出现。但是，我认为这不能比事实更进一步。NoOps并不是DevOps的终结，而是在您的开发团队或组织中不断应用正确的DevOps原则的结果。这就是这件作品旨在阐明的。一劳永逸地解散误区。
　　
　　NoOps没有什么？
　　
　　2011年，现任Forester Research副总裁兼首席分析师的Mike Gualtieri在他的文章“我不想要DevOps”中创造了NoOps一词。我想要NoOps。从那时起，NoOps一词就出现在关于软件团队协作和构建软件的最佳方式的各种讨论中。
　　
　　这里的概念是，在不再需要Ops的情况下，开发环境会变得高度自动化。因此，术语NoOps。达到这种状态的旅程是DevOps本身推动的，因为自动化是DevOps的关键支柱之一。然而，出现的争论是，环境是否会一直处于自动化状态，以至于开发团队将不再需要与运营进行交互。因此，术语无操作；无需任何操作。
　　
　　现任AWS云架构战略副总裁AdrianCockcroft曾写道：“没有运营组织参与运行我们的云，开发人员不需要与运营人员互动来完成工作，并且花在运营任务上的时间比开发人员会花时间向其他人解释需要做什么。
　　
　　对于那些参与运营的人来说，这个想法乍一看似乎很可怕。然而，这些担忧是由于对NoOps承诺的误解而产生的。
　　
　　NoOps：DevOps的扩展
　　
　　随着NoOps的概念在软件开发实践领域占据应有的地位，它通常被视为DevOps的竞争者。甚至可能扼杀DevOps的概念。然而，这是一个误解的概念。
　　
　　如上所述，NoOps是这样一种想法，即开发环境已经实现了一定程度的自动化，开发人员不再需要与操作交互。然而，这种程度的自动化并不是可以立即实现的。它需要转变文化习俗以及引入和设置工具来促进自动化过程。
　　
　　达到这种自动化水平是DevOps的目标。要理解这一点，我们必须退后一步，提醒自己什么是DevOps。
　　
　　DevOps：工具、实践和理念的组合，可在保持系统稳定性的同时提高开发速度。
　　
　　DevOps旨在实现上述总体目标的方法有多种。然而，核心支柱之一是自动化。这不仅是为了提高速度，而且还有利于系统的稳定性。自动化旨在减少混淆墙想法产生的障碍。这堵“墙”可以被认为是想要改变的人和想要稳定的人之间的障碍。
　　
　　现实中的这堵墙是沟通和理解的鸿沟。传统上，在DevOps之前，当开发人员进行更改时，运维人员（即SRE）有责任确保在没有任何中断的情况下合并更改。但是，如果发生事故，系统操作人员将难以理解和解决事故，因为他们不是系统的开发者，而只是运行系统的人。这种沟通和理解上的差距，混乱之墙，当墙两边的人都是一样的时候，可以最有效地拆除。因此，Dev和Ops的结合。
　　
　　问题是，我们能否将整个开发流程自动化到不再需要操作的程度？理论上是的，但实际上这是不可能的。NoOps是我们希望达到的理想状态，即使在这种状态下，仍然需要DevOps。
　　
　　DevOps万岁
　　
　　既然我们对DevOps和NoOps的含义有了深入的了解，那么我们就可以开始理解为什么NoOps不是人们认为的王者杀手了。
　　
　　人的因素
　　
　　运营的死亡是不可避免的，但传统开发者的死亡也是不可避免的。许多人通常认为DevOps或更极端的概念（如NoOps）将意味着运维的死亡。然而，这也意味着传统开发商的死亡。DevOps的整个想法是尽可能地将开发和运维的职责结合起来。
　　
　　因此，DevOps的概念正在导致创新的新实践和技术的兴起，例如基础设施即代码和事件调查。
　　
　　这些新方法旨在使开发人员和运营人员能够在混乱之墙的另一端担任角色。因此，不仅传统的运维角色正在发生变化，传统的开发人员角色也在发生变化。仅仅知道如何用Java编写代码或使用一组AWS开发工具包已经不够了。了解如何设置CI/CD管道和启动容器实例现在被视为开发人员角色的一大优势。
　　
　　DevOps是持续创新
　　
　　通过进一步考虑引入的所有工具和实践，注意到实现自动化的过程是一个持续的过程。完全自动化的系统可以设置一次，然后再也不会修改，这一事实表明开发过程本身并没有随着软件开发领域的新进步而创新和发展。因此，可以说NoOps实际上成为了DevOps创新精神的对立面。
　　
　　例如，无服务器功能现在很流行。随着团队和组织开始采用AWSLambda函数等无服务器技术，整个开发管道的消息都将被彻底改革。软件开发对快节奏的开发和创新并不陌生。甚至在DevOps的想法如何随着新技术的引入而发展中也注意到了这一点。GitOps只是自动化开发管道的最新想法，这是由于ibnKubernetes的日益流行而产生的。
　　
　　运营并不总是在墙的右侧
　　
　　上面分享的混乱之墙的插图描绘了一个非常简单的关于Dev和Ops如何交互的想法。但是，运营和开发角色不是由单个工作角色定义的，而是由开发管道中的工作性质定义的。
　　
　　一个这样的例子是调试部分，强大的调试实践有助于减少未来的事件。然而，与开发本地或本地应用程序相比，针对云的开发是非常不同的，在本地或本地应用程序中，所有依赖资源（例如服务和数据存储）都在本地可用。
　　
　　因此，在开发管道中更早地拥有可观察性指标将有助于在云中进行调试。这意味着以日志、指标跟踪的形式呈现数据，以了解开发的组件在投入生产之前如何交互并影响云架构的其他区域。
　　
　　这产生了远程调试的概念，这是通过将远程运行的应用程序与开发环境连接来完成的。因此，能够复制与在生产中运行时已经实现的指标类似的指标。
　　
　　可以结合几个第三方工具进行远程调试。Thundra最近发布了利用可观察性概念的调试功能。它使用非侵入式调试策略（例如不间断断点和IDE集成支持）来实现这一点。总体而言，该功能允许您在预生产和生产环境中测试您的云应用程序，通过呈现所需的洞察力而不会在您的实际代码库中构成风险。这是一个视频，展示了ThundraSidekick的能力。这是一个有效的工具，因为它极大地促进了急需的左移文化。
　　
　　结论
　　
　　NoOps绝对是一个有吸引力的概念，所有团队都应该朝着这个方向努力，因为它可以被视为DevOps实践的最终目标。然而，实际上，这样的最终目标可能永远无法实现，因为在产品的开发管道和生命周期的多个领域中都存在操作。因此，可以肯定地说，任何声称NoOps是DevOps之死的说法绝对是一个误区，只是被社区中过度兴奋的对话所重申。
　　
　　编辑：Harris