Serverless基础架构下，运维人员将何去何从？

作者 Tom McLaughlin， 译者 无明

正如serverless一词会让人感到困惑，运维一词也是如此。当谈话中出现这个术语时，人们会想到不同的东西，这会让谈话变得混乱。

什么是serverless? serverless是一种架构理念，最新的定义这样描述它：“serverless架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务，客户端逻辑和服务托管远程过程调用的组合。”

运维有着很广泛的定义。通常，人们会在谈话中提到一个不存在运维的场景，但实际上，他们建议作为替代品的东西在我看来仍然是运维。当我们甚至无法就所谈论的内容达成一致时，我们该如何讨论serverless对运维所带来的影响呢？

在我们对所谈论的内容有了共同的理解之后，让我们来看看运维人员在serverless中应该属于处于什么样的位置。我认为运维团队在serverless环境中没有多大意义。但是，运维人员其实是有价值的。那么他们应该处在什么样的位置上？

什么是运维？

人们对运维的理解通常是不一样的，但通常都是正确的。选择什么样的定义取决于一个人的经验、需求和优先事项，以及他们看问题的角度。然而，这些不同的定义往往会导致人们的交谈相互脱节。

从最高层面看，运维是一种实践，让支撑业务的技术保持运作。但如果你深挖一下，运维一词可以以用在许多方面。因为这些含义紧密耦合了很长时间，人们往往会把它们混为一谈。

什么是运维？运维是：

• 一个团队

• 一种角色

• 一种责任

• 一组任务

通常，这个角色由运维团队的运维工程师承担，他们负责执行与运维相关的任务。近年来，DevOps的出现极大改变了这种局面。曾经有关所有这些定义的死板结构被拆解，由此，定义本身也就分崩离析。

在DevOps频谱的一端，运维团队和个体角色基本保持不变。开发人员和运维人员都是独立的团队，只是开发团队开始承担一部分的运维职责，运维团队和开发团队之间的沟通比之前上升了一个层次。当我们听到有人说“开发人员先收到警报”或开发人员不能再让代码“翻墙”时，我们知道，运维职责发生了变化。

在DevOps频谱的另一端没有了运维团队和个体角色。有些企业将具备运维和软件开发技能的工程师组合在一起，创建了跨职能团队。这些企业没有运维团队，也没有计划组建一个。

在DevOps频谱的中间，运维角色各不相同。在一些企业中，除了增加了自动化技能（例如Puppet、Ansible和Chef）之外，其他几乎没有变化。其他团队已经将自动化视为强化运维职责的手段。在某些情况下，运维工程师更接近于开发人员——掌握了配置管理和其他工具的开发人员。

那么serverless对于这些运维定义有什么影响？

Serverless之下的运维会变成什么？

以下是我对serverless运维的未来的看法：

• 运维团队将会消失。

• 运维工程师将被开发团队吸收。

• 运维工程师将负责应用程序栈的深层需求。

Serverless运维并不是NoOps，也不是反DevOps。如果传统的运维团队被解散，原先的运维工程师需要新的去处。他们的去处将是各个开发团队，而这些团队会是产品团队或职能团队。

这样，能够处理开发和运维的跨职能团队将会迅速崛起。最后，很多运维工程师会发现自己的优势将比过去更多地被应用到应用程序中。

为什么要解散运维团队？

在DevOps出现之前，我们看到的是两个孤岛：一个是开发，一个是运维，他们之间隔着一堵墙，开发人员将工程设计扔给毫无戒心的运维团队是日常。DevOps出现了之后，中间那堵墙被拆掉了，两个团队之间的协作变得更加紧密。

但实际上，“拆掉中间那堵墙”对于不同的组织而言也有不同的含义。在某些情况下，它只是意味着更多的会议。现在，有人在向运维“扔东西”之前会先告知他们。

但是，你仍然需要独立团队，让他们共同努力交付解决方案。实际上，这可能涉及两个以上的团队。还有谁？

• 需要一个项目或产品经理负责监督交付过程，确保交付的东西能够满足公司的需求。如果你是在一家产品或SaaS公司，可能还需要UX和设计师确保产品的可用性和外观。

• 可能涉及多个开发团队，前端和后端开发可能由不同的团队负责。所有这些独立的团队需要共同努力来提供解决方案。

特别是产品和SaaS公司意识到整个过程效率低下。因此，组织开始重新调整团队，从职能团队转向产品、功能或问题领域。这些功能团队、产品团队或其他任何跨职能的团队都在解决特定领域的问题。

这些团队现在看起来是怎样的？在我看来，它们通常类似这样：

• 产品或项目经理

• 工程主管

• 前端开发人员

• 后端开发人员

• 产品设计师和/或用户体验研究员（通常是同一个人）

产品或项目经理（PM）是业务需求的所有者和代表。PM的工作是将业务需求转化为明确的目标，同时引导团队提出促进成功的想法。产品设计师或UX研究人员与PM合作，收集用户数据并将想法转化为设计和原型。技术负责人负责领导工程任务，估算所涉及的技术工作，并适当地为前端和后端工程师提供指导。

你最终得到的是一支具备多种能力的团队，他们都朝着同一个方向前进，从始至终都是这个过程的一部分。这些跨职能的技能让团队变得更加强大，从而提供更好的解决方案和服务。

然而，运维往往被排除在重新调整之外（虽然有时候运维会组建属于自己的跨职能团队，并为其他团队提供服务）。团队中的个人通常难以承担基础设施的运维需求。因此，当组织的其他部分进行重新调整时，运维仍然是一个独立的团队。

这已经很好地运作了很长一段时间。对于很多团队来说，基础设施并不简单，他们无法在不影响主要问题领域的情况下进行可靠的交付和运维。

但serverless颠覆了这种关系。现在，开发人员可以轻松地交付自己的云基础设施。事实上，他们需要这么做，因为serverless将基础设施配置和应用程序代码结合在一起。

开发团队不需要运维团队的帮助来交付解决方案。单独的运维团队无法在不回归到守门人角色的情况下将自己插入到服务流程中。但多年来，守门人角色已经在很多组织中消失了。

运维团队的改变不是由serverless技术驱动的，而是由serverless对组织及其员工的运作方式和履行职责的影响驱动的。

当开发人员不再需要基础设施时，运维团队在很大程度上将变得可有可无。当他们遇到小问题时不会再来找你，他们可以自己解决这些问题。

运维团队不再是服务交付流程的一部分，这是迟早的事。到最后，有人会问为什么这些团队依然存在。当人们质疑你的工作为什么还会存在时，你的处境将变得很尴尬。

但从职责和任务方面来看，运维仍然很重要。构建serverless系统仍然需要这些功能。运维团队的作用在减弱，但对他们的技能仍然有需求，因此需要重新思考运维人员应该被放在什么位置上。这就是为什么说是时候解散运维团队并让成员加入产品团队和功能团队。

产品团队中的运维角色

作为产品团队成员的运维工程师将扮演怎样的角色？他们的主要职责是负责团队服务和系统的健康。这并不意味着他们每次都是第一个收到警报的人，他们应该是这些领域的专家。

软件开发人员仍然专注于各个组件，而运维工程师专注于整个系统。他们将采取整体方法确保整个系统正常可靠地运行。开发人员就可以花更少的时间在运维上，就会有更多的时间用于功能开发。

运维工程师还可以为团队提供帮助。虽然他们的主要职责是确保团队服务的可靠性，但在必要的时候，也可以承担其他角色的职责。

对于DevOps这个术语，有很多定义和实现，但对于我来说，DevOps团队的形成才是这个术语最有力的表现。DevOps是实现成果和价值的人、流程和工具。

我们很早就意识到协作和跨职能团队在促进成功方面的价值。对于我来说，解散运维团队并让成员加入到跨职能团队中是交付价值的最有效手段。

与将人们放在单独的团队中相比，你会让合作变得有多紧密？Serverless将帮助我们实现许多人多年来一直试图实现的目标。