研发通知重复发送，通常不是单一环节出错，而是消息来源、集成投递、通知规则或接收端去重中的某一层出现了重复。排查时建议按“来源触发→集成投递→规则叠加→接收端去重”的顺序逐层验证，每层先拿到可观察证据再下结论。本文给出一套从症状记录、原因验证到处置修复和复发预防的完整路径，适合研发、平台运维或负责消息集成的同学在故障现场直接对照使用。
要点总览（TL;DR）
- 先统一重复判定口径：同一业务事件在设定时间窗内多次到达同一接收方，并按即时消息、邮件、Webhook、工单、流水线通知分渠道统计。
- 排查顺序固定为“来源触发→集成投递→规则叠加→接收端去重”，每层先取可观察证据，再决定是否修改配置。
- 关键证据是对比数量：来源事件数与接收方实收数一致说明投递正常，实收明显偏多则指向订阅重复、Webhook 重试或消费端缺幂等。
- 处置前备份规则与集成配置，分批灰度并保留回滚点；规则合并要确认覆盖人群，避免修好重复却造成漏发。
- 验证同时看重复率、同一事件到达次数和漏发数量，观察期至少覆盖一个完整业务周期，并把去重键与上线验收纳入接入规范。
重复通知长什么样：先界定症状与影响范围
“重复发送”需要先统一判定口径，否则不同人统计出的数字无法对比。建议把重复定义为：同一业务事件在设定时间窗内多次到达同一接收方。时间窗可以按渠道设定，即时消息常用几分钟，邮件可以放宽到十几分钟，Webhook 回调和工单通知则按业务对时效的敏感度确定。口径确定后，再按渠道分别统计，避免把即时消息的重复和邮件的重复混在一个数字里。
研发场景中常见的通知渠道包括即时消息群机器人、邮件、Webhook 回调、工单系统通知以及流水线构建通知。不同渠道的重复表现不一样：即时消息表现为同一内容连续刷屏，邮件表现为同一主题多封到达，Webhook 表现为接收方收到多次相同回调，工单和流水线通知则可能表现为同一工作项或同一次构建产生多条记录。排查前先把渠道拆开，后续定位会快很多。
影响范围决定了排查的起点。需要确认重复是集中在单个项目还是覆盖全组织，是单一渠道还是多渠道同时出现，以及是否伴随漏发。单项目单渠道的重复，优先怀疑该项目内的规则配置或该渠道的连接；全组织多渠道同时重复，则更可能指向来源侧的事件重复触发或集成侧的投递机制。伴随漏发的场景要格外注意，重复和漏发可能来自同一个原因，比如重试策略把失败消息补发成了重复消息。
建议在动手排查前先填一张症状记录表，把现象固定下来：
| 记录项 | 填写内容 | 用途 |
|---|---|---|
| 渠道 | 即时消息 / 邮件 / Webhook / 工单 / 流水线通知 | 分渠道统计，避免口径混用 |
| 接收方 | 具体群、邮箱、回调地址或人员范围 | 判断是单点问题还是面状问题 |
| 重复次数 | 同一事件到达次数，取典型样本 | 区分偶发重试与稳定重复 |
| 时间窗 | 首次出现时间、重复集中时段 | 与近期变更做时间比对 |
| 近期变更 | 集成上线、规则调整、人员变动、流水线配置修改 | 缩小原因假设范围 |
记录首次出现时间和近期变更是很关键的一步。多数重复通知都能对应到某个时间点附近的一次配置变更、一次集成上线或一次人员交接。把变更清单和首次出现时间放在一起看，往往能直接圈定需要重点验证的环节。
重复从哪来：原因假设与排除证据
研发通知重复发送的常见原因可以归为四层：来源侧重复触发、集成侧重复投递、规则侧叠加命中、接收侧缺少去重。这四层是假设，不是结论。排查的价值在于为每个假设找到可观察的证据，用证据排除或确认，而不是凭经验直接改配置。
| 原因假设 | 典型表现 | 验证方法与判定证据 |
|---|---|---|
| 来源侧重复触发 | 定时任务重跑、流水线重试、状态回退后再前进 | 查任务执行记录与流水线重试日志，确认同一业务事件是否被多次产生；若事件本身出现多次，问题在来源 |
| 集成侧重复投递 | 事件订阅重复、Webhook 重试、消息队列至少一次投递 | 对比来源事件数量与接收方实际收到数量；来源只发一次而接收多次，指向投递环节 |
| 规则侧叠加 | 多条通知规则命中同一事件，转发与抄送规则叠加 | 列出该事件命中的全部规则，检查是否存在条件重叠；关闭其中一条后重复消失即可确认 |
| 接收侧缺去重 | 无消息唯一键、无幂等处理 | 检查接收端是否按事件 ID 做幂等；同一 ID 多次到达仍被处理，说明去重缺失 |
排查顺序建议固定为“来源→集成→规则→接收”。先确认来源侧是否只产生了一次事件，这是最基础的一层证据。如果来源记录显示同一业务动作被执行了多次，比如流水线因失败重试而重复触发通知，那么后续环节都是无辜的，直接回到来源侧处理即可。
来源侧排除后，进入集成侧验证。核心证据是对比数量：来源产生的事件数与接收方实际收到的消息数。两者一致说明投递正常，问题在规则或接收端；接收数明显大于来源数，则要检查事件订阅是否被重复创建、Webhook 是否配置了激进的重试策略、消息队列是否采用至少一次投递而消费端未做幂等。这一层的证据通常可以从集成连接的配置和投递日志中获得。
规则侧叠加在研发团队中很常见。一个工作项状态变更，可能同时命中“状态变更通知”“指派给某人通知”“项目周报汇总”等多条规则，每条规则各自发送一次，接收方看到的就是重复。验证方法是把该事件命中的规则逐条列出，观察触发条件是否有交集。转发与抄送规则也容易叠加，比如一条规则把消息转发到群，另一条规则又把同一消息抄送给群成员。
接收侧缺去重是最容易被忽略的一层。即使上游只发一次，网络重试或消费端重复拉取也可能造成多次处理。判断依据是接收端是否以事件唯一标识作为幂等键。如果接收方对同一事件 ID 的多次到达都执行了完整处理流程，那么无论上游如何优化，重复都会在末端显现。
按排查结果处置：分场景的修复步骤
处置动作要和已确认的原因对应，避免在未定位的情况下大面积改配置。下面按四层原因分别给出修复方向，每项操作前都应先备份现有规则与集成配置，变更分批灰度，并保留可回滚的版本记录。
来源侧重复触发。先合并重复的触发条件，把同一业务动作的多个触发入口收敛为一个。对流水线重试，限制自动重试次数，并明确重试是否应重新发送通知；如果重试只是恢复构建而不代表新的业务事件，通知应在首次触发时发送一次。状态回退再前进导致的重复，需要修正状态流转逻辑，让通知只在进入目标状态时触发，而不是每次状态变化都触发。操作风险在于修改触发条件可能造成漏发，建议先在测试项目验证，再推广到生产项目。
集成侧重复投递。检查事件订阅是否存在重复创建，同一事件被多个订阅同时消费时应合并订阅。Webhook 的重试策略要核对：重试次数和间隔是否过于激进，重试是否携带同一事件标识。消息队列采用至少一次投递时，消费端必须按消息唯一标识做幂等处理，重复到达的消息直接丢弃或跳过。这一层的操作风险在于调整重试策略可能影响失败消息的补偿能力，变更后要观察一段时间内失败消息的补发情况。
规则侧叠加。把命中同一事件的多条通知规则列出来，合并条件重叠的规则，或者为规则增加互斥条件。转发与抄送规则要明确触发边界：哪些事件需要转发、哪些只需要抄送、两者是否允许同时命中。合并规则时注意保留原有的覆盖人群，避免合并后部分接收方收不到通知。建议先在单个项目内调整，确认通知覆盖完整后再推广。
接收侧缺去重。在消费端引入按事件 ID 去重的逻辑，并设置短时窗口抑制，同一事件在窗口内重复到达时只处理一次。去重键应选择业务上唯一且稳定的标识，避免使用时间戳这类每次都不同的字段。这一层改动通常涉及接收方系统，需要与对接团队约定去重键的格式和窗口长度。
所有处置动作都应遵循同一套操作纪律：变更前备份规则配置和集成连接参数，变更按项目或渠道分批灰度，每批变更后保留回滚点。对于影响面较大的规则合并，建议设置停止条件，比如灰度期间重复率未下降或漏发明显增加，就暂停推广并回滚到上一版本。
在通知规则和集成连接的管理上，ONES 的工作项通知与集成配置可以作为承载这些动作的平台：规则调整、订阅核对、变更记录都在同一处留痕，便于排查时回溯近期变更。具体到多条规则命中同一事件时是否支持合并或抑制、Webhook 是否提供消息唯一标识与重试策略配置，需要在实际环境中核验，本文不对此作确定判断。
怎么确认修好了：验证指标与复发预防
修复后的确认不能只看“暂时没再重复”，而要用指标和观察期来验证。建议同时观察三类指标：单位时间重复率、同一事件到达次数、漏发数量。重复率下降是修复生效的直接信号；同一事件到达次数应稳定在 1 次；漏发数量用于确认修复没有以牺牲通知覆盖为代价。三类指标要放在同一时间窗内对比修复前后，避免只看重复而忽略漏发。
| 验证指标 | 观察方式 | 通过标准 |
|---|---|---|
| 单位时间重复率 | 按渠道统计同一事件多次到达的比例 | 较修复前明显下降并趋于稳定 |
| 同一事件到达次数 | 抽取典型事件跟踪完整链路 | 稳定为 1 次，重试场景下不超过约定次数 |
| 漏发数量 | 对比应发事件数与实发事件数 | 与修复前持平或更少 |
| 失败消息补发情况 | 观察集成重试策略调整后的补偿效果 | 失败消息仍能被补发，未产生新的重复 |
观察期建议至少覆盖一个完整的业务周期。研发团队的业务周期可以按迭代或发布节奏确定，比如一个迭代周期内包含需求流转、开发、测试和发布各阶段，只有覆盖完整周期，才能确认各类事件的通知都恢复正常。灰度范围从小到大推进：先在单个项目或单个渠道验证，指标达标后再扩到全组织。
复发预防要把检查动作固化到日常流程中。通知规则变更前做评审，确认新规则与现有规则的触发条件是否重叠；集成连接建立定期健康检查，核对订阅数量、重试配置和消费端幂等状态；把去重键纳入接入规范，要求所有新接入的通知渠道在消费端按事件 ID 去重。重复通知还应纳入集成上线的验收项，上线前用小流量验证同一事件只到达一次，验收通过后再放量。
把这些检查项整理成一张可核验的清单，每次集成变更或规则调整后逐项确认，能显著降低重复通知再次出现的概率：规则变更是否经过评审、订阅是否去重、重试策略是否明确、消费端是否有幂等键、上线前是否做过小流量验证、观察期内重复率和漏发是否都在预期范围。清单本身不需要复杂，关键是每次变更都执行并留下记录，这样下一次出现重复时，排查起点会更清晰。
常见问题
重复通知只出现在一个项目的一个群里，应该先查哪里？
单项目单渠道的重复，优先查该项目内的通知规则配置和该渠道的连接。把该事件命中的规则逐条列出，看触发条件是否有交集；再核对该群机器人或 Webhook 是否被重复创建。来源侧和集成侧可以顺带确认，但排查重心放在规则与渠道连接上，通常能更快定位。
来源只发了一次，接收方却收到多次，问题一定在接收端吗？
不一定。来源只发一次而接收多次，说明重复发生在投递或消费环节。需要继续区分：事件订阅是否被重复创建、Webhook 是否配置了激进重试、消息队列是否采用至少一次投递而消费端未做幂等。对比订阅数量与投递日志，可以判断重复是投递环节产生的，还是消费端重复处理造成的。
合并重叠的通知规则时，怎么避免合并后有人收不到通知？
合并前先记录每条规则覆盖的接收方范围，合并后逐项核对新规则的覆盖人群是否完整。建议先在单个项目内调整，用典型事件验证各类接收方都能收到通知，再推广到其他项目。灰度期间同时观察重复率和漏发数量，任一指标异常就回滚到上一版本。
去重键应该选什么字段，窗口设多长？
去重键应选择业务上唯一且稳定的标识，比如事件 ID 或业务单据编号，避免使用时间戳这类每次都不同的字段。窗口长度按渠道时效要求确定：即时消息可用几分钟，邮件可适当放宽。窗口过短起不到抑制作用，过长可能把合法的再次通知也挡掉，建议结合业务事件的实际频率设定并观察效果。
修复后观察多久才算确认恢复？
建议至少覆盖一个完整的业务周期。研发团队可以按迭代或发布节奏确定，确保需求流转、开发、测试、发布各阶段的通知都被观察到。观察期内同时看重复率、同一事件到达次数和漏发数量，三项都稳定后再从灰度范围扩到全组织。
