消息通知映射表把业务事件翻译成通知内容与投递方式，设计的关键是让每条通知都能追溯到具体事件字段和接收对象。本文给出可直接建表的字段清单、五步建表流程、角色分工、一条完整填写示例和上线前检查项，适合负责企业应用集成的研发与平台人员从零建立并维护这张表。
要点总览（TL;DR）
- 映射表一行对应“某事件在某种条件下，向某类对象，通过某渠道，发送某条内容”，字段分四组：事件标识与来源、接收对象与角色、渠道模板与触发条件、去重升级与失效。
- 建表按五步推进：盘点事件并编号、确定接收角色与渠道、编写模板与变量占位、设定触发去重与升级条件、样例回放与修订，每步都有明确产物。
- 业务方负责事件语义与接收对象，集成或平台方负责字段映射与渠道接入，表所有者统筹变更评审，变更按影响范围分级确认。
- 上线前用四项检查判断可用性：事件覆盖完整性、字段与变量可解析、接收对象无歧义、异常与兜底路径已定义，再做一次端到端回放。
映射表先定哪几列：一张表的核心字段
映射表的一行代表“某个事件在某种条件下，向某类对象，通过某个渠道，发送某条内容”。围绕这句话拆字段，可以分成四组：事件标识与来源、接收对象与角色、渠道模板与触发条件、去重升级与失效。字段先定全，后续填表才有稳定的结构；字段定得含糊，联调阶段就会反复返工。
建表时建议把“取值来源”一并写进字段说明，明确这个值是人工填写、从事件报文读取，还是由平台配置生成。这样在评审时能快速判断哪些字段依赖上游系统改造，哪些字段只需业务确认。
| 字段名 | 含义 | 取值来源 | 是否必填 |
|---|---|---|---|
| 规则ID | 每条映射记录的唯一编号，便于引用与变更追踪 | 人工按规则分配，如EVT-BUILD-001 | 必填 |
| 事件标识 | 业务事件的唯一编码，与来源系统的事件类型一一对应 | 来源系统事件定义或接口文档 | 必填 |
| 来源系统 | 产生该事件的应用或服务名称 | 系统清单 | 必填 |
| 事件描述 | 用一句话说明事件发生的业务含义 | 业务方确认 | 必填 |
| 接收对象 | 通知的最终接收人、角色或群组 | 组织架构、项目角色或订阅关系 | 必填 |
| 接收角色类型 | 区分个人、岗位角色、项目成员、值班组等类型 | 人工按组织约定选择 | 必填 |
| 投递渠道 | 站内信、邮件、即时消息、短信等通道 | 平台已接入的通道清单 | 必填 |
| 模板标识 | 该条通知使用的消息模板编号 | 模板库 | 必填 |
| 模板变量 | 模板中需要填充的字段，如事件名、对象名、时间、链接 | 事件报文字段与模板定义 | 必填 |
| 触发条件 | 事件满足什么条件才发送，如状态为失败、优先级为高 | 业务规则 | 必填 |
| 去重键 | 用于判断重复通知的字段组合，如事件标识加对象ID | 人工设计，需与事件字段对应 | 必填 |
| 去重窗口 | 同一去重键在多长时间内只发一次 | 业务方按事件频率确定 | 必填 |
| 升级条件 | 未确认或未处理时触发二次通知的条件与时限 | 业务方与值班制度 | 选填 |
| 升级对象 | 升级后追加或替换的接收对象 | 组织架构或值班表 | 选填 |
| 失效时间 | 该规则停止生效的日期或版本条件 | 变更计划 | 选填 |
| 规则状态 | 草稿、启用、停用，控制规则是否参与投递 | 维护人更新 | 必填 |
四组字段中，事件标识和接收对象是追溯的锚点：任何一条发出的通知，都应能通过规则ID反查到事件标识，并确认接收对象当时是否存在、是否匹配。去重与升级字段决定通知的“量”和“节奏”，缺失时容易出现同一故障刷屏，或关键告警无人跟进。
从事件到通知：建表的五步操作
字段确定后，按事件来源、接收对象、模板、规则条件、回放校验的顺序推进。每一步都有明确产物，前一步的产物是后一步的输入，避免边填边改导致结构混乱。
第一步：盘点事件来源并编号
输入是各业务系统的接口文档、事件清单和现有告警配置。动作是逐个系统列出会产生通知的事件，按“来源系统缩写加事件序号”统一编号，并记录事件描述和关键字段。输出是一份事件清单，完成标志是每个事件都有唯一标识，且能对应到来源系统中的具体事件类型。这一步要特别留意同名不同义的事件，例如两个系统都叫“审批完成”，业务含义可能完全不同，编号时必须分开。
第二步：确定接收角色与渠道
输入是事件清单和组织角色信息。动作是为每个事件确定“谁需要知道”，优先用角色而非具体人名，再为角色选择渠道：需要即时响应的走即时消息，需要留档的走邮件，需要长期跟踪的走站内信。输出是事件与接收角色、渠道的对应关系。完成标志是每个事件至少有一个接收角色，且角色在组织中有明确成员来源。用角色而不是个人，可以避免人员变动后映射表失效。
第三步：编写模板与变量占位
输入是事件清单和已确定的渠道。动作是为每类通知编写模板，正文中用占位符标出变量，如事件名称、影响对象、发生时间、处理入口。输出是模板库和变量清单。完成标志是模板中的每个变量都能在事件报文中找到对应字段，且变量为空时有默认展示方式。变量对不上是联调阶段最常见的问题，这一步就要逐项核对。
第四步：设定触发、去重与升级条件
输入是事件字段和业务处理时限要求。动作是写明触发条件，例如仅在状态为失败时发送；确定去重键和去重窗口，例如同一构建任务十分钟内只提醒一次；对需要跟进的告警设置升级条件和升级对象。输出是每条规则的完整条件配置。完成标志是任意一条规则都能回答“什么情况下发、多久内不重复发、没人处理时发给谁”。
第五步：样例回放与修订
输入是已填写的映射表和若干真实或构造的样例事件。动作是逐条模拟事件进入系统后的匹配、渲染和投递过程，检查是否命中预期规则、变量是否正确填充、接收对象是否收到。输出是回放记录和修订后的映射表。完成标志是所有样例事件的结果与预期一致，偏差项已修正或登记为待确认。回放阶段发现的规则冲突，应回到第四步调整，而不是在投递环节临时打补丁。
映射表建好后需要随事件和工作项状态持续维护。在ONES中，可以把映射表作为项目文档承载，将每条规则关联到对应的工作项类型或状态变更，规则变更走文档版本与评审记录，使“事件定义—规则配置—变更历史”在同一处可查，减少表与系统实际配置脱节的情况。
谁维护这张表：角色分工与交付物
映射表跨越业务语义和技术配置，单一角色难以独立维护。常见做法是业务方对“发什么、发给谁”负责，集成或平台方对“怎么发、字段怎么取”负责，并指定一名表所有者统筹变更。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 业务方 | 确认事件业务含义、触发条件的业务口径、接收角色与升级规则 | 事件描述、接收角色清单、触发与升级条件确认记录 |
| 集成或平台方 | 负责事件字段与模板变量的映射、渠道接入、去重键的技术实现 | 字段映射说明、模板与变量清单、渠道配置记录 |
| 表所有者 | 维护映射表整体结构，汇总变更，组织评审，控制规则状态 | 映射表主版本、变更记录、评审结论 |
| 值班或运维代表 | 从接收侧反馈通知是否准确、是否过多或遗漏 | 通知效果反馈、升级路径调整建议 |
变更评审建议按影响范围分级：新增事件或调整接收角色，需业务方与表所有者确认；修改去重窗口或升级时限，需值班代表参与；仅修正模板文案，可由表所有者直接更新并记录。评审方式不必复杂，关键是每次变更都留下“谁提出、谁确认、何时生效”的记录，避免映射表与实际投递行为不一致。
填表示例：一条构建失败通知的完整映射
下面以“构建失败通知”为例，演示一条记录如何填写。示例为构造情景，用于说明字段填法，不代表任何具体产品的实际配置。
| 字段 | 填写内容 |
|---|---|
| 规则ID | EVT-BUILD-001 |
| 事件标识 | BUILD_FAILED |
| 来源系统 | 持续集成服务 |
| 事件描述 | 某代码分支的构建任务执行失败 |
| 接收对象 | 该代码仓库的提交人与项目构建值班组 |
| 接收角色类型 | 项目成员、值班组 |
| 投递渠道 | 即时消息（提交人）、站内信（值班组） |
| 模板标识 | TPL-BUILD-FAIL |
| 模板变量 | 项目名称、分支名、构建编号、失败阶段、失败日志链接、提交人 |
| 触发条件 | 构建状态为失败，且非手动取消 |
| 去重键 | 项目ID + 分支名 + 构建编号 |
| 去重窗口 | 30分钟 |
| 升级条件 | 失败后60分钟未标记处理，追加通知值班组负责人 |
| 升级对象 | 值班组负责人 |
| 失效时间 | 随构建流程版本升级时复核 |
| 规则状态 | 启用 |
逐字段看几个关键点。接收对象写成“提交人加值班组”，而不是固定人名，人员变动时规则仍然有效。模板变量中的“失败日志链接”必须来自事件报文字段，若该字段缺失，模板渲染会出现空值，因此要在第三步核对变量来源。去重键选择“项目加分支加构建编号”，是因为同一分支可能连续多次构建失败，按构建编号区分可以保证每次失败都被记录，同时避免同一构建因重试机制重复触发通知。升级条件写成“60分钟未标记处理”，把升级判断落到一个可观测的状态上，而不是依赖人工判断“是否重要”。
扩展到其他事件时，可以沿用这个结构：先确认事件标识与来源，再确定接收角色和渠道，然后核对模板变量，最后补齐去重与升级条件。不同事件的差异主要体现在触发条件和去重窗口上，字段结构保持一致即可。
上线前检查：映射表是否可用的判断项
映射表能否进入联调和运行，可以用四项检查判断。每项都给出通过标准，检查结果记录在表上，未通过项明确责任人和修正时间。
| 检查项 | 检查内容 | 通过标准 |
|---|---|---|
| 事件覆盖完整性 | 对照事件清单逐条核对映射表，确认每个需要通知的事件都有对应规则 | 事件清单中的事件全部有规则覆盖，或明确标注“不通知”并说明理由 |
| 字段与变量可解析 | 检查模板中每个变量是否能在事件报文中取到值，空值时是否有默认展示 | 所有变量均有来源字段，空值场景已定义展示方式 |
| 接收对象无歧义 | 核对每个接收角色是否有明确的成员来源，是否存在一人多角色导致重复接收 | 每个接收对象可解析到具体人员或群组，重复接收已通过去重或角色合并处理 |
| 异常与兜底路径已定义 | 检查事件字段缺失、渠道不可用、接收对象为空时的处理方式 | 每类异常都有明确处理动作，如转备用渠道、记录失败日志并通知表所有者 |
四项检查之外，建议再做一次端到端回放：选取覆盖不同渠道和不同触发条件的样例事件，完整走一遍匹配、渲染、投递和升级流程，确认结果与映射表记录一致。回放通过后，映射表可以进入试运行；试运行期间收集接收侧反馈，重点看通知是否过多、是否有该收未收的情况，再据此调整去重窗口和接收角色。试运行稳定后，将规则状态统一置为启用，并把映射表纳入变更管理，后续事件新增或规则调整都按评审流程更新。
常见问题
映射表里的接收对象写具体人名还是写角色？
优先写角色或群组，例如“项目构建值班组”“该仓库提交人”，再在组织侧维护角色成员来源。写具体人名在人员变动后容易失效，而且同一人承担多个角色时难以判断重复通知的来源。只有在接收对象是固定岗位且短期不会变动时，才考虑直接写个人，并在变更记录中注明复核时间。
去重窗口设多长比较合适？
去重窗口取决于事件的产生频率和处理节奏，没有统一数值。判断方法是看同一去重键在正常情况下的重复频率：构建失败这类可能连续触发的事件，窗口可覆盖一次重试周期；低频的审批类事件，窗口可以很短甚至不去重。窗口设得过长会漏掉真实的新故障，过短则同一问题反复提醒。建议先按事件频率给出初值，试运行期间根据接收侧反馈调整，并把调整记录在映射表变更历史中。
事件字段缺失导致模板变量为空时怎么处理？
在第三步编写模板时就要为每个变量定义空值展示方式，例如显示“未提供”或省略该句，避免通知出现空白或报错。同时在第五步回放中专门构造字段缺失的样例，确认渲染结果可读。若某个变量是判断事件性质的关键信息，缺失时应视为异常路径，按兜底规则处理，例如转备用渠道发送并记录失败日志通知表所有者，而不是照常发出不完整的通知。
映射表和系统里的实际通知配置如何保持一致？
把映射表当作配置的唯一说明来源，任何规则调整先改表再改系统配置，变更记录写明提出人、确认人和生效时间。规则状态字段用于标记草稿、启用、停用，避免表里写着启用而系统已停用的情况。定期用样例事件回放核对表与系统行为是否一致，发现偏差时回到映射表定位是字段映射问题还是条件配置问题，再统一修正。
新增一个事件时，最少要改映射表的哪些部分？
至少新增一条规则记录，补齐事件标识、来源系统、事件描述、接收对象与角色类型、投递渠道、模板标识与变量、触发条件、去重键与窗口、规则状态这些必填字段。如果新事件可以复用已有模板，只需在变量清单中确认字段能对上；如果需要新模板，则同步更新模板库。新增事件属于影响范围较大的变更，建议由业务方确认事件语义和接收对象，表所有者确认结构一致性后再置为启用。
