别让配置“裸奔”：一次生产事故让我彻底搞懂了配置管理

凌晨两点，手机突然狂震——监控系统告警，生产环境订单服务大面积超时。我迷迷糊糊爬起来，连上 VPN 一看日志：java.sql.SQLException: Access denied for user 'root'@'xxx'。

数据库连不上？密码错了？我脑子嗡的一声，赶紧去翻配置文件。结果在 application-prod.yml 里赫然看到：

spring:
  datasource:
    url: jdbc:mysql://prod-db:3306/order
    username: root
    password: 123456

密码是明文，而且还是 root 账号。 更可怕的是，这个文件就躺在 Git 仓库里，任何有代码权限的人都能看到。后来查出来，是 DBA 凌晨改了生产库密码做安全加固，但没通知开发，而我这边硬编码了旧密码。

那次事故持续了 47 分钟，损失不小。但从那以后，我彻底重构了团队的配置管理方案，也总结了三条保命经验。

一、敏感配置，永远不要进 Git

这是底线。密码、密钥、证书，任何能让你睡不好觉的东西，都不该出现在代码仓库里。

我们的做法是引入 配置中心（用的是 Nacos）。应用启动时从配置中心拉取配置，本地只留一个 bootstrap.yml 指定配置中心的地址和命名空间。Git 仓库里再也不见任何敏感信息。

如果团队规模小、暂时用不起配置中心，至少用环境变量或者 git-crypt 加密。哪怕是最简陋的 .env 文件加 .gitignore，也好过明文提交。

二、配置要有“环境隔离”，别靠手改

以前我们靠手动改配置文件区分环境：本地改成本地库，打包前改成测试库，上线前再改成生产库。听起来就很蠢，但确实这么干过。有一次打包时忘了改回来，直接把测试库地址打进了生产包——后果可想而知。

后来我们统一用 Profile 机制：application-dev.yml、application-test.yml、application-prod.yml 各就各位，启动时通过 spring.profiles.active 指定。容器化后更彻底——镜像只有一份，配置全靠环境变量注入，镜像本身不包含任何环境信息。

三、配置变更要能“秒回滚”

配置中心最大的好处不是集中管理，是动态推送 + 版本历史。

有一次运营要调一个促销活动的阈值，我在配置中心改了个值，推送下去 3 秒后，监控显示订单量断崖式下跌。我立刻打开配置中心的版本历史，点了“回滚到上一版本”，10 秒后服务恢复正常。

如果是以前，改配置文件、重新打包、重新部署，至少 15 分钟起步。配置中心让我把故障恢复时间从分钟级压缩到秒级。

一个容易被忽略的点：配置也要做 Code Review

很多人觉得配置文件不是代码，改了就改了。但配置的破坏力往往比代码更大——一行错误的配置，能让整个集群瘫痪。现在我们规定：配置中心的变更也要走审批流程，关键配置（如数据库、限流阈值、开关）必须有第二个人确认。

那次凌晨事故之后，我在工位上贴了张纸条：“配置不是代码，但比代码更危险。”

代码有 Bug，最多功能异常；配置有 Bug，可能直接把系统送走。花点时间把配置管理做规范，不是为了炫技，是为了能睡个安稳觉。毕竟，凌晨两点的告警声，听一次就够了。