成本复查与工具退出计划

从成本归属到退出签收高清原图

某团队停用了一个代码协作工具，管理员在控制台取消了大部分成员座席，随后把工单标成“已退出”。一个月后，账单仍然出现基础订阅和 API 用量；对象存储中保留着导出包与附件，日志平台还在接收 Webhook，CI 里有两个机器人继续调用接口，三名外部协作者和四封待接受邀请仍占用许可。更麻烦的是，负责停用的人已经转岗，没人能解释哪些数据可以删、哪些审计证据必须留，也没人敢直接删除最后一个组织。

这类事故的根源不是不会点“取消订阅”，而是把工具成本误解成一个金额，把退出误解成一个按钮。研发工具会同时留下人员座席、按量 API、日志索引、对象与备份、付费插件、应用安装、Webhook、机器人、CI secret、OAuth 授权、域名验证和本地缓存。只有把这些对象关联到 owner、使用证据、依赖和清理动作，团队才能判断它究竟在创造价值、处于短期静默，还是已经成为无人负责的残留系统。

成本复查服务于工程决策，不替代财务总账、税务处理或采购制度。这里真正要回答的是：谁对这项消耗负责，什么证据证明仍需要它，停掉会影响哪些链路，怎样在可回退窗口内冻结，哪些数据应导出，哪些身份和集成必须撤销，何时能证明后续账期不再产生非预期消耗。

先把“还在付费”还原成九类工程对象

座席是最直观的一类，却不是唯一一类。一个工具至少要从九类对象观察，漏掉任何一类都可能让“已停用”继续产生费用或风险。

对象	常见计量信号	使用证据	退出时的关键动作
人员座席	成员、外部协作者、待接受邀请、附加产品席位	登录、仓库访问、工单变更、内容贡献	移交资产、撤销角色、回收座席、取消邀请
API 与自动化	请求、模型 token、构建分钟、任务次数、流量	调用主体、端点、响应码、关联流水线	停止触发器、轮换或撤销凭据、验证拒绝
云资源与托管服务	租户、项目、实例、集群、IP、负载均衡器、托管数据库	资源清单、标签、账单资源 ID、最近活动与依赖	冻结创建、迁移流量、处理保护锁、删除并复查残留资源
存储与备份	附件、制品、对象版本、快照、导出包	最后读取、法定或项目保留理由、恢复演练	导出所需数据、校验、设置生命周期、删除副本
日志与观测	摄入量、索引容量、查询、归档、转发	告警、排障查询、审计用途、保留责任	停止采集、调整保留、清理转发和归档
合同与承诺	年度合同、最低消费、预付额度、续费日、退出通知期	订单、合同条款、采购审批、供应商确认	阻止自动续费、确认尾款与退款边界、保留终止证据
权威财务数据	发票、账单明细、贷项、冲正、税费、付款状态	发票号、结算周期、币种、最终明细与财务签收	对账、解释迟到费用、确认最终账期、关闭或重开退出事项
插件与扩展	商店订阅、每用户附加许可、实例级应用	安装范围、活跃用户、产生的字段与数据	禁用写入、导出配置、卸载、清理应用数据
外部集成	OAuth、GitHub App、Webhook、机器人、SCIM 连接	最近投递、token 使用、目标系统日志	解除安装、撤销授权、删除 secret、验证无投递

不同产品对“占用座席”的定义并不相同，不能只用登录时间推断。例如 GitHub 的许可使用说明会区分组织成员、外部协作者、待接受邀请和不同企业身份形态；团队应从目标产品的许可报告或 API 读取实际计费主体，而不是维护一套想当然的统一规则。GitHub 也支持通过界面或 API 下载许可使用报告，这类产品侧明细应与内部 owner 台账关联，而不是被当成最终判断。

还要把“身份是否能登录”“座席是否被分配”“何时停止计费”拆成三个字段。退出登录、禁用本地账号或关闭浏览器会话，只改变访问状态，不会自动取消座席、基础订阅、按量任务和第三方插件。GitHub 的计费周期说明给出了一个典型反例：周期中移除用户或座席时，访问可以立即撤销，但当前周期仍可能按完整周期计费。因此座席回收证据至少应同时保存产品侧许可明细、访问撤销时间、计费变更生效周期和合同或账单依据。

金额只用于排序，不能单独决定删除。一个月消耗很低的审计导出可能是事故调查的关键证据；一个金额很高但持续支撑交付的构建工具也不能因“超过阈值”直接停用。架构判断依赖成本对象、业务能力、替代路径、数据可迁移性和退出风险的组合。

这些对象的证据也不能混成一张“看起来权威”的表。产品许可报告、资源 inventory 和 API 调用日志回答的是对象是否存在、由谁使用；云成本导出和供应商用量明细回答的是费用如何形成，但在关账前仍可能迟到、重算或冲正；合同、最终发票、贷项与付款状态才回答财务义务是否结束。Azure 官方明确提示当前账期数据可能重定价，费用可在账期结束后继续更新，而发票签发后才应视为最终金额；其定时导出还会在月初重复刷新上月数据，以纳入迟到费用。参见 Cost Management 数据时效与最终账单和定时成本导出。因此工程台账必须保存数据源、提取时间、水位、账期和是否已关账，不能用某次控制台截图覆盖后来的发票事实。

建立能驱动动作的成本清单

清单的最小粒度不是“产品”，而是可独立归属、暂停和验证的计费对象。一个产品可能拆出基础订阅、AI 附加座席、日志容量包、对象存储、插件和 API 用量；同一个组织还可能跨多个租户、区域或项目。只登记供应商总额，会让真正的闲置对象藏在合计数里。

下面的合成清单使用虚构组织 your-org。monthly_estimate 只是复查排序用的合成数值，不代表任何产品价格；真实单价、计费周期和中途移除是否影响当期费用，应在目标租户的合同与计费页面确认。生产清单还应增加 contract_id、billing_cycle_start、billing_cycle_end、source_extracted_at、source_watermark、access_revoked_at、billing_change_effective_at、expected_final_invoice 和 invoice_status，防止把“已经不能登录”误判成“已经不再计费”，也防止把尚未关账的估算导出误当最终金额。

[
  {
    "cost_id": "COST-001",
    "tool": "code-hub",
    "object_type": "seat",
    "object_id": "user-demo-17",
    "owner": "platform-team",
    "cost_center": "cc-platform-demo",
    "monthly_estimate": 80,
    "last_used_days_ago": 106,
    "usage_source": "license-export",
    "dependency_ids": [],
    "data_class": "internal",
    "renewal_mode": "metered",
    "status": "review"
  },
  {
    "cost_id": "COST-002",
    "tool": "code-hub",
    "object_type": "api",
    "object_id": "bot-release-demo",
    "owner": "release-team",
    "cost_center": "cc-release-demo",
    "monthly_estimate": 260,
    "last_used_days_ago": 1,
    "usage_source": "api-usage-export",
    "dependency_ids": ["DEP-CI-07"],
    "data_class": "internal",
    "renewal_mode": "metered",
    "status": "keep"
  },
  {
    "cost_id": "COST-003",
    "tool": "code-hub",
    "object_type": "storage",
    "object_id": "archive-demo",
    "owner": "",
    "cost_center": "",
    "monthly_estimate": 140,
    "last_used_days_ago": null,
    "usage_source": "storage-inventory",
    "dependency_ids": ["DEP-EXPORT-02"],
    "data_class": "restricted",
    "renewal_mode": "metered",
    "status": "review"
  }
]

这些字段分别驱动动作：owner 接收确认与签收；cost_center 表示内部归属而非会计凭证；usage_source 指向可复查证据；dependency_ids 阻止误删；data_class 决定导出、访问和删除要求；renewal_mode 决定复核时间；status 只能由证据变化推动。计费周期、水位和发票状态决定何时查最后一张预期账单，访问与计费生效时间的差值解释过渡期费用。空 owner、空证据、未知依赖、未知水位或未知计费生效日不是“待补充备注”，而是阻断自动删除和财务签收的状态。

这里的台账服务于单个工具的准入、使用和退出动作：它把一个 cost_id 追到具体座席、资源、凭据、数据副本和责任人。跨云账单摄取、FOCUS 规范化、币种与摊销、共享成本分配、单位经济和发票守恒应进入成本数据底座与守恒关卡。两条链通过稳定的资源 ID、账期和 owner 连接；退出工单不能自行重算企业成本口径，FinOps 数据平台也不能仅凭低利用率直接删除工具资源。

清单最好由许可导出、用量 API、云资源清单和插件安装列表自动生成，再由 owner 补充业务判断。手工表格可以作为启动入口，却不应长期承担对象发现：人员变动、机器人调用和新插件会持续变化，静态表格很快失真。

用正反实验验证闲置判断，而不是凭印象停用

“三十天没登录”经常被错误地等同于“闲置”。登录只是一个信号：服务账号从不交互登录，却可能每天触发发布；季度审计账号可能数月不使用，但有明确恢复时间；待接受邀请可能没有任何活动，却仍可能消耗许可。合理判断至少组合活动、依赖、owner 确认、数据责任和未来窗口。

把上面的 JSON 保存为临时文件 tool-cost-inventory.json，再建立只读分析脚本 review-costs.mjs。脚本不调用任何产品 API，也不删除对象，只把“候选回收”和“必须阻断”分开。

import { readFile } from "node:fs/promises";

const rows = JSON.parse(await readFile("tool-cost-inventory.json", "utf8"));

for (const row of rows) {
  const reasons = [];
  if (!row.owner) reasons.push("OWNER_MISSING");
  if (!row.cost_center) reasons.push("COST_OWNER_MISSING");
  if (!row.usage_source) reasons.push("USAGE_EVIDENCE_MISSING");
  if (!Number.isInteger(row.last_used_days_ago)) reasons.push("ACTIVITY_EVIDENCE_MISSING");
  if (row.dependency_ids.length > 0) reasons.push("DEPENDENCY_PRESENT");
  if (row.data_class === "restricted") reasons.push("DATA_REVIEW_REQUIRED");

  const stale = Number.isInteger(row.last_used_days_ago)
    && row.last_used_days_ago >= 60;
  const decision = reasons.length > 0
    ? "BLOCK_EXIT"
    : stale
      ? "RECLAIM_CANDIDATE"
      : "KEEP";

  console.log(JSON.stringify({
    cost_id: row.cost_id,
    idle_days: Number.isInteger(row.last_used_days_ago)
      ? row.last_used_days_ago
      : null,
    decision,
    reasons
  }));
}

node .\review-costs.mjs
Remove-Item -LiteralPath .\review-costs.mjs, .\tool-cost-inventory.json

正向结果中，COST-001 有 owner、有费用归属、无依赖且超过合成阈值，应输出 RECLAIM_CANDIDATE；这仍只是进入确认和冻结，不是自动删除。COST-002 最近仍被 CI 使用且有依赖，应输出 BLOCK_EXIT。COST-003 故意缺少 owner 与归属，又包含受限数据、未知活动证据和导出依赖，必须输出包括 ACTIVITY_EVIDENCE_MISSING 在内的多个阻断原因。若脚本把 COST-003 直接归为闲置，说明规则把“没有活动数据”误当成“没有使用”，反向实验失败，应先修复发现链路。

阈值应因对象而异：交互座席可观察登录和贡献；API 看成功调用、失败重试和触发器；存储看读写、保留义务与恢复用途；插件看安装范围、产生的数据结构和依赖页面；日志看摄入、查询、告警和审计用途。阈值必须带复查周期和例外到期日，永久例外等于取消治理。

依赖检查要覆盖人、机器、数据和网络四条链

停用前最危险的问题是“有人说不用了”，却没有机器证据。依赖扫描至少从四个方向展开：人员是否仍通过 SSO 或本地账号访问；机器人是否持有 PAT、OAuth、GitHub App 或服务账号；项目是否引用 SDK、CLI、域名、Webhook 和插件字段；数据是否被下游报表、审计查询、导出任务或恢复流程读取。

仓库侧可以先做静态搜索，搜索词来自工具域名、环境变量名、CLI 名称、Webhook 路径和 secret 名，而不是只搜产品品牌。以下命令只读；执行前应确认搜索目录不会包含不该被操作者读取的高敏文件。

$patterns = @(
  'api\.tool-demo\.example\.com',
  'TOOL_DEMO_TOKEN',
  'tool-demo-cli',
  'webhooks/tool-demo',
  'DEP-CI-07'
)

rg -n --hidden `
  --glob '!node_modules/**' `
  --glob '!.git/**' `
  --glob '!dist/**' `
  ($patterns -join '|') .

没有命中不代表没有依赖。CI 变量可能只存在于平台，OAuth 授权在个人设置里，GitHub App 安装在组织设置里，Webhook 由对端保存，DNS 和防火墙白名单由另一团队维护。最终依赖图至少记录 source -> credential -> integration -> target -> owner。只记录“调用了某 API”而不记录由哪个身份调用，退出时仍无法找到撤销对象。

插件尤其容易被低估。卸载应用可能阻止其继续访问组织资源，却不必然替用户撤销所有个人授权，也不保证第三方已经删除此前同步的数据。GitHub 官方对应用授权复查与撤销明确区分个人授权和组织安装：组织 owner 可以卸载安装以阻止应用访问该组织资源，但不能代替成员撤销个人 GitHub App 授权；个人授权只能由授权者撤销。OAuth App、GitHub App 安装、用户授权、应用签发的 token、Webhook、商店订阅和应用侧数据副本必须分别列项，逐项保存撤销主体、预期拒绝、最后投递和供应商删除状态。只删除用户或组织账号，不能证明这些独立信任关系和外部副本已经消失。

冻结不是关机，而是建立可回退的静默窗口

直接删除会同时破坏证据、迁移和回滚。更稳妥的做法是进入冻结期：禁止新增座席和新集成；停止非必要写入；把自动化切到替代工具或只读模式；保留有限的 break-glass 管理入口；记录冻结开始时间、预计结束时间和恢复条件。冻结期内若仍出现调用、写入或人工访问，就能暴露遗漏依赖。

冻结控制要作用在真实对象上，而不是发一封通知。可以暂停 Webhook、禁用机器人工作流、把 API token scope 降为只读、关闭自助安装、撤销待接受邀请，并在代理或防火墙侧为目标域名增加可观测的拒绝规则。不要一开始销毁最后一个管理员身份；否则发现漏项时只能走供应商支持恢复，延长停机和付费周期。

一次合格冻结至少产生四份证据：变更前对象清单、冻结动作及执行者、冻结后的零新增或预期拒绝记录、回退操作及审批人。若冻结后 CI 出现 401、Webhook 持续重试或用户报告只读失败，先根据依赖 ID 判断是预期阻断还是漏迁移。不要为了让告警消失而临时恢复永久 token；应修复调用链或按时间盒恢复。

导出必须同时验证完整性、可读性和删除责任

“已下载一个压缩包”不能证明数据可迁移。导出前先把对象分类：源代码与配置、工单与评论、附件、审计事件、成员和角色、应用配置、密钥元数据、日志与报表。凭据值通常不应导出后继续使用；应该导出标识、owner、scope、最后使用和撤销状态，再在目标系统创建新凭据。

导出包需要 manifest、文件数量、字节数、哈希、生成时间、导出工具版本、数据时间窗和读取责任。下面的 PowerShell 示例为合成目录生成清单，不包含上传动作。真实导出目录若含受限数据，应在加密卷或受控对象存储中执行，并限制日志输出。

$exportRoot = Resolve-Path -LiteralPath '.\tool-exit-export-demo'
$manifest = Get-ChildItem -LiteralPath $exportRoot -File -Recurse |
  Where-Object Name -NE 'manifest.json' |
  Sort-Object FullName |
  ForEach-Object {
    [pscustomobject]@{
      path = $_.FullName.Substring($exportRoot.Path.Length + 1).Replace('\', '/')
      bytes = $_.Length
      sha256 = (Get-FileHash -Algorithm SHA256 -LiteralPath $_.FullName).Hash.ToLowerInvariant()
    }
  }

$manifest | ConvertTo-Json -Depth 3 |
  Set-Content -Encoding UTF8 -LiteralPath (Join-Path $exportRoot 'manifest.json')

$verification = Get-Content -Raw -Encoding UTF8 `
  -LiteralPath (Join-Path $exportRoot 'manifest.json') |
  ConvertFrom-Json |
  ForEach-Object {
    $candidate = Join-Path $exportRoot $_.path
    $exists = Test-Path -LiteralPath $candidate -PathType Leaf
    $actualHash = if ($exists) {
      (Get-FileHash -Algorithm SHA256 -LiteralPath $candidate).Hash.ToLowerInvariant()
    } else { $null }
    $actualBytes = if ($exists) { (Get-Item -LiteralPath $candidate).Length } else { $null }
    [pscustomobject]@{
      path = $_.path
      exists = $exists
      bytes_match = $actualBytes -eq $_.bytes
      hash_match = $actualHash -eq $_.sha256
    }
  }

$verification | Format-Table -AutoSize
if ($verification.Where({ -not $_.exists -or -not $_.bytes_match -or -not $_.hash_match })) {
  throw 'Export verification failed; stop before revocation or deletion.'
}

正向验证是：抽样文件能够由不参与导出的另一位操作者读取，哈希重算一致，关键对象数量与产品侧统计相符，恢复到隔离环境后关系仍可解释。反向验证可以删除一个合成附件或篡改一行文本，再重算哈希；校验应明确指出缺失或不一致，而不是因为压缩包可以打开就通过。

导出会制造新的敏感副本。台账应同时登记导出位置、加密方式、可读角色、保留理由、到期日、删除 owner 和恢复演练结果。若产品侧删除完成、导出包却永久留在个人电脑或共享盘，退出只是把风险从供应商搬回了团队。

撤销、停用与删除必须按可逆性排序

退出动作应从最可逆走向最不可逆，并且每一步都验证结果。一个可复用顺序是：停止新增与续费变更，冻结写入，迁移调用，导出并校验，撤销人员访问，撤销机器人和 token，解除 Webhook 与应用安装，清理日志和存储，取消订阅，最后删除租户或组织。删除账号只是这条链末端的一个动作，不能代替资产移交、依赖迁移、授权撤销、数据处置和账期核验；在前置证据缺失时先删账号，反而会失去执行后续清理所需的管理员入口。

撤销必须有反向调用证据。token 在控制台显示“revoked”之后，用该 token 发起最小只读请求，应得到明确认证失败；如果仍成功，可能使用了缓存凭据、另一枚 token 或代理层复用连接。GitHub 的token 过期与撤销说明指出，已过期或撤销的 token 不能恢复，需要重新创建；这意味着撤销是不可逆动作，必须在迁移验证后执行，不能拿生产凭据做随意演练。

人员撤权也不是在身份目录里点一次禁用就结束。Microsoft Entra 的紧急撤权说明区分身份提供方 token 与应用自己的 session：目录侧阻止新 token 或撤销刷新 token，不会直接销毁第三方应用签发的会话 cookie；应用仍需执行自己的会话撤销与去配。退出证据应分别记录目录账号、组分配、SCIM 状态、应用本地账号、个人授权、应用 session 和终端缓存的预期失效时间，并在各控制面验证拒绝。

存储删除比界面上的“对象不可见”更复杂。版本化对象存储中，不带 versionId 的普通删除会创建 delete marker，使普通读取返回不可见，但旧版本仍可按版本 ID 读取并继续产生存储费用；AWS 的 S3 版本删除说明还明确区分当前版本过期与 NoncurrentVersionExpiration 对非当前版本的永久删除。清理记录要分别验证当前版本数、非当前版本数、delete marker、未完成分片上传、复制目标、Object Lock 或 legal hold、快照和备份。只有删除 API 返回成功、ListObjectVersions 或 Storage Lens 等清单不再显示目标版本、复制和备份状态得到确认，才能关闭对应对象；只看普通 ListObjects 为空，或者只收到删除请求成功，均不能证明数据已经物理消失。

日志也可能延迟删除。CloudWatch Logs 的保留行为说明指出，事件达到保留期后先被标记删除，实际删除通常最多还需 72 小时，极少数情况可能更久；但被标记后已经不再计入归档存储费用，也不再包含在 storedBytes 中。这个行为不能泛化成所有日志产品的统一计费规则。清理时应分别记录最后摄入时间、保留策略生效时间、过期标记或 storedBytes 变化、查询不可见时间、后台物理删除确认和账单停止时间；其中任何一个时间点都不能单独替代其余证据。

一份可执行的退出运行手册

运行手册不能只有负责人和日期；每一步都需要输入、执行者、命令或界面对象、预期证据、失败时的停止条件和回退动作。下面的 YAML 使用合成对象，适合进入受控工单或配置仓库。真实凭据只能引用 secret ID，不能写入文件。

exit_id: EXIT-code-hub-demo-01
tool: code-hub
tenant: your-org
decision_owner: platform-team
technical_owner: developer-experience-team
security_reviewer: security-team
data_owner: data-governance-team
state: dependency_check
renewal:
  mode: metered
  contract_id: <contract-or-order-id>
  notice_deadline: <renewal-notice-deadline>
  next_review_at: <next-billing-review-date>
freeze:
  starts_at: <freeze-start>
  restore_until: <restore-deadline>
  break_glass_account: <controlled-admin-id>
evidence:
  license_export: <evidence-uri>
  usage_export: <evidence-uri>
  resource_inventory: <evidence-uri>
  dependency_graph: <evidence-uri>
  data_manifest: <evidence-uri>
  audit_export: <evidence-uri>
  contract_and_order: <evidence-uri>
  final_invoice: <pending-or-evidence-uri>
  source_watermark: <billing-data-watermark>
steps:
  - id: E01
    action: stop_new_seats_and_integrations
    expected: no_new_assignment_events
    rollback: restore_admission_policy
  - id: E02
    action: freeze_writes_and_migrate_automation
    expected: legacy_calls_zero_or_explicitly_denied
    rollback: enable_time_boxed_read_write_access
  - id: E03
    action: export_and_verify_required_data
    expected: manifest_hash_and_restore_sample_pass
    rollback: repeat_export_before_any_deletion
  - id: E04
    action: revoke_people_apps_tokens_and_webhooks
    expected: old_credentials_rejected_and_no_delivery
    rollback: issue_new_limited_credentials_by_approval
  - id: E05
    action: delete_storage_logs_plugins_and_tenant
    expected: all_resource_and_replica_checks_empty
    rollback: restore_only_from_approved_export
  - id: E06
    action: verify_next_billing_cycle
    expected: no_unexpected_charge_or_usage
    rollback: reopen_exit_incident_and_trace_cost_id
signoff:
  technical: { signer: pending, evidence: pending, signed_at: pending }
  security: { signer: pending, evidence: pending, signed_at: pending }
  data: { signer: pending, evidence: pending, signed_at: pending }
  cost_owner: { signer: pending, evidence: pending, signed_at: pending }

状态机应限制跳转：dependency_check -> frozen -> exported -> access_revoked -> deleted -> billing_verified -> signed_off。owner 缺失、合同通知期未知、导出校验失败、恢复抽样失败、关键依赖仍有调用、撤销后凭据仍可用、删除副本未确认、账单水位未收敛或下一账期仍有异常消耗时，状态必须停留在当前阶段。管理员手工把字段改成 signed_off 不应绕过证据检查。每次失败都要保存失败证据、当前可逆点和重新执行条件：冻结失败回到受控读写，导出失败重新导出而不撤权，迁移失败恢复时间盒调用，删除后恢复只进入隔离环境，账单异常则重开退出事项并沿 cost_id 追踪。

回退不意味着恢复旧风险。撤销 token 后若需回退，应按审批创建新的短期、最小 scope 凭据；删除后若需恢复，应从已校验导出恢复到隔离位置；冻结后若需恢复写入，应限定时间、对象和调用方。把旧永久 token 重新放回 CI，虽然恢复快，却会破坏撤销证据和后续追踪。

下一账期复核才决定退出是否完成

取消席位或订阅后的当期账单不一定立即变化，原因可能是预付、按量结算延迟、最低承诺、按日折算、账单时区、冲正或已发生用量。不要写死某个供应商的退款和折算规则；在目标租户的计费周期、合同和官方说明中确认，并登记 access_revoked_at、billing_change_effective_at、source_watermark、expected_final_invoice 和下一完整复核周期。以 GitHub 为例，其计费周期说明明确指出，中途移除用户或座席时访问立即撤销，但仍可能按完整周期计费；移除组织或仓库则停止后续费用，但已发生用量仍会结算。不能把一种 SKU 的行为套到另一种 SKU，更不能用“用户已登出”推导“费用已停止”。

复核至少比较三组数据：退出前完整周期、执行退出的过渡周期、退出后的完整周期。比较对象不是只有总额，还包括座席数、API 用量、存储字节、日志摄入与保留、插件订阅、税费之外的产品明细和未知项目。过渡周期中的费用必须能对应到合同承诺、完整周期座席或退出前已发生用量；退出后的完整周期仍出现新用量，则说明存在残留身份、触发器、复制、缓存刷新或另一个租户。若供应商按年、周年日或最低承诺结算，一个月零增量只能证明没有新增消耗，不能证明合同义务已经结束，复核窗口必须覆盖实际续费边界。

发现残留时，先用 cost_id 追到产品对象，再用依赖图追到调用主体。不要用“金额很小”关闭问题：小额 API 调用常常说明某枚凭据仍有效；少量日志摄入说明某个 agent 或转发器仍运行；存储缓慢增长说明备份或导出任务没有停。它们同时是安全和数据边界问题。

退出签收需要四类角色分别确认：技术 owner 确认依赖和替代链路；安全责任人确认身份、token、应用与审计；数据 owner 确认导出、保留和删除；成本 owner 确认下一完整账期没有无法解释的项目。一个人代签全部角色会让遗漏再次回到口头判断。

深水区：最容易让退出失真的六个陷阱

席位回收不等于身份消失。 成员可能还保留个人 OAuth 授权、外部协作者身份、待接受邀请或另一个组织中的访问。现象是许可下降了，但应用仍收到用户级调用。判断时同时比对许可报告、SSO/SCIM 状态、授权应用列表和审计事件；修复动作分别撤销，不把“禁用账号”当成万能开关。

不能登录不等于不再付费。 会话退出、SSO 禁用、目录停用和座席回收作用在不同控制点，计费还可能受当前周期、预付合同、最低承诺和附加产品影响。现象是用户收到拒绝，但当期或下一张账单仍有许可项目。应比对访问撤销时间、许可导出、计费变更生效日和合同边界；能解释的最后账单进入预期尾款，无法解释的新周期项目继续追踪，不能因账号已删而关闭工单。

零调用不等于无依赖。 定时任务可能只在季度末运行，灾备账号只在故障时使用，Webhook 可能因为对端停机而暂时没有投递。现象是冻结数周没有流量，删除后特殊流程失败。判断标准应包含业务日历、最近成功与失败调用、代码引用、owner 证明和替代演练；无 owner 的低频链路不能默认删除。

删除当前对象不等于删除全部副本。 版本、快照、缓存、搜索索引、复制桶、导出包和第三方同步可能继续存在。现象是主界面查询为空，但存储容量、恢复接口或下游搜索仍能找到数据。应分别列出副本类型和删除 API，以恢复抽样或 inventory 证明结果，不能只保存一张“删除成功”截图。

降低保留不等于立即释放容量。 日志与对象生命周期可能异步执行，也可能受最短存储期、复制状态、删除保护或不可变策略影响。现象是策略已更新但容量没有下降，或者删除请求被拒绝。先查资源状态、保护策略、版本和后台任务，再决定等待、解除保护或升级审批；不要反复提交删除造成更多 marker 或审计噪声。

卸载插件不等于撤销所有信任。 插件可能创建自定义字段、Webhook、机器人、OAuth 授权、导出副本和本地扩展配置。现象是商店显示已卸载，但旧 endpoint 仍收到请求，或用户浏览器仍持有扩展。退出清单必须按安装面、授权面、数据面和终端面分别清理，并在对端观察零投递和认证拒绝。

把复查与退出变成持续运行的团队能力

成本复查不应等到年度预算收缩才启动。人员座席适合按成员变化和固定周期检查；高波动 API、日志与存储适合更高频地观察异常；插件和集成应在安装、权限变化、长期无使用和产品退出时触发复查。频率由变化速度和风险决定，不是所有对象统一每月填一次表。

自动化适合做发现、关联和阻断，不适合在证据不全时直接删除。脚本可以发现无 owner 对象、异常增长、长期静默座席、过期邀请、未知插件和无调用 token；工作流可以要求 owner 在期限内选择保留、降级、迁移或退出；真正的不可逆删除仍应经过数据、依赖和恢复证据。

一项工具治理成熟的标志，不是账单永远下降，而是每一项消耗都能解释，每一个闲置判断都能复查，每一次退出都能在没有原管理员口述的情况下重放。团队最终应能回答：哪个对象停止了，旧凭据为什么不可用，数据保存在哪里并何时删除，替代链路怎样验证，下一账期为什么没有残留，以及谁对这个结论完成签收。

退出签收检查表

座席、API、云资源、存储、日志、合同承诺、权威财务数据、插件和外部集成都有独立 cost_id、owner、归属和证据来源。产品清单、用量导出、合同、最终发票和付款状态分层保存，数据源、水位、提取时间与是否关账可追溯。访问撤销时间、计费变更生效时间、预计最后账单和续费边界已分开登记，没有用退出登录或删除账号代替费用核验。

闲置判断同时检查活动、依赖、数据责任、业务日历和例外到期日，没有只看登录时间。依赖图包含人员、服务账号、PAT、OAuth、应用安装、Webhook、CI secret、域名和数据下游。冻结期禁止新增和非必要写入，保留受控恢复入口，并观察到零新增或明确拒绝证据。

导出包有对象统计、manifest、哈希重算、隔离环境抽样恢复、访问权限、保留期限和删除 owner；任一校验失败都会阻断撤权和删除。撤销后的旧凭据实际返回认证失败，未使用生产凭据做破坏性演练。存储清理检查当前对象、非当前版本、delete marker、未完成上传、复制目标、保护策略、快照和导出副本，没有把删除请求成功或普通列表为空当成物理删除完成。

日志清理区分停止摄入、保留到期、过期标记、实际不可查询、后台删除和停止计费，并按产品口径核验，没有把策略保存当成删除完成。插件退出分别处理组织安装、个人授权、机器人、Webhook、字段、第三方数据和终端扩展。退出后的完整账期已与退出前和过渡期对比，并覆盖合同续费边界；迟到费用、贷项、冲正和残留项目都能追到对象并关闭。

技术、安全、数据和成本责任人分别以姓名、时间和证据位置签收，失败回退与重新开启条件仍可访问。