什么是配置漂移？

在某种程度上，配置漂移在系统生命周期中是不可避免的。这种情况可能由两种原因导致：一是人工手动修改网络配置，进而影响网络各组件间的交互方式；二是自动化工具以管理员未预期的方式擅自调整各项设置。如果缺乏完善的文档记录，随着老管理员离职、新管理员接手，可能会做出不兼容或有害的配置变更。

配置漂移的一个典型案例是，管理员在负载均衡环境中修复了一台服务器，但未对其他服务器进行修复。即使系统暂时继续正常运行，也可能在未来出现问题。修补后的服务器可能会使用新的程序库，而该程序库与后续基于原有环境条件进行的网络更新互不兼容，进而可能引发系统中断与运行低效问题。

配置漂移不仅会对性能构成威胁，偏离预设配置的系统，更容易遭到恶意人员攻击并引发数据泄露。例如，如果防火墙规则在向网络添加新资源时没有更新，黑客就可以直接潜入。

配置漂移也会影响合规状态。如果网络文档记录的是一套安全设置，而实际运行环境的配置却与之不符，企业就可能审计不通过。

DevOps 专业人员和系统管理员可以使用工具来防止配置错误、应对配置漂移。诸如 Terraform 这类基础设施即代码 (IaC) 工具，可将网络配置绑定至作为唯一可信源的配置文件。配置文件有助于确保新的网络资源以标准状态自动配置部署，减少发生配置漂移的可能性。

可观测性工具为管理员提供了对指标、日志和痕迹的可视化，帮助他们及时发现配置漂移并实施修复。不可变基础设施通过直接废弃老旧服务器、而非就地修补修复的方式，限制配置漂移的产生。配置漂移也可通过 Ansible 等配置管理工具进行处理。

配置漂移最常见的成因包括：人工手动修改系统配置、自动化执行异常、组织层面管理疏漏导致配置不一致，或是以上多种因素共同作用。

一次性手动修补是配置漂移的主要原因。

热修补程序 (hotfix) 指在常规更新计划之外部署的修复方案，可用于解决紧急突发问题，例如服务器超时参数配置错误而频繁崩溃这类故障。但这种类型的配置更改日后可能会破坏系统：

• 后续的系统更新若未兼容此次修复，可能会将其覆盖，导致原有漏洞再次复现。
  
  
• 此次修复可能引入了未被纳入考量的依赖项，且该依赖项与后续的网络更新存在兼容性冲突。
  
  
• 为修复而创建的临时管理员凭据可能仍然有效，但这会成为额外的安全隐患。

人为失误，甚至只是难以预料的连锁后果，能让系统偏离其应有基准状态的诱因几乎不计其数。即使是很小的改动，也会以这样一种方式累积起来，以至于实时生产环境与版本库几乎没有相似之处，充满错误和安全风险。

如果没有适当的测试和监督，自动化更新和流程可能导致重要的网络资源偏离预期配置。

自动化的有效性取决于其信息来源的真实性。如果 IaC 工具依赖过时的配置文件来启动新服务器，最终可能会破坏环境。对应用程序及 Microsoft Windows 等操作系统的自动软件更新，可能会在不同服务器上于不同时间执行，进而产生具有潜在风险的配置差异。同时这类更新可能与企业专属的网络架构适配不佳，引发更多后续问题。

即使是用于管理配置的工具在某些情况下也可能会导致漂移。例如，网络连接故障可能导致 Ansible 不均衡地推送配置更新，使得部分服务器未被同步修改。该服务器将逐渐偏离环境，并可能导致服务中断。

在组织层面，持续集成/持续交付 (CI/CD) 管道和 DevOps 实践问题可能会导致配置问题。

当开发、运营和安全团队彼此隔离时，混乱、沟通不畅和排查不足是不可避免的。除了技术规范不统一之外，内部各团队在变革管理方面也可能各自为政、采用不同流程规范。一些组织完全缺乏正式的变革管理流程。

缺乏清晰的既定变更操作规范，可能导致变更日志不一致、未经授权的变更以及工作流不被执行。最终，管理员、开发人员和工程师可能会完全规避变革管理流程。

配置漂移会给系统的安全、性能和合规状态带来重大风险。

配置漂移会因产生管理员未知且未修复的安全策略特例，大幅增加组织的攻击面。

例如，为应用热修复而创建的凭据可能仍处于原地，容易遭到黑客的恶意利用。同样，工程师可能会对防火墙规则设置临时例外，但事后未及时关闭，从而大幅削弱网络整体安全状况。开发者可能激活一个安全控制不完整的应用程序进行测试，却从不关闭它，从而为恶意行为者制造另一个安全漏洞。

同样，每一个新添加的应用程序、端点或其他资源，如果未应用适当的安全控制，都可能导致配置漂移。例如，在未正确配置端点检测和响应 (EDR) 系统的情况下添加新服务器可能会产生薄弱环节。微服务配置中的一处简单失误，就可能导致大量未受防护的资产接入网络。

与网络安全一样，网络性能是配置漂移带来的最重大且代价最高的风险。

以一台流量负载高于其他同类型服务器的服务器为例。该服务器可能通过热修复增加连接池容量以提升性能。由于该服务器被负载均衡器控制，均衡器会自动设置策略，将更多流量推向该服务器，以更均匀地分配服务器负载。

在新一轮部署更换服务器时，原本用于扩容资源池的热修复将会失效，该服务器便会因承载过量流量而发生崩溃。最初为优化流量而部署的热修复程序，本身就构成了配置漂移。若未对此情况加以考量，后续的网络变更可能引发代价高昂的业务停机，直至排查出根本原因。

配置漂移可能会使组织在毫无察觉的情况下违反合规要求。当网络实际状态与组织认知中的运行状态或文档记录的配置状态出现偏差时，组织就会面临合规不达标的风险。即使不合规是无意的，组织仍可能面临罚款和成本。

以《健康保险流通和责任法案》（HIPAA）为例。HIPAA 要求组织使用特定的加密方法来保护传输和静止中的敏感数据。

假设管理员需要将一套老旧系统接入符合 HIPAA 合规标准的网络，而该老旧系统采用的是过时的加密方式。如果不解决该加密方式存在的问题，此次系统接入将导致组织不符合 HIPAA 合规要求。

配置漂移检测，即持续追踪网络配置变更、识别与预期基准状态偏差的管理手段，需要结合基础设施即代码、GitOps、不可变基础设施、可观测性等多种工具协同实现。

基础设施即代码，即通过脚本而非手动流程来配置和管理 IT 基础设施的做法，是配置漂移管理中最强大的工具之一。

IaC 通过将网络的理想状态转化为一段可与每个网络组件进行比较的版本受控代码，协助解决配置漂移问题。

例如，在 Terraform 中进行变更操作时，IaC 工具会将状态文件（平台对网络最新的实际状态快照）与声明式配置文件（定义网络理想基准状态的文件）进行比对。随后 Terraform 会比对并修正状态文件与声明配置之间的差异，通过更新基础设施使其与配置文件保持一致，从而降低配置漂移悄然发生的概率。

组织对 IaC 工具实施严格的访问控制可以进一步减少漂移概率。通过仅向有业务需求的授权人员开放 IaC 访问权限，组织可从整体上严控基础设施配置的变更权限。发生变更时，会执行 IaC 版本控制流程，进一步降低漂移风险。

GitOps 是一种 DevOps 实践，它使用开源存储库 Git 作为配置文件的单一可信信息源。GitOps 帮助许多组织以最高的效率和安全性部署 IaC。

GitOps 实践侧重于借助自动化手段，实时校验网络实际状态与 Git 仓库中存储的理想基准状态是否一致。GitOps 平台可以持续扫描网络、检测错误配置并进行标记或应用修复，从而使发生的任何漂移都成为暂时的。而且由于所有变更都与 Git 关联，每一次操作都会记录作者、时间戳和变更说明，全程可追溯。

不可变基础设施通过大幅减少更改网络配置的机会总数来减少配置漂移。

不可变基础设施是指在需要变更时，通过替换而非修改服务器等 IT 资源来实现管理的实践模式。

假设某台服务器需要安全更新。管理员不会在现有服务器上直接执行更新，而是下线旧服务器，并替换为一台已完成更新的全新服务器。

不可变基础设施利用 IaC 工具，在需要更改时按照代码中的描述自动部署新系统。添加到网络中的每个新组件都会自动匹配所需的状态。

IaC、GitOps 和不可变基础设施这三种实践密切相关。IaC 工具定义网络组件镜像，而 GitOps 负责简化部署流程、建立完整的网络变更记录，并有效防范配置偏差。

可观测性的三大支柱（日志、指标和跟踪）在防止配置漂移方面也可以发挥作用。

例如，可观测性平台能够检测到某台服务器的各项指标（如响应时间、CPU 使用率）与配置本应完全一致的其他服务器出现明显偏差。这种差异是漂移的潜在症状。同样，若某台服务器出现某类错误的数量异常偏高，各服务器错误率日志中的差异也可能预示着发生了配置漂移。应用程序调用链的追踪数据，也可以定位出现配置偏差与配置漂移的节点位置。

漂移检测是将网络实际状态与预期基准状态进行比对，从而识别配置差异的一种运维实践。虽然理论上可以手动完成这一过程，但许多云和 IaC 服务商都提供配置漂移检测功能工具，能够将原本耗时繁琐的工作实现自动化、流程化。

例如，AWS 配置会记录 AWS 模块的配置，标记任何偏离期望状态的内容，并帮助修复漂移问题。Terraform 的运行状况检查会核验基础设施实际配置是否与工作区状态文件中的记录一致，并持续验证各项资源是否满足系统配置中设定的合规检查要求。

Terraform Enterprise 将实际条件与状态文件进行比较，或更新状态文件以反映实际条件，从而揭示变化。Ansible 和 Puppet 等配置管理工具也可用于漂移检测。