踩过生产大坑才摸透的配置管理

上周帮朋友排查一个凌晨三点的告警，最后发现是测试环境的数据库连接串，被人改了之后没同步到生产的配置表。

这事说出来都好笑。整个团队花了四个小时复盘，才找到那个被遗留在测试分支里的修改。没人留记录。没人知道谁改的。甚至那台测试数据库的实例地址，在团队的共享文档里都停留在两年前的版本。

最先被砍的预算项

很多公司做项目预算评审，第一波砍的就是配置管理相关的投入。没人觉得这玩意能直接带来营收，不如多招两个能写业务代码的开发，多上两个功能。

说白了，大家都愿意为“看得见的产出”花钱，没人愿意为“不出事”花钱。直到凌晨的告警电话打过来，直到大促当天的接口直接崩掉，才想起来当初为啥要做配置管理。

之前接触过的一个做本地生活服务的小团队，大促前压测直接卡壳。查了三天才找到问题：某个缓存的过期时间被改成了7天，热点数据占满了内存，实例直接OOM。修改的人是三个月前离职的开发，当时为了调试本地缓存改的，走的时候忘了改回去，也没留任何痕迹。

生产环境配置台账漏写告警截图

你说这是技术问题吗？根本不是。是没人愿意花时间把最基础的配置记录下来。大家总觉得改个配置是小事，随手就弄了，没必要走流程，没必要写记录。

麻烦在于，人是会忘的。三个月前改的参数，你自己都记不起来，更何况后来接手的同事。

很多团队一提到配置管理，第一反应就是买最贵的CMDB，要做全量自动发现，要搭完整的变更审批流，要和所有的监控、发布系统打通。

结果呢？平台搭了三个月，业务团队嫌录入数据麻烦，每次变更都要填一堆表单，干脆还是走老路子，直接登服务器改配置。最后那个花了几十万买的平台，就变成了运维团队自己的内部台账，里面的配置项还停留在上线那天的版本。

这事没那么玄。小团队先把核心配置项列清楚就行——生产环境的服务器IP、数据库连接串、中间件的核心参数、业务的开关配置。不用上来就搞全量，先把最容易出问题的那10%管好，比啥都强。

我见过最实用的配置管理，就是一个在线表格，每一条配置后面跟着修改人、修改时间、修改原因。没有复杂的审批流，没有自动发现，但是每次改配置，必须在表格里留一行记录。就这么简单的规则，帮他们团队省了至少一半的故障排查时间。

别迷信工具。工具只是载体，核心是规则能不能落地。

很多开发觉得配置管理是运维团队给自己上枷锁，是限制自己的操作权限。其实根本不是。

你把配置管好了，开发不用每次找运维要服务器的SSH地址，不用每次翻两年前的工作群聊天记录找中间件的端口号，不用每次出问题的时候挨个服务器登上去查参数。运维不用每次故障排查的时候，对着一堆过期的文档猜哪个是对的。业务团队不用每次出问题的时候，绕着圈子问到底是谁改了什么配置。

之前碰到一个团队，之前配置乱到什么程度？新入职的运维要花两周时间，才能把生产环境的所有服务器摸清楚，哪个是跑订单接口的，哪个是存用户数据的，哪个是用来做定时任务的。后来他们把核心配置整理成了统一的在线台账，新人入职第一天就能拿到准确的列表，省下来的时间能多处理好几个日常告警。

真的，别觉得留记录是麻烦事。上次我碰到一个开发，直接在生产环境把订单接口的限流阈值从1000改成了100，说要测一下限流逻辑。结果当天下午订单量涨了20%，接口直接被打挂。他自己都忘了改完的事。要是当时改完之后留了一行记录，也不至于整个团队花三个小时找问题。

没人天生愿意做台账。你总不能指望每个人都自觉把所有修改都记下来。所以得有个简单的规则，不用复杂，但是所有人都得遵守。

配置管理从来不是什么高大上的技术活。就是把你用的每一个参数、每一个实例、每一次修改，都明明白白摆在那里，让所有人都能看到。