EASH 本体类梳理方法论

出处：docs/teaching-kit/教辅-02-工作坊模板与能力问题.md · 华东金融云样例 CQ-01～CQ-10。

以 docs/planning/产品编码启动计划-2026-06-23.md §四 与 consulting-kit/00-咨询交付包总导航.md 为准：

P0 · 首期必须验收（8～12 周）

P1 · 第二期（根因跑通后）

P2 · 第三期（路线图，本期不做）

S7 定时巡检 · S8 变更评审 · S9 告警自动分诊 · S10 受控处置

图例：● 主用 · ●● 核心 · ○ 可选/后期

22 类是怎么凑出来的？

1. 拿 P0 四条场景（S1/S2/S3 + 场景 B）逐条画证据链/资产链
2. 链上出现的名词 → 候选类（Pod、Alert、支付网关…）
3. 把候选类归入四层贴标签；合并同义项（如 runs_on 与 deployed_on 留一）
4. 对照 CQ-01～CQ-10：每条必要 CQ 必须在图上有路径，否则补类或补关系
5. 控制在 15～25 类 MVO；华东金融云定稿 22 类（教辅-04 / consulting-kit）

Incident、Problem 等类为工单扩展预留，P0 可不灌实例；Team 可合并为属性。

③ 不是「又做一遍对接」。对接配置在②（规则）+ 管理端连接器（地址密钥）；③ 是同步跑完以后在「图谱实例」页验收：pay-gw-03、ALERT-991 是否已入图。

flowchart LR
  S1[① 本体模型 TBox]
  S2[② 映射与归一]
  S3[③ 图谱实例 ABox]
  S35[③½ AI适配助手
可选]
  S4[④ 可调用工具]
  S5[⑤ 编排+评测]
  S6[连接器持续同步]

  S1 --> S2 --> S3
  S2 --> S6 --> S3
  S3 --> S35 --> S4 --> S5

  style S3 fill:#e3f2fd
  style S35 fill:#f3e5f5
  style S4 fill:#e8f5e9
  style S5 fill:#fff3e0
          

所以：③ 是「数据能支撑场景查询」的里程碑，不是 Pack 交付终点。咨询验收通常按「场景 A/B 智能体考过 + 图谱可查」一起签。

所以：四层不是 CMDB 的「基础设施/应用/人员」分类，而是智能体办事时需要的四类语义——既有「资源」（结构层），也有「发生了什么」（动态层）和「怎么做才合法」（规程层）。

出处：docs/teaching-kit/教辅-04 类清单「层级」列 · docs/marketing/agentic-aiops-benti-zhishitupu-luodi.md · ops-pack 模板 packs/ops/

路由器 vs 交换机：在本体是同一个类 NetworkDevice，用属性 device_role 区分，而不是再建 RouterClass / SwitchClass 两级子类——除非场景 CQ 明确要区分且智能体要分别遍历。

1. 对齐场景与 CQ（30min）— 念 8～12 条能力问题，客户签字「必要 / 可选 / 不做」
2. 画故障/办事故事（60min）— 用 ALERT-991 等真实案例，从左到右画 Alert→CI→服务→业务→变更
3. 拆运维六块积木（60min）— 对象、关系、属性、规程、动作、事件 → 便签出类名与关系名
4. 贴四层标签（30min）— 每个类便签标：结构/功能/动态/规程
5. 对齐数据源（60min）— 每类写：CMDB 哪张表、监控哪个字段（映射草稿）
6. 规程与争议（30min）— R01～R05 便签；命名不一致进归一清单

flowchart LR
  CQ[能力问题 CQ] --> STORY[故障故事白板]
  STORY --> CLASS[类便签 15-22个]
  STORY --> REL[关系便签 20+]
  CLASS --> LAYER[标四层]
  CLASS --> MAP[映射草稿]
  REL --> MAP
  LAYER --> PACK[导入 Pack / 本体构建]
  MAP --> PACK
          

产出物对齐：teaching-kit/教辅-02 工作坊 · 教辅-04 22 类清单 · consulting-kit 华东金融云样例。