配置漂移指南以及如何防止它

配置漂移是所有 IAAC 开发人员关注的重要问题。 这篇文章将了解配置漂移管理、它的重要性、原因和潜在的解决方案。

什么是配置漂移？

应用程序所有者必须随着时间的推移改变他们的应用程序和底层基础设施，以不断增强客户体验。 这些客户可能在公司内部或外部。

这些更新和更改会导致应用程序和基础架构的配置发生更改。 这些修改可能是有益的，也可能会降低系统的硬化状态。 配置漂移就是这个术语。

配置漂移的工作原理

配置漂移的可能性随着软件生产和交付系统的复杂性而增加。 代码通常从开发人员的工作站转移到共享开发环境、测试和 QA 环境，最终转移到登台和生产环境。

潜在影响随着沿管道发生漂移的距离而增加。 即使是安装在开发人员笔记本电脑上的软件包版本与安装在测试服务器上的版本之间的微小差异也会延迟问题调试。 通常，只有分期和生产预计是彼此的副本。 压力很大，因为许多企业每天都会多次部署新代码。

配置漂移的常见原因

缺乏沟通

有时上游团队无法与下游合作伙伴就他们所做的更改进行沟通，从而导致整个下游系统崩溃。

修补程序

修补程序是对代码所做的更改，以解决不能等到应用程序的下一次计划更新的关键问题。 有时，致力于解决问题的工程师未能对管道中的其他环境进行更改或记录相同的修复，从而导致漂移。 通常，重新引入原始问题将解决这种漂移。

关键软件包更新

关键包更新有点类似于修补程序。 两者都以快速的速度执行。 主要区别在于应用关键包更新是为了避免将来发生事件。 因此，此类更新可能会以与修补程序相同的方式导致漂移。

缺乏自动化

自动化不会完全消除配置漂移的可能性。 它只会减少它的机会。

便利变化

有时，开发人员所做的更改是暂时的。 例如，如果开发人员在测试服务器上安装了一个新包来测试某些功能并且忘记将其恢复到其原始状态，就会发生漂移。

为什么配置管理很重要？

配置漂移如此具有破坏性的原因之一是，如果没有人一直在寻找它，漂移可能不会被发现，因为它会逐渐破坏您的基础设施的基础，就像墙后房子里的小泄漏一样。

当发现配置漂移时，找到导致这一切发生的配置漂移的根本原因需要时间，这是紧急情况下的宝贵资源。

在软件开发中，漂移是发布周期缓慢的重要原因。 它可能会导致不必要的工作并妨碍开发人员的工作效率。

降低成本

  当您拥有 IT 基础架构的详细图像时，您可以通过识别重复或过度配置来降低所需的总量。

更高的生产力

  具有稳定且知名配置的集群可以实现批量管理和基础设施建设。 此外，通过限制唯一（或雪花）服务器减少了手动管理单个设置的要求。

更快的调试

一致的配置允许调试团队排除配置错误。 团队可以专注于其他潜在原因，更快地解决故障单，因为他们不必寻找服务器、服务器集群或环境之间的配置差异。

由于配置偏差导致的问题

安全问题

不安全的配置是安全漏洞最常见的原因之一。 即使您从受保护的配置开始，配置漂移也可能使其他攻击和网络破坏更有可能发生。

停机时间

  配置错误可能导致严重的停机时间，使攻击者能够使用 DoS 漏洞或危及关键服务器。 不过，这还不是全部。 假设您修改了网络设备的配置，从而影响了性能。 你总是可以回到你的“黄金配置”，对吧？ 如果该配置有缺陷，恢复服务将需要更长的时间。

不合规

  严格的安全控制对于遵守 ISO 27001、PCI-DSS 和 HIPAA 等法规是必要的。 如果不停止配置漂移，可能会导致您破坏合规性。

性能下降

当配置处于预期状态时，配置通常处于最佳状态。 临时修改会通过导致瓶颈和冲突来阻碍网络优化尝试。

浪费时间

对您不太了解或与网络文档不匹配的网络进行故障排除可能需要很长时间。 这意味着配置偏差可能会导致 IT 故障排除问题，如果网络处于预期状态，这些问题可能不存在或更容易解决，此外还会导致用户停机。

监控配置漂移时要注意的常见错误

在一个完美的世界中，开发人员（Dev/QA/Staging/Prod）的所有环境服务器都将具有相同的配置。 不幸的是，这不是事物在“真实”世界中的运作方式。 在商业环境中，当向软件引入新功能时，应用程序所有者经常修改基础架构。

监控配置漂移对于确保软件环境尽可能同质至关重要。 配置管理可减少开支、提高生产力和调试时间，并增强用户体验。

为了尽可能成功地进行监控，组织必须避免错误，即使他们使用配置管理并监控其配置漂移。

常见的错误如下：

不维护 CMDB

使配置管理数据库 (CMDB) 保持最新是配置管理的重要组成部分。 可以在一个地方检查网络硬件和软件安装的信息，由配置管理数据库提供。 为每个资产或配置项收集数据，提供工作场所的可见性和透明度。

未能维护 CMDB 会使企业面临无法完全理解一个项目的配置如何影响另一个项目的危险。 组织冒着破坏其基础设施和安全性的风险，却不了解后果。

CMDB 可能难以管理，尤其是随着资产数量的增加，但有效的数据库组织和管理对于成功跟踪配置漂移和理解基础设施至关重要。

没有如何监控配置漂移的计划

组织经常拥有需要监视的庞大、复杂的基础设施。 确定最需要监控的组件至关重要。 否则，配置管理可能很快变得难以管理和混乱。

组织必须指定哪些资产对于公司监控和特定业务部门至关重要。 将关注最关键的系统，这些系统将因单位和行业而异。

不自动监控

组织可以通过多种方式监控配置漂移。 然而，有些方法比其他方法更精细和更成功。

手动监控配置漂移既昂贵又耗时。 手动监控也暴露了人为错误的可能性。 除非您的公司的基础架构占用空间非常小，否则这不是监控配置漂移的最佳技术。

自动监控是将配置保持在所需状态的最发达和最有效的方法。 专用配置监控系统可以立即检测漂移并经常提供解决方案，包括快速校正。 这保证了业务的基础设施在可行的情况下尽快恢复到所需的状态，并且影响最小。

如何监控配置漂移：

一旦您意识到配置漂移可能造成的损害，为什么检测配置漂移应该成为头等大事就变得显而易见了。 了解要保留的内容以及为什么将其呈现为造成漂移的更改是该过程的第一步。

知道你在找什么

您可以通过识别对整个组织至关重要的组件以及对每个业务部门至关重要的组件来对您的组织进行分类。

这因单位而异，并且可能在高度监管的行业中很广泛，或者仅专注于较窄的系统关键文件/应用程序。 系统的重要性将决定监控系统的频率和严重性。

设置基线

由于各种设置，生产环境和测试阶段之间总会存在差异。 通过定义每个步骤应该是什么以及允许的偏差类型来创建检查漂移的基线。

与用户验收测试设置或零漂移制造阶段相比，早期测试阶段可能更适合更高的漂移容限。

监控您的系统

所需的监控级别将根据组织的成熟度、其当前系统、工具、需要检查的配置总数以及所需的审查级别而有所不同。 根据要求和合规性，组织内每个单位的监控可能会有所不同。

如何防止配置漂移

在定义了配置基线和允许的差距之后，监控必须确保基础设施保持在适当的配置中。 如果没有监控策略，构建配置计划和文档会浪费时间。

可以采用各种方法来监控配置漂移，许多企业将根据其成熟度和合规性要求组合方法和工具。

持续手动监控

可以手动查看单个机器配置并将其与已知配置文件进行比较。 由于人为因素，这个过程仍然容易出错并且在员工工时方面成本高昂。 我应该只小规模地用于一些特定的服务器集群或具有适度基础设施足迹的公司。

审计

作为配置审计的一部分，一个团队手动检查服务器配置，并将它们与指定的模型进行比较。 这些审计可能很昂贵，因为它们需要专业知识来确定应该如何构建系统，然后对任何未记录的机会进行彻底调查，以决定是否应该保留它。

审核小组还对将在下次审核期间应用的配置文件进行必要的调整。 出于时间和成本方面的考虑，通常会为高价值或合规性高的集群保留审计，并定期执行，通常一年多次。

审计确实可以保证按照预定的时间表进行一致且可重复的服务器配置。

但是，在下一次审核之前，设置会越来越多地漂移并保持不变。

实时自动监控

自动实时监控是将配置保持在所需状态的最复杂的方法。 为此，必须创建服务器或服务器组，并说明应如何使用专用服务器设置工具对其进行配置。

这些程序将使用轻量级代理来监视该组中的服务器配置并将其与其定义进行比较。

这个自动化过程会立即对漂移发出警告，并且通常会提供多种选择来纠正服务器漂移。

最后的话：

计算机或设备之间不一致的配置项 (CI) 是配置漂移的根本原因。 配置漂移在数据中心环境中很自然地发生，当软件和硬件修改是在没有彻底记录或跟踪的情况下动态完成时。

许多高可用性和灾难恢复系统故障都归因于配置漂移。 管理员应仔细记录硬件设备的网络地址，以及安装在设备上的软件版本和已进行的升级，以尽量减少配置漂移。