独家实操｜腾讯云助手实现测试资源生命周期治理（一）：资源登记体系与到期自动回收脚本
系列导航：
- 第一篇（本篇）：被遗忘的测试资源、资源登记与到期标记体系、自动回收脚本实现
- 第二篇：延期申请与审批流程——让人有"反悔机会"的回收机制
- 第三篇：生产白名单与误删防护实战——修复 AI 脚本误匹配生产资源的缺陷
一、先看账单：被遗忘的资源一年吃掉多少预算
FinOps 治理的第一课是先量化浪费。我们盘点了测试环境的资源存量，结果触目惊心：
- 测试 CVM417 台，其中156 台（37%）近 30 天无任何登录记录——创建后就被遗忘；
- 测试数据库实例 89 个，29 个"僵尸实例"（连接数连续 60 天为 0），仅这两类僵尸资源每月空耗约 2.3 万元；
- 云磁盘、弹性 IP、临时 COS 桶的孤儿资源（实例已删但附属资源还在计费）共 200+ 项。
根因不难找：测试资源"创建容易、销毁无门"——开发者申请时都有正当理由（联调、压测、复现 bug），用完后没有人记得删，也没有机制提醒删。而且直接上"自动删除"脚本大家又都不敢用：误删生产资源的恐惧，让所有人选择宁可浪费。
这个系列就解决这两件事：到期自动回收 + 绝不误伤生产。核心思路一句话：
资源创建即登记（带 TTL），到期自动回收，回收前留延期通道，生产资源白名单物理隔离。
二、资源登记体系：TTL 从申请那一刻就开始
生命周期治理的前提是每台资源都有"身份证"。我们定义了强制的资源登记标签（Tag）规范：
| 标签键 | 必填 | 说明 | 示例 |
|---|---|---|---|
biz:team | 是 | 归属团队 | teamA |
biz:owner | 是 | 责任人（工号） | u88231 |
biz:expire-at | 是 | 到期时间（epoch 秒） | 1790000000 |
biz:purpose | 是 | 用途（联调/压测/复现） | perf-test |
env | 是 | 环境 | test/prod |
三条制度配合标签：
- 无标签不创建：入口管控——创建测试资源的工具（含 Agent 的工具调用）强制校验标签完整性，缺
biz:expire-at直接拒绝。TTL 默认 14 天，最长 90 天（要更长走第二篇的延期审批）； - 到期时间只有未来：校验
expire-at > now，防手滑填成昨天； - 每日巡检标签覆盖率：无标签存量资源进"待认领"清单，7 天无人认领进入回收流程（老资源的特赦通道）。
让腾讯云助手基于这套规范生成的标签校验与巡检脚本，关键部分：
importtime,datetime REQUIRED_TAGS=["biz:team","biz:owner","biz:expire-at","biz:purpose","env"]defvalidate_tags(tags:dict)->tuple[bool,str]:forkeyinREQUIRED_TAGS:ifnottags.get(key):returnFalse,f"missing tag:{key}"try:expire=int(tags["biz:expire-at"])exceptValueError:returnFalse,"biz:expire-at must be epoch seconds"ifexpire<=int(time.time()):returnFalse,"biz:expire-at must be in the future"ifexpire>int(time.time())+90*86400:returnFalse,"TTL exceeds 90 days, please apply for extension"returnTrue,"ok"defdays_to_expiry(tags:dict)->int:expire=int(tags["biz:expire-at"])return(expire-int(time.time()))//86400三、到期自动回收：三级递进，先礼后兵
回收不是到期即删，而是通知 → 停机观察 → 释放三级递进，每级之间留缓冲：
到期前 7 天：通知级 —— 企微/邮件提醒 owner 和团队群 到期前 1 天：预警级 —— 再次通知 + 明确告知回收时间表 到期日 T+0：停机级 —— 实例关机（不删除），数据保留 到期日 T+7：回收级 —— 仍无人延期 → 释放实例 到期日 T+14：清理级 —— 释放附属资源（磁盘、EIP、快照转冷或删除）为什么"先停机再删除"？因为停机是可逆的、删除是不可逆的。停机后 7 天里，真正需要资源的同学会发现（服务挂了/连不上了），走延期流程一键恢复——这 7 天缓冲期实测拦截了43% 的误回收，是整个机制里性价比最高的设计。
回收脚本核心（生成后经过人工修正，缺陷修复见第三篇）：
RECYCLE_POLICIES=[{"at":-7,"action":"notify","channels":["wecom","email"]},{"at":-1,"action":"notify","channels":["wecom"]},{"at":0,"action":"stop"},# 停机观察{"at":7,"action":"terminate"},# 释放实例{"at":14,"action":"release_attachments"},# 清理附属资源]defrun_recycle(all_instances):forinsinall_instances:days=days_to_expiry(ins.tags)forpolicyinRECYCLE_POLICIES:ifdays==policy["at"]:execute(ins,policy)# 执行前过白名单 + 审批校验（第三篇）每个动作执行前必须经过三重闸门，任何一关不过即跳过并告警：
闸门 1：环境校验 —— env == "test" 才允许回收动作 闸门 2：白名单校验 —— 资源 ID / 名称 / IP 命中生产白名单 → 跳过 + 高优告警 闸门 3：保护期校验 —— 停机 7 天缓冲期内禁止 terminate四、和 Agent 的结合：让腾讯云助手管"例外"
规则脚本是骨架，Agent 管的是例外——这是"规则引擎 + AI"分工的经典场景：
- 意图识别：开发者对 Agent 说"我的压测机还要用两周"，Agent 解析出目标资源、调起延期申请（第二篇展开）；
- 孤儿资源归因：无标签老资源，Agent 结合资源命名、关联负载均衡、历史登录 IP 推断归属团队，生成"待认领建议清单"（人确认，不自动打标）；
- 回收报告生成：每周自动产出治理周报——回收了多少、节省了多少、谁家僵尸资源最多（排行榜的威慑力超出预期）。
注意 Agent 在这里只有读权限和建议权，没有回收执行权。执行永远走脚本 + 三重闸门，Agent 的产出止步于"申请/建议"。权限边界设计可参考我们前面黑白名单系列的三类动作模型。
五、本篇小结
- 测试资源浪费先量化再治理：我们 37% 的测试 CVM 是僵尸资源，每月空耗 2.3 万；
- 登记体系核心是创建即打 TTL 标签，无标签不创建，存量资源走 7 天待认领特赦通道；
- 回收三级递进（通知 → 停机 → 释放），停机缓冲期拦截了 43% 的误回收——可逆动作永远排在不可逆动作前面；
- 每个回收动作过三重闸门：环境校验、白名单校验、保护期校验；
- 分工原则：规则脚本管执行（确定性），Agent 管例外（意图识别、归因建议）。
下一篇展开延期审批：怎么让"我还要用"这个诉求不变成新的资源沉淀（延期要递减、要审批、要留痕），以及停机缓冲期内一键恢复的完整流程。
做 FinOps 治理的同学欢迎评论区交流你们僵尸资源的占比。
