云服务器配置也能“漂移”？这个问题在IDC行业经常被提及，但很少站长会关注和重视这个问题。”配置漂移“(某些文件在部署到服务器之后发生了一些变化)是不允许出现的，因为这很可能会导致应用程序不稳定，是系统的一大致命隐患。以下内容介绍什么是配置漂移以及如何避免配置漂移。

云服务器配置“漂移”咨询：http://www.hkt4.com/dedicated/hkcloud.html

一、云服务器配置也能“漂移”？

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

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

2、 “为满足某台云服务器实例中应用程序的需求，我改动了某个安全组规则，造成这个安全组内的其他云服务器出现问题”;

3、 “我之前设置了某些自动化任务，后来运行其他任务时，与之前的自动任务产生了冲突”。

事实上，超过 50% 不定期系统停机时间可归因于配置问题。如果云服务器和应用部署不是采用相同的标准进行配置，则管理多个云服务器实例和应用可能很快变得非常复杂。即使对于最初被完全相同的配置的云服务器实例和应用副本，配置变化也可能随时间的退役而产生偏差。配置漂移越大，就变得越难以调试问题，使得对系统的有效管理和维护更加困难。

二、如何避免配置漂移?

1.)基础设施代码化

基础设施，即制作服务镜像时的需要的 jdk 库、环境变量配置、证书文件等。将其代码化，保证了服务镜像的一致性。为快速修复做好准备。对于经常偏移的特定资源(如安全组)，请考虑部署自动修正解决方案以防止系统停机事件。

2.)服务器不可变

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

3.)定期重启服务器

为避免因基础架构漂移而遭受数据泄露，必须使用自动检测和修复关键资源的漂移事件的解决方案。你不能让关键数据暴露数小时、数天或更长时间。

这里我们针对的是测试环境。服务运行的时间越长，就越容易发生配置漂移，因为我们不能保证一定不会有人会去修改环境的配置数据。我们需要对服务器进行定期重启，使用最开始的配置来重启服务。能有效避免服务被更改配置的情况。不过这种做法目前没见过，可能是大家对配置漂移都不太重视的原因，也有可能是我经验不丰富见识少的缘故。

在测试环境重启服务一般是升级和重新部署时才有的行为，如果一定要这样做，又不影响到QA进行测试，实现起来应该是这样子，先新增一台初始配置的服务实例，然后下线旧的实例，当然这种情况需要考虑业务对机子存在粘性的情况，旧的实例下线可能会影响正在进行的业务。这就需要服务支持灰度升级，才能实现对 QA 无感知的效果。

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