云配置也能“漂移”？

云配置也能“漂移”？这个问题在IDC行业经常被提及，但是很少有站长会去关注。不允许“配置漂移”(有些文件部署到服务器后发生了变化)，因为很可能造成应用不稳定，这是系统的致命隐患。下面描述了什么是配置漂移以及如何避免它。

云配置“漂移”咨询:

1.云服务器配置也能“漂移”？

以Linux操作系统为例。如果更改规范后执行ifconfig命令，发现云服务器的eth0和eth1原来的网卡设备都没有了，变成了eth2和eth3，说明更改云服务器的规范后发生了网卡漂移。云服务器配置漂移，主要原因是你在云服务器环境下改变了某项配置，造成了偏差或超出预期的变化。尤其是随着时间的推移，在开发和运维多次响应需求和问题后，云服务器环境和系统逐渐偏离了既定的政策或标准。举个例子，

1.在排查bug，或者处理在线问题时，经常会出现这样的场景:“我在测试环境中做了一个更改，但是忘记在生产服务器上同步这个更改”；

2.“为了满足云服务器实例中某个应用程序的要求，我更改了某个安全组规则，导致该安全组中的其他云服务器出现问题”；

3.“我之前设置了一些自动任务，但后来运行其他任务时，与之前的自动任务发生冲突”。

事实上，超过50%
计划外的系统停机时间可归因于配置问题。如果云服务器和应用程序部署没有配置相同的标准，管理多个云服务器实例和应用程序可能会很快变得非常复杂。即使对于最初以相同方式配置的云服务器实例和应用程序副本，随着时间的推移，配置更改也可能导致偏差。配置漂移越大，问题的调试难度越大，系统的有效管理和维护难度也越大。

二、如何避免配置漂移？

1.)基础设施编码

基础设施，也就是制作服务映像时需要的jdk。
库、环境变量配置、证书文件等。对其进行编码，保证服务形象的一致性。准备好快速修复。对于经常偏移的特定资源(如安全组)，可以考虑部署自动纠正解决方案来防止系统停机。

2.)服务器是不可变的

映像完成并成功部署到环境中后，开发人员或系统管理员不允许修改服务器。在某些时候，您需要对应用程序可能创建的配置选项范围进行一些安全性验证。

3.)定期重启服务器。

为了避免由于基础设施漂移造成的数据泄露，有必要使用一种解决方案来自动检测和修复关键资源的漂移事件。您不能让关键数据暴露数小时、数天或更长时间。

我们针对的是这里的测试环境。服务运行的时间越长，发生配置漂移的可能性就越大，因为我们不能保证没有人会修改环境的配置数据。我们需要定期重启服务器，并使用初始配置来重启服务。可以有效避免业务配置发生变化的情况。不过目前还没有看到这种做法，这可能是大家不太关注配置漂移的原因，也可能是因为我经验不足，知识渊博。

在测试环境中重启服务一般是升级和重新部署的行为。如果有必要在不影响QA的测试的情况下这样做，就应该这样实现。首先，添加一个初始配置的服务实例，然后注销旧的实例。当然这种情况需要考虑业务对机器的粘性，旧实例注销可能会影响正在进行的业务。这就要求服务支持灰度升级，以达到正确
没有感知的QA的效果。

当然，也可以约定一个服务的卸载时间。例如，操作和维护脚本在凌晨3点卸载所有服务，然后重新部署这些服务。这相当于运行和维护-测试之间的协议。运维保障服务定期卸载，QA
这种行为是已知的，测试时需要注意。我们讨论的避免配置漂移的方案的主要目的是在配置漂移影响生产环境之前尽可能地消除它。