避免不完全的云原生（二）：人员和流程要素.docxVIP

避开不完全的云原生（二）：人员和流程要素 2021-01-12 在前一篇文章中，我们争辩了云原生的实际含义，并且指出，要从云原生方法中获益，就需要从多个角度来端详它。这不只与你使用的技术和基础设备所在的位置有关，还与你如何构建处理方案有关。 但最重要的或许是，它和你如何组织员工和遵照什么流程有关。在这篇文章以及接下来的两篇文章中，我们将引见成功迈出云原生第一步的最重要的部分，并从不同的角度进行分析。本系列文章的主题摘要如下图所示： 云原生组件 让我们从最简约被忽视的角度开头——云原生对相关人员及其所在流程的影响。 云原生要素：人员和流程 要想在云原生方法上取得成功，人员组件比其他任何组件都重要。为了实现云原生的业务价值，团队需要能够在业务和 IT 之间快速协调，以一种“低接触”的方式将更改提交到生产环境，并对所交付的内容担任，而且决心十足。任何新技术或现代架构方法都无法凭一己之力实现这一点。团队需要投入精力转向灵敏方法，接受 DevOps 准绳和软件生命周期自动化，引入新的角色（例如 SRE），而且，组织必需赐予团队肯定程度的自治权。下图呈现了云原生方法中人员要素的一些最重要的方面： 云原生要素：人员和流程 这个列表确定不完整。我们还认为，关于人员，还有其他方面可以提高团队弹性，超出了上面列举的要素，如转向无责怪文化，鼓舞成长型思维。接下来，我们将对上图中的每一项进行深化探讨。 灵敏方法 云原生基础设备和基于微服务的设计使得开发可快速更改和部署的细粒度组件成为可能。然而，假如我们没有能够用来实现交付并兑现承诺的开发方法，这将毫无意义。灵敏方法使被授权的（去中心化的）团队能够缩短变更周期，更紧密地结合业务需求，其特点如下： · 短而有规律的迭代周期 · 固有的业务协同 · 数据驱动的反馈 通常，灵敏方法会被拿来与旧有的“瀑布式”方法做对比。传统的瀑布方法会提前收集全部的需求，然后，团队在近乎隔离的形态下工作，直到他们交付最终产品供验收为止。虽然这种方法能够最小化实现团队的妨碍，使他们不受变更恳求的影响，但是在当今快速变化的业务环境中，最终交付物很可能与当前的业务需求不同步。 灵敏方法使用迭代开发周期，会与业务定期接触，再结合有意义的客户使用数据，可以确保项目一直专注于业务目标。其目的是依据实际的业务需求不断地修正项目的方向。 工作被分解成相对较小的、业务相关的特性，业务可以在每个发布周期中更直接地确定它们的优先级。当他们可以接受没有精确的长期交付方案，但可以确定接下来构建什么时，对业务的真正好处就消灭了。 灵敏本身正在成为一个“陈旧的”术语，和很多术语一样，它已经患病了近二十年的误用。然而，就目前而言，它或许仍旧是对这些方法的最好的概括。 生命周期自动化 除非你缩短将新代码转移到生产环境所花费的时间，否则你无法达到你想要的灵敏程度。假如生命周期流程很慢，那么你的方法多灵敏，或者你设计的组件多轻量化，就都没有什么关系了。此外，假如反馈周期被打破，你就不能实时地对业务需求的变化做出响应。生命周期自动化次要围绕三个关键管道，它们是： · 持续集成——构建/测试管道自动化 · 持续交付/部署——部署、验证 · 持续接受——运转时更新 下图说明白它们之间的交互关系： 管道自动化（CI/CD）是 DevOps 和灵敏方法的基础 持续集成（CI）意味着经常（“持续”地）向源代码存储库提交更改，并且可以即刻进行自动构建、质量检查、相关代码集成及测试。CI 可以即时为开发人员供应反馈，让他们晓得更改与当前代码库能否兼容。我们发觉，基于镜像的部署使得构建管道更简约、更全都。此外，愈加模块化的、细粒度的、完全解耦的无形态组件的创建简化了自动化测试过程。 CD 既可以表示持续交付，也可以表示持续部署（两个都对，虽然 Jez Humble 的著作让持续交付这个术语流行了起来，它实际上涵盖了这两个过程)。持续交付从 CI 猎取输出，并执即将其部署到目标环境所需的全部预备工作，但是不部署，把最终的步骤留在审批之后，以受控的方式手动执行。当环境允许自动向环境中部署时，这就是持续部署，对灵敏的优势和潜在的风险进行了平衡。 持续接受（CA）这个术语晓得的人比较少，它表示一个越来越常见的概念：保持对底层软件运转时和工具的更新。这包括 Kubernetes、言语运转时等平台。大多数供应商和开源社区已经开头按季度甚至按月进行升级。无法跟上软件的进展步伐会导致应用程序过时，变得难以更改和支持。 通常，平安更新是由软件内部的管理机制强制执行的。供应商会为数量很少的旧版本供应支持，所以支持窗口一直在变短。例如，Kubernetes 每三个月发布一次，社区仅支持最近的三个版本。如上所述，CI/CD 意味着代码更改触发构建和可能的部署。企业应当自动化类似的 CA 管