声明状态与实际状态
每个受管系统都有两个状态：仓库里声明应该存在的东西，以及实际正在运行的东西。系统年轻时两者一致。时间一长，有人在故障中改了安全组，一次控制台修改绕过了评审，一次不完整的回滚让一半集群停留在旧模板上。这个差距就是配置漂移。
漂移如何累积
漂移很少以一次戏剧性的动作出现。它来自压力下的临时修复、模板从未记录的 manual scaling，以及流水线之外创建的资源。每次改动单独看都合理，合起来却有腐蚀性：模板不再描述生产环境，于是没人再信任它，下一次变更也就继续手工完成。
为什么它在最糟的时刻暴露
代价往往在恢复时显现。运行手册假设的配置已经不存在，替换环境由缺少三个紧急补丁的模板建成，审计也说不清是谁改了策略。漂移把有文档的系统变成口口相传的经验，而经验在压力下最容易失效。
检测与收敛
检测要定期比对声明状态与实际状态，并在每次部署后执行。只检测不够：每个发现都需要负责人、严重级别，以及要么修复资源、要么把变更写回代码的处理路径。例如，每晚生成漂移报告并为每处差异开单，同时允许把变更正式接纳入仓库，才能让两个状态持续收敛而不是越走越远。
与不可变基础设施的对比
不可变基础设施用替换代替原地修改，消除了一大类漂移，但并非全部：镜像、策略、DNS 和运行时配置仍然可能分叉。把不可变性看作强力的减量手段，而不是证明。剩余的部分依然需要检测，因为未被检查的假设正是故障时最先崩塌的东西。