关联要解决什么
故障排查中最高频的问题是「最近有什么改动」。如果执行记录与变更单各自存在、互不引用，就只能靠时间戳人工比对，既慢又容易漏。做法是让每次执行强制携带关联键——变更单号、工单号或任务标识，并记录变更前后的状态摘要，使变更侧能查到自己产生了哪些执行、执行侧能回到对应依据。两者构成一条可双向追溯的链。
基本信息
| 关联键 | 变更单号、请求标识、任务标识 |
|---|---|
| 记录内容 | 变更前状态摘要、实际执行动作、变更后状态摘要 |
| 时间基准 | 统一时间源，记录开始与结束时刻 |
| 关联方向 | 变更到执行、执行到变更双向可查 |
| 缺失处理 | 无单执行也必须记录，并标注无关联单据 |
典型使用场景
- 故障回溯：按时间窗口列出全部变更与执行，锁定嫌疑改动
- 影响面统计：某次变更实际触及多少对象、是否超出计划范围
- 发布窗口核对：窗口外的执行动作单独列出并解释
- 未授权变更发现：有执行记录却无对应单据的条目需人工确认
- 人与自动化分工：区分人工操作与平台执行，明确责任归属
场景与关联方式
| 场景 | 关联方式 | 用途 |
|---|---|---|
| 计划变更 | 执行时强制携带变更单号 | 核对窗口内动作是否与计划一致 |
| 紧急变更 | 先记录后补录并标注紧急 | 不丢动作，同时可事后审查 |
| 自动化执行 | 任务标识加触发人 | 自动动作也能归属到人 |
| 配置漂移 | 实际状态与变更记录比对 | 发现未登记的改动 |
| 发布验证 | 执行与验证结果共用同一标识 | 判断是否真的做过验证 |
关联字段与查询思路
关联字段与查询思路
{
"exec_id": "EX-88213",
"change_ticket": "CHG-20418", // 关联键：执行必须能回到变更依据
"triggered_by": "pipeline/deploy-web", // 自动执行也要写触发来源
"before_digest": "sha256:1a7b...", // 变更前状态摘要，便于确认改了什么
"after_digest": "sha256:8c02...", // 变更后状态摘要，用于比对是否相符
"scope": "2 hosts / 1 service", // 影响范围，判断爆炸半径
"started": "2026-10-17T09:12:31+08:00",
"ended": "2026-10-17T09:13:02+08:00",
"unlinked": false // 无单据执行标记为 true，进入异常清单
}只有变更单没有执行记录，等于只知道计划；只有执行记录没有变更单，等于不知道意图。两者都要有，且用同一标识串起来，事后才有可用的时间线。
查不到关联单据的执行记录不要直接忽略，应进入异常清单核查：它可能只是流程漏录，也可能是绕过变更管理的未授权操作。