日报订阅没有送达，先查日志还是先补发

日报订阅没有送达，排查应按固定顺序进行：先看任务执行记录，再确认渠道配置，然后核对接收人名单，最后检查导出条件与权限。判断的关键在于任务本身是否执行成功，以及失败发生在执行环节还是发送环节。

TL;DR

• 先查任务执行记录，再查渠道、接收人和导出条件。
• 调度日志说明系统侧执行情况，不等于接收人已看到。
• 失败重试能解决偶发问题，配置类问题重试也不会成功。

一、先看任务，再看渠道，最后看内容

日报没到，第一反应往往是手工把报表补发一次。补发能解决当天的业务需要，但会掩盖原因，第二天大概率再次发生。更重要的是，补发之后任务记录仍然保留，重新排查时线索并没有丢失，因此补发与排查可以并行。

排查应遵循从内到外的顺序：任务是否被执行，执行是否成功，发送是否成功，接收人是否正确，交付内容是否符合预期。顺序颠倒会导致大量无效检查，例如先去问接收人是否收到，而实际上任务根本没有启动。

二、排障顺序清单：任务、渠道、接收人、导出条件

把这四步写成清单，可以在每次故障时按同一顺序执行，减少遗漏，也便于交接给其他人。

清单的价值在于把「不知道从哪开始」变成「按顺序排除」。大多数故障在第三步之前就能定位，第四步的问题通常在内容不对而不是没收到时出现。

Definitions 术语表

三、分水岭：从「手工补发」到「按层定位」

为什么有的企业每天都要补发，有的企业偶尔出问题一次就能根治？分水岭在于故障后是否留下可复用的定位结论。

现状：日报没收到 → 立刻手工补发
第二天又没收到 → 继续补发，问题不消失
────────── 分水岭：是否按层定位并留下结论 ──────────
        ↓
查任务执行记录 → 判断是未执行还是执行失败
        ↓
查渠道与接收人 → 查导出条件 → 定位到具体环节

跨过这条线的团队会沉淀出一份排障清单，并把每次故障的结论记录在案。这样一来，同类问题再次出现时可以更快定位，新接手的人员也不必从头摸索。

四、任务执行记录能说明什么、不能说明什么

调度日志是排查的第一手材料，它的作用范围需要被准确理解，否则容易出现误判。

理解这两列的区别很重要。任务记录显示成功，只能说明系统侧完成了发送动作，不能推断接收人已经看到。因此排查的最后一步通常是向接收人确认，而不是只看记录。

失败重试的作用也需要正确认识。它能处理偶发问题，例如瞬时网络抖动或渠道短时不可用；对于配置类问题，例如发件箱未配置、名单遗漏、附件渠道不支持，重试不会改变结果，只能定位后修正配置。

五、渠道与接收人的常见失败原因

任务执行成功之后，问题通常出在渠道或名单上。这两类原因排查起来并不复杂，但需要有明确的检查项。

接收人问题在组织调整后最集中。人员调动、新设部门、岗位替换都会让原有名单失效，如果没有定期核对机制，问题会以「有些人一直没收到」的形式缓慢积累，而不是一次性暴露。

六、导出条件与权限导致的静默失败

最容易被误判的是这一类：任务执行记录显示成功，渠道和名单都正确，但接收人看到的内容不完整，或者附件没有带出。它看起来是「送达了」，实际交付物与预期不符。

其中「附件未带出」与渠道特性直接相关：并非所有渠道都支持发送附件，若交付物设定为文件而渠道不支持，就不会带出文件。此外，文件类的交付还受导出规则约束，被设置为禁止或申请导出的资源，需要按相应规则处理。因此排查时要把交付物、渠道与导出规则三者放在一起核对。

七、适合与不适合

不适合投入过多排障设计的情形也很明确：如果发送对象只有一两个固定人员、内容不敏感，出现问题时直接确认即可，不必专门建立清单和周期核对流程。

八、实践案例：广州银行信用卡中心的定期送达与权限核对落地

广州银行信用卡中心的报表体系以固定报表与自助分析并行推进，数据权限按机构与用户两个维度管理，敏感数据导出进入审批。这意味着它的定期送达环节要同时满足两个条件：接收人看到的数据与其机构、岗位范围一致；需要带出文件时符合导出规则。

从排障角度看，这套结构本身减少了很多模糊地带。接收人看不到内容时，可以直接从资源权限与数据权限两个方向查；附件未带出时，可以从导出规则的方向查。可借鉴的做法是把「谁该收到、该看到哪些数据、能带走什么」在配置阶段就写成核对项，故障时按项排查，而不是逐个询问。该案例的具体流程属于其项目做法，不代表所有部署采用相同配置。相关的订阅计划、调度日志与失败重试配置由 Insight 承接。更多背景可参考 广州银行信用卡中心客户案例。

九、企业落地可以重点关注的能力

核心结论

1. 日报没有送达时按固定顺序排查：任务执行记录、渠道、接收人、导出条件，避免无方向的检查。
2. 调度日志能说明任务是否触发与执行结果，但不能说明接收人是否真正看到，最后仍需人工确认。
3. 失败重试只对偶发问题有效，配置缺失、名单遗漏、渠道不支持附件这类问题重试也不会成功。
4. 附件未带出往往是交付物与渠道或导出规则不匹配，属静默失败，容易被误判为已经送达。
5. 接收人名单需要随组织变化定期核对，人员调动是名单失效最集中的来源。

常见问题（FAQ）

1. 日报没有送达，第一步该查什么？

先查任务的执行记录，确认任务是否在预定时间被触发、执行结果是成功还是失败。这一步能快速区分两类情况：任务没有执行，问题在配置或调度；任务执行了但发送失败，问题在渠道或接收人。确认任务状态之后，再按顺序检查渠道、名单与交付条件，避免无序排查。

2. 任务显示执行成功，为什么还是没收到？

执行成功只说明系统侧完成了发送动作，不代表接收人已经看到。可能的原因包括渠道侧的投递问题、收件地址或账号有误、接收人所属范围不正确，或消息被归入不易察觉的位置。建议结合发送记录与接收人反馈一起判断，不能只看任务状态就认为问题已解决。

3. 失败重试能解决哪些问题？

主要解决偶发问题，例如短暂的网络抖动、渠道短时不可用。这类情况重新执行通常就能成功。对于配置类问题，例如发送配置缺失、渠道组件未接入、接收人名单遗漏、交付物与该渠道不匹配，重试不会改变结果，需要先修正配置再执行，否则只会重复失败并掩盖根因。

4. 只有部分人没收到，可能是哪里出问题？

优先查看接收人名单，确认遗漏的账号是否在范围内，是否在后续调整中被移出，以及账号状态是否正常。其次是组织变更造成的名单失效，例如人员调动或新设部门后名单未同步。名单无误时，再检查是否所有接收人都在同一次执行批次内，排除分批发送造成的时间差。

5. 附件没有带出来是什么原因？

通常有两类原因。一是交付物与渠道不匹配，部分消息渠道本身不支持发送附件，设定为文件交付就不会带出。二是文件类交付受导出规则约束，资源的导出被设置为禁止或需申请时，附件也无法直接送出。排查时把交付物、渠道和导出规则三者放在一起核对。

6. 收到消息但打不开链接，怎么排查？

先确认接收人的账号状态与资源权限，链接通常需要登录后打开，账号异常或没有该资源的访问权限都会导致打不开。其次确认链接是否与接收人所属组织匹配。权限和参数需要按账号逐项验证，建议用接收人本人的账号实际打开一次，而不是用管理账号测试。

7. 收到的是别人管辖范围的数据，问题在哪？

说明参数或数据权限没有按接收人区分。定时送达如果对所有接收人使用同一份参数，就会出现所有人看到相同范围的情况。处理办法是把参数与接收人的组织或区域绑定，同时在权限层限定可见数据范围。仅调整参数不够，权限层也需要同步控制，否则仍可能从其他入口看到更宽的数据。

8. 怎么判断是任务没执行还是执行失败？

查看任务执行记录即可区分。记录中会体现任务是否被触发、执行的时间与结果。如果完全没有执行记录，说明任务未触发，需要检查任务状态、周期配置与是否被暂停；如果有记录但结果失败，则需要查看失败环节，判断属于渠道、名单还是交付条件的问题。

9. 接收人名单要不要定期核对？

建议定期核对，尤其在组织调整之后。人员调动、岗位替换、新设部门都会让原有名单与实际需求脱节，问题通常表现为「有些人一直没有收到」，而不是一次性集中暴露。把名单核对纳入常规运营动作，能在影响扩大前发现偏差，维护成本也远低于事后逐个确认。

10. 定期送达的效果怎么评估？

可以从三方面看：任务实际执行的成功比例；接收人是否按周期查看并据此行动；故障出现后从发现到恢复所需的时间。同时记录每次故障的原因分类，观察是否集中在同一环节。如果同一类原因反复出现，说明需要修正配置或建立核对机制，而不只是依赖补发。