本文最初发布于 TheStartup 博客，经原作者授权由 InfoQ 中文站翻译并分享。

注意：这是该系列文章的第 2 部分。你可以点击这里阅读第1部分，或者跳转到第3、4、5部分。

在前一篇文章中，我们讨论了云原生的实际含义，并且指出，要从云原生方法中获益，就需要从多个角度来审视它。这不仅与你使用的技术和基础设施所在的位置有关，还与你如何构建解决方案有关。但最重要的也许是，它和你如何组织员工和遵循什么流程有关。在这篇文章以及接下来的两篇文章中，我们将介绍成功迈出云原生第一步的最重要的部分，并从不同的角度进行分析。本系列文章的主题摘要如下图所示：

云原生组件

让我们从最容易被忽视的角度开始——云原生对相关人员及其所在流程的影响。

云原生要素：人员和流程

要想在云原生方法上取得成功，人员组件比其他任何组件都重要。为了实现云原生的业务价值，团队需要能够在业务和 IT 之间快速协调，以一种“低接触”的方式将更改提交到生产环境，并对所交付的内容负责，而且信心十足。任何新技术或现代架构方法都无法凭一己之力实现这一点。团队需要投入精力转向敏捷方法，采用 DevOps 原则和软件生命周期自动化，引入新的角色（例如 SRE），而且，组织必须赋予团队一定程度的自治权。下图展示了云原生方法中人员要素的一些最重要的方面：

云原生要素：人员和流程

这个列表肯定不完整。我们还认为，关于人员，还有其他方面可以提高团队弹性，超出了上面列举的要素，如转向无责备文化，鼓励成长型思维。接下来，我们将对上图中的每一项进行深入探讨。

敏捷方法

云原生基础设施和基于微服务的设计使得开发可快速更改和部署的细粒度组件成为可能。然而，如果我们没有能够用来实现交付并兑现承诺的开发方法，这将毫无意义。敏捷方法使被授权的（去中心化的）团队能够缩短变更周期，更紧密地结合业务需求，其特点如下：

• 短而有规律的迭代周期

• 固有的业务协同

• 数据驱动的反馈

通常，敏捷方法会被拿来与旧有的“瀑布式”方法做对比。传统的瀑布方法会提前收集所有的需求，然后，团队在近乎隔离的状态下工作，直到他们交付最终产品供验收为止。尽管这种方法能够最小化实现团队的障碍，使他们不受变更请求的影响，但是在当今快速变化的业务环境中，最终交付物很可能与当前的业务需求不同步。

敏捷方法使用迭代开发周期，会与业务定期接触，再结合有意义的客户使用数据，可以确保项目始终专注于业务目标。其目的是根据实际的业务需求不断地修正项目的方向。

工作被分解成相对较小的、业务相关的特性，业务可以在每个发布周期中更直接地确定它们的优先级。当他们可以接受没有精确的长期交付计划，但可以确定接下来构建什么时，对业务的真正好处就出现了。

敏捷本身正在成为一个“古老的”术语，和许多术语一样，它已经遭受了近二十年的误用。然而，就目前而言，它也许仍然是对这些方法的最好的概括。

生命周期自动化

除非你缩短将新代码转移到生产环境所花费的时间，否则你无法达到你想要的敏捷程度。如果生命周期流程很慢，那么你的方法多敏捷，或者你设计的组件多轻量化，就都没有什么关系了。此外，如果反馈周期被打破，你就不能实时地对业务需求的变化做出响应。生命周期自动化主要围绕三个关键管道，它们是：

• 持续集成——构建/测试管道自动化

• 持续交付/部署——部署、验证

• 持续采用——运行时更新

下图说明了它们之间的交互关系：

管道自动化（CI/CD）是 DevOps 和敏捷方法的基础

持续集成（CI）意味着经常（“持续”地）向源代码存储库提交更改，并且可以即刻进行自动构建、质量检查、相关代码集成及测试。CI 可以即时为开发人员提供反馈，让他们知道更改与当前代码库是否兼容。我们发现，基于镜像的部署使得构建管道更简单、更一致。此外，更加模块化的、细粒度的、完全解耦的无状态组件的创建简化了自动化测试过程。

CD 既可以表示持续交付，也可以表示持续部署（两个都对，尽管 Jez Humble 的著作让持续交付这个术语流行了起来，它实际上涵盖了这两个过程)。持续交付从 CI 获取输出，并执行将其部署到目标环境所需的所有准备工作，但是不部署，把最后的步骤留在审批之后，以受控的方式手动执行。当环境允许自动向环境中部署时，这就是持续部署，对敏捷的优势和潜在的风险进行了平衡。

持续采用（CA）这个术语知道的人比较少，它表示一个越来越常见的概念：保持对底层软件运行时和工具的更新。这包括 Kubernetes、语言运行时等平台。大多数供应商和开源社区已经开始按季度甚至按月进行升级。无法跟上软件的发展步伐会导致应用程序过时，变得难以更改和支持。通常，安全更新是由软件内部的管理机制强制执行的。供应商会为数量很少的旧版本提供支持，所以支持窗口一直在变短。例如，Kubernetes 每三个月发布一次，社区仅支持最近的三个版本。如上所述，CI/CD 意味着代码更改触发构建和可能的部署。企业应该自动化类似的 CA 管道，当供应商或社区发布新的升级补丁时触发这些管道。有关 CA 的更多信息，请参见持续采用。

值得注意的是，生命周期自动化的效率取决于与之相关的过程。如果你的发布审批周期仍然需要几周，或者有个依赖项的生命周期以月为单位，那么将 CI/CD 周期缩短到几分钟就没有意义了。

DevOps 和站点可靠性工程

正如我们从上图中看到的，生命周期自动化为人们工作方式的更深刻变革奠定了基础。我们简化了从编码完成到将其部署到生产环境的机制，缩短了开发人员和运营角色之间的距离，甚至可能将两个角色合二为一。

这就是所谓的 DevOps，以下是其核心内容：

• 跨开发和运营角色的协作和联合

• 运营关切“左移”

• 快速的运营反馈和处理

在传统环境中，开发和运营角色是严格分开的。开发人员不许接近生产环境，运营人员也很少接触软件开发的过程。这可能导致开发人员编写代码时没有考虑到生产环境的实际情况。当运营团队为了保护环境而单独引入质量门，增加进入生产环境的障碍时，这种分离就会加剧，开发和运营之间的距离会周期性地加大。

DevOps 采取的方法是，我们应该不断努力减少并尽可能消除开发和运营之间的距离，以便保持目标一致。这可以激励开发人员“左移”许多运营上关注的事项。在实践中，这可以归结为问一系列问题，然后根据答案采取行动：

1. 我们可以使开发环境与生产环境有多相似？

2. 我们可以将可伸缩性、可用性和可观察性测试作为早期测试的一部分吗？

3. 我们能否从一开始就将安全性放在适当的位置，而不仅仅是在主要环境的最后才把它打开？

在这方面，容器和 Kubernetes 等平台元素可以发挥重要的作用，稍后，我们将讨论基于镜像的部署和基础设施即代码等概念，从中我们就可以看出来。

显然，使用 CI/CD 缩短开发和生产之间的路径是与 DevOps 联系在一起的，因为关注迭代和业务是敏捷方法的特点。这也意味着改变人们的工作模式。软件开发人员应该在照管生产系统方面发挥积极的作用，而不仅仅是创建新的功能。运营人员应该专注于那些可以让单调而枯燥的任务自动化的方法，这样他们就可以转向更有价值的活动，比如创建自动化程度更高的自愈环境。当这两者结合起来时，这个特定的角色通常被称为站点可靠性工程师，以强调他们也是软件工程师的事实。成功的关键是需要充分认识到，组件“失败是正常的”，因此，我们应该计划好如何管理失败，而不是徒劳地试图阻止它发生。

在理想情况下，软件开发和运营会成为一个团队，每个团队成员都可以承担开发和运营角色，彼此之间可以互换。然而，大多数组织在这方面都有某种程度的妥协，角色往往会向一端或另一端倾斜。

团队自治

如果我们使方法更加敏捷，通往生产环境的路径更加自动化，就不会扼杀这些方法所带来的生产力和创新能力。每个团队都在处理一个独一无二的问题，他们将更适合于特定的语言和工作方式。我们应该通过以下方式给予团队尽可能多的自主权：

• 所有权去中心化

• 技术自由

• 自助配置

如果我们要在更细粒度的组件上快速迭代，就需要放弃“一刀切”的策略，允许更多的局部决策。正如我们稍后将讨论的那样，只要组件以一致的方式交付（例如容器镜像），一个好的云平台就理所当然地应该鼓励将构建、部署和运营标准化。为了提高生产力，团队需要能够自由决定如何实现这些组件；选择他们自己的技术，比如语言和框架。同样重要的是，确保团队能够快速完成所需工具和资源的自助配置，当然，这也符合云基础设施的特点。

在整个企业中，仍然需要在方法和技术上保持一定程度的一致性。例如，像 Spotify 模式这样的方法，通常是通过“协会（Guild）”来实现这种需求。“协会”是由团队中的个人组成的团体，他们专注于鼓励（而不是强制）团队基于自己的实际经验选择常见的方法和工具。

当然，需要注意，权力下放通常无法普遍施行，也不能一下子全部应用。它可能只对企业的某些部分有意义，或者对企业中的某些类型的计划有意义。最终，要在促进公司创新和探索以保持市场领先地位，和确保企业不会因为不断变化和日益分化而破坏核心竞争力，之间寻求平衡。

在本系列的下一部分中，我们将看一下，为充分利用云环境，我们需要做出哪些架构和设计选择。同时，如果你想了解关于这些问题的更多信息，请访问IBM Garage Method网站，在那里，我们在端到端方法的上下文中更深入地讨论了这些主题。

查看英文原文：

The “How” of Cloud Native: People and Process Perspective

延伸阅读：

云原生到底意味着什么？

避免不完全的云原生