在我电脑上是好的：聊聊配置漂移

「在我电脑上是好的。」这句话被戏称是程序员说得最多的谎话，但它其实很少是谎话——大多数时候，它字面上是真的。真正的问题在于：为什么同样的代码，换个环境就不一样了？

答案几乎总是同一个词：配置漂移。

什么是配置漂移

一个系统从代码到能跑起来，中间隔着几十上百个「环境决定项」：依赖版本、环境变量、配置文件、数据库参数、网络策略、时区、locale、文件权限。这些决定项散落在各处，任何一个被单独改动而其他副本没跟上，各环境就开始分叉。

分叉不会立刻爆炸。它会安静地长大——今天测试环境改了个超时参数，明天生产环境手动热修了一行配置，后天某台机器被运维顺手升级了依赖。每一次「就改这一处」的临时操作，都是在往漂移的账户里记账。直到某天，一个新版本在所有环境都测试通过，上了生产就崩，你才第一次看到这本账的总余额。

漂移为什么防不住

不是没人知道要管配置，而是管配置的手段天然落后于改配置的冲动。

改配置太容易了。代码改动要走 review、要过 CI、要出变更单；而改一行配置，SSH 上去十秒钟搞定。越容易做的事，越容易在压力下被选择。半夜三点系统抖动，你改不改那个参数？大多数人都改。改完大概率忘了同步回配置仓库。

漂移不可见。代码的版本有 Git 记录，谁改的、什么时候改的、为什么改，一目了然。配置呢？很多团队的生产配置就是一个「谁也说不清当前状态」的黑盒。没有 diff，没有历史，没有「这个值为什么是这个」的注释。不可见的东西无法被审计，无法被审计的东西必然漂移。

收敛漂移的四个实践

把配置当代码。所有环境配置进版本库，环境之间的差异用显式的覆盖文件表达（base + overlay），而不是各存一份。上线 = 提交，而不是登录服务器。

声明式管理 + 持续校验。用配置管理工具（Ansible、Terraform、K8s 声明式对象都算）描述「系统应该是什么样」，然后定期跑检测，发现实际状态和声明不符就报警。漂移从「上线时才发现」变成「漂了十分钟就被抓」。

禁止热修，或让热修自动留痕。理想状态是 SSH 上去改配置的行为彻底消失。做不到的话，至少做到：任何绕过正常流程的改动，都会被下一个同步周期冲掉。让「手改」变成一个注定徒劳的动作，比贴一百张「禁止手改」的告示有用。

缩小环境数量。每多一个环境，就多一份需要保持同步的副本。能用同一个镜像 + 不同配置参数解决的，就不要维护多套构建产物。环境数量越多，「一致」这件事的概率越低。

一个判断标准

怎么知道你的团队漂移控制得好不好？有个简单的测试：现在就重建一个全新的生产等价环境，要多久？

如果答案是一小时以内，说明配置基本都在声明式的仓库里；如果答案是「得先问问老王」，说明大量环境知识只存在于某些人的脑子里和某些服务器的硬盘上——前者会离职，后者会宕机。

配置漂移不是某个人的失误，它是所有「临时改动」的自然累积。对抗它的方式也只有一条：让每一次改动都必须经过同一个、留下痕迹的通道。通道越窄越好，窄到没有第二条路可走。