Clouisle云屿

通知渠道配置

按选择渠道、填写参数、测试发送和上线治理的顺序建立稳定的通知出口。

功能概述

通知渠道配置决定平台里的通知到底从哪里发出去。
如果通知规则已经定义好,但渠道没有配置或配置不稳定,最终用户仍然收不到任何提醒。

适用场景

适合下面几类需求:

  • 第一次接入邮件、Webhook 或企业 IM 通知
  • 把平台事件发给运维、审批人或业务群组
  • 排查通知为什么没有成功送达

前置条件

开始前建议准备:

  • 渠道所需的账号、SMTP 信息、Webhook URL 或 Bot Token
  • 一个测试接收对象,例如测试邮箱或测试群
  • 一条可重复触发的测试事件

操作步骤

第 1 步:进入站点设置,确认通知入口

先进入后台的 站点设置 页面,确认平台通知和邮件配置入口是否已经可见。
这里通常会集中放置平台级通知能力。

站点设置页

这一步的重点是先确定通知属于全局配置,而不是每个团队单独随意维护。

第 2 步:先选择一个主渠道

第一次配置时,不建议同时接多个渠道。
推荐先从最容易验证的一种开始,例如:

  • 邮件
  • Webhook

先跑通一条主链路,再考虑补充 Slack、飞书、钉钉或企业微信。

第 3 步:填写渠道参数并保存

不同渠道通常需要填写:

  • SMTP 主机、端口和发件人
  • Webhook URL
  • Bot Token、签名或额外请求头

填写时建议同步记录:

  • 这个渠道给谁用
  • 用于哪些事件
  • 后续由谁维护

通知渠道配置区块

第 4 步:执行测试发送

保存后不要直接上线。
先使用测试对象验证:

  • 是否能成功送达
  • 内容格式是否可读
  • 鉴权、签名和网络策略是否正常

如果平台里有通知中心,也可以同步查看测试通知是否成功进入通知链路。

通知中心

第 5 步:把渠道绑定到真实事件前,先定义使用规则

测试通过后,再明确:

  • 哪些事件走这个渠道
  • 哪些事件只在站内通知
  • 哪些事件需要备用渠道

这样可以避免一上线就通知泛滥,或者关键告警没有兜底。

结果验证

通知渠道配置完成后,至少应满足:

  • 测试消息可以成功送达
  • 失败时可以看到明确错误信息
  • 通知中心或发送状态中能看到链路结果

常见问题

为什么保存成功了,但实际没有收到通知

优先检查:

  • 接收地址或群配置是否正确
  • Webhook、SMTP 或签名参数是否完整
  • 是否真的触发了对应事件

为什么第一次建议只接一个主渠道

因为一次接太多渠道后,问题会同时混入网络、签名、接收方限制和通知规则,很难快速定位。

为什么测试发送不能省略

通知是跨系统链路。
只要不做测试发送,你就无法确认平台之外的那一段链路到底是不是通的。

注意事项

  • 所有渠道都要先做测试发送,再接真实事件
  • Webhook 和企业 IM 渠道尤其要关注签名、超时和重试
  • 建议明确主渠道和备用渠道,避免关键通知只有单点出口

目录