为什么说 DevOps 治理是实现快速开发的关键

对于任何组织，产品创新都是其在垂直市场中取得商业成功的关键因素。用户希望获得高度差异化、高性能而又令人愉悦的功能体验，而且这种期望比以往任何时候都强烈。COVID 加剧了对速度的需求，越来越多的企业将他们的主要精力转移到通过多种渠道在互联网上提供服务。

不过，在有些组织中，速度和创新与成本控制、规划及合规性是针锋相对的。如今，每一个阻碍快速操作的潜在障碍都是标准化和自动化的候选项。测试方式和测试主体的转变就是一个这样的例子。从一个中心化团队负责测试所有应用程序，到要求软件开发\设计工程师在开发团队中进行测试（SDET），这是一个巨大的转变。这个过程伴随着工具和流程的升级。应用程序基础设施这个主题（关乎开发/测试环境的可用性）早就应该进行全面改革了，这是一个理想的候选。

传统上，中心化 DevOps 团队负责定义应用环境，因为开发人员很少会将环境定义视为自己工作职责，它们既没有相关的技能，也没有意愿。那些职责包括基础设施分配、编排、配置和管理。在这个场景中，常用的技术有 Terraform、Helm Charts,和 Ansible 脚本。举例来说，开发人员将代码提交到特性分支时可能会用到应用环境，他们希望运行一个快速的冒烟测试，以确保自己不会引入漏洞。然后，构建服务器会构建代码，并将应用程序部署到一个新创建的环境中。该环境定义由 DevOps 团队通过这些资产创建，并由 DevOps 团队或开发团队配置到构建服务器中。

问题所在

和其他许多情况一样，多个开发团队与中心化 DevOps 团队在协作过程中可能会产生摩擦。例如，环境会随着应用程序不断变化的需求或是开发人员的需要而周期性地变化。如果组织有多个应用程序和许多团队，原本就已经为有效消除开发人员的障碍而疲于奔命的 DevOps 团队负担就更重了。开发人员讲求实效；他们会挽起袖子做好准备，而你会面对一大堆配置文件，调整，重新配置，有时还会用到不同的配置和组件。这会带来多领域的挑战，包括文化、财务以及合规性。

混乱之治：小（环境）变更可能导致大延误

在许多组织中，CI 使用的应用环境是由首席架构师或 DevOps 工程师提前设计好的。根据产品和团队的规模，团队内部已经产生了那些资产的许多变体。当不需要做任何修改时，这种方法很有效。然而，一旦有一天需要修改，尤其是当修改会影响到多个团队和基础设施配置资产时，这就会成为开发人员的绊脚石。

以下面这个简单的 Terraform 定义为例：

provider "aws" { profile = "default"  region = "us-west-2"}

resource "aws_instance" "app_server" { ami = "ami-830c94e3"  instance_type = "t2.micro"  tags = { Name = "ExampleAppServerInstance" }}

假如有人要求 DevOps 团队将机器换成一台性能更强的机器，或是他们需要修改标签。在每个团队都在使用的大量 Terraform 文件中，找出谁了解这个库以及文件是如何编写的又该如何调整，是一种极其繁重的工作。为 10 个团队做这项工作就可能会是一项具有里程碑意义的任务，整个过程很容易就会用掉两周甚至更多的时间。

在此期间，为了能够继续编码，开发人员会非法侵入 Terraform，即使他们知道这样做可能会有问题。

由此得出的一个重要结论是：通过模块化和重用经过测试和验证的元素来整合应用描述符可以提高效率。这样，DevOps 团队就可以用一种可扩展、可重复的方式快速响应开发团队的需求了。

下面是一些可能出现的反模式。

开发人员通过工单系统将应用环境变更需求扔给 DevOps 团队，导致他们之间的关系进一步紧张。领导者应该采取预防措施，提前发现这种情况，然后考虑适当的应对措施。在许多情况下，基础设施控制平面会提供发现底层 IaC 文件并将其纳入控制平面的能力，以及检测环境间任意代码漂移的能力。将这个过程自动化可以大幅减少开发人员和 DevOps 团队之间的摩擦。

开发人员自己变更应用环境，导致本地 IaC 文件越来越多，并出现与之相关的失控。当错误出现，事情停止，相互指责随之而来。和上面类似，需要赋予 DevOps 团队合适的工具，帮助开发人员专注于应用开发，让他们无需管理环境。

控制成本

公司在他们提供的服务中嵌入某种形式的、基于海量数据的人工智能，现如今这很常见。这意味着，当开发人员想要创建或修改代码并测试时，他们需要一个相当健壮的环境，成本可能会很高。如果有许多开发人员连续并行工作，成本还要翻好多倍，那会极其高昂。使用异构环境时，云成本管理可能会更加复杂。

一个有效的工具应该能够管理各种复杂的现实场景。例如，想象这样一个应用程序，它托管在由本地基础设施组件和云组合而成的混合基础设施上，通过 Terraform 和 Helm 来描述。成本计算工具应该能够提供成本分析功能，包括设计和操作，并且可以管理多个用户、团队和环境：

关键信息：标签和成本要从一开始就嵌入流程和环境。在此基础上，在启动和评估环境时，以及作为工具更广泛地审查支出效率时，都需要提供适当的报告。在典型的单云供应商中，有一些工具可以提供这种服务。在异构基础设施设置中，这可能要困难一些。

下面是一些需要当心的反模式。

团队承诺在环境设计和使用时更加规范（比如在一天结束的时候拆除环境）。像许多行为变化一样，这变化是不自然的，很难维持。随着时间的推移，这种情况不太可能持续下去。此外，如果这些环境的启动和拆除还得手动完成，那么随着时间的推移，就可能会导致环境中配置漂移。

将 DevOps 团队的个人指定为“成本所有者”是一种不切实际的方法。没有恰当的标签工具，这个人就得遍访各个团队，要求他们在某个时点设置和维护标签，并在之后继续维护。他们将不得不构建报表基础设施并提供报告。这是一项很夸张的任务，尤其是在（繁忙的）开发团队在不断增加，基于异构基础设施的应用程序在快速演进的情况下。

合规性与开发速度相矛盾吗？

通常，普通开发人员并不熟悉合规性这个主题，这个话题出现的时候，通常也不会受到热烈的欢迎。是的，合规性并不能提升速度或是方便最终用户，但在某些市场上（比如金融服务和医疗），合规性要么是强制性的，要么是竞争优势。有些组织可能会担心软件创建和创新的加速会导致合规性无法保持。

对于 DevOps 团队负责人来说，其任务通常是报告和领导所有团队的合规性议程事项（至少在涉及到基础设施及其访问时），与多个团队打交道是很有挑战性的。

以 Terraform 文件内秘密的管理方式为例。显然，不同的秘密保护等级对应不同的投资水平（金钱和精力）。

当 DevOps 团队负责这个决策制定过程时，他们首先需要评估不同团队使用的基础设施即代码文件集，然后浏览这些文件，做必要的修改。这个过程涉及的范围很广。相反，如果 Terraform 文件是由 DevOps 团队按模块化的方式集中管理，他们就会确切地知道那个库哪些文件需要修改，在开发团队看来，修改过程很快而且透明。

使用分散的、不相干的 IaC 文件配置的环境，有一个非常典型的情况（和主要缺点）是它们无法反映生产环境。这种过程的结果是，有时开发人员可能会对生产环境做假设，而生产环境可能会被另一个团队更改。如果环境不是实行中心化管理，那么一个环境的更改可能无法反映到软件开发生命周期的其他环境中。其结果就是，可能会将破坏性的缺陷引入生产环境，有可能导致停机。对于众多的基础设施定义，DevOps 团队现在需要在生产环境中调试，这个过程通常会延长停机时间。

关键信息：在环境拓扑（在多大程度上模拟了生产环境）、秘密和密钥等方面，将低级别的环境当成生产环境来对待。通过提供一种可以根据需要快速配置和拆除环境的方法来控制低级别环境的成本。

请注意，低级别的环境（准生产、开发等）正逐渐向着模拟生产环境迈进，但只是做了一个不很重要的尝试。最终的结果是，随着时间的推移，这项工作将无法持续下去，可能会出现生产环境部署失败的风险，或者更糟，出现停机和安全漏洞。

为模拟生产环境创建专门的构建项目和环境，但只能涵盖少数情况。在生产环境中部署失败（所部署版本的构建环境没有模拟生产环境），或类似的，发现安全漏洞，自然的反应是增强那个团队和/或微服务。但这种方法只是将风险转移到了下一个团队。关于哪个团队及微服务需要更真实的环境，要有全面而完备的分析和统筹方法。对低级别的环境进行模块化描述，这样它们的基本组件就会是公用的，而有些团队会添加额外的层，这基本可以避免每个团队都完全不同的情况，那会非常难以管理。

总之，变更管理、成本控制以及合规性，我们只是通过这三个方面来凸显这样一个事实，应用环境是一个特别复杂的主题，一个对任何产品组织的创新和速度都至关重要的主题。绝大多数组织都没有做到完美，实际上离完美还差很远。他们正在转换基础设施解决方案（典型地，从本地到云），或是从单体转变为面向服务的架构。然后是业务增长需求，需要精心的应用架构规划来支持。企业的运维成本控制和治理需求往往与开发人员的快速创新目标相矛盾。但事情并不一定要如此。有一种更好的方法可以为每个团队提供恰当的控制级别，方便大规模协作，并实现业务增长目标。

作者简介：

Amir Rozenberg 是 Quali 的产品副总裁。该公司是基础设施自动化解决方案的全球领导者，在测试和 QA 解决方案方面有非常丰富的经验。Amir 及其团队热衷于帮助用户和公司加快软件交付，而所采用的方法是消除复杂的基础设施所造成的障碍，并创建一个高效、可扩展和可预测的环境。在加入 Quali 之前，Amir 曾担任 Sauce Labs 的产品负责人，推动低代码测试和移动测试自动化等关键变革举措。而在加入 Sauce Labs 之前，Amir 领导了 Perfecto（移动和 Web 应用自动化测试领域的全球领导者）的一系列产品，在保持高质量标准的同时加速了应用创新。Amir 拥有特拉维夫大学工学学士学位。

原文链接：

Why DevOps Governance Is Crucial to Enable Developer Velocity