在上一篇文章中，我们讨论了云原生的实际含义，我们确定了要从云原生方法中获得所需的收益，您需要从多个角度来研究它。它不仅与您使用什么技术以及基础架构位于何处有关，还与您如何设计解决方案有关。但也许最重要的是，这与您如何组织人员和遵循的流程有关。在本篇以及接下来的两篇文章中，我们将逐一介绍我们认为成功的云原生计划最重要的要素。下图显示了本系列主题的摘要：
云原生组件
首先，我们来看一下也许最被忽视的观点-云原生如何影响所涉及的人员以及他们所参与的流程。
云原生的人员和流程要素
在获得云原生成功方面，人为因素胜过其他任何方面。为了实现云原生的业务价值，团队需要能够在业务与IT之间快速进行协调，以一种“低接触”的方式将其变更付诸生产，并对所提供的内容负责。没有任何新技术或现代体系结构方法能够自己完成此任务。团队需要投资于采用敏捷方法，采用DevOps原理和软件生命周期自动化，采用新角色（例如SRE），并且组织必须赋予团队适当的自治权。我们在下图中显示了云原生云的一些最重要的方面：
Cloud Native的人员和流程要素
此列表绝不完整。我们还要断言，还有其他一些基于人的方面可以提高团队的应变能力，并切入以下所有要素，例如转变为无怨无悔的文化，并鼓励增长的心态。在下一部分中，我们将深入研究上图中的每种成分。
敏捷方法
云原生基础架构和基于微服务的设计支持开发可快速更改和部署的细粒度组件。但是，如果我们没有可以利用并兑现承诺的开发方法，那么这将毫无意义。敏捷方法使授权（分散）的团队能够实现与业务需求更加紧密相关的快速变更周期。它们的特点如下：
短而规则的迭代周期内部业务协作数据驱动的反馈
敏捷方法通常与较旧的“瀑布”方法进行对比。在传统的瀑布方法中，所有需求都被预先收集，然后实施团队几乎孤立地工作，直到交付最终产品以供接受为止。尽管此方法使实施团队能够以最小的变更请求阻碍工作，但是在当今快速变化的业务环境中，最终交付可能与当前业务需求不同步。
敏捷方法论使用迭代开发周期，与业务部门的定期互动以及来自消费者使用情况的有意义的数据，以确保项目始终专注于业务目标。目的是根据实际业务需求不断纠正项目的过程。
将工作分解为相对较小的业务相关功能，然后业务可以在每个证书发布周期将其更直接地确定优先级。当他们接受无法为长期交付的产品制定精确计划，但他们可以优先考虑接下来要制造的产品时，真正的业务收益就会显现出来。
敏捷本身已成为一个“旧”术语，并且随着时间的推移，由于滥用了将近二十年而遭受了痛苦，就像许多术语一样。但是，目前，对于这些方法而言，它是否仍可能是最笼统的术语。
生命周期自动化
除非您减少将新代码投入生产所需的时间，否则您无法达到所需的敏捷度。如果生命周期过程很慢，方法的敏捷性或组件的轻量级都无关紧要。此外，如果您的反馈周期中断了，您将无法实时响应业务需求的变化。生命周期自动化围绕三个关键管道进行。这些都是：
持续集成—构建/测试管道自动化持续交付/部署-部署，验证持续采用-运行时货币（常绿）
我们在下图中显示了这些相互作用：
管道自动化（CI / CD）是DevOps和敏捷方法的基础
持续集成（CI）意味着经常（“连续”）对源代码存储库进行更改，并且这些更改将立即自动构建，进行质量检查，与相关代码集成并进行测试。 CI为开发人员提供了有关其更改是否与当前代码库兼容的即时反馈。我们发现基于映像的部署可以实现更简单，更一致的构建管道。此外，创建更多模块化，细粒度，解耦和无状态的组件可简化测试的自动化。
CD代表“持续交付”或“持续部署”（两者都是有效的，尽管Jez Humble的书普及了“持续交付”一词，其中涵盖了两者）。持续交付从CI中获取输出，并执行将其部署到目标环境中所需的所有准备工作，但是并没有部署它，因此最后一步要在受控的，认可的条件下手动执行。当环境允许自动化部署到环境中时，即连续部署，其敏捷性优势与潜在风险之间得到了平衡。
持续采用（CA）是一个越来越不常见的概念，因此鲜为人知。与基础软件运行时和工具保持最新。这包括Kubernetes，语言运行时等平台。大多数供应商和开源社区已转向季度甚至每月升级。并且无法跟上当前软件的发展，将导致过时的应用程序难以更改和支持。内部治理通常要求至少进行一次安全更新。供应商可以提供对最少数量的后继版本的支持，因此支持窗口一直都在缩短。例如，Kubernetes每三个月发布一次，社区仅支持最新的三个。如上所述，CI / CD意味着代码更改会触发构建以及潜在的部署。企业应自动执行在供应商或社区发布新升级时触发的类似CA管道。有关CA的更多信息，请参见持续采用。
值得注意的是，生命周期自动化仅与其周围流程的效率一样好。如果您的发布批准周期仍需要数周，或者您的生命周期以月为单位，那么将CI / CD周期时间缩短到几分钟就没有任何价值。
DevOps和站点可靠性工程
从上图可以看出，生命周期自动化为人们工作方式的更深刻变化奠定了基础。随着我们简化代码完成和将代码部署到生产之间的机制，我们缩短了开发人员和操作角色之间的距离，甚至可能将它们组合在一起。
这被称为DevOps，并具有一些关键主题：
跨开发和运营角色的协作和组合运营关注点“左移”快速的操作反馈和解决方案
在传统环境中，开发和运营角色之间存在很大的分离。不允许在生产环境附近开发人员，并且操作人员几乎不会接触软件开发过程。这可能意味着在编写代码时并未考虑到生产环境的实际情况。当运营团队为了保护自己的环境而独立尝试引入质量门，从而进一步阻碍生产路径并周期性地扩大差距时，这种分离变得更加复杂。
DevOps采取了一种方法，我们应不断努力减少并可能消除开发与运营之间的差距，以使它们与目标保持一致。这鼓励开发人员“左移”许多操作注意事项。实际上，这归结为提出一系列问题，然后根据答案采取行动：
我们可以使开发环境与生产环境有多相似？作为最早的测试，我们可以测试可伸缩性，可用性和可观察性吗？我们是否可以从一开始就设置安全性，而不仅仅是针对主要环境在最后打开安全性？
容器和Kubernetes等平台元素可以在其中发挥重要作用，正如我们将从基于映像的部署和基础架构之类的概念中看到的代码一样，我们将在后面讨论。
显然，通过使用CI / CD缩短开发和生产之间的路径与DevOps息息相关，敏捷方法的迭代和业务侧重本质也是如此。这也意味着改变人们的工作类型。软件开发人员应在维护生产系统方面发挥积极作用，而不仅仅是创建新功能。运营人员应专注于自动执行单调任务的方法，以便他们可以继续从事更高价值的活动，例如创建更具自治性的自我修复环境。当将两者结合在一起时，通常将这种特殊角色称为“站点可靠性工程师”强调他们也是软件工程师这一事实。成功实现这一目标的关键是必须接受组件中的“故障是正常的”，因此我们应该计划如何管理故障，而不是徒劳地尝试阻止故障的发生。
在一个理想的世界中，软件开发和运营成为一个团队，并且该团队的每个成员都可以交替执行开发和运营角色。但是，对于大多数组织而言，现实情况在此方面存在一定程度的折衷，并且角色仍然倾向于在频谱的一端或另一端变得两极分化。
团队自治
如果我们使这些方法更加灵活，并使生产路径更自动化，那么我们就不能扼杀它们的生产力和创新能力。每个团队都在解决一个独特的问题，它将更适合于特定的语言和工作方式。我们应该通过以下方式赋予团队尽可能的自主权：
所有权下放技术自由自我配置
如果我们要快速迭代更多细粒度的组件，则需要分散“一刀切”的政策的权力下放，并允许更多的本地决策。正如我们稍后将讨论的，只要组件以一致的方式交付（例如，容器映像），一个好的云平台自然应该鼓励围绕构建，部署和操作的标准化。为了提高生产力，团队需要在如何实现这些组件方面拥有自由度。选择自己的技术，例如语言和框架。同样重要的是，确保团队可以快速自我配置所需的工具和资源，这当然与云基础架构的本质非常吻合。
整个企业在方法和技术上仍需要一定程度的一致性。例如，诸如Spotify模型之类的方法通常通过“行会”来满足这种需求，“行会”是由团队中的个人组成的小组，他们专注于鼓励（而不是强制执行）基于自己团队中实际经验的通用方法和工具。
当然，需要注意的是，控制权的分散通常不能普遍应用，也不能一次全部应用。仅对企业的某些部分或企业中的某些类型的计划有意义。最终，要在公司的创新要素和创新要素之间保持平衡，以保持市场领导地位，并确保您不因不断变化和差异扩大而损害企业核心竞争力的完整性。