你改了Nginx的配置文件，网站正常。三天后你发现PHP版本升级了，有些配置项已经不兼容了。你改了数据库连接池的地址，忘了改监控告警里的连接目标。配置分散在各处，你改了一处，漏了另一处。没人会责怪你——你只有一双眼睛，而配置是分散的。
配置管理解决的不是“怎么配置”，是“怎么让配置不失控”。
配置的三种类型
服务器的配置通常分为三类，管理方式各不相同。
基础设施配置：服务器的主机名、时区、DNS、内核参数。这些配置通常在系统安装时设置，很少变动。修改这类配置需要重新启动或重载系统服务，影响范围广，适合用配置管理工具统一管理。
应用配置：Nginx的nginx.conf、MySQL的my.cnf、PHP的php.ini。这类配置直接影响服务运行，不同环境（开发/测试/生产）的值通常不同。调整频率中等，每次改动都需要重启对应服务。
环境配置：数据库连接地址、API密钥、第三方服务凭证。这类配置在不同环境之间差异最大（开发连测试库，生产连生产库）。需要在部署时动态注入，通常通过环境变量管理。
配置管理工具：基础设施即代码
手工维护配置文件的方式在服务器数量少时还可行。当你有10台以上服务器时，手工操作的问题就暴露出来了：某台服务器和别的配置不一致，排查问题时花费数小时才发现是配置差异。
Ansible使用声明式的YAML文件定义服务器应有的状态。你写一份Playbook，描述“这台服务器应该装Nginx 1.24、配置文件应该长什么样”，Ansible负责执行。执行结果通过--check参数预览，不会在确认前改动任何配置。配置状态通过Git管理，每次变更都有审计记录。
配置模板的价值在于多环境管理。Ansible使用Jinja2模板语法，同一个模板文件根据变量值生成不同环境的配置：开发环境连接测试数据库，生产环境连接生产数据库。变量值保存在group_vars/目录下，按环境（dev/prod）或按组（web/db）分类。
配置漂移：让配置保持一致
配置漂移是指服务器实际状态与预期状态不一致的现象：一台服务器的nginx.conf被运维直接改了，另一台用的还是旧版本；一台服务器的内核参数被调过，其他机器还是默认值。
配置管理工具定期执行可以自动纠正配置漂移。Ansible的--check和--diff选项会显示配置差异，你可以决定是否应用变更：
bash
ansible-playbook site.yml --check --diff
通过定期执行（cron或CI/CD触发），确保所有服务器与Git仓库中的配置定义一致。手工改动会在下次执行时被覆盖，强迫团队通过代码变更来修改配置。
配置版本控制
配置管理的核心是“用代码管理配置”。把配置文件放进Git仓库，所有变更都有记录：谁改的、什么时候改的、改了什么、为什么改。
变更历史提供了回滚能力。如果某次变更导致故障，git revert可以直接回退到上一个正常版本。通过git blame追踪每一行配置的最后修改人和提交信息。
Pull Request流程确保变更经过审核，避免单人操作的风险。你提交一个PR，团队审核通过后合并，CI/CD自动将变更应用到目标环境。
配置变更的三种回滚路径
配置变更后业务异常，需要快速回退变更。不同配置类型对应不同的回滚路径：
基础设施配置（内核参数、系统服务状态）：多通过Ansible等工具自动部署，回滚时在Git仓库中git revert后重新执行Playbook即可。
应用配置（Nginx、MySQL等配置文件）：通常在服务器上cp备份原配置，回滚时恢复备份文件，或手动将配置改回原状态。
环境配置（数据库连接串、API密钥）：通过环境变量注入，回滚时切换环境变量或引用备份的历史变量值。
一个真实案例
某在线教育平台维护着20多台服务器。某次修改Nginx配置时，运维直接在3台Web服务器上手动修改了nginx.conf，但漏了另外2台。几天后流量高峰，漏改的2台服务器因配置不同步出现502错误。排查耗时4小时，期间部分用户无法访问课程页面。事故后团队将Nginx配置纳入Ansible管理，所有变更通过Playbook统一部署，配置不一致问题不再发生。
最后一句
配置管理的核心目标：所有服务器配置一致，所有变更可追溯。实现这一目标只需要几个习惯：配置写进代码、变更经过审核、定期检查漂移。每次改动后问自己一个问题：这台服务器的配置改了，其他服务器同步了吗？如果你的答案是“我手动去改”，说明你还需要一个配置管理工具。