2. 对象模式设计入门
对象模式（Object Schema）是 Jira Assets 中所有资产数据的顶层容器，它决定了“哪些类型的对象可以被管理、它们之间如何关联、谁能看到和修改”。如果把 Assets 比作一个数据库，对象模式就是这张数据库的 schema：它定义了表（对象类型）、字段（属性）、外键（引用关系）以及访问权限。本节的目标不是把模式设计得大而全，而是先建立一个最小可行模式——包含业务服务、应用、服务器、数据库四类对象，并让它们之间的依赖关系能够被清晰表达。
一、对象模式的三个设计维度
创建对象模式时，需要同时考虑三个维度，它们互相制约：
- 命名规范：模式名、对象类型名、属性名、引用名必须统一风格，否则后续在自动化规则、JQL 查询和报表中会频繁出现“同名不同义”或“同义不同名”的问题。
- 层级规划：对象类型之间是平铺还是分层？引用关系是单向还是双向？层级决定了查询路径的长度和权限继承的复杂度。
- 最小可行边界：第一版模式只纳入当前运维和变更管理真正需要的对象与属性，避免把 CMDB 的全部理想模型一次性塞入。
一个常见的误区是先把所有可能的对象类型都建出来，结果导致属性字段冗余、引用关系混乱、维护成本陡增。更稳妥的做法是：先确定“谁依赖谁”这条主线，再围绕主线补充必要属性。
二、命名规范：从模式到属性的一致性约定
命名规范不是审美问题，而是可维护性问题。建议在团队内约定以下规则，并在创建时直接执行：
- 模式名：使用“业务域 + Schema”格式，例如
ITSM Core Schema，避免使用个人姓名或临时项目名。 - 对象类型名：使用单数名词，首字母大写，例如
Business Service、Application、Server、Database。不要用复数或缩写，除非缩写是团队公认的（如DB可接受，但Dtb不可接受）。 - 属性名：使用“业务含义 + 类型”格式，例如
Service Owner、Environment、IP Address。避免attr1、field_a这类无意义名称。 - 引用名：使用“源对象 + 动词 + 目标对象”格式，例如
Business Service depends on Application、Application runs on Server。引用名要能读成一句完整的话。
三、层级规划：四类对象的最小依赖链
业务服务、应用、服务器、数据库这四类对象，天然形成一条从“业务视角”到“基础设施视角”的依赖链。设计时不需要把所有关系都建成双向引用，而是先建立一条主链，再按需补充辅助关系。
主链的依赖方向是：业务服务 → 应用 → 服务器 → 数据库。含义是：业务服务由若干应用支撑，应用运行在服务器上，服务器上部署或连接数据库。这条链的每一段都是一个“多对多”或“一对多”关系，具体取决于实际场景。例如，一个业务服务可能依赖多个应用，一个应用可能运行在多台服务器上，一台服务器上可能运行多个数据库实例。
在 Assets 中，引用关系通过“引用类型”（Reference Type）定义。建议为这条主链创建以下引用：
Business Service depends on Application（业务服务依赖应用）Application runs on Server（应用运行在服务器上）Server hosts Database（服务器承载数据库）
如果实际场景中数据库是独立于服务器的托管服务（如云数据库），则可以把最后一段改为 Application connects to Database，让应用直接引用数据库。关键是保持依赖方向一致：从上层业务指向下层基础设施，便于后续做影响分析时沿着引用方向向下追溯。
四、创建对象模式的实际操作路径
在 Jira Assets 中创建对象模式，通常从“Assets → Object Schemas → Create Object Schema”进入。创建时需要填写模式名称、描述和键（Key）。键是模式的唯一标识，建议使用大写字母和短横线，例如 ITSM-CORE。创建完成后，进入模式内部，依次创建对象类型和属性。
以 Server 对象类型为例，建议至少包含以下属性：
| 属性名 | 类型 | 说明 |
|---|---|---|
| Hostname | Text | 服务器主机名，唯一标识 |
| IP Address | Text | 管理 IP 地址 |
| OS | Select | 操作系统类型，如 Linux / Windows |
| Environment | Select | 环境，如 Production / Staging / Dev |
| Status | Status | 资产状态，如 Active / Retired |
属性创建后，再回到对象类型级别，创建引用关系。引用关系需要指定源对象类型、目标对象类型和引用名称。例如，在 Application 上创建 runs on 引用，指向 Server。创建完成后，可以在对象详情页看到“引用”区域，并手动或通过导入方式建立具体对象之间的连接。
五、最小可行模式的验证与迭代
模式创建完成后，不要急于批量导入数据。先用少量真实或模拟数据验证三件事：
- 引用方向是否正确：从业务服务出发，能否沿着引用链找到其依赖的应用、服务器和数据库？如果方向反了，影响分析会变成“向上找”，不符合运维直觉。
- 属性是否够用：在创建一个业务服务对象时，是否因为缺少某个属性而无法记录关键信息？如果缺少，先补充属性，而不是新建对象类型。
- 命名是否一致：检查所有对象类型和属性名，是否都遵循了团队约定的命名规范。不一致的地方应在数据量还小的时候立即修正。
最后，把模式的设计说明、命名规范、引用方向和验证结果记录在团队文档中。这样，当后续有人需要新增对象类型或修改引用时，可以先对照文档判断是否与现有设计冲突，再决定如何调整。一个清晰、一致、可迭代的对象模式，是后续资产数据质量和自动化规则可靠性的基础。