结论先行：多数企业的资产台账只覆盖网络设备与物理服务器，"应用层到底跑着哪些服务实例"没人说得清。可行做法是让可观测平台从调用链、进程与容器运行数据中自动抽取服务实例，形成应用层台账，再把它与规划清单里"应该有"的内容做差值比对——多出来的是未纳管实例与僵尸实例，少掉的是缺失资产，两类都是要清理的对象。
为什么网络设备台账回答不了应用问题
把网络设备的资产盘点做清楚之后，很多团队以为家底就摸清了。但一到故障定位，还是找不到责任人，原因有三层错位。
- 登记对象错位：台账记的是设备与虚拟机，业务关心的是服务实例。一台物理机上可能跑着七八个实例，台账里只有一行。
- 更新节奏错位：实例随发布和扩缩容天天变，台账通常按季度人工更新，一上线就已经过期。
- 下线不同步：实例销毁后台账往往还挂着，时间一长，台账里的东西和实际跑的东西重合度越来越低。
直接的后果是：故障发生时定位不到归属团队；容量与授权口径失真，钱花在哪说不清；安全扫描与策略下发漏掉临时实例，留下盲区。
应用层台账怎么建：三类数据来源
不需要人工重新抄一遍清单，把三类已经存在的数据接起来即可。
| 数据来源 | 能拿到什么 | 主要用途 |
|---|---|---|
| 调用链上报 | 服务名、实例标识、上下游依赖关系 | 自动绘制依赖拓扑，识别长期无人调用的服务 |
| 主机与容器运行时 | 进程、监听端口、镜像、所在节点 | 发现未纳管实例与已下线的残留 |
| 配置管理与工单系统 | 规划中的服务清单与责任人 | 作为"预期基准"，用于差值比对 |
差值比对：把结果分成四类
建好两份清单后，每周自动做一次比对，人工只处理差异项，工作量可控。
| 比对结果 | 含义 | 处置建议 |
|---|---|---|
| 台账有、实际有 | 正常 | 核对属性，补齐责任人与业务归属 |
| 台账有、实际无 | 缺失资产 | 核查是漏部署还是已下线未注销，二选一处理 |
| 台账无、实际有 | 未纳管实例 | 补录台账，纳入监控、策略与授权口径 |
| 台账无、实际无 | 无 | 忽略 |
僵尸实例怎么判定
"长期没流量"不等于可以删，误删一次就没人敢再治理。建议三条同时满足再标记为僵尸实例：
- 连续一个完整业务周期（建议 7–14 天，要覆盖周末批处理与月末结算）无调用、无访问连接、无日志输出；
- 但仍在消耗计算资源、占用授权额度，并且对外开着端口；
- 在台账里找不到明确的业务归属或责任人。
处置顺序固定为：先标注观察 → 通知责任人确认 → 备份配置与数据后下线 → 台账同步注销。跳过确认直接删，是治理推不动的主要原因。
落地四步
- 定口径：先明确"服务实例"的唯一标识，建议用"服务名 + 环境 + 实例号"组合，避免同名不同环境混在一起。
- 接数据：先把调用链与容器运行时接进来，覆盖率比精度更重要，先做到"大致全"再逐步校准。
- 跑比对：每周自动生成差值清单，按责任团队拆分下发，让业务方自己确认差异。
- 建闭环：把"上线自动登记、下线自动注销"接进发布流程。这一步不做，治理成果会被新增实例一点点抵消。
容易踩的坑
- 学习期太短，把低频的批处理实例误判成僵尸实例；
- 只维护台账不看实际运行，或只看运行不设基准，差值比对压根做不起来；
- 一次性清理之后不再复核，半年后又回到原样。
奇摩在给客户做可观测体系建设时，通常把应用层台账与发布流程绑定一起做——台账准不准，取决于每次发布有没有自动更新它。若您的团队正在推进这块，欢迎预约咨询。