自动化为什么难归属
人工操作天然带着主体：有人登录、有人执行。自动化把这条线索抹掉了——动作由调度器、事件或流水线发起，日志里留下的往往是服务账号。这不是小事：一次由定时任务引发的配置变更若无法归属，事后既无法追责，也无法判断是否需要人工复核。归属留存就是把触发链记全：谁触发、以什么方式触发、依据哪份审批，执行身份代表谁。
基本信息
| 归属三要素 | 触发主体、触发方式、审批或策略依据 |
|---|---|
| 执行身份 | 服务账号加代表主体（on-behalf-of）关系 |
| 记录位置 | 任务记录、审计日志、关联变更单三处一致 |
| 触发类型 | 人工、定时调度、事件触发、接口调用、链式触发 |
| 例外要求 | 定时任务也必须有归属人与变更留痕 |
典型使用场景
- 定时任务改了配置：通过任务归属人找到改动来源与理由
- 事件驱动自愈：记录事件内容与策略版本，判断自动动作是否在边界内
- 流水线自动发布：把发布记录归属到提交人、审批人与触发方式
- 外部接口调用：把接入凭据映射到责任主体，避免无主操作
- 脚本被多人复用：执行时携带调用者身份，而不是只留脚本作者
触发方式与归属要点
| 触发方式 | 归属主体 | 留存要点 |
|---|---|---|
| 人工触发 | 自然人账号 | 记录触发人与其当时角色 |
| 定时调度 | 任务归属人与创建人 | 任务启用与参数变更需留痕 |
| 事件触发 | 策略定义人与事件来源 | 留存事件内容与策略版本号 |
| 接口调用 | 调用方应用与接入凭据 | 凭据与责任主体映射可查 |
| 链式触发 | 上游任务与最终触发主体 | 逐级传递原始主体，不丢失源头 |
归属字段示意
归属字段示意
{
"task": "rotate-app-key",
"trigger_type": "schedule", // human/schedule/event/api 显式标记
"triggered_by": "owner:platform-team", // 定时任务也有归属，不是无主操作
"on_behalf_of": "liuwei", // 代表谁执行：链路末端仍是人
"policy_ref": "policy-key-rotate-v3", // 依据的策略或其版本
"exec_identity": "svc-automation-01", // 执行账号，仅用于表示身份
"scope": "2 services",
"result": "success"
}服务账号是执行身份，不是责任主体。它必须能映射到人、团队或策略责任人；映射关系不可查时，自动化记录在审计上等同于无效。
多人共享同一凭据会让归属彻底失效：出了事故无法判断是谁触发，也无法区分授权与越权。执行凭据应按调用方主体划分并轮换。