期望状态与漂移
期望状态是写在自动化资产里的目标描述：软件包应为某版本、配置项应为某值、服务应处于运行状态。实际状态是机器现在的样子，两者不一致即形成漂移。自动化的语义是「发现差异并收敛」，因此它必须解决三个问题：期望状态写在哪里、现状从哪里读、差异由谁决定是否修复。只把期望状态写进文档而没有比对机制，等于没有自动化。
基本信息
| 期望状态载体 | 配置管理资产、编排清单、模板与变量文件 |
|---|---|
| 现状来源 | 主机事实采集、接口查询、状态文件或快照 |
| 比对方式 | 干跑、计划模式或定期巡检任务 |
| 处置策略 | 自动收敛、告警人工确认、或列入豁免清单 |
常见漂移来源
- 应急手工改动：故障时直接改配置文件，事后未回写自动化资产。
- 其他自动化写入：另一套脚本或平台也管同一份配置，互相覆盖。
- 升级与补丁：软件包升级顺带改写了默认配置模板。
- 外部依赖变化：证书到期、上游地址变更导致实际配置需要调整。
- 扩容与缩容：新节点未按同一基线初始化，带着默认配置上线。
漂移处置策略
| 漂移类型 | 典型例子 | 建议处置 |
|---|---|---|
| 可自愈漂移 | 目录权限被改、配置项被注释掉 | 巡检发现即自动收敛 |
| 需确认漂移 | 端口、副本数被人为调整 | 告警并等待人工确认再收敛 |
| 合法漂移 | 应急期间临时放宽的参数 | 登记豁免与到期时间 |
| 基线漂移 | 新节点未按统一基线初始化 | 纳入交付流程，从源头修正 |
| 工具冲突漂移 | 两套自动化写同一文件 | 收敛资产归属，划清边界 |
漂移检测的价值在于把「配置什么时候被改的」变成可回答的问题。周期巡检任务产出的差异报告要落到可检索的位置，并与变更工单关联，否则报告只会变成没人看的附件。
不要对全部漂移一律自动收敛：应急期间人工改的参数被自动化无提示地覆盖，可能直接放大故障。收敛前先区分漂移性质，必要时按服务与时间窗设置收敛豁免。