基础设施即代码：只是漂移管理还不够

什么是配置漂移？

随着公司的发展，软件生产和交付系统往往会变得越来越复杂。随着而来也会发生配置上的经常变更。

在最理想的情况下，变更会以良好的方式进行全面跟踪。但是，我们的生产环境并不完美，比如其中的许多修改都没有记录。如果是无关紧要的修改，那么对系统的影响会很小。如果这些修改导致系统变得不稳定，那么就会出现所谓的“配置漂移”。

当新建并合并分支，以及将其他多个变更提交到主分支时产生某种冲突时，就会出现漂移。在小型团队中，开发人员可以及时告知同事他提交了变更。而在较大的团队中，分叉（fork）和合并之间的变更数量可能非常多，产生的冲突数量以及解决冲突耗费的时间都会更多。

也许，代码漂移是最常见的漂移类型，但由于现如今软件架构和依赖关系的复杂性，配置漂移也很常见。开发人员可能会在分支创建完成后在过渡环境或预生产环境中新建一张表。可能会新建一个 lambda 表达式，或是更新 SQS 配置。如果开发人员的环境发生漂移，那么代码在旧版本上可能运行正常，但合并到经过更新的环境就会出问题。在一些简单的场景，这可能不会立即发生问题，但随着复杂性增加，应用场景越来越多，问题可能就出现了。大量的调试和返工在所难免，进而导致发布时间延期。在接下来的几节中，我们将介绍几种配置漂移的管理方法。

图 1 代码漂移示例

配置漂移的影响

代码会在多个环境中“传播”，从个人工作站到共享开发、测试、QA、过渡以及生产环境。如果其中某些环境之间存在不一致，就会导致安全漏洞和部署问题。如果你要处理的应用程序和服务需要遵从严格的法规或标准，那么开发过程就会面临风险。

确保软件开发生命周期中各个环境共享相似的配置是一项非常费时的工作，这需要多个部门的配合。有时候，团队要花数周时间为不同阶段配置不同的环境。

员工经常会对他们的环境做些小修改，但不会将它们传递给生产环境。这类配置漂移通常不为人所注意，但也会造成严重影响。如果长时间不注意，它们就会导致应用程序出问题，软件工程师可能要花费数小时来追踪并修复。他们需要排查代码和环境问题，找出可能导致异常行为的原因，而这些时间原本可以花在更有效率的事请上。

随着时间流逝，产品开发生命周期延长。除了宕机外，这是环境漂移最常见的后果之一。Gartner 2014年发表的一篇文章提到，IT 公司每宕机 1 分钟平均损失约 5600 美元。

此外，这类事件会导致开发停顿，开发人员不得不立即放下手头的工作，切换环境并着手解决事件。这种中断可能会导致代码 Bug，因为我们的思路被中断了，有些想法可能会遗漏。这样就有恶性循环的风险。

配置漂移会影响员工满意度，导致与开发体验相关的指标下降。

减少漂移的方法

配置漂移多少有些不可避免。不过有许多方法可以减少配置漂移。在接下来的内容中，我们将探讨漂移管理的一些实用方法。

建立清晰的流程，并做好文档记录

在处理配置漂移时，应该优先确定一套清晰的变更管理策略和流程。在许多情况下，人为错误是漂移的主要原因，可能是因为没有遵守流程，也可能是因为没有和其他团队沟通好。设计良好的变更管理策略可以保证所有必要的测试都已进行，并且可以保证在正式批准应用于生产环境之前，有某个有权限的人评审并评估这些变更的影响，从而降低产生副作用及未知问题的风险。你要记录好应该做哪些变更，什么时候做，以及在什么系统上做。

应用基础设施变更的方法越少越好，最理想的情况是，只有一个通道可以进行更改，不管是应用、开发、过渡还是生产环境。

除了推送变更的通道外，还需清晰地定义好权限并严格执行，将审批/发布权限授予一组预先选定的人，他们经验最丰富，而且根据以往的情况看最值得信任。

任何不符合标准的情况都可能导致配置漂移。

实现基础设施即代码（IaC）

遵循基础设施即代码原则并使用类似 Terraform 这样的解决方案，是消除配置漂移最有效的方法之一。

使用代码定义环境，而不是通过手动变更来同步环境，这本身就容易出错。代码很清晰，而且在任意数量的资源上应用/运行都一样，没有漏掉什么东西或颠倒操作顺序的风险。

借助代码版本控制（如Git），基础设施即代码平台还可以提供详细的记录，包括现在和以前的配置，解决了修改没记录的问题，这还有一个额外的好处就是留下审计线索。像 Terraform、Pulumi 和 Ansible 这样的工具就是设计用来管理配置的，可以用它们识别漂移并发出信号，有时甚至还能自动纠错——这样，你就有可能在变更真正影响系统之前将其纠正过来。

和任何工具一样，效果取决于你的用法。使用一款像 Terraform 这样的工具本身并不能使你所在的公司免疫配置漂移。还是要设计好流程，而且每个人都要遵守；即使所有的部署都依赖 IaC，在某些情况下（如添加、移除或修改远程资源）还是会发生漂移。你也无法保证所有部署都通过 IaC，因为在许多情况下，仍然可能使用 CLI、API 或 Web 浏览器手动部署。

在 Terraform 中，检测潜在漂移最简单的方法是重新计算并评估 Terraform 预期状态的计划：如果计划为空，则基础设施状态符合预期，什么都没变；如果计划中有需要采取的步骤（而且你也没有修改代码），则表示有来自其他通道的变更导致了配置差异。有时候，这可以自动修复，系统可以立刻回到预期状态，但你至少应该查下差异是怎么出现的——对流程做相应地调整，避免同样的事情再发生。

在共享和发布容器化应用程序时，基础设施即代码显得更加有用。虽然容器镜像包含运行所需的所有代码和软件依赖，但一旦部署到云上，它常常需要额外的基础设施元素来实现可扩展性以及提高可靠性（如负载均衡器、监控、日志等）。

在将应用程序成功部署到云上之后，你需要确保它流畅地运行，而且限制特定受众访问。也就是说，你需要围绕容器镜像重建所有基础设施，而完成这项工作最简单的方法就是使用描述所有必要配置的 IaC 模板。

注意，环境间（如开发和生产）的差异对容器化应用程序的行为和可靠性有很大的影响。这是由包括数据库、服务在内的所有云原生资源所致，它们都位于应用程序之外，但对于其正常运行至关重要。从这个意义上讲，IaC 让变更可再现且可预测，保证过渡环境与生产环境非常相似，生产环境代码部署和基础设施变更的风险大幅降低，而效率则有很大的提升。

规程与 IaC 的优缺点比较

频繁重复手动执行变更步骤（不同的人在多次执行时都要严格遵守）很容出错。意外事件一定会发生——不是“是否”的问题，而是“什么时候”和“什么方式”以及“多么经常”的问题。

运行速度快、每次都能一致应用的已测试代码可以消除大部分问题，但最终，这都归于强大的流程，即变更管理。要制定策略，强制使用 IaC，屏蔽应用变更的其他方式，还要确保所有团队成员都遵循质量相关的流程。最终，测试、代码评审、影响评估以及审批都归结为 UI 中的几次按钮点击或是 CLI 工具中的一次命令执行，但是，在这些最终动作发生之前开展的底层工作非常重要，仍然是由人手动完成的。

IaC 让你可以做得更好，消除问题，减少意外事件，加快前进步伐，但实际怎么用还是取决于你。

使用环境即服务（EaaS）解决漂移

变更管理和自动化将帮你创建并扩大业务规模，并建立以简单明了的流程为基础的工程文化。而环境即服务解决方案可以帮助你恰当地实施这一切。

在文章开头，我们介绍过配置漂移对工程团队的严重影响：花费数小时排查代码和环境故障，试图找出意外行为的潜在原因。此外，静态环境更容易发生配置漂移，因为它们是可变的——为了达到某个状态，将更改应用到当前状态，但这个当前状态可能并不是每次都像我们期望的那样。从零开始创建不可改变的环境，肯定可以减少阻力，大大降低遇到错误的概率。

从这个意义上讲，环境即服务解决方案可以对很多工程团队产生巨大影响，让他们可以无缝地访问测试及开发环境，把省下的时间增加到实际的产品开发中。随着时间的推移，工程团队将变得更加独立，也更加专注于产品。

总结

在可预见的未来，配置漂移仍然不可避免。而市场上正在实施的一些配置管理方法，如自动对比环境的当前配置和基线配置，能缓解配置漂移的副作用。EaaS 解决方案，配合 IaC 和良好的变更管理，可以帮助你预防漂移，缩短开发周期。借助合适的网勾（Webhook），我们可以识别代码或基础设施变更。通过维护每个环境的状态，可以知道它是否发生了漂移，并决定是否触发一次自动更新。我们希望任何生产环境都不出现漂移。但是，生产环境服务于在线客户，通常需要满足特定的服务等级协议（SLA），而且有维护窗口，因此，这些环境会有手动触发的更新，或是持续部署调度器触发的更新。

作者简介：

Roxana Ciobanu 是 Bunnyshell 的联合创始人兼首席技术官。她是一名云爱好者，热衷于保障高可用性、性能调优和云架构安全。她曾担任 DevOps 和解决方案架构师，实现了云技术与运营和开发的完美结合。

原文链接：

Infrastructure as a Code—Why Drift Management Is Not Enough