先别急着上工具
配置管理这四个字，听起来像采购清单。实际上，它更像是一份“谁动了我的环境”的追责记录。开发改了一个参数，测试环境没同步。运维在凌晨两点SSH上去，把连接数调到5000。第二天服务重启，配置回滚，连接数又变成200。然后所有人都说，我不知道。
这就是配置管理的起点。不是Puppet，不是Ansible，也不是某个CMDB大屏。是你得知道系统里有哪些配置项，它们是什么值，谁改的，什么时候改。没有这个，工具只是把混乱自动化了一遍。
我见过小团队用Excel管服务器清单。也见过大团队用一堆YAML，每个环境一个目录，最后没人敢删。麻烦在于，配置管理不是一次性的项目。它是持续性的清洁工作。脏了要擦，乱了要收。指望上线一套系统就一劳永逸，基本会失望。
配置漂移才是夜里响警报的那位
什么叫配置漂移？说直白点，就是实际运行的东西，和文档、代码、仓库里写的不一样。有人手改。有脚本漏跑。有镜像版本对不上。漂移一开始很隐蔽。业务跑得挺好。直到扩容。新节点按模板起来，配置不对，流量一进来就挂。老节点没事，因为老节点是之前手改过的。这时候排查，像在一堆长得一样的线里找那根断的。
解决漂移，靠的不只是巡检。要有单一事实来源。配置从哪来，怎么渲染，怎么下发，谁有权限改，改完怎么验证。这一串必须能串起来。否则巡检报告只能告诉你“有差异”，不能告诉你“差异从哪来，该以谁为准”。
容器化之后，这事换了马甲。ConfigMap、Secret、环境变量、启动参数、Sidecar配置。看起来都在YAML里。但YAML和代码一起进Git，不等于配置管理就做好了。镜像里如果还藏着一份默认配置，环境变量又覆盖一层，启动脚本再拼接一层，最后生效的值，可能连写它的人都说不清。
把配置当代码不等于把YAML塞进Git
Git是配置管理的好朋友。但别误会。把文件提交上去，只是第一步。接下来要回答：分支怎么分？环境差异怎么表达？密钥放哪？回滚是回滚代码还是回滚配置？发布顺序是否有依赖？
有些团队一上来就搞多环境目录。dev、test、staging、prod各一套。复制粘贴。开始还行。三个月后，dev里改了超时时间，prod忘了。半年后，没人知道哪套是基准。配置的复用和差异，需要显式设计。可以用基线加覆盖，可以用模板渲染，也可以分层。关键是别让差异藏在复制粘贴里。
还有密钥。把密码写进Git，和把家门钥匙插在门上没区别。就算仓库私有，也扛不住离职员工、CI日志、误发截图。密钥应该走单独的注入通道。Vault也好，KMS也好，Kubernetes Secret也好，至少别硬编码。麻烦在于，安全一严格，开发体验就下降。取个密钥要三层审批，人就会想办法绕过。这事没那么玄，就是在安全和效率之间找可执行的平衡。
工具能帮你一半 剩下的一半是权限和习惯
Ansible、SaltStack、Puppet、Chef，各有脾气。Ansible上手快，无Agent，SSH就行。规模大了，执行速度和控制力要花心思。Puppet声明式强，适合长期收敛，但学习曲线不温柔。Kubernetes原生那套，ConfigMap加Operator，适合云原生，但调试门槛不低。选哪个，看团队技能、存量系统和变更频率。别因为别人说好就上。
更关键的是权限。谁能改生产配置？谁能合并到主干？谁能触发发布？如果谁都能，配置管理就是摆设。如果只有一个人能，他就是瓶颈。比较现实的做法：按环境分权，按变更风险分级，所有修改留痕。紧急变更可以走快速通道，但事后必须补记录。不然下一次故障，连时间线都拼不出来。
有个小例子。一个团队把Nginx配置放进了Git，也写了CI校验。看起来挺规范。但有个老运维习惯直接SSH改，改完不提交。某次机房迁移，新机器从仓库拉配置。结果漏了一条转发规则。故障不大，但排查花了很久。因为所有人都以为配置在Git里。后来他们加了一条：生产机器禁止手工编辑配置，改了也会被下一轮同步覆盖。习惯才慢慢拧过来。
配置管理做到最后，拼的不是工具功能。是纪律。是愿不愿意把“临时改一下”变成“提交一个变更”。是把环境当成代码，而不是当成一台可以随时登录的宠物。是承认混乱会不断回来，然后定期清理。
如果现在让你画一张图，标出从代码到生产的每一层配置来源。你能画全吗？画不全，就先别急着买平台。把配置项找出来，把来源标清楚，把修改入口收拢。这一步很土，但有用。