状态跟踪解决什么问题
自助交付是「一次提交、后台异步完成」的过程：用户点下申请后，资源创建、配置下发、DNS 解析、权限开通由平台排队执行，耗时从几分钟到几小时。状态跟踪把整个过程显式建模成状态机，把每次跃迁持久化，并分别面向申请人、运维、审计呈现。没有它，用户只能反复刷新，运维只能翻日志拼时间线，卡单原因永远说不清。
基本信息
| 适用对象 | 工单系统、交付平台、资源编排任务 |
|---|---|
| 核心组成 | 状态机定义、状态存储、事件回写、通知 |
| 关键标识 | request_id 贯穿全流程，子任务各带自己的 id |
| 状态粒度 | 主状态加子任务状态，可表达部分成功 |
| 更新方式 | 执行端回写事件，平台按事件推进主状态 |
典型使用场景
- 用户自助查询：到哪一步了、还要等多久、现在卡在谁那里
- 运维排查卡单：区分审批未处理、编排报错、下游接口超时三种成因
- SLA 计时与考核：以状态变更时间为准，统计各环节耗时与超时率
- 失败重试与断点续做：从失败子任务继续，而不是整单重跑
- 审计取证：状态变更序列本身就是交付过程的证据链
常见状态设计
| 状态 | 含义 | 下一步 | 滞留处理 |
|---|---|---|---|
| 待审批 | 已提交，等审批人处理 | 通过或驳回 | 超时提醒审批人，可配置升级 |
| 待执行 | 审批通过，等待调度 | 进入执行队列 | 队列积压超阈值告警 |
| 执行中 | 编排正在创建与配置资源 | 等子任务回写 | 超过单步超时判失败并重试 |
| 部分成功 | 部分子任务成功部分失败 | 按子任务重试或人工介入 | 保留已完成部分，不整单回滚 |
| 待验收 | 资源就绪，等用户确认 | 确认或超时自动验收 | 超时按默认通过并通知 |
| 已完成 | 交付闭环，进入运维期 | 纳入回收与成本统计 | 无 |
| 失败或已取消 | 不再推进的终止态 | 重试或关闭 | 记录原因与中间产物清单 |
状态机与事件回写
状态机与事件回写
states: [pending_approval, queued, provisioning, partially_ready, ready_for_acceptance, completed]
transitions:
- {from: provisioning, to: partially_ready, event: subtask_failed} # 子任务失败先落部分成功
- {from: partially_ready, to: provisioning, event: retry_requested} # 重试只覆盖失败子集
rule: completed 与 cancelled 为终态，禁止回退 # 终态回退会污染 SLA 与审计口径
notify: 每次主状态变更写一条事件并通知申请人 # 通知与状态同源，避免两处不同步用「部分成功」表达局部失败比整单标失败更贴近事实：已完成的部分不必重做，重试范围也更小。主状态要单调推进，子任务状态允许在重试中反复。
状态只写在执行端日志或只存在内存里，编排节点重启后用户就查不到进度，事后也无法还原时间线。状态必须落库，且以平台侧存储为准。