正如术语无服务器可能令人困惑一样，术语操作也是如此。当这个词在谈话中出现时，人们会想到不同的东西，这可能会混淆谈话。什么是无服务器？Serverless是一个架构概念，最新的定义是这样描述的：“Serverless架构是一个基于互联网的系统，在这个系统中，应用程序的开发不需要使用常规的服务器进程。相反，它们完全依赖于第三方服务，客户端端逻辑远程过程调用与服务托管的组合。”运营有一个广泛的定义。通常，人们会在对话中提出一个Ops不存在的场景，但实际上，他们建议的替代方案在我看来仍然是Ops。当我们甚至无法就我们正在谈论的内容达成一致时，我们如何讨论无服务器对操作的影响？既然我们对所讲的内容有了一个共同的认识，那么我们就来看看运维人员在serverless中应该属于一个什么样的位置。我认为运维团队在无服务器环境中没有多大意义。但是，运维人员其实是很有价值的。那么他们应该在哪里？什么是运营？人们对运维往往有不同的理解，但通常都是正确的。选择哪种定义取决于个人的经验、需求和优先事项，以及他们的观点。然而，这些不同的定义通常会导致对话脱节。在最高级别，运营是保持支持业务运行的技术的实践。但是，如果您深入挖掘，就会发现运维一词有多种用法。由于长期以来这些含义紧密耦合，人们往往将它们混为一谈。什么是运营？运维是：一个团队一个角色一个职责一组任务通常，此角色由运维团队中执行与运维相关任务的运维工程师担任。近年来，DevOps的出现极大地改变了这种状况。所有这些定义曾经僵硬的结构被拆除，随之而来的是，定义本身也分崩离析。在DevOps范围的一端，运营团队和个人角色在很大程度上保持不变。开发人员和运维人员是独立的团队，但开发团队开始承担部分运维责任，运维团队与开发团队的沟通比以前上升了一个层次。当我们听到人们说“开发人员首先得到提醒”或开发人员不能再“翻转”代码时，我们就知道运维职责发生了变化。在DevOps范围的另一端，不再有Ops团队和个人角色。一些公司将工程师与运营和软件开发技能结合起来，创建跨职能团队。这些企业没有运营团队，也没有组建运营团队的计划。在DevOps范围的中间，Ops角色各不相同。在一些企业中，除了增加Puppet、Ansible和Chef等自动化技能外，几乎没有什么变化。其他团队已将自动化视为加强运营责任的一种手段。在某些情况下，运维工程师更接近于开发人员——掌握配置管理和其他工具的开发人员。那么无服务器如何影响这些操作定义呢？Serverless下的运维会变成什么样子？以下是我对无服务器运维未来的看法：运维团队将会消失。运营工程师将被开发团队吸纳。运营工程师将负责应用程序堆栈的深层需求。Serverless运维不是NoOps，也不是反DevOps。如果传统的运维团队解散，原来的运维工程师需要一个新的位置。他们的位置会是各种开发团队，而这些团队会是产品团队或者职能团队。这样，能够处理开发和运营的跨职能团队将迅速出现。最终，很多运维工程师会发现，他们的优势会比过去更多地应用到应用中。为什么要解散运营团队？在DevOps之前，我们看到了两个孤岛：一个用于开发，一个用于运营，一墙之隔，开发人员将工程设计交给毫无戒心的运营。维队日常。随着DevOps的出现，中间的墙被推倒了，两个团队之间的协作变得更加紧密。但实际上，“推倒中间墙”对不同的组织意味着不同的事情。在某些情况下，这只是意味着更多的会议。现在，有人会在Ops向他们“扔东西”之前告诉他们。但是，您仍然需要独立的团队一起工作来交付解决方案。实际上，这可能涉及两个以上的团队。还有谁？需要项目或产品经理来监督交付过程并确保交付的内容满足公司的需求。如果你在做产品或者SaaS的公司，你可能还需要UX和设计师来保证产品的易用性和外观。可能涉及多个开发团队，前后端开发可能由不同的团队负责。所有这些独立的团队都需要共同努力来提供解决方案。产品和SaaS公司尤其意识到整个过程的低效率。因此，组织开始将团队从职能团队重新调整到产品、功能或问题领域。这些职能团队、产品团队或任何其他跨职能团队正在解决特定领域的问题。这些球队现在是什么样子的？在我看来，他们通常看起来像这样：产品或项目经理工程主管前端开发人员后端开发人员产品设计师和/或用户体验研究员（通常是同一个人）产品或项目经理(PM)是所有者和业务需求的代表。PM的工作是将业务需求转化为明确的目标，同时指导团队获得推动成功的想法。产品设计师或UX研究人员与PM一起收集用户数据并将想法转化为设计和原型。技术负责人负责领导工程任务，估算所涉及的技术工作，并酌情为前端和后端工程师提供指导。你最终得到的是一个多才多艺的团队，他们都朝着同一个方向前进，并且从头到尾都参与了这个过程。这些跨职能技能使团队更强大，可以提供更好的解决方案和服务。然而，Ops经常被排除在重组之外（尽管有时Ops会组建自己的跨职能团队并为其他团队提供服务）。团队中的个人常常被基础设施的运营需求所淹没。因此，虽然组织的其他部分进行了重组，但Ops仍然是一个独立的团队。这在很长一段时间内都运作良好。对于许多团队来说，基础架构不够简单，无法在不影响主要问题领域的情况下可靠地交付和运行。但是无服务器颠覆了这种关系。现在，开发人员可以轻松交付自己的云基础架构。事实上，他们需要这样做，因为无服务器将基础设施配置和应用程序代码结合在一起。开发团队不需要运营团队的帮助来交付解决方案。一个单独的运营团队不能在不恢复到看门人角色的情况下将自己插入到服务流程中。但多年来，守门人的角色在许多组织中已经消失。运营团队的变化不是由无服务器技术驱动的，而是由无服务器技术对组织及其员工运营和履行职责的方式产生的影响所驱动的。当开发人员不再需要基础设施时，运营团队就变得可有可无了。当他们有小问题时，他们不会回来找你，他们可以自己解决。迟早，运营团队将不再参与服务交付流程。归根结底，人们可能会问为什么这些团队仍然存在。当人们质疑你的工作为何存在时，你将处于尴尬的境地。但是运维在职责和任务上还是很重要的。构建无服务器系统仍然需要这些功能。运维团队的作用正在减弱，但他们的技能仍然很受欢迎，因此需要重新考虑运维人员的位置。这就是为什么是时候解散运营团队并将成员引入产品和功能团队的原因了。产品团队中的运营角色作为产品团队的一员，运营工程师将扮演什么角色？他们的主要职责是负责团队服务和系统的健康。这并不意味着他们每次都是第一个被提醒的人，他们应该是这些领域的专家。软件开发人员仍然专注于单个组件，而运维工程师则专注于整个系统。他们将采取整体方法来确保整个系统正常可靠地运行。开发者可以将更少的时间花在运维上，将更多的时间花在功能开发上。运营工程师也可以帮助团队。虽然他们的主要职责是确保团队服务的可靠性，但他们也可以在必要时承担其他角色的责任。对于DevOps这个词，有很多定义和实现，但对我来说，组建DevOps团队是这个词最有力的体现。DevOps是交付结果和价值的人员、流程和工具。我们很早就认识到协作和跨职能团队在促进成功方面的价值。对我来说，解散Ops团队并将成员添加到跨职能团队是提供价值的最有效方式。与将人们放在不同的团队中相比，您会使协作更紧密吗？无服务器将帮助我们实现许多人多年来一直试图实现的目标。英文原文：https://www.serverlessops.io/blog/serverless-devops-where-does-ops-belong
