4. 传递单元数据模型：设计传递单的元数据字段

传递单的本质是“故障上下文的结构化快照”。元数据字段的设计直接决定了后续审查、检索、关联分析的效率。本节定义传递单的核心元数据模型，涵盖标题、优先级、影响范围与关联系统四大支柱字段。

4.1 元数据字段总览

传递单元数据模型采用“核心字段 + 扩展属性”的分层结构。核心字段确保所有传递单具备最低限度的可读性与可追溯性；扩展属性则根据业务场景按需挂载。下表列出四个必选核心字段的定义与约束：

4.2 标题字段：故障现象 + 系统名称

标题是传递单的“门面”，也是后续检索与聚类分析的核心维度。我们要求标题必须采用 【系统名称】故障现象 的格式，禁止使用模糊描述（如“系统挂了”“网络有问题”）。

• 正例：【用户中心】登录接口 5xx 错误率突增 30%
• 反例：登录报错（缺少系统名、缺少量化指标）
• 正例：【消息队列】消费延迟堆积至 10 万条
• 反例：消息太慢（无具体数值、无系统边界）

标题字段在元数据模型中承担双重角色：既是人工阅读的第一入口，也是自动化聚类算法的文本特征来源。因此，标题中应包含 系统名、故障类型、量化指标 三个要素。

4.3 优先级字段：P0–P3 分级模型

优先级决定了故障响应节奏与升级路径。我们采用四阶分级模型，每个级别对应明确的 SLA 指标：

4.4 影响范围字段：结构化 JSON 描述

影响范围是故障排查与资源调度的重要依据。我们要求使用 结构化 JSON 存储，而非自由文本。最小必填字段包括：

{
  "affected_users": 1200,          // 受影响用户数（整数）
  "affected_modules": ["下单", "支付", "退款"],  // 受影响功能模块列表
  "duration_min": 18,              // 已持续时长（分钟）
  "business_impact": "订单支付成功率下降至 60%", // 业务影响描述
  "region": "cn-east-2"            // 受影响区域（可选）
}

结构化影响范围带来的三个直接收益：

• 自动化聚合：运维平台可实时计算“当前所有 P0/P1 故障累计影响用户数”。
• 资源调度：根据 affected_modules 自动拉起对应系统的备用实例或限流策略。
• 事后分析：按 duration_min 统计 MTTR（平均修复时间），识别瓶颈环节。

4.5 关联系统字段：CMDB 标准名称绑定

关联系统字段是传递单与 CMDB（配置管理数据库）之间的桥梁。每个传递单必须关联至少一个系统，且系统名称必须使用 CMDB 中注册的标准名称，禁止使用别名或 IP 地址。

关联系统字段在故障排查中的核心价值在于 拓扑推导：通过传递单中关联的系统列表，自动在 CMDB 中查询系统间的依赖关系，生成可能的故障传播路径。这是后续章节“审查意见驱动的根因分析”的数据基础。

4.6 元数据字段关系图

下图展示四个核心字段在传递单生命周期中的协作关系：标题与优先级用于快速筛选与排序；影响范围驱动资源调度；关联系统触发拓扑分析。三者共同构成故障排查的“元数据三角”。

4.7 元数据字段的审查意见驱动逻辑

在审查意见驱动的故障排查框架中，元数据字段不仅是静态描述，更是 审查意见的触发条件。例如：

• 标题缺失系统名：审查引擎自动生成“请补充【系统名称】”的审查意见，并阻止传递单进入处理队列。
• 优先级与影响范围不匹配：若影响范围显示“影响用户 5 人”但优先级标记为 P0，审查引擎发出“优先级疑似过高，请确认”的提示。
• 关联系统不在 CMDB 中：审查引擎自动查询 CMDB，若系统名称不存在，则生成“关联系统未注册，请先完成 CMDB 录入”的阻断意见。

4.8 元数据字段的版本管理

传递单元数据模型并非一成不变。随着业务演进，可能需要在影响范围中增加“影响客户等级”字段，或在关联系统中增加“依赖中间件”字段。我们建议采用 语义化版本 管理元数据模型：

版本管理确保历史传递单的可追溯性，同时为自动化审查引擎提供字段校验的版本依据。审查引擎根据传递单的元数据版本号，选择对应的校验规则集。

4.9 小结