技术人员如何发通知？

tips：文档会继续完善，也欢迎读者评论补充完善

前言

这里指的开发人员发给自己的通知，比如以下这些情形：

1. 定时任务的执行日志发送给开发查阅。
   比如定时给某些人发送通知的任务，可以把每次发送通知的人数发给开发，人数出现异常时，就可以及时感知并处理。
2. 离线任务巡检业务中的数据逻辑是否存在异常，巡检结果发送给开发查阅。
3. 关键业务执行过程中的各种异常，发送给开发

一、最重要的原则-有效传达

1. 信息有效

发送的通知中，不要携带无用信息。
如果一个通知你根本都不会看，那就不要发。

2. 人能处理

人能处理的信息量是有限的，所以：

1. 单次通知的信息量不能超出人的处理能力。
   比如把任务执行过程中的所有异常都发给开发人员，这么多的异常，开发人员能看的过来、能处理嘛？如果不能，那么这些信息中不能处理的那部分就是无效信息。
2. 通知频率不能过高
   这是大公司邮件通知的通病了。什么都喜欢发邮件，一打开邮箱就是几百封邮件，全处理完，今天也不用干别的了，所以只能选择无视。

3. 确认送达

确保通知发送之后，相关用户会接收并查阅。
比如某些公司，喜欢不加节制的发邮件，每个人每天打开邮箱都是几百上千的邮件，大家渐渐都不咋看邮件了。那么如果通知采用邮件发送，实际上和没法也没区别了。

二、通知内容要素

1. 时间

• 通知中的每条记录，需要添加时间前缀
  这样在自己对于通知中的内容存在疑问时，可以精确定位到具体发生的时间，并在哪个时间段附近查询相关日志、监控等进行排查。
• 业务逻辑执行时间
  对于完整业务逻辑的监控通知，比如定时任务、接口执行情况等，需要知道整个完整逻辑执行完需要的时间，以及内部各个子逻辑模块的执行时间（比如第三方接口调用占用多少时间）。

2. 宏观指标统计与具体信息采样结合

宏观指标的统计是为了对任务整体执行情况有一个把控。
具体信息采样，则是在我们想要验证排查时，无法针对全部日志记录做处理，但是也不能不管不问，因此做一个采样，对采样的记录进行验证排查即可。

三、其他注意点

1. 给自己也要发一份，确认通知逻辑在执行

无论是发任何通知，无论执行成功还是失败，最好是要给自己也发一份，主要目的是为了确认通知逻辑在正常运行，以及通知内容正确无误。
如果发送通知频率很高，可以在给自己发通知的逻辑上，加个频率限制。

四、最佳实践

1. 定时任务：给100w用户发送私信

通知范本：

[2021-12-10 01:54:56] 定时任务-私信通知发送-开始
总计需要发送的用户数量：1,000,000
    成功：50，000
    失败：50，000
发送陈成功的用户Id采样：[1,2,3,4,5]
异常采样：["用户(6)无效", "用户(7)不能接收私信", "私信接口调用异常：null"]
[2021-12-10 01:54:56] 结束

要素解析：

1. 开始和结束时间
2. 宏观的指标统计：我们最关心的结论
3. 数据采样：
   1. 发送成功采样：我们可以走流程验证下这个用户是否有真的发送成功，来检验逻辑正确性。
   2. 发送失败异常采样：看这个采样信息，去针对修复具体的异常
4. 大数字格式化，更易读
   宏观指标数据，采用三位分隔的格式化方法，便于更快查看具体具体数值数量级。如果是十亿以上的指标，初次看上去的时候，数多少个0就是个麻烦事，还得担心数错了。