运维准备关闭旧服务器，负责人确认常用服务都搬走了。月底，财务助手突然不能生成对账表：它每月只调用一次的转换脚本还在那里。停机前问过“有没有人在用”，但提问的对象没有包括这段自动运行的工作。
如果所有消费者都在同一个仓库，搜索调用位置、确认维护人就能解决大半问题。已经有完整服务目录的团队也不必另建一套。困难在于脚本和 Agent 分散在不同设备，没人拥有全部代码，几天没有日志又覆盖不了月末任务。
对已经通过 EasyNet 接入的操作，可以按能力地址调查，而不是只列机器名。旧服务器上的查询、转换、导出是不同的下线对象；各自的描述和调用记录能帮助找到实际使用者。没有经过该入口的直接调用仍需向业务方调查，不能被算作“无人使用”。
还需要一个由维护者确认的迁移清单，把观察到的调用者、主动声明的依赖和暂未联系上的使用方分开。负责人应能说明记录覆盖哪个业务周期，以及哪个低频任务仍未试跑。这些依赖登记和通知不是现有目录自动生成的完整依赖图。
替代操作要用代表性输入核对。报表函数即使返回了文件，也可能换了列名、币种或截止时间；调用方要实际取回输出，确认消费程序能继续工作。新入口的调用权限和存储访问分别准备，不能靠替换一个地址假定迁移结束。
最后才安排停止新增依赖、通知切换和关闭旧入口。用测试任务确认旧地址的失败能定位到负责人，并观察约定周期内是否还有遗留请求。EasyNet 在这里提供共同调查线索，停机决定仍属于掌握业务依赖的团队，而不是一次空查询的自动结论。
- 01
列出旧操作
报表、转换分别确认负责人
- 02
找低频任务
调用记录加业务方申报
- 03
核对替代输出
同一输入核对列名和口径
- 04
确认后停用
保留遗留请求的负责人线索
把未确认的消费者留在清单上
本地清单校验，不会自动发现依赖；month-end 来自负责人申报，而非短期日志。
consumers = [
{"name": "daily-export", "replacement_tested": True},
{"name": "month-end-reconciliation", "replacement_tested": False},
]
pending = [c["name"] for c in consumers if not c["replacement_tested"]]
assert pending == ["month-end-reconciliation"]
print("Do not retire:", ", ".join(pending))预期结果：输出 Do not retire: month-end-reconciliation；清单全部确认也不能证明未登记的调用不存在。
接入时的检查项
- 月末或季度任务是否包含在观察窗口内。
- 能否从一个失败调用定位具体能力与维护者。
- 停用后是否仍出现旧地址请求，并能识别其来源。