闲置资源清理工作流

识别零流量零引用的资源，向干系人核实休眠后带恢复窗口删除，而不是永远堆积。

目标

每个环境都会悄悄堆满使命已死的资源：取消项目的测试集群、两年前迁移留下的桶。多信号休眠评分、owner 核实、带恢复窗口的删除，让清理从风险变成例行动作；新资源出生就带 owner 与过期标签，下一轮清理不再考古。

步骤要点

多信号关联使用情况：对每个候选资源关联多个休眠信号——零流量、零 API 引用、零日志活动、近期无配置变更。
找到 owner 或宣告孤儿：通过标签或历史定位资源归属，窗口期内无人响应则凭证据宣告孤儿。
向 owner 核实休眠：询问指标窗口可能漏掉的季节性或周期性用途，有理由就延长观察。
带恢复窗口删除：可行则先快照或导出再删除，恢复工件保留有界时长并附文档化恢复路径。
给创建设门减缓再堆积：资源创建强制 owner 标签与过期元数据，下次清理从有标签的资产开始。

排错提示

单一零信号可能是坏了不是没用，多信号交叉才够强；月度报表库在 90 天流量图上像休眠但每月末跑结账，owner 核实就是为这种模式存在的；删一个在用资源毁掉整个清理计划的信任，宁可延长观察。

适用边界

休眠判定受观察窗口限制，年度性用途需跨年窗口或人工确认；部分资源删除有依赖连锁（挂载的盘、关联的 DNS），删除顺序要先拓扑后执行。

代码示例

dormancy score (signals, 90d):
  traffic: 0 req   api refs: 0   logs: 0
  config changes: 0   cost: $211/mo

queue (scored):
  eks-test-cluster-3   dormant  owner: team-C
    -> confirmed cancelled project  DELETE
  s3-migration-2024    dormant  owner: NONE
    -> orphan declared (2wk notice)  DELETE
  rds-reporting-rep    low traffic (1 conn/d)
    owner: finance "month-end use"  KEEP

deletion w/ recovery:
  snapshot -> delete -> artifact kept 30d
  restore runbook attached to deletion ticket

creation gate: tag owner + expiry required
  (next cleanup: labeled estate, no archaeology)