冲突从哪来
冲突的典型形态有三种：运维为应急手工改了配置，下一次自动化执行把它改回去，故障现场被破坏；自动化写入的配置与手工维护的配置属于同一文件的不同行，双方各自改一处，最终文件内容与任何一方预期都不一致；以及两个人都以为对方会处理某个参数，导致该参数长期无人维护。共同点是变更入口不唯一，且缺少对覆盖行为的记录。
基本信息
| 冲突根源 | 变更入口不唯一、缺少记录、缺乏例外机制 |
|---|---|
| 典型后果 | 现场被覆盖、配置半自动化半手工 |
| 规避前提 | 明确每份配置的唯一责任人 |
| 配套机制 | 例外登记、差异比对、覆盖前提示 |
规避做法
- 收敛入口：同一份配置只允许通过一个通道修改，手工通道需登记。
- 执行前比对：任务执行前输出将要变更的差异，人工能提前发现异常覆盖。
- 例外登记：应急改动登记为临时例外，附到期时间，到期自动提醒回收。
- 明确责任：每份配置与每个变量写明归属人，避免无人认领。
- 留痕可查：执行记录写明改了什么、改成什么，而不只是「成功」。
- 定期对账：用巡检把现网状态与期望状态做比对，把差异显式化。
冲突场景与处置
| 场景 | 直接后果 | 处置方式 |
|---|---|---|
| 应急手改后被覆盖 | 故障现场丢失，二次故障 | 登记例外并暂停该主机的收敛 |
| 两边改同一文件不同行 | 文件内容自相矛盾 | 整文件模板化，禁止局部手改 |
| 参数无人认领 | 长期保持过时值 | 变量层面明确归属与复核周期 |
| 自动化写成手工样子 | 手工再改时无法判断影响 | 把手工判断显式写入变量与任务 |
| 多套自动化同管一处 | 配置反复来回变化 | 划定资产归属，删除多余通道 |
收敛任务在执行前如果不输出差异清单，一次执行可能同时覆盖多处人工调整，事后只能从日志里倒推，恢复成本很高。
例外机制要有人负责回收：没有到期清理的例外会不断累积，最终让自动化管理的范围名存实亡。