跨应用通知遗漏往往不是某一个应用单独出了问题，而是事件从产生到送达之间某一段连接链路断了。处理时先记录哪些应用、事件、接收人和时间段受影响，再沿“事件产生→触发规则→消息投递→接收端展示”逐段取证，定位后分场景修复，最后用对照事件验证恢复并补上告警与巡检。
要点总览（TL;DR）
- 先按应用对、事件类型、接收人、时间段记录遗漏现象，区分全部遗漏与部分遗漏、稳定复现与偶发，再与近期配置、版本、权限变更对齐。
- 排查沿“事件产生→触发规则→消息投递→接收端展示”从上游往下游推进，用业务记录、规则配置比对、投递日志和对照发送逐段取证。
- 处置按根因分场景：规则错误先备份再逐项修正，凭证失效按最小权限重新授权，投递失败在原因消除后小范围补发，接收端恢复成员与权限后用测试消息确认。
- 修复后用对照事件做端到端验证，对遗漏期间的关键通知评估补发并由接收人确认，同时建立投递失败告警、失败队列巡检和定期连通性检查。
- 把连接配置、凭证有效期和订阅变更纳入变更记录，与通知异常时间线对照，下次遗漏时能快速定位到最近的改动。
先界定遗漏范围：哪些通知没到、影响到谁
“通知没到”是一句笼统描述，直接开始查配置容易在错误的方向上花时间。第一步应把现象收敛成一份可核对的对象清单，让后续排查有明确的比对基准。记录时按四个维度展开：应用对（从哪个系统发往哪个系统）、事件类型（如审批通过、工单指派、告警触发）、接收人（个人、群组或机器人）、时间段（首次发现到最近一次）。
在范围记录中，还要区分几种容易混淆的形态。全部遗漏指某类事件对所有接收人都不达，通常指向连接或规则层面的整体故障；部分遗漏指同一事件只有部分人收到，更可能出在接收端权限、成员变更或终端差异。稳定复现说明链路中存在确定性断点，偶发遗漏则要关注限流、重试耗尽、网络抖动等间歇性因素。若只有特定终端或特定群组收不到，排查重点应放在该终端或群组的订阅状态与展示设置上。
时间线同样关键。记录首次发现时间，并回溯此前是否发生过配置修改、应用版本升级、权限调整或成员变动。很多遗漏在变更后立即出现，只是发现得晚。下面这张表可以作为现场记录模板：
| 记录项 | 填写内容 | 用途 |
|---|---|---|
| 应用对 | 来源系统 → 目标系统 | 锁定连接链路范围 |
| 事件类型 | 具体业务事件名称 | 判断是单类事件还是全部事件 |
| 接收人 | 个人/群组/机器人，是否全部受影响 | 区分全局故障与局部过滤 |
| 时间段 | 首次发现时间、最近一次正常接收时间 | 与变更记录对齐 |
| 复现情况 | 稳定复现/偶发，触发条件 | 决定取证方式 |
| 近期变更 | 配置、版本、权限、成员变动 | 缩小嫌疑范围 |
这份记录的价值在于：当后续取证得出“规则未命中”或“投递失败”的结论时，可以用它反查影响面，确认修复是否覆盖了全部受影响对象，也便于判断补发范围。
沿连接链路列原因假设并逐项取证
跨应用通知的链路可以拆成四段：事件源产生事件、触发规则判断是否发送、投递通道完成送达、接收端展示给用户。遗漏可能发生在任何一段，排查时应先列假设再找证据，用证据排除，避免凭经验直接下结论。建议的排查顺序是从上游往下游推进，因为上游不产生事件时，下游的一切检查都没有意义。
事件源侧：事件是否真实产生
先确认业务动作是否真的触发了事件。常见情况包括：业务操作实际未成功、事件被去重逻辑合并、批量操作只产生一条汇总事件。验证方式是查业务系统的操作记录或事件日志，确认对应时间点存在事件产生记录。若事件源没有记录，问题不在通知链路，应回到业务侧排查。
触发规则侧：订阅与过滤是否命中
事件产生了但没发出去，常见原因是订阅范围不包含该事件类型、过滤条件把目标事件排除、字段映射缺失导致规则判断失败。取证时对照规则配置与事件的实际字段值，确认条件表达式的结果。特别注意规则修改后是否生效、是否存在多条规则互相覆盖。
投递侧：连接与通道是否可用
投递失败的典型原因有：连接凭证过期、接口限流、重试次数耗尽、回调地址不可达、网络策略阻断。取证依据是投递日志中的状态码、错误信息和重试记录。若日志显示请求已发出但返回失败，问题在通道；若根本没有发出记录，应回到规则侧。
接收侧：消息是否被过滤或隐藏
消息已送达但用户看不到，通常与机器人被移出会话、接收人权限变更、消息被折叠或处于免打扰时段有关。验证方式是检查接收端的成员列表、权限配置和消息展示设置，并用同一接收人做一次对照发送。
把上述假设整理成对照表，逐项标注“已排除”或“待确认”，可以避免排查过程中反复走回头路：
| 链路环节 | 原因假设 | 验证证据 | 结论 |
|---|---|---|---|
| 事件源 | 业务事件未产生或被合并 | 业务操作记录、事件日志 | 已排除/待确认 |
| 触发规则 | 订阅范围或过滤条件未命中 | 规则配置与事件字段比对 | 已排除/待确认 |
| 投递 | 凭证过期、限流、重试耗尽 | 投递日志状态码与错误信息 | 已排除/待确认 |
| 接收端 | 机器人移除、权限变更、消息折叠 | 成员列表、权限配置、对照发送 | 已排除/待确认 |
排查中有一个实用技巧：选一条已知会触发通知的对照事件，在记录时间点的同时完整走一遍链路，观察每一段是否留下记录。哪一段没有记录，断点就在那一段之前。
按定位结果分场景处置
取证结论不同，处置动作和风险边界也不同。以下按常见根因分别说明操作顺序、前置条件和回滚点。涉及修改生产配置或批量补发的操作，建议先在测试环境或小范围对象上验证，确认效果后再扩大范围。
规则与订阅配置错误
修正前先导出或截图保存当前规则配置，作为回滚依据。按“订阅范围→过滤条件→字段映射”的顺序逐项修正，每改一项就用对照事件验证一次，避免一次改动过多导致无法判断哪项生效。修正完成后记录变更内容和时间，便于后续追溯。
凭证与授权失效
重新授权时确认使用最小权限，只授予通知投递所需的接口范围。授权完成后立即做一次连通性测试，确认凭证可用。若涉及多个应用连接，逐一检查各自的凭证有效期，避免同类问题在其他连接上重复出现。
投递失败后的重试与补发
先确认失败原因已消除，再执行补发。补发前明确补发范围和时间窗口，避免把已成功送达的通知重复发出。补发可能造成接收人收到重复消息，对审批、告警类通知尤其要提前告知相关接收人。批量重放应先选少量对象验证，确认无重复、无遗漏后再扩大。
接收端权限与成员变更
恢复机器人入群或接收人权限后，用一条测试消息确认展示正常。若涉及群组成员调整，核对新成员是否继承了通知订阅，避免修复了旧问题又产生新的遗漏。
处置过程中，把每个场景的根因、操作、验证结果和回滚点记录在同一处，能让多人协作排查时信息不散落。ONES 的工作项和文档可以承载这类记录：把遗漏事件登记为工作项，关联对应的连接配置变更记录，处置完成后附上验证结果，后续复盘时可以直接按时间线回看。
验证恢复并防止再次遗漏
修复动作完成不等于链路恢复。验证应覆盖端到端：构造一条对照事件，确认事件产生、规则命中、投递成功、接收端展示四个环节都有记录，并核对发送记录与接收结果一致。只验证其中一段，可能漏掉尚未暴露的断点。
对遗漏期间的关键通知，需要评估是否补发。补发后由接收人人工确认收到，形成闭环。对于时效性已过的通知，补发意义有限，应改为人工告知或纳入日报汇总，避免制造大量过期消息。
预防机制可以从三个方向建立。第一，投递失败告警：对连续失败、重试耗尽、凭证临近过期设置告警，让问题在用户反馈之前被发现。第二，失败队列巡检：定期查看待重试和失败消息的积压情况，设定积压阈值。第三，定期连通性检查：对关键应用连接做周期性测试发送，确认链路持续可用。
变更管理同样重要。连接配置、凭证有效期、订阅规则的每次修改都应留下记录，并与通知异常的时间线对照。把这类变更纳入统一的变更记录，配合工作项跟踪待办与责任人，可以在下次出现遗漏时快速定位到最近的改动。ONES 的变更记录与工作项关联能力适合承载这一环节，具体使用方式以团队现有的配置为准。
最后，建议把本次排查的范围记录、原因对照表、处置步骤和验证结果整理成一份复盘文档，沉淀为同类问题的检查清单。下次遇到跨应用通知遗漏时，可以从清单直接进入取证，缩短定位时间。
常见问题
补发遗漏通知时，怎么避免接收人收到重复消息？
补发前先明确补发范围和时间窗口，只覆盖确认未送达的事件，把已成功送达的记录排除在外。批量补发先选少量对象验证，确认没有重复后再扩大范围。审批、告警这类通知对重复尤其敏感，补发前告知相关接收人，补发后由接收人确认收到，形成闭环。
偶发性的通知遗漏，排查方式和稳定复现的情况有什么不同？
稳定复现说明链路中存在确定性断点，按四段链路逐段取证通常能直接找到没有记录的那一段。偶发遗漏要关注限流、重试耗尽、网络抖动这类间歇性因素，单次日志可能看不出问题，需要结合投递日志中的失败状态码、重试记录和发生时间做趋势比对，必要时拉长观察窗口，用多次对照事件累积证据。
只有部分接收人收不到通知，应该先查哪里？
部分接收人收不到，问题更可能出在接收端而不是连接通道。先检查这些接收人所在群组的成员列表、机器人是否仍在会话中、权限是否发生过变更，以及消息是否被折叠或处于免打扰时段。用同一接收人做一次对照发送，能快速区分是订阅状态问题还是展示设置问题。
修复后怎么确认通知链路真的恢复了？
构造一条对照事件完整走一遍链路，确认事件产生、规则命中、投递成功、接收端展示四个环节都留下记录，并核对发送记录与接收结果一致。只验证其中一段，可能漏掉尚未暴露的断点。对遗漏期间的关键通知，补发后由接收人人工确认，验证才算完成。
怎么让下一次遗漏在用户反馈之前就被发现？
可以从三个方向建立发现机制：对连续投递失败、重试耗尽、凭证临近过期设置告警；定期巡检失败队列的积压情况并设定阈值；对关键应用连接做周期性测试发送。同时把连接配置、凭证有效期和订阅规则的每次修改记入变更记录，出现异常时先与最近变更对照。
