上个月跟做了八年运维的老周吃夜宵，冰啤酒刚倒满，他手机叮的一声亮了。他扫了一眼，骂了句脏话。不是线上告警。是上周那次事故的复盘邮件，要他写原因说明。
上次的事说起来真的不值当。凌晨三点被电话喊起来，说线上用户领的优惠券全没法核销，爬起来登服务器查了俩小时，最后发现是测试环境的一个接口超时参数，被谁同步配置的时候覆盖到生产了。就这么个破事。导致三个小时的服务不可用，最后还要写复盘。太亏了。
很多人对配置管理的误解，就是觉得这是个边角料工作。不就是把参数记下来吗？不就是写个脚本批量改吗？说白了，那顶多算配置存储，连管理的边都没摸到。
那些半夜被喊起来的事故根源
问题的核心是什么？大部分团队的配置从一开始就是散的。代码仓库里混着写死的环境变量，服务器本地的配置文件改了从来没人同步记录，云平台控制台改个带宽参数、改个权限，转头就忘了跟团队说。新入职的工程师想查个生产数据库的连接池大小，得问三个人，最后得到三个不一样的答案。
你说大家不知道这有隐患吗？都知道。但一到排期，配置相关的整理工作永远是第一个被砍的。毕竟这东西不直接产出业务价值，没人看得到你每天花在理配置上的时间。直到出事了，才拍大腿。
配置管理的核心从来不是存参数，是搞清楚”谁在什么时间改了什么、为什么改、改完会影响哪些业务链路”。
别把工具当成管理本身
这两年市面上的配置管理工具吹得神乎其神。什么一键同步、版本回溯、灰度推送，好像买了一套接入系统，所有配置问题就自动解决了。拉倒吧。
我见过不下五个团队，花了六位数买了商用配置中心，结果团队里的老工程师还是习惯登服务器手动改配置，改完也不往平台上传，理由特别充分：”走平台审批流程要二十分钟，我赶时间上线，改完就好了，回头补记录”。回头？哪有什么回头。等真出了问题要回溯，翻平台里的记录，跟实际服务器上跑的版本差了三个迭代。平台里存的全是过时的摆设。
工具是载体，不是目的。麻烦在于，很多团队把”上了工具”等同于”做好了配置管理”，跳过了最关键的梳理环节：哪些参数是需要统一管控的，哪些是可以保留在服务器本地的，改参数需要走什么校验流程，出了问题怎么在一分钟内回滚到上一个可用版本。这些最基础的规则没理清楚，再贵的工具也救不了散沙一样的配置台账。
之前接触过一个三十人左右的研发团队，之前每次大版本发布，都要花半天时间核对各个环境的配置参数，生怕漏了哪个导致线上出问题。后来他们没急着买新工具，先抽了两个工程师花了两周时间，把所有线上跑的参数拉了个完整清单，把参数分成三类：跟业务逻辑绑定的，比如优惠券的核销阈值、活动的时间窗口，直接跟着代码存在代码仓库里，走标准的版本控制流程；跟环境绑定的，比如生产数据库的连接地址、对象存储的密钥，存在统一的配置中心里，每个环境单独隔离，不允许跨环境同步；还有一类是临时调试用的参数，要求必须在24小时内清理，所有修改留痕。
就这么简单的分类，没有什么复杂的架构。后来他们每次发布前的配置核对时间压到了二十分钟，半夜因为配置问题触发的告警少了七成。没有什么玄乎的操作。
那些容易被忽略的隐性成本
很多人算配置管理的账，只看得见买工具、搭流程的显性成本，算不清藏在背后的隐性损耗。比如新工程师入职，要花一周时间摸清楚各个环境的配置规则，这一周的人力成本谁算过？比如每次线上排障，花在找正确配置版本上的时间平均半小时，一个月二十次排障就是十个小时，相当于一个人两天的工作量。还有更糟的，因为测试和生产的配置不一致，功能在测试环境跑通了，到生产就出问题，来回返工的开发、测试人力，这些都是看不见的窟窿。
有人说，我们是小团队，人少，配置管理没必要搞那么复杂。对吧，其实不对。人越少，越禁不起一次配置事故的折腾。小团队本来就没多少冗余人力，半夜爬起来排两个小时的故障，第二天好几个人的状态都受影响，这个代价比你花两天时间把基础配置规则理清楚要高得多。不用搞什么复杂的审批流程，哪怕你就是把所有生产配置存在一个加密的共享文档里，每次改的时候留个记录，署上名，写清楚改的原因，都比散在各个地方强。
上周再跟老周吃夜宵，他说他们团队今年把配置管理的优先级提到了跟代码质量一样的位置。没买新工具，就是先把所有散在各处的参数归拢了一遍，补全了近半年的所有修改记录。现在再遇到配置相关的告警，登进去就能看到上次改了什么，不用再挨个发消息问人。他说上次写复盘的事也过去了，现在终于不用再因为这种破事半夜爬起来。
就这么点事。没什么高大上的。