验收与回收的位置
自助交付常被误判为「资源创建成功即完成」。实际上资源就绪只是编排结束，交付闭环要等到用户确认可用、责任转到运维期；而生命周期另一端，到期与闲置资源必须被回收，否则成本和暴露面只增不减。验收与回收共用同一份交付物清单：验收按清单核对是否真的可用，回收按清单确认数据与依赖是否可以放弃。
基本信息
| 验收触发点 | 资源就绪且基础配置完成后自动进入待验收 |
|---|---|
| 验收内容 | 交付物清单、连通性、权限边界、监控与备份接入 |
| 超时策略 | 约定天数内未确认按默认通过，避免长期滞留 |
| 回收触发 | 到期、连续闲置、项目下线、人员离职或转岗 |
| 回收前置 | 数据确认、依赖检查、二次确认、留痕 |
典型使用场景
- 新环境交付：验收确认账号、网络、监控、备份四项都可用
- 测试资源到期：按约定自动进入回收流程，避免资源被长期占用
- 人员离职或转岗：以身份系统变更事件触发资源核查与回收
- 成本优化：按用量阈值筛出闲置资源，先提醒后回收
- 合规要求的数据销毁：归档或销毁需留下可核查的证据
从交付到回收的关键控制点
| 阶段 | 动作 | 关键控制点 |
|---|---|---|
| 交付完成 | 生成交付物清单与访问方式 | 清单与实建资源逐项对齐，避免只写「已开通」 |
| 自动检查 | 连通性、权限、监控、备份探测 | 失败项退回编排修复，不进入人工验收 |
| 用户验收 | 确认可用并签署确认 | 超时默认通过需提前告知用户 |
| 责任交接 | 转入运维期，纳入监控与变更管理 | 交接后责任人与 SLA 口径同步更新 |
| 到期回收 | 提醒、确认、执行回收 | 先确认无数据留存需求，再执行删除 |
| 数据处置 | 归档或按规则销毁 | 销毁动作保留执行记录作为证据 |
验收检查清单片段
验收检查清单片段
acceptance:
- name: 网络连通性 # 从申请人侧发起，而不是只在平台内探测
check: tcp_connect(target, port)
- name: 权限边界 # 确认申请人可访问，且未越权到其他租户
check: authz_probe(user, resource)
- name: 监控接入 # 无监控的交付等于把盲区交出去
check: metric_exists(resource_id)
- name: 备份策略 # 检查策略已绑定，而非仅创建了策略
check: backup_policy_bound(resource_id)
on_fail: 退回编排修复并通知申请人 # 不通过人工签字掩盖验收要查「是否真的可用」，不是查「编排是否返回成功」。缺少自动检查的验收会把连通性、权限、监控、备份四类配置问题带进生产，代价远高于在交付关口拦下。
回收不可逆。默认先提醒、再确认、后执行，并维护保护名单（生产核心、不可再生数据）。直接按到期时间批量删除资源是典型的重大事故来源。