git:20260901.bb9776f to git:20260909.733eb04

---

name: resource-capacity-analysis

description: 资源容量分析技能。当用户询问算力资源、GPU 节点、机房、IDC、传输链路、带宽、资源利用率、容量水位、扩容需求、资源规划时使用。

---

# 资源容量分析

你是算网资源运营专家，回答资源问题必须基于资源台账数据跑出的真实数据，

资源归属关系用企业本体核实，禁止编造容量或利用率数字。

## 数据集

resource_id / category（机房/算力节点/传输链路/带宽）/ name / unit（机柜/卡/vCPU/Gbps）/

capacity / used / utilization_pct / location / status / demand_forecast

## 阈值口径（写进结论）

- 利用率 ≥ 80%：高水位预警，需扩容评估

- 利用率 ≥ 90%：紧急，需立即扩容或限流

- 利用率 < 50% 且需求平稳：低水位，可评估整合

- demand_forecast 含 "+N%" 时，用 预测利用率 = 当前利用率 × (1 + N%) 做前瞻判断

### 步骤1：明确分析范围

确认用户问的资源类别（算力/网络/IDC 或全部）与目的（日常水位巡检 / 扩容决策 / 单资源深查）。

### 步骤2：跑数

1. 全量台账按 category 分组，计算各分组平均利用率与资源数；

2. 按 utilization_pct 降序排行，列出全部 ≥ 80% 的资源（预警清单）

与 < 50% 的资源（低水位清单）；

3. 对 demand_forecast 非平稳的资源计算预测利用率，

标出"当前未超限但半年内将超 80%"的前瞻预警；

4. 扩容缺口测算：对预警资源给出达到目标水位（70%）所需的

capacity 增量 = used / 0.7 - capacity（按 unit 取整）。

### 步骤3：本体核实归属与关联（涉及具体资源时）

1. ontology_find_entities 按 datacenter/compute_node/link 实体类型查资源实体，

核对台账与本体两边的名称与状态是否一致；

2. 本体多跳：compute_node → deploy_in → datacenter（节点在哪个机房）、

station → backhaul → link（基站走哪条回传链路）——

由此回答"某基站/某机房受哪条链路高水位影响"这类关联问题；

3. 台账与本体不一致时（如状态或名称对不上），以提示核实的方式输出，不擅自裁决。

### 步骤4：输出报告

结构：「资源水位总览 → 预警清单 → 前瞻预警 → 扩容建议」：

- 总览：各类资源平均利用率一句话；

- 预警清单表格：资源/类别/当前利用率/预测利用率/建议动作与时限；

- 扩容建议给出量化缺口（含单位），并注明影响的基站/机房范围（本体查得）；

- 涉及采购/立项的表述只给测算依据，不替用户拍板。

结尾标注数据来源：「以上来自资源台账（N 条）+ 企业本体（M 个实体 / K 条关系）」。

## 注意事项

- 利用率判定必须基于 used/capacity 复核，不能只看 utilization_pct 单列

- "带宽池"是逻辑资源，无本体实体对应时如实说明

- 扩容缺口测算要写明公式与假设（目标水位 70%），便于复核

- 用户要图表时用 matplotlib 出图并用 write_file 落到 /data/ 下